A support agent promise checklist is a short register of every commitment an AI support agent is allowed to make to a customer, written in approved words, with the system that must honour it and the person who owns it. Anything not on the list, the agent does not promise. Copy the fields below and fill them the same day.
Why does a support agent need a promise list?
Customers act on what an agent tells them. If the agent says "your refund will arrive by Friday", the customer plans around Friday, and your complaints team inherits the gap when it does not. Whether that sentence binds you is a legal question, discussed in whether an AI agent's promise to a customer is legally binding. Whether it damages trust is not in doubt. The guide to the AI support agent that knows when to say no sets out why fewer, firmer promises serve customers better.
A promise list moves the decision upstream. Someone with authority decides, once, what the business is willing to commit to in writing, and the agent repeats only that. This is the practical form of the idea that you should judge a support agent by what it will not promise.
When do you use it?
Build the list before launch and treat it as a dependency of the support agent launch checklist. Review it whenever an operational process changes. If the refunds team moves from three-day to five-day processing, every promise that mentions refund timing is now wrong, and the agent will keep saying it until someone updates the list.
The list should also cover every channel where the agent works. A promise made in email lasts longer than one made in chat, because the customer keeps the email; the different channels of omnichannel support carry different weight.
How do you fill in each field?
Start from what the agent will be asked, not from what you would like it to say. Pull the top request types from your queue and ask, for each, "what does the customer want to hear, and what can we stand behind?"
- Exact wording matters. "Usually within five working days" and "within five working days" are different promises.
- Condition states when the promise may be made. A delivery-date promise might only be allowed once the order shows as dispatched.
- Source of truth names the system the agent must read before making it. No reading, no promise.
- Never-say pair records the tempting variant the agent must not use, so testers can look for it.
The support agent promise checklist
| Field | What to write |
|---|---|
| Promise ID | Short reference, such as P-04 |
| Situation | The customer request that triggers it |
| Approved wording | The exact sentence the agent may use |
| Condition | What must be true before it is said |
| Source of truth | System and field the agent reads to confirm the condition |
| Who honours it | Team or process that delivers on the promise |
| Never-say variant | The stronger or vaguer version that is forbidden |
| Channels | Chat, email, messaging, voice |
| Owner | Named person who approved the wording |
| Last reviewed | Date of last check against the real process |
Keep a second short list of standing refusals: things the agent never commits to, such as compensation amounts, policy exceptions, or outcomes of a complaint.
A filled sample
A hypothetical online retailer's chat agent.
| ID | Situation | Approved wording | Condition | Source | Never-say variant |
|---|---|---|---|---|---|
| P-01 | Where is my refund? | "Your refund was issued on [date]. Banks usually show it within five working days." | Refund status is "issued" | Order system, refund status | "It will be in your account by [date]." |
| P-02 | Can I return this? | "You can return this item until [date]." | Item is in a returnable category | Product catalogue, returns flag | "Of course, no problem." |
| P-03 | Complaint | "A member of our team will reply within two working days." | Complaint case created | Case system, case ID | "We will sort this out for you." |
| P-04 | Late delivery | "I've passed this to our delivery team, who will contact you." | Escalation ticket raised | Ticketing system | "We'll refund your delivery charge." |
Standing refusals for this retailer: no discount codes, no compensation figures, no statements about the outcome of a complaint, no promises on behalf of a courier.
Note P-04. The tempting response gives away money. Customers in difficulty are the most likely to receive, and rely on, an improvised concession, so align this list with the vulnerable customer handling checklist.
Questions people ask
How many promises should the list hold?
Fewer than you expect. Most support agents need between ten and thirty. If the list grows past that, some entries are probably variations that could share one wording.
What happens when a customer asks for something not on the list?
The agent says what it can do, explains that it cannot commit to the rest, and routes the request to a person with the context. That refusal should be polite and specific, never a vague "I'm not able to help".
Who should approve promise wording?
The owner of the process that has to deliver on it, with a check from complaints or compliance. The support team drafts; the people who will be held to the promise sign it.