Series · 7 parts Published May 13, 2026

FAQ builder

A serverless builder that turns the questions customers actually ask into a self-updating FAQ. It reads your support email and chat, groups the repeat questions, drafts a clear answer from your own help docs that cites its source, and proposes new or updated FAQ entries for a human to approve before anything publishes. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

  1. 01

    A self-updating FAQ builder on AWS for a few dollars a month

    The whole system on one page — a question intake, a grouper, and a drafter, plus the human review that gates every entry before it publishes.

  2. 02

    How the question pile gets built

    Three lanes feed the pile — an inbox-forwarding lane for support email, a chat-export lane that picks up transcripts, and a manual lane where a rep drops in a question worth answering once and for all.

  3. 03

    How repeat questions get grouped

    A daily pass embeds each new question, compares it against the question vectors, and groups the near-duplicates into clusters. Clusters that cross a repeat threshold become candidates for a FAQ entry. Plain Python over the vectors.

  4. 04

    How the FAQ answer gets drafted

    For a candidate cluster, the drafter pulls the matching passages from your help docs, asks the model for a short answer grounded in those passages, and makes it cite a source. If nothing grounds the answer, it says so instead of guessing.

  5. 05

    How a FAQ entry gets approved

    Three actions on each proposal: approve (publish to the live FAQ doc), edit (fix the wording, then publish your version), and reject (drop it with a note). Every action is logged, and nothing reaches the live FAQ without a human tap.

  6. 06

    What the FAQ builder costs

    A few dollars a month at SMB volume. The system embeds each question, groups once a day, and only drafts an answer for the handful of clusters that earn one.

  7. 07

    Engineering reference: the FAQ builder architecture

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

What is a FAQ builder?
A small serverless system that reads the questions customers actually ask in your support email and chat, groups the ones that keep repeating, drafts a clear answer from your own help docs that cites its source, and proposes a new or updated FAQ entry for a human to approve. Nothing publishes until a person taps approve.
How much does it cost to run?
About $3/month at typical small-business volume (around 800 support messages a month). The fixed cost is essentially zero. The variable cost is dominated by the embeddings made for each incoming question and the once-a-day grouping pass; the drafting model fires only on a handful of clusters per week, so it stays small. At heavier volume the bill lands around $12.
Which AWS services does it use?
Lambda (Python 3.14, arm64) with Function URLs for the approve button, EventBridge Scheduler for the daily grouping pass, DynamoDB on-demand, S3 (with versioning), S3 Vectors for the question and help-doc vectors, SES inbound, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Titan Text Embeddings V2 for vectors, Claude Haiku 4.5 to draft answers) via Global cross-Region inference. No API Gateway, no NAT Gateway, no always-on compute.
Where does the FAQ live?
In a Google Doc in a Drive folder you control. Each approved entry is one short section with a question, an answer, and a link to the help-doc source it was grounded in. A small drive-sync Lambda mirrors the published FAQ and your help docs to S3 every 15 minutes; the builder reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does the builder use AI?
Where it earns its place. Titan Text Embeddings V2 turns each question into a vector so the grouping pass can find repeats. Claude Haiku 4.5 drafts the answer for a cluster, grounded in your help docs, and is told to cite a source and never invent a fact. The grouping itself is plain Python over the vectors. Most of the system is deterministic by design, and a person approves every entry.
How does it avoid publishing a wrong answer?
Two ways. First, the draft is grounded: the model only answers from passages pulled out of your own help docs, and it must cite the source passage for each claim. If it can’t find a grounded answer, it says so and flags the cluster for a human to write one. Second, nothing publishes on its own. Every proposed entry lands in a review queue where a person can approve, edit, or reject it before it reaches the live FAQ doc.
What happens when I approve an entry?
Three buttons on every proposal: Approve writes the entry to the live FAQ doc via the Docs API and marks the cluster published. Edit opens the draft in a fillable box so you can fix the wording, then publishes your version. Reject drops the proposal and notes why. Every action is recorded in the fb-audit DynamoDB table with timestamp, cluster, action, by-user, and a before-and-after snapshot, so changes are reversible and the trail is auditable for years.
All posts