Start customer support automation with requests that have an approved answer, accessible records and a clear route to a person when something goes wrong. A request's frequency matters, but frequency alone does not make it a good candidate for autonomous handling.
For a support leader choosing a first project, the decision is which work to assign and how much authority to grant. This guide proposes a selection and evaluation method. It does not assume that a chatbot should handle every conversation or that closing a session proves the customer's problem was resolved.
Separate answering a question from changing a customer record
Take a representative set of support conversations and describe the customer's intended outcome. A question about a returns policy, a request for an order update and a demand for an exception may arrive in the same channel while requiring very different access and authority.
For each intent, write down the approved source, the necessary identity check and whether fulfilling the request changes anything. An answer can quote a policy. A cancellation changes a record. A refund may involve further approvals and reconciliation. Do not let a shared conversational interface obscure those boundaries.
Use the following as a selection worksheet, with your own rules filled in:
| Request | What must be known | A candidate first treatment |
|---|---|---|
| Explain a published policy | Current approved wording and any relevant conditions | Answer with a source and an escalation route. |
| Find an order status | Verified access to the right customer's current record | Read-only lookup with a fallback for conflicting or unavailable records. |
| Change a booking | Identity, eligibility, available capacity and confirmation | A bounded action only after its failure and recovery paths are tested. |
| Make a policy exception | Who has authority and what evidence they need | Collect context and route to an authorized member of staff. |
These are possible treatments to assess, not rules that apply to every business. The process owner must decide what the assistant may do and which requests require a person.
Compare a rules-based flow, a copilot and a customer-facing assistant
A fixed menu can be adequate when the customer has a small set of known choices and the response comes directly from a business system. Test that simpler option first if it meets the need.
A staff copilot can draft an answer or assemble context while a service representative makes the decision. It is a candidate when policies require interpretation or the evidence is scattered. Evaluate whether checking the draft actually saves effort; a fluent response that needs extensive correction may create extra work.
A customer-facing assistant needs a defined response when it cannot help, as well as an approved path for the requests it can handle. Introduce actions individually. Permission to look up a delivery estimate should not imply permission to amend an address or cancel the order.
The broader comparison of chatbots, copilots and agents explains the categories. In a first project, choose the smallest authority that can complete the selected request.
Make the staff fallback part of the first scope
Write down what happens when the customer asks for a person, authentication fails, the policy does not cover the request or a connected system is unavailable. Assign the destination queue and the team responsible for it.
Include operating hours. If no one is available to accept a live transfer, the assistant should accurately describe the alternative and any known follow-up arrangement. It should not suggest that a human has taken over merely because it created a ticket.
Define what the receiving representative sees: the unresolved request, relevant identity context, approved records checked and actions already attempted. Test this with the people who will use the queue. A technically successful transfer can still leave them asking the customer to repeat the whole conversation.
The support handoff guide addresses the transfer record in detail. For choosing a first automation project, the essential question is whether the team can actually receive and resolve the remaining work.
Build the evaluation from real request types
Use appropriately redacted examples and hold some back from configuration. Include the routine language customers use, incomplete requests, corrections, unsupported cases and attempts to obtain an action outside policy. For voice, add realistic audio conditions and interruptions; a text test does not establish voice performance.
Microsoft's support-agent guidance recommends creating test sets early so evaluation can be automated. That supports making evaluation part of development rather than a final demonstration arranged after the scope is fixed. 1
Agree the expected result for each case. Sometimes it is an answer; sometimes it is a verified lookup, a refusal to act or a completed transfer. The reviewer needs enough information to judge that outcome without rewarding confident wording by itself.
Use a practical release exercise:
- Run the selected intents against the approved answer or business record.
- Remove access to a connected system and check what the customer is told.
- Attempt an action outside the allowed scope and verify that it does not occur.
- Repeat a request after an uncertain action result and check reconciliation or escalation.
- Ask for a human and inspect what reaches the receiving queue.
Keep the evaluation cases with the release record and rerun the relevant set when a policy, integration or model changes. A previously correct answer can become inappropriate when the underlying business rule changes.
Measure resolution and the work left behind
Track correctly completed requests, repeat contacts, staff corrections and handling effort. Review these by intent so a strong result on policy questions cannot hide poor handling of order changes.
Define the repeat-contact window around your own service process. A customer returning immediately may indicate an unresolved issue, but later contact may concern a different need. Sample the conversations to understand the reason before treating the count as success or failure.
Also measure the workload transferred to staff. A system can reduce the number of conversations staff receive while concentrating the difficult ones in their queue. Plan coverage using the work remaining and its urgency, rather than assuming every automated session releases the same amount of capacity.
Make AI involvement clear to customers. Microsoft recommends that users know when a support agent uses AI; the disclosure should match the actual interaction and handoff. 1
What a first support pilot cannot prove
Success on one request family does not establish readiness for every language, channel or action. Refund decisions, complaints and urgent cases can require different permissions and staffing. Scope expansion deserves its own evidence.
Automation also cannot repair an inaccurate order database or a policy that staff cannot interpret consistently. Fix those dependencies or keep the affected intent with a person while the underlying problem is addressed.
Questions before choosing the first support workflow
Should we automate our highest-volume request first?
Treat volume as one factor. Prefer a request with a clear source, feasible access, bounded authority and an operational fallback. A common but ambiguous request may be a better fit for assistance to staff.
Is a high containment rate enough to expand?
No. A conversation ending without a transfer may still leave the customer unresolved. Inspect correct outcomes, repeat contacts and staff rework before deciding to expand.
What should go into the implementation brief?
Record the selected intents, approved sources, system access, allowed actions, fallback owner and acceptance cases. Use the support and voice solution to discuss how those decisions become implementation scope.