What is a review request sender?

It is a small serverless system that watches for jobs and orders being marked complete. When the completion webhook fires, the system records the job and schedules exactly one review request for a sensible moment — a day or so later, inside opening hours. Just before it sends, it reads whatever signal the customer has left (a star rating, a reply, past sentiment) and grades it. Happy customers get a warm, personalised ask with a direct review link; anyone who looks unhappy is diverted to a private feedback form instead. A finished job stops being a missed chance for a review, and a bad day never becomes a public one-star.

How much does it cost to run?

About $1.90/month at a typical small-business volume of roughly 150 completed jobs a month. There is no always-on compute, so the bill is almost entirely usage-priced — two small Bedrock calls per job (one to grade the signal, one to write the ask) and the messages themselves are the main lines, and the only real fixed cost is Secrets Manager for the platform keys. At ten times the volume (around 1,500 completed jobs a month) the bill lands near $12, because the fixed lines don’t move.

Which AWS services does it use?

Lambda (Python 3.14, arm64) behind a single Function URL for the completion webhook, DynamoDB on-demand for jobs and requests, EventBridge Scheduler for the per-request timed send, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the platform keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to grade the sentiment signal and compose each ask. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.

When does the ask go out?

Not the instant a job finishes — that reads as grabby. When the completion webhook arrives, the system schedules the ask for a sensible delay (a day or so, configurable per business) and snaps it into opening hours, so nobody gets a review request at 2am. At the scheduled moment it re-checks that the customer hasn’t opted out and hasn’t already been asked, reads the signal, and sends — a warm ask to happy customers, a private feedback link to unhappy ones. The timing is deterministic; the model is never asked when to send.

Only to grade and to phrase — never to decide. Bedrock’s Claude Haiku 4.5 fires twice per job: once to grade the sentiment signal into a simple happy / unhappy / unclear band, and once to compose the personalised ask in the business’s voice. Whether to send, when to send, who gets the public review link versus the private feedback form, and the once-only and opt-out rules are all deterministic Python. The model reads a signal and writes words; it never chooses to send, and it never sees a link to mangle.

How does it protect the public rating?

By never asking an unhappy customer for a public review. Before any ask goes out, the sentiment gate grades whatever signal exists — a low star rating, a terse reply, a run of past complaints. A happy signal gets the warm ask with a direct review link; an unhappy one is diverted to a private feedback form that goes straight to the owner, and a genuine complaint is escalated to a person to put right. The public star rating only ever gets pointed at customers who already seem glad — the unhappy ones are caught in private first.

Series · 7 parts Published July 3, 2026

Review request sender

A job finishes and the moment to ask for a review opens and closes fast — ask too soon and it feels grabby, ask too late and the customer has moved on, ask the wrong person and a bad day turns into a public one-star. This is the design of a small serverless system that turns a completed job into one well-timed, personal review request: when an order or job is marked done it schedules a single ask for the right moment — a sensible delay, inside opening hours — then, just before sending, it reads whatever signal exists (a rating, a reply, past sentiment) and splits the road. Happy customers get a warm, personalised note with a direct review link; anyone who looks unhappy is quietly routed to a private feedback form instead, so a poor experience is caught in private rather than aired in public. It asks each customer once, honours opt-out and quiet hours, and never nags. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A review request sender on AWS for a few dollars a month

The whole system on one page — the completion webhook, a scheduled one-per-job ask, a sentiment gate that splits happy from unhappy, a personalised review link for the glad and a private feedback form for the rest, plus the guardrail that it asks each customer once and never nags.
02

How a completed job triggers a request

How a finished job becomes a scheduled ask — the completion webhook, signature checks, the one-request-per-job guard, the opt-out list, and capturing whatever signal the customer already left before anything is scheduled.
03

How the ask gets timed

How the ask gets timed — a per-request one-off EventBridge Scheduler schedule set to a sensible delay, snapped inside opening hours, re-checked at fire time for opt-out and once-only, and rescheduled rather than sent if the moment has drifted into quiet hours.
04

How the review ask gets written

How the review ask gets written — the single Bedrock call handed only the facts it may use, a review-link token injected by code, the one-message rule, and why the model writes the words but never decides whether, when, or to whom to send.
05

How unhappy customers get filtered

How unhappy customers get filtered — the sentiment gate that grades whatever signal exists, sends the glad to a public review link and the unhappy to a private feedback form, and escalates a real complaint to a person — so a bad experience is caught in private, never aired as a one-star.
06

What the review request sender costs

A line-by-line monthly cost at about $1.90 for roughly 150 completed jobs, where the money actually goes (two small Bedrock calls per job and the messages), and what the bill looks like at ten times the volume.
07

Engineering reference: the review request sender architecture

The same system drawn for engineers — the Lambda inventory, the completion Function URL, the per-request EventBridge schedules, DynamoDB tables and key schema, the two Bedrock calls, SES and SNS, IAM scope, and the region.

What is a review request sender?: It is a small serverless system that watches for jobs and orders being marked complete. When the completion webhook fires, the system records the job and schedules exactly one review request for a sensible moment — a day or so later, inside opening hours. Just before it sends, it reads whatever signal the customer has left (a star rating, a reply, past sentiment) and grades it. Happy customers get a warm, personalised ask with a direct review link; anyone who looks unhappy is diverted to a private feedback form instead. A finished job stops being a missed chance for a review, and a bad day never becomes a public one-star.
How much does it cost to run?: About $1.90/month at a typical small-business volume of roughly 150 completed jobs a month. There is no always-on compute, so the bill is almost entirely usage-priced — two small Bedrock calls per job (one to grade the signal, one to write the ask) and the messages themselves are the main lines, and the only real fixed cost is Secrets Manager for the platform keys. At ten times the volume (around 1,500 completed jobs a month) the bill lands near $12, because the fixed lines don’t move.
Which AWS services does it use?: Lambda (Python 3.14, arm64) behind a single Function URL for the completion webhook, DynamoDB on-demand for jobs and requests, EventBridge Scheduler for the per-request timed send, SES for email and SNS for SMS, SQS with a dead-letter queue, Secrets Manager for the platform keys, CloudWatch Logs with 7-day retention, AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) to grade the sentiment signal and compose each ask. No API Gateway, no NAT Gateway, no always-on compute. One region, eu-west-2.
When does the ask go out?: Not the instant a job finishes — that reads as grabby. When the completion webhook arrives, the system schedules the ask for a sensible delay (a day or so, configurable per business) and snaps it into opening hours, so nobody gets a review request at 2am. At the scheduled moment it re-checks that the customer hasn’t opted out and hasn’t already been asked, reads the signal, and sends — a warm ask to happy customers, a private feedback link to unhappy ones. The timing is deterministic; the model is never asked when to send.
Does it use AI?: Only to grade and to phrase — never to decide. Bedrock’s Claude Haiku 4.5 fires twice per job: once to grade the sentiment signal into a simple happy / unhappy / unclear band, and once to compose the personalised ask in the business’s voice. Whether to send, when to send, who gets the public review link versus the private feedback form, and the once-only and opt-out rules are all deterministic Python. The model reads a signal and writes words; it never chooses to send, and it never sees a link to mangle.
How does it protect the public rating?: By never asking an unhappy customer for a public review. Before any ask goes out, the sentiment gate grades whatever signal exists — a low star rating, a terse reply, a run of past complaints. A happy signal gets the warm ask with a direct review link; an unhappy one is diverted to a private feedback form that goes straight to the owner, and a genuine complaint is escalated to a person to put right. The public star rating only ever gets pointed at customers who already seem glad — the unhappy ones are caught in private first.

All posts

Frequently asked questions

Other series