What is an order status responder?

A small serverless system that answers the question every shop hears all day — where’s my order? A message arrives by email, SMS, or web chat; the responder matches it to the right order (by the order number in the message, or by the sender’s email or phone), queries the carrier’s live tracking, and writes one friendly reply with an honest ETA. It never invents a status, and anything it can’t match or any order that looks delayed or lost goes to a human with the full context.

How much does it cost to run?

About $2.80/month at typical small-business volume — roughly 500 enquiries a month. The fixed cost is essentially zero because nothing runs when no one is asking. The variable cost is dominated by one small Bedrock Haiku 4.5 call per reply; the matching and the carrier lookup are cheap. At ten times the volume (around 5,000 enquiries a month) the bill lands near $20.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the SMS and web-chat webhooks, EventBridge Scheduler for the Drive mirror and the daily stuck-order sweep, DynamoDB on-demand, S3, SES inbound and outbound for email, SQS with a dead-letter queue, Secrets Manager for the carrier and SMS-provider keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to write each reply. No API Gateway, no NAT Gateway, no always-on compute.

How does it match a message to the right order?

First it looks for an order number in the message body or subject — the cleanest signal. If there isn’t one, it matches on the sender: the from email for email and web chat, or the phone number for SMS, against the orders mirrored from your Drive sheet. A confident single hit goes straight to the tracking lookup. Ambiguous matches (several open orders for one customer) and no match at all are escalated to a person rather than guessed.

Only to write the words. Bedrock Haiku 4.5 fires once per enquiry, and it is handed the real, already-fetched tracking facts — carrier, last scan, location, and the ETA — with strict instructions to use only those. The matching is plain Python and the carrier lookup is a real API call; the model never decides a status and never invents a tracking event. If the facts aren’t there, there is nothing for it to dress up — the order is escalated instead.

Can it give a wrong status or act on its own?

No. It only ever sends a status reply, and only when it has a confident order match and a real carrier response to ground it. It cannot refund, cancel, reship, or change an order. Anything it can’t match, anything a customer is upset about, and any order the carrier shows as delayed, lost, or stuck is escalated to a person with the message, the matched order, and the raw tracking attached — a human decides what happens next.

Series · 7 parts Published June 20, 2026

Order status responder

Customers ask “where’s my order?” by email, SMS, and web chat, and the answer is always the same boring lookup — find their order, check the carrier, tell them when it’s coming. This is the design of a small serverless responder that matches each message to the right order, pulls the carrier’s live tracking, and writes one friendly, accurate reply with a real ETA. It never invents a tracking status, and anything it can’t match — or any order that’s delayed, lost, or stuck — is handed to a person with the full context. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

An order status responder on AWS for a few dollars a month

The whole system on one page — three inbound channels, a matcher, a live-tracking lookup, a reply writer, and an escalation lane, plus the guardrail that it never invents a status.
02

How a “where’s my order?” message gets matched

How an inbound message becomes a confident order match — order number first, then sender email or phone — and why ambiguous and no-match cases are escalated rather than guessed.
03

How live tracking gets pulled

How the responder turns a matched order into live carrier tracking — the carrier API call, the normalised status, the cached result, and what it does when the carrier is silent.
04

How a status reply gets written

How one short, accurate reply gets written — the Bedrock call that is handed only the real tracking facts, the one-reply rule, and why the model can never invent a status.
05

How a stuck order gets escalated

How the ones that shouldn’t get an automatic reply reach a human — unmatched messages, upset customers, and orders the carrier shows as delayed, lost, or stuck — each with full context.
06

What the order status responder costs

A line-by-line monthly cost at about $2.80 for roughly 500 enquiries, where the money actually goes, and what the bill looks like at ten times the volume.
07

Engineering reference: the order status responder architecture

The same system drawn for engineers — Lambda inventory, EventBridge schedules, DynamoDB tables and keys, S3 buckets, SES rules, IAM scope, the Bedrock model id, and the region.

What is an order status responder?: A small serverless system that answers the question every shop hears all day — where’s my order? A message arrives by email, SMS, or web chat; the responder matches it to the right order (by the order number in the message, or by the sender’s email or phone), queries the carrier’s live tracking, and writes one friendly reply with an honest ETA. It never invents a status, and anything it can’t match or any order that looks delayed or lost goes to a human with the full context.
How much does it cost to run?: About $2.80/month at typical small-business volume — roughly 500 enquiries a month. The fixed cost is essentially zero because nothing runs when no one is asking. The variable cost is dominated by one small Bedrock Haiku 4.5 call per reply; the matching and the carrier lookup are cheap. At ten times the volume (around 5,000 enquiries a month) the bill lands near $20.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the SMS and web-chat webhooks, EventBridge Scheduler for the Drive mirror and the daily stuck-order sweep, DynamoDB on-demand, S3, SES inbound and outbound for email, SQS with a dead-letter queue, Secrets Manager for the carrier and SMS-provider keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to write each reply. No API Gateway, no NAT Gateway, no always-on compute.
How does it match a message to the right order?: First it looks for an order number in the message body or subject — the cleanest signal. If there isn’t one, it matches on the sender: the from email for email and web chat, or the phone number for SMS, against the orders mirrored from your Drive sheet. A confident single hit goes straight to the tracking lookup. Ambiguous matches (several open orders for one customer) and no match at all are escalated to a person rather than guessed.
Does it use AI?: Only to write the words. Bedrock Haiku 4.5 fires once per enquiry, and it is handed the real, already-fetched tracking facts — carrier, last scan, location, and the ETA — with strict instructions to use only those. The matching is plain Python and the carrier lookup is a real API call; the model never decides a status and never invents a tracking event. If the facts aren’t there, there is nothing for it to dress up — the order is escalated instead.
Can it give a wrong status or act on its own?: No. It only ever sends a status reply, and only when it has a confident order match and a real carrier response to ground it. It cannot refund, cancel, reship, or change an order. Anything it can’t match, anything a customer is upset about, and any order the carrier shows as delayed, lost, or stuck is escalated to a person with the message, the matched order, and the raw tracking attached — a human decides what happens next.

All posts

Frequently asked questions

Other series