How to write a prompt for an agent that talks to customers
Not prompt engineering. Job description writing — scope, tone, refusals, and the three sentences that prevent most embarrassing transcripts.
Writing the prompt for an agent that talks to your customers is not prompt engineering. It is job description writing, and the people who are good at it are usually the ones who have trained a new hire, not the ones who have read about tokens.
A working prompt has five parts. Most bad ones have only the first.
1. The job, in one paragraph
Who it is, who it is talking to, and what a good conversation ends with.
You answer first-time enquiries for a dental clinic in Pune. Most people are asking about price, availability or whether we do a particular treatment. A good conversation ends with an appointment booked or a callback arranged.
Note what that does: it tells the model what to expect. An agent that knows the three common questions handles the fourth one better, not worse.
2. The scope, stated as a boundary
Models are relentlessly helpful. Left alone, they will attempt anything, which is how you end up with a transcript where your agent estimated a treatment cost it had no business estimating.
Answer only from the knowledge base and this prompt. If you do not know, say you do not know and offer a callback. Never estimate a price for anything not on the published list. Never give clinical advice, including whether something sounds urgent.
"Say you do not know" needs to be explicit. Without it, not knowing feels to the model like a failure to be worked around.
3. The refusals, named individually
Not a category — a list. Each one an actual sentence you would be unhappy to read in a transcript. Three to six is usually right; twenty and it starts refusing ordinary questions.
- Discounts or negotiating a price.
- Anything medical, legal or financial specific to this person.
- Complaints about a previous visit.
- Anything about an order it cannot look up.
For each, say what to do instead. A refusal with no alternative is a dead end, and the model will improvise one.
4. The tone, in examples not adjectives
"Be friendly and professional" means nothing — every model already thinks it is being both. Give it two lines of the register you want:
Keep replies under three sentences. Plain words. It is fine to say "I'll check" and "I'm not sure". Do not use exclamation marks or call anyone "valued".
Length is the highest-leverage instruction in the whole prompt. Unconstrained, models write paragraphs; on a phone call that is unbearable, and in chat it gets skimmed.
5. When to stop
The conditions that end its turn, named in advance. Not "escalate when appropriate" — appropriate is doing no work there.
- The customer asks for a person. Immediately, no persuading.
- They are upset. Do not defend, hand over.
- Two consecutive replies where it could not help.
- Anything on the refusal list.
Handover is worth its own thought.
What to leave out
- Facts that will change
- Prices, hours, staff names, the current offer. These belong in the knowledge base, where one person can update them without touching the agent's behaviour. Structuring that.
- A decision tree
- If you find yourself writing "if they say X, then ask Y", you are building an IVR with extra steps. Describe the goal and let it find the route.
- Threats
- "You MUST NEVER" in capitals does not work better than a clear sentence, and it makes the prompt harder for the next person to edit.
Testing it honestly
Everyone tests the happy path. Test these instead:
- The question you cannot answer. Does it say so, or invent?
- An angry opening line. Does it hand over, or argue?
- Something adjacent but out of scope. Does it hold the boundary?
- A caller who changes their mind halfway.
- Somebody being deliberately silly. Every public agent meets this in week one.
Then read fifty real transcripts before widening the scope. The prompt you write on day one is a hypothesis; the transcripts are the data. Where the prompt lives in Convarza.