build.allanninal.dev

Part 5 of 7 · Review responder series ~5 min read

How a reply stays in your voice

A generic AI reply to a review is recognisable in the first sentence — the cadence, the “we appreciate your feedback,” the careful avoidance of any fact about the actual business. The composer here reads three short Drive docs that describe how you sound, what you can promise, and what you must never say, and writes from those only. Four guardrails sit between the model and the post button.

Key takeaways

  • Three Drive docs ground every reply: a voice file (tone, openers, signature), a policies file (refund window, hours, staff roster), and a never-say file (banned phrases, comparative claims, legal/medical language).
  • The composer pulls only from those three docs — it never invents a refund window, a phone number, or a staff name not on the roster.
  • Four guardrails sit between the model and the post button: citation required, no personal-info echo, no fabricated specifics, no off-policy promises.
  • Edit a Drive doc and the system picks up the change on the next refresh. No deploy, no code change.
  • Any guardrail failure on an auto-reply demotes it to a draft — the human sees why on the package.

The composer and its guardrails

Three inputs, one composer, four guardrails, one reply A horizontal flow with three input boxes on the left, a composer in the middle, four guardrail boxes on the right, and a reply output. The three inputs, stacked top to bottom on the left: the structured review with score, themes, specifics, and confidences; the voice file from Drive describing tone, opener templates, signature, and length; the policies file from Drive listing what you can promise — refund window, replacement policy, contact phone, hours, and the staff roster. Three arrows feed into the composer in the middle, which is a single box labelled "Composer" with sub-steps: pick an opener template that matches the score and sentiment, address the named themes one at a time, ground every claim in the policies file, sign off in your voice. From the composer, an arrow leads right into a vertical strip of four guardrail gates. Gate one, "Citation": every factual claim must trace to a passage in the policies file or it cannot appear in the reply. Gate two, "No personal info echo": order numbers, emails, phone numbers, addresses the reviewer mentioned are never repeated in a public reply. Gate three, "No fabricated specifics": staff names not in the roster, menu items not in the menu file, and dollar figures not in the policies file are stripped. Gate four, "No off-policy promises": anything that commits beyond what the policies file allows is replaced with a deferral to a human contact. Past the four gates, an output arrow on the far right reads "to dispatch". A note at the bottom reads: any guardrail failure on a draft is shown on the package so you can see why; any guardrail failure on an auto-reply demotes it to a draft instead. Structured review score, themes, specifics (from extractors) Voice file tone · openers signature · length Policies file refund window, hours, contact phone, staff roster Composer • Pick an opener that matches score & tone • Address each named theme in one line • Ground every claim in the policies file • Sign off in your voice Gate 1 · Citation every claim traces to a policies-file passage Gate 2 · No personal info no order numbers, emails, phones in a public reply Gate 3 · No fabrication staff/menu/dollar figures must come from a file Gate 4 · No off-policy promises beyond the file defer to a human contact → to dispatch A guardrail failure on a draft is shown on the package; on an auto-reply, the move is demoted to a draft.
Fig 5. Three Drive files ground the composer; four guardrails sit between it and the post button. Anything that fails a gate is either shown on the draft or demoted out of the auto-reply lane.

The voice file: how you sound

The voice file is one short Google Doc, ideally a single page. It captures three things about how the business writes. Tone — warm and brief, or formal and detailed, or playful and short, or whatever fits. A few example openers for each rating band (a five-star opener is not a one-star opener), so the composer has a template to start from rather than inventing one. And a signature line if there is one (“— the team at Such-and-Such” works for some businesses; for others, the owner’s first name).

The voice file does not contain facts about the business. It contains how, not what. The clean separation matters because tone changes rarely — you write it once and edit twice a year — while the policies-and-facts file changes regularly as hours, prices, and offers shift.

The policies file: what you can promise

The policies file is the fact base. It lists the things the responder is allowed to say to a customer in a reply: refund window (“up to 14 days from purchase”), replacement policy (“a return-visit credit equal to the order value if you let us know within a week”), contact information (the phone number and email a complaint can be redirected to), opening hours, and the current staff roster (first names of people who work there, so a review that names a current employee can be flagged correctly).

If the customer is asking for something that isn’t covered in the policies file, the responder cannot promise it on the business’s behalf. It will defer to a human (“please reach out to <phone-from-policies-file> so we can look into this with you”) instead of making up a refund window or compensation. The whole point of the file is to make “what we offer” a thing the system reads, not a thing the model invents.

The four guardrails between model and post button

The composer’s output goes through four gates. Each is small and deliberate.

Citation. Every factual claim in the reply must trace to a passage in the policies file. “We’re glad you enjoyed the soup” doesn’t need a citation; “We offer a 14-day refund window” does. The composer attaches the policy passage it leaned on; the runtime checks that the passage actually exists in the current policies file. If a claim has no citation, that claim cannot appear in the reply. (This is the same shape as the chat assistant’s citation rule from the previous series — same logic, different fact base.)

No personal info echo. If the reviewer wrote “order number 81234” or their email or phone number into the public review, the reply doesn’t repeat it. The reviewer might be comfortable putting their order number in a review they wrote at 11pm; the business should not be amplifying that to every future visitor of the listing. The gate strips out personal info — emails, phone numbers, addresses, order IDs — from the proposed reply before it’s sent.

No fabricated specifics. Staff names not in the roster, menu items not in the menu file (if you have one), dollar figures not in the policies file. The composer can refer to “your visit” or “the team that served you” without making up a name. If it tries to insert “Sarah” and Sarah isn’t on the roster, the gate replaces the specific with the generic phrasing.

No off-policy promises. Anything the reply commits the business to — a future refund, a special accommodation, an appointment, a free replacement, a callback — must trace to the policies file. If the customer is asking for something the policies file doesn’t allow, the reply pivots to deferral: “We’d like to look into this with you — please call <phone-from-file> or reply to this directly.” That’s a fine answer, and it’s the only honest one when the system genuinely can’t commit on the business’s behalf.

What “in your voice” actually means

The phrase gets used loosely, so it’s worth being specific. “In your voice” here means three concrete things.

First, the cadence and word choice come from the voice file. A business that uses contractions and short sentences does not suddenly start writing “We sincerely regret to inform you”; one that uses formal language doesn’t suddenly drop into “hey, sorry about that.”

Second, the facts come from the policies file. The reply doesn’t invent the business’s refund window or guess the manager’s name. If a fact isn’t in the file, it isn’t in the reply.

Third, the structure follows a small handful of templates the voice file provides. An opener that matches the rating, a sentence acknowledging the specific theme the customer raised, a sentence offering the appropriate next step (or a thank-you, on positive reviews), and a sign-off. That’s the shape; the words inside it are filled in by the model, grounded in the two files. The result reads like the same business wrote a hundred replies, because in the only sense that matters, it did.

What this hands to the next post

The composer hands a reply (and its citations) to dispatch, which posts it, packages it for your inbox, or escalates it — depending on the move the previous post described. The next post is the cost picture: where the dollars go, and why a typical small business runs this for coffee money.

All posts