AI for Customer Support: What to Automate and What Not To

The best candidates for full automation are frequent, well documented, and low stakes if something goes slightly wrong. Zendesk describes AI agents that understand intent, ask follow-up questions and complete multi-step requests by taking action in business systems (Zendesk). That capability matters: an assistant that can only talk can answer questions, while one connected to your order system can actually resolve "where is my order?"

Good candidates usually share four traits:

• The answer is written down. Policies, prices and procedures exist in a current knowledge base.
• The action is reversible. Rescheduling an appointment is easy to undo; issuing a large refund is not.
• Identity is simple to confirm, or the request does not need it.
• The customer's emotional stakes are low. A delivery date question is not a bereavement.

Proactive messages belong here too. IBM lists automatic acknowledgements for emails and social messages, and automatic updates about shipping delays or outages, as standard automation (IBM). A customer who gets a clear status message before asking will often never need to contact you at all, which is better than any chatbot conversation.

Be realistic about how much this group covers. Supportbench, writing about business-to-business support, notes that basic FAQ-style chatbots resolve a much smaller share of requests than systems that can take actions such as processing refunds or reading live account data (Supportbench). If your AI cannot act in your systems, plan for it to answer questions and hand off the rest.

Some of the most reliable uses of AI in support never speak to a customer. They make the people who do faster and more consistent.

Routing and triage. IBM describes automated ticketing that organizes requests by predefined criteria and routes them to the agent best equipped to help, cutting wait times (IBM). Zendesk adds classification by intent, sentiment and language, so urgent issues are prioritized automatically (Zendesk).

Summaries and suggested replies. Zendesk lists instant conversation summaries and suggested responses grounded in context as core workflow automation, along with call transcription and summaries for phone support (Zendesk). A person still reads and sends the reply, but starts from a draft instead of a blank box.

Collecting details before a handoff. Zendesk publishes a workflow in which an AI agent gathers the information human agents need, then escalates immediately: to a live agent on messaging during business hours, or as an email ticket outside them (Zendesk help). This is a strong pattern for businesses that want every customer to reach a person but do not want staff asking for the order number every time.

Sentiment and quality review. AI can flag frustration or urgency as a conversation unfolds and review interactions at scale for knowledge gaps and coaching opportunities, instead of relying on manual sampling (Zendesk).

Translation. IBM notes that support software can translate conversations in real time, allowing support for customers in other languages (IBM). Have a fluent speaker spot-check important replies.

Assist mode is often the right first step. Mistakes are caught by staff before customers see them, and the team learns where the AI is reliable.

Petronella Technology Group's guide to escalation triggers groups the cases an AI should hand off into clear categories (Petronella). Four of them describe work that should not be automated at all:

1. Authority. Refunds beyond standard limits, disputed charges, chargebacks, legal requests, formal complaints and policy exceptions such as waived contract terms. These bind the company and need a person who can be accountable.
2. Sensitive data. Requests for full records, customers pasting passwords, one-time codes or card numbers, government IDs or health details, and changes that require proof of identity the AI cannot verify.
3. Safety and abuse. Threats, self-harm references, harassment, requests for illegal activity and attempts to pressure staff into breaking policy.
4. Capability limits. Cases where the AI lacks system access, a backend action fails, or the request falls outside its allowed tools.

To these, add the emotional cases. Bland, writing about where AI agents struggle, notes that real customers arrive frustrated, skip context, switch topics mid-sentence and expect to be understood, which demo scripts never reflect (Bland). A long-time customer threatening to leave, someone dealing with a death in the family, or a business customer whose operations are down deserves a person from the first reply.

Escalation should be a policy, not a judgment the AI improvises. Petronella recommends four design principles: define authority boundaries (what the AI can do, what it can recommend, and what requires approval), measure conversation health, classify issues by risk, and escalate with context (Petronella).

The same guide lists signals that a conversation is going nowhere and should move to a person:

• The AI cannot confidently tell what the customer wants, or several requests compete.
• Required details, such as an order number, are missing and the customer cannot supply them.
• The customer's statements contradict each other.
• The conversation is looping through repeated clarifying questions without progress.
• Troubleshooting has stalled: the customer has tried the suggested steps and the problem remains.

Turn these into a short written rule set your tool can follow. For example:

Escalate to a person when any of these is true:
- The customer asks for a person, once.
- The request involves a refund, credit or charge dispute.
- The customer shares a password, code, card number or ID.
- The message mentions harm, threats, legal action or a complaint.
- Two clarifying questions have not produced the needed details.
- A system action failed.

On escalation, pass along: the customer's request in their own words,
details collected so far, steps already tried, and the reason for handoff.

The handoff itself matters. Petronella advises passing the customer's identity signals, the exact request, prior attempts and relevant timestamps with every escalation (Petronella). Nothing frustrates a customer more than explaining the problem a second time.

Deflection, the share of contacts kept away from staff, is the most common support automation metric and the easiest to mislead with. Teneo explains why: deflection counts whether a contact reached an agent, not whether the problem was solved. A customer pushed into a bot that cannot help, who calls back the next day, counts as a success on one report and a repeat contact on another (Teneo). Worse, every barrier between the customer and a person improves the number.

Swept AI makes the same point with a simple example: a high deflection rate can mean customers got their problems solved, or that they gave up or received wrong information, and the number looks identical either way (Swept AI). Its fix is practical. Sample the conversations counted as deflected, check whether the answers were accurate and complete, and track whether the same customers come back with the same issue within a day or two.

A scorecard that holds up:

Teneo recommends reporting resolution per channel and per type of request rather than in aggregate, because a single average hides where the system works and where it fails (Teneo). For technical products, Supportbench quotes a support leader arguing that the better headline measure is time to first useful response (Supportbench).

A rollout that builds trust tends to move from the inside out:

1. Internal assistance first. Routing, summaries and suggested replies. Staff see every output before customers do.
2. Acknowledgements and status updates. Automatic replies that confirm receipt and set expectations, plus proactive updates.
3. Answers to documented questions, with an obvious path to a person.
4. Simple, reversible actions, such as rescheduling or changing a delivery address, once the system integrations are reliable.
5. Wider scope only on evidence, request type by request type, using the resolution scorecard.

Hold a short review every week during the first months. Read a sample of automated conversations, every escalation the AI made, and every case a staff member had to correct. Each problem has one of a few causes: a missing or stale answer in the knowledge base, an escalation rule that is too loose or too strict, or a system connection that failed. Fix the cause, note what changed, and check the same sample type the following week.

Expect integration to be the hard part. Bland notes that many AI agent failures are system failures rather than model failures: the agent lacks live account data, cannot trigger the escalation workflow, or answers without the ticket history (Bland). Fix those before blaming the AI.