Product · 5 min read
Smart Replies: How a Generated Reply Gets Tied to a Source
The impressive thing about a language model is that it always has an answer. That is also the problem, and it is the entire reason this feature is built the way it is.
Someone asks whether you deliver to Siliguri. You have never written that down anywhere. A model with no constraints will produce a confident, well-punctuated sentence about your delivery to Siliguri, in your register, with your habits of phrasing, and there is a decent chance it is wrong. Your customer will read it as a commitment, because it arrived from your account and sounded exactly like you.
Grounding is the rule that stops that. A generated reply must be traceable to something you supplied. If it cannot be, it does not get written.
Two separate problems that people merge
Worth splitting cleanly, because they have different failure modes and different fixes.
How a reply sounds is voice. That comes from replies you actually wrote, and what a voice profile records covers it properly. A voice profile has no opinion about your prices. It will write a wrong number in exactly your register.
What a reply says is grounding. It is the question of whether the content of the sentence came from somewhere real.
A tool that solves only the first produces replies that sound like you and are occasionally false, which is worse than a generic reply that is true. Sounding right is what makes a wrong answer believable.
What a reply is allowed to draw on
The context assembled for any given reply is narrower than people expect, and the narrowness is deliberate.
- The message itself. The comment or DM text, as written, including how the person actually phrased it.
- The post it is attached to. Which piece of content the person was looking at when they asked. "Is this available" means different things under two different Reels.
- The automation that matched. Its keywords and, crucially, the replies you typed into it. Your own template is a source, not just a fallback.
- What has already been said in this thread, inside the window. Someone who asked about size and then asks "and price?" is asking about that item.
- The answers you wrote down. The material you supplied about how you actually operate — delivery, returns, what is in stock, what you do not do.
That is the list. Not on it: your stock system, your calendar, anything that happened on the phone, anything a colleague knows, and anything true about your business that you have never written anywhere.
What happens when there is nothing to ground on
This is the behaviour worth judging the feature by.
The reply is not written. Instead, one of three things happens, in this order of preference.
Your template goes out. If the automation has a written reply, that is what gets sent. It is general rather than specific, and it is true, which is the correct trade. The same thing happens if the model is slow, or unsure, or out of credits — credits is the ninth of ten pre-send checks and running dry lowers reply quality rather than stopping the automation.
It goes to the review queue. Where a draft exists but confidence is low, a person sees it before the customer does. You edit and send, or you delete it.
Nothing is sent, and Activity records why. content_safety is the last check in the fixed sequence, and a reply stopped there leaves a row with a reason on it rather than a silence.
Silence is a bad customer experience. A confident wrong answer is a refund, a review, and a conversation you have to have.
Why "guess" is not a setting
People ask for it, in different words. Can it be a bit more willing. Can it fill in the gaps. Can it be less cautious about the ones it is unsure of.
It cannot, and not because of a missing toggle. The refusal is what makes the rest safe to switch on. The moment a generated reply is allowed to invent one fact, every generated reply becomes something you have to read before you trust it, which is the job you were trying to hand over.
What you can change is the direction of the refusal: whether an ungrounded question falls back to your template, waits in the queue, or sends nothing. All three are honest. None of them make something up.
Fewer refusals is a content problem, not a settings problem
If the queue is full and templates keep going out where a real answer would have been better, the fix is upstream.
Write the awkward answers down. Refunds, delivery times outside your main cities, what you do when something arrives damaged, the thing you do not sell that people keep asking for. These are the questions the tail is made of, and they are the ones nobody puts in the source material because they are unpleasant to write.
Keep numbers in one place. Prices and delivery windows change. If they exist once, updating is one edit; if they are scattered through six templates, one of them will be stale in a month and it will be the one that sends.
Answer in the register you would use. If half your DMs are Hinglish, the written answers should include Hinglish. "Haan ji, COD available hai" and "Yes, cash on delivery is available" are the same fact for two different customers, and only one of them sounds like you.
Read Activity weekly, filtered to refusals. That list is a to-do list. Each refused question is either something you should write down or something a template should have caught.
Every reply the model writes costs one credit and templated sends cost nothing, so the direction all of this pushes you in is also the cheaper one — what our free plan covers sets that arithmetic out. And if you would rather feed it a body of your own writing before switching anything on, training it on your replies is the place to start.
