How much does it cost to run?

About $1.80/month at typical small-business volume (around 300 asks a month). The fixed cost is essentially zero. The variable cost is dominated by sending the asks and reading the replies; Bedrock fires only on the short replies that need a mood read it can't get from a tap, plus the monthly summary, so those are small slivers. At around 3,000 asks a month the bill lands near $13.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the tap-and-reply endpoint, EventBridge Scheduler for the deferred asks and the daily sweep, 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) for reading free-text replies and the monthly summary. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where does the customer list live?

In a Google Sheet in a Drive folder you control. One row per completed visit or purchase with the customer name, contact, what they bought or booked, the date it happened, and the staff member who served them. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the system reads from S3 to keep Drive API calls predictable and to get S3 versioning for free. Your point-of-sale or booking tool can drop rows in via a webhook too.

Sparingly. The timing and the happy-or-unhappy split from a star tap use no AI — it's plain Python. Bedrock Haiku 4.5 fires only when a customer writes a few words instead of just tapping, so the system can read the mood of those words, and once a month for the owner summary. Most of the system is deterministic by design.

How does it ask without being annoying?

It waits for the right moment set in the rules doc — a sit-down meal might ask two hours later, a delivered product three days later. The ask goes out once. Quiet hours (default 8pm–9am local) and the holiday calendar are respected. If the customer doesn't reply, the system sends at most one gentle follow-up after a few days, then stops for good. A customer who already gave feedback this cycle is never asked again.

What happens to an unhappy reply?

It never gets nudged toward a public review. Instead the owner is pinged privately and immediately with the customer's name, what they bought, their words, and a one-tap way to call or message them back. The goal is to fix the problem while it's still a private conversation. Every reply and every routing decision is recorded in the fc-feedback DynamoDB table with timestamp, customer, score, and where it was routed, so the trail is auditable.

Series · 7 parts Published June 12, 2026

Feedback collector

A serverless system that asks every customer how it went, at the right moment after a visit or purchase, with one simple question. It collects the answer and routes by it: happy customers get a gentle nudge to leave a public review; unhappy ones go straight to the owner privately so the problem gets fixed before it becomes a bad review. Quiet hours respected; it asks once and never nags. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A feedback collector on AWS for a few dollars a month

The whole system on one page — a request builder, a router, and a dispatch piece, plus the simple happy-or-unhappy split that decides where every reply goes.
02

How a feedback request goes out

Three lanes feed the customer list — the Drive sheet itself, a point-of-sale webhook lane, and an hourly booking import — then a timing rule picks the right moment to send one simple ask.
03

How a feedback reply comes back

A one-tap star link hits a Function URL, or a short written reply comes back by email. The reply is recorded, the customer is marked as answered, and the same ask is never sent twice.
04

How feedback gets routed by mood

A star tap is read by plain Python; a few words of free text get a quick mood read from Bedrock. Either way each reply lands as happy, unhappy, or unclear — and that decides the next move.
05

How a review ask or a private fix happens

Happy gets a gentle, one-tap nudge to a public review link. Unhappy goes straight to the owner privately with the customer’s words and a way to reach back. Unclear waits for a human. Every move is logged.
06

What the feedback collector costs

A couple of dollars a month at SMB volume. The system sends a handful of asks, reads the taps with no model, and only fires Bedrock on free-text replies and the monthly summary.
07

Engineering reference: the feedback collector architecture

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

What is a feedback collector?: A small serverless system that asks every customer how it went, at the right moment after a visit or purchase, with one simple question. It collects the answer and routes by it: happy customers get a gentle nudge to leave a public review, while unhappy ones go straight to the owner privately so the problem gets fixed before it becomes a bad review. It respects quiet hours, asks once, and never nags.
How much does it cost to run?: About $1.80/month at typical small-business volume (around 300 asks a month). The fixed cost is essentially zero. The variable cost is dominated by sending the asks and reading the replies; Bedrock fires only on the short written replies that need a mood read it can’t get from a tap, plus the monthly summary, so those are small slivers. At around 3,000 asks a month the bill lands near $13.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the tap-and-reply endpoint, EventBridge Scheduler for the deferred asks and the daily sweep, 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) for reading free-text replies and the monthly summary. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where does the customer list live?: In a Google Sheet in a Drive folder. One row per completed visit or purchase with the customer name, contact, what they bought or booked, the date it happened, and the staff member who served them. A small drive-sync Lambda mirrors the sheet to S3 every 15 minutes; the system reads from S3 to keep Drive API calls predictable and to get S3 versioning for free. Your point-of-sale or booking tool can drop rows in via a webhook too.
Does it use AI?: Sparingly. The timing and the happy-or-unhappy split from a star tap use no AI — it’s plain Python. Bedrock Haiku 4.5 fires only when a customer writes a few words instead of just tapping, so the system can read the mood of those words, and once a month for the owner summary. Most of the system is deterministic by design.
How does it ask without being annoying?: It waits for the right moment set in the rules doc — a sit-down meal might ask two hours later, a delivered product three days later. The ask goes out once. Quiet hours (default 8pm–9am local) and the holiday calendar are respected. If the customer doesn’t reply, the system sends at most one gentle follow-up after a few days, then stops for good. A customer who already gave feedback this cycle is never asked again.
What happens to an unhappy reply?: It never gets nudged toward a public review. Instead the owner is pinged privately and immediately with the customer’s name, what they bought, their words, and a one-tap way to call or message them back. The goal is to fix the problem while it’s still a private conversation. Every reply and every routing decision is recorded in the fc-feedback DynamoDB table with timestamp, customer, score, and where it was routed, so the trail is auditable.

All posts

Frequently asked questions

Other series