A support agent launch checklist is the signed list of conditions an AI support agent must meet before it answers real customers. It records the agent's scope, its certified depth and the depth each capability needs, its refusal and escalation routes, the evidence from testing, and the named person who signs it off. Nothing goes live with a blank line.
What is a launch checklist for and when do you use it?
Use it once per agent, per channel, before the first live conversation, and again whenever the agent gains a new capability. A chat agent that already passed launch on web chat needs a fresh checklist before it goes on messaging apps, because the customers, the identity checks and the handoff routes differ.
The checklist is not a project plan. It is a gate. Each line is either evidenced or the launch waits. The wider case for gating support agents this way is in the guide to the AI support agent that knows when to say no.
How do you fill in each field?
Write every line as a fact someone else can check. "Escalation tested" is not enough; "40 sample handoffs reached the queue with full context" is.
- Scope lists the intents the agent may handle and, just as important, the ones it must pass on. Write both lists.
- Depth is certified for the agent, and each job needs its own. Answering a balance question might be depth 1; issuing a goodwill credit might be depth 4 within a limit; closing an account stays with a person.
- Promises are the commitments the agent may make in writing. Pull these from your support agent promise checklist rather than restating them.
- Test evidence should come from replaying past conversations from your own queue, not from scripted demos. The method is set out in how to test an AI support agent before launch.
- Vulnerability routes say what the agent does when a customer shows signs of distress, financial difficulty or confusion, and how fast a person picks it up.
The support agent launch checklist
| No. | Field | What to record | Signed by |
|---|---|---|---|
| 1 | Agent and channel | Agent name, version of its brief, channel(s) | Support lead |
| 2 | In-scope intents | Named list of request types it may handle | Support lead |
| 3 | Out-of-scope intents | Named list it must route to a person | Support lead |
| 4 | Depth | The agent's certified depth, and each capability with the depth it needs (1 to 4) | Risk owner |
| 5 | Customer limits | Money and action limits that apply on top of depth | Finance or risk |
| 6 | Approved promises | Commitments it may make, with wording | Complaints lead |
| 7 | Forbidden statements | Things it must never say or offer | Complaints lead |
| 8 | Identity checks | What it verifies before account-specific answers | Fraud lead |
| 9 | Escalation routes | Queue, hours, context passed, target pickup time | Operations lead |
| 10 | Vulnerability handling | Triggers and route to a trained person | Customer outcomes lead |
| 11 | AI disclosure | How customers are told they are talking to an AI | Compliance |
| 12 | Test evidence | Cases replayed, pass floor, failures and fixes | Quality lead |
| 13 | Monitoring | Daily review owner, sample size, alerts | Operations lead |
| 14 | Rollback | How to switch it off and where traffic goes | Operations lead |
| 15 | Final sign-off | Named accountable person and date | Accountable executive |
Fields 6 and 7 deserve the most attention. A support agent that can negotiate or improvise concessions creates commitments you never approved, which is why a support agent should not negotiate at all.
A filled example
A hypothetical energy retailer launching a chat agent for billing questions.
| No. | Field | Sample entry |
|---|---|---|
| 2 | In-scope intents | Explain a bill, meter reading submission, payment date questions, direct debit date change |
| 3 | Out-of-scope intents | Disputes over 200, debt and payment plans, complaints, home moves, any mention of a medical device |
| 4 | Depth | Explain bill: 1. Draft payment date change: 2. Record meter reading: 3. Credit or refund: none |
| 6 | Approved promises | "A person will reply within one working day." "Your reading has been recorded." |
| 7 | Forbidden statements | Any discount, any waiver, any statement that a debt is cleared |
| 9 | Escalation routes | Billing queue, 8am to 8pm, full transcript and account reference passed, pickup within 10 minutes in hours |
| 10 | Vulnerability handling | Words about medical equipment, bereavement or being unable to pay route to the priority team at once |
| 12 | Test evidence | 500 past chats replayed, 12 failures, all in payment-date wording, brief corrected and re-run clean |
| 14 | Rollback | Toggle in the chat platform returns all traffic to the human queue within one minute |
The out-of-scope list is longer than the in-scope one. That is normal for a first launch. Vulnerable customers in particular are better served by a person sooner, and the vulnerable customer handling checklist gives the detail for line 10.
Questions people ask
How long does a support agent launch take to sign off?
The checklist itself takes a day or two once the evidence exists. The time goes into replaying enough real cases to fill line 12 and fixing what fails. Plan for the test cycle, not the paperwork.
Should the launch checklist include cost?
Not as a gate, but record the expected cost per resolved conversation so you can compare it after launch. The drivers are set out in how much an AI customer support agent costs.
Can we launch with some lines marked "to follow"?
No. Any blank line means the agent is not ready for that part of the job. Narrow the scope until every remaining line is evidenced, then launch the narrower agent.