Automate or Assist? Deciding Which Support Work AI Should Own

By Linh Ngo · Updated Oct 11, 2026

Deciding between automating and assisting means sorting each type of customer contact by two tests, complexity and risk, then giving AI one of three roles: resolve it alone (automate), draft and suggest while a person decides (assist), or stay out of it (human). Low-complexity, low-risk contacts such as order status or password resets are candidates to automate. Messy or judgment-heavy contacts where a mistake is cheap to fix are candidates to assist. Anything where a wrong answer creates legal, financial or safety harm stays with a trained person, with AI limited to preparation.

This guide is for support leaders, CX directors and support managers who have already heard "AI can handle support" and now need to decide, queue by queue, what that means. It sits under the overview in AI in customer service and focuses on one question: who owns the work.

Key Facts

• In a study of 5,179 customer support agents using a generative AI assistant, productivity rose 14% on average, measured as issues resolved per hour, and 34% for novice and low-skilled workers, with minimal impact on experienced workers (Brynjolfsson, Li and Raymond, NBER).
• Klarna reported on February 27, 2024 that its AI assistant had handled 2.3 million conversations in its first month, two-thirds of its customer service chats, with resolution time under 2 minutes versus 11 minutes before and a 25% drop in repeat inquiries (Klarna press release).
• In May 2025 Klarna's CEO said the push to automate had gone too far and compromised quality, and the company began hiring human agents again (Maginative, reporting a Bloomberg interview).
• In Moffatt v. Air Canada (2024 BCCRT 149), a tribunal held the airline liable for negligent misrepresentation after its chatbot gave wrong bereavement-fare advice, and awarded $650.88 in damages (EH Law summary).
• The US Consumer Financial Protection Bureau found that each of the 10 largest commercial banks uses chatbots in customer service, and warned about wrong answers and "doom loops" with no route to a person (CFPB).

Why "Automate Everything" and "Assist Only" Are Both Wrong

Teams usually start from a tool, not a decision. A vendor offers a bot that deflects tickets, or a copilot that drafts replies, and the question becomes "where do we switch it on?" That gets the order backwards. The same AI capability can be the right answer for one contact type and a liability for another.

Klarna is the clearest public example of both edges. Its own announcement described a fast, high-volume result: two-thirds of chats, faster resolution, fewer repeat contacts. A little over a year later its CEO told Bloomberg that cost had become too dominant a factor and that quality had suffered, and he said customers should always be able to reach a human if they want (Maginative). The lesson isn't that automation fails. It's that one blanket policy over every contact type eventually hits the contacts where it shouldn't have been applied.

The opposite mistake is just as expensive. If every contact goes to an agent with a copilot, you pay human handling time on password resets that a bot could finish in seconds. Assist-only protects quality and gives up most of the capacity gain.

The Three Roles AI Can Play

Automate. AI resolves the contact end to end, including any action, without a person in the loop. In ACE Framework terms this is the full chain through Execute, and it's the highest-risk setting because the system changes something in the real world. Patterns used: rag-assistant for grounded answers, autonomous-agent when it takes actions.

Assist. AI prepares and a person decides. It retrieves the relevant policy, summarizes the thread, drafts a reply, suggests the next step and fills the form. The agent edits, approves and sends. This stops at Generate. Patterns used: workflow-copilot and rag-assistant. The evidence for assist is strong: in the NBER study above, the biggest gains went to the least experienced agents, because the tool surfaced what the best agents already knew (NBER).

Human. A trained person owns the contact. AI may still work in the background by routing it to the right person (scoring-routing), flagging urgency and summarizing history, but it doesn't draft the customer-facing words or decide the outcome.

Routing is worth singling out. Classification and prioritization sit upstream of every decision in this guide, because you can't send a contact to the right role until something recognizes what kind of contact it is. See the AI support triage agent.

The Two Tests: Complexity and Risk

Every contact type gets scored on two questions.

Complexity: how much judgment does a correct resolution need?

• Low: one clear answer from a stable source. "Where's my order?" "How do I reset my password?"
• Medium: the answer exists but depends on context. Which plan, which region, which exception applies. It needs the right document retrieved and the customer's account read.
• High: no single right answer. The agent weighs trade-offs, interprets ambiguous policy or manages emotion. A cancellation threat from a key account, a complaint with several causes.

Risk: what does a wrong or tone-deaf response cost, and can it be undone?

• Low: a mistake is cheap and fixable. A wrong help-article link gets corrected in the next message.
• Medium: a mistake costs money or goodwill but is recoverable. A wrong delivery estimate, a missed discount.
• High: a mistake creates legal, financial, safety or regulatory harm, or can't be reversed. Refunds above a limit, medical or safety information, account closure, dispute handling, anything involving vulnerable customers.

Risk is the dominant test. Moffatt v. Air Canada shows why. The chatbot's answer was ordinary-sounding, a customer relied on it, and the tribunal held the airline responsible for what its own chatbot said (EH Law). The award was small. The principle isn't: the tribunal treated the chatbot's answer as the airline's own representation. That is the question of how much hallucination your use case can tolerate.

The Decision Matrix

Use this table to assign a default role to each contact type. Treat it as a starting position for your queues, then adjust with your own error data.

Two rules keep the matrix honest. First, risk overrides complexity: a simple contact with high risk goes to Assist or Human. Second, the role can differ by customer segment as well as contact type, so a refund request from a first-time customer and one from an enterprise account may route differently.

Real Examples by Function

E-commerce and retail support. Order status, returns eligibility and delivery changes are low-risk lookups, and they usually make up the largest share of volume. Automate these first, with a cap on automated refunds. Klarna's published numbers show what high-volume, structured contacts look like once they're handled by an assistant: two-thirds of chats in the first month (Klarna). Notice that this is Klarna's own reporting, not a neutral benchmark, and it covers chats, not every channel.

Financial services. The CFPB's review is blunt about the risks of customer-facing chatbots: wrong answers from generative models, failure to recognize a dispute when the customer doesn't use the expected words, and loops with no human exit (CFPB). Balance questions are fine to automate. Disputes belong to a person, with AI assisting in the background.

SaaS and technical support. Tier-1 how-to questions are good automation candidates when the answer is in your docs. Troubleshooting is an assist case. An agent working a login error across three integrations benefits from suggested diagnostics, similar past tickets and a drafted reply, and still needs to decide which fix applies.

Travel and logistics. Anything that states a fee, fare or policy is a commitment. Air Canada learned that a chatbot's answer about a bereavement fare was treated as the airline's own representation. If your bot can state policy, it should quote from locked, version-controlled policy text and decline when it can't find the answer.

For more use cases in a list format, see AI agents for customer support.

How to Implement the Decision, Step by Step

1. Inventory your contact types. Pull 90 days of tickets and group them into 15 to 30 contact types. Use your own tags if they're reliable, or have a model cluster the text and a human name the clusters. Record volume and average handling time for each.
2. Score each type for complexity and risk. Use the low, medium, high scale above. Have support, legal or compliance, and a team lead score together, since risk judgments differ by function. Disagreements are useful: write down why.
3. Assign a default role from the matrix. Mark each type Automate, Assist or Human. Put the high-volume, low-risk types at the front of the queue to start.
4. Check the data behind each automate candidate. An automated answer is only as good as the knowledge it retrieves. If the policy page is out of date or conflicts with another, fix the source before you switch anything on. Preparing support data for AI covers the clean-up.
5. Set action limits. For anything where the AI acts, define caps (refund amounts, account changes) and the conditions that force a handoff: customer asks for a person, sentiment turns negative, the same question is asked twice, confidence is low. Put the limits in the system, not in a policy document nobody reads.
6. Build the escape hatch. Every automated path needs a visible route to a person that passes along the full conversation. The oversight design is covered in human-in-the-loop AI agents. The "doom loop" the CFPB describes is a design failure, not a model failure.
7. Pilot one or two contact types. Run Automate on a slice of traffic with sampled human review of the transcripts. Run Assist with agents who can accept, edit or reject each suggestion, and record which they do.
8. Measure resolution quality, not just deflection. Track repeat contact rate, escalation rate, post-contact satisfaction and error rate from sampled reviews. Klarna's repeat-inquiry figure is a good example of a quality-aware measure (Klarna). Deflection alone can reward a bot that frustrates people into giving up.
9. Move contact types between roles on evidence. A contact type can graduate from Assist to Automate when edit rates stay low and error rates are measured and acceptable. And it can drop back. Review the matrix quarterly.
10. Reset the team's roles. Agents who review AI drafts do different work from agents who write every reply. See AI and support team roles.

Common Pitfalls

Deciding by channel instead of by contact type. "Chat is automated, phone is human" ignores that a chat message can be a billing dispute and a phone call can be an order-status check. Decide by what the customer needs.

Treating deflection as success. A contact that never reaches an agent isn't necessarily resolved. Watch repeat contacts and customers who come back through another channel.

Letting the bot make commitments. Pricing, eligibility, refunds and deadlines are promises. If the bot can state them, they should come from controlled source text, and the bot should say it can't answer rather than improvise.

Automating before the data is ready. If your knowledge base is thin or contradictory, the bot will produce confident wrong answers at scale. Fix the content first.

Ignoring who the Assist benefit goes to. The NBER study found the largest gains for novice agents and minimal effect for experienced ones (NBER). That's useful for onboarding and for planning where to pilot, and it means you shouldn't expect your top agents to report big time savings.

Where to Go Next

If you do one thing this month, list your top 20 contact types by volume and score each for complexity and risk in a single workshop with support, legal and operations in the room. That one table will tell you more about where AI belongs than any vendor demo. Then see where the risk sits across patterns in the AI pattern risk gradient.