How much does it cost to run?

About $3/month at typical small-business volume (around 1,500 tickets a month). The fixed cost is essentially zero. The variable cost is dominated by one small Bedrock Haiku 4.5 call per ticket to read the topic, urgency, and tone; everything else — Lambda, DynamoDB, SQS, the routing rules — is pennies. At 6,000 tickets a month the bill lands around $11.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the web-form and correct-routing endpoints, SQS (with a dead-letter queue) to absorb bursts, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to read each ticket. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where do the routing rules live?

In a Google Sheet and a short doc in a Drive folder you control. The sheet maps each topic to a team or person; the doc covers the urgency words, the VIP customer list, and the priority rules. A small drive-sync Lambda mirrors them to S3 every 15 minutes; the router reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

Does the router answer customers?

No. The router only sorts and routes. It reads the ticket, picks a topic, judges the urgency and tone, tags the ticket, and hands it to the right team. It never writes a reply to the customer. A person always answers. This keeps the risky part — what the customer actually reads — fully in human hands.

What happens when it routes a ticket to the wrong place?

A misroute is cheap to fix. Whoever picks up the ticket sees the chosen topic and team, and a one-click Reassign button. They pick the right team; the ticket moves and the correction is recorded in the tr-corrections DynamoDB table with the original tag, the corrected tag, and who changed it. Those corrections feed back into the router's examples, so the same kind of mistake gets less likely over time.

How does it flag an angry or urgent ticket?

On each ticket the router judges three things: topic, urgency, and tone. A ticket that reads as angry, or that mentions an outage, a payment failure, or a deadline, or that comes from a VIP customer on the list, is flagged priority and jumps the queue — it lands at the top of the right team's list and pings the team lead. The rules for what counts as urgent live in the Drive doc, so a manager can tune them without a deploy.

Series · 7 parts Published June 1, 2026

Ticket router

A serverless router that reads each new support ticket, works out the topic and how urgent it is, tags it, and routes it to the right team or person — flagging anything angry or urgent to jump the queue. It only sorts and routes; it never answers the customer itself. A misroute is one click for a human to fix, and the router learns the correction. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A ticket router on AWS for a few dollars a month

The whole system on one page — a ticket intake, a router, and a hand-off piece, plus the four moves they share for every new ticket.
02

How a ticket gets read

Three lanes feed the queue — an email inbox, a web form on your site, and a chat lane — all land as one ticket. Then one small Bedrock Haiku 4.5 call reads the topic, the urgency, and the tone.
03

How a ticket gets routed

The router takes the topic, urgency, and tone, checks the rules doc and the VIP list, and picks one of four moves: route, priority, escalate, or hold. The decision logic is plain Python.
04

How a ticket reaches the right team

Team resolution per topic, a priority lane that jumps the queue, a Slack ping with full context, an email fallback, and the four guardrails between the chosen move and the ticket actually landing.
05

How a misroute gets corrected

Three actions on a routed ticket: reassign (move it and teach the router), bump priority (raise or drop the urgency), and split (one ticket, two topics). Every action is logged and feeds the examples.
06

What the ticket router costs

A few dollars a month at SMB volume. The cost is one small model call per ticket to read it; everything else is pennies. No always-on compute, no API Gateway.
07

Engineering reference: the ticket router architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the SES inbound rule set, the SQS queue config, and the DynamoDB schemas.

What is a ticket router?: A small serverless system that reads each new support ticket, works out the topic and how urgent it is, tags it, and routes it to the right team or person — flagging anything angry or urgent to jump the queue. It only sorts and routes; it never answers the customer itself. A human can correct a misroute in one click, and the router learns the correction.
How much does it cost to run?: About $3/month at typical small-business volume (around 1,500 tickets a month). The fixed cost is essentially zero. The variable cost is dominated by one small Bedrock Haiku 4.5 call per ticket to read the topic, urgency, and tone; everything else — Lambda, DynamoDB, SQS, the routing rules — is pennies. At 6,000 tickets a month the bill lands around $11.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the web-form and correct-routing endpoints, SQS (with a dead-letter queue) to absorb bursts, DynamoDB on-demand, S3 (with versioning), SES inbound + outbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to read each ticket. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where do the routing rules live?: In a Google Sheet and a short doc in a Drive folder. The sheet maps each topic to a team or person; the doc covers the urgency words, the VIP customer list, and the priority rules. A small drive-sync Lambda mirrors them to S3 every 15 minutes; the router reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does the router answer customers?: No. The router only sorts and routes. It reads the ticket, picks a topic, judges the urgency and tone, tags the ticket, and hands it to the right team. It never writes a reply to the customer. A person always answers. This keeps the risky part — what the customer actually reads — fully in human hands.
What happens when it routes a ticket to the wrong place?: A misroute is cheap to fix. Whoever picks up the ticket sees the chosen topic and team, and a one-click Reassign button. They pick the right team; the ticket moves and the correction is recorded in the tr-corrections DynamoDB table with the original tag, the corrected tag, and who changed it. Those corrections feed back into the router’s examples, so the same kind of mistake gets less likely over time.
How does it flag an angry or urgent ticket?: On each ticket the router judges three things: topic, urgency, and tone. A ticket that reads as angry, or that mentions an outage, a payment failure, or a deadline, or that comes from a VIP customer on the list, is flagged priority and jumps the queue — it lands at the top of the right team’s list and pings the team lead. The rules for what counts as urgent live in the Drive doc, so a manager can tune them without a deploy.

All posts

Frequently asked questions

Other series