[ research · august 2026 ]
Customer service automation: what not to automate, and why
Every customer service automation vendor publishes the share of conversations its agent resolves. Nobody publishes the list it is told to leave alone. Ours is the more useful document.
What customer service automation actually covers in 2026
Customer service automation is software answering and acting on customer conversations without a person in the loop, and in 2026 the phrase covers four different layers that vendors rarely separate. The first is answering from what is written down: the return policy, the opening hours, the setup guide, read from a knowledge base or from the website itself. The second is acting on the account: where is my order, move my booking, resend my invoice, which needs the agent to reach the system that holds the answer, in the customer's own session or through an integration. The third is routing: deciding who a conversation belongs to when the agent should not take it. The fourth is assisting the humans, drafting replies and summarising threads inside the helpdesk, which is automation of the agent's work rather than of the customer's conversation.
Every product on the market does some of these. The helpdesks with an agent inside, Zendesk, Gorgias, Freshchat and tawk.to, started from the fourth layer and added the first two. The enterprise agents, Sierra, Decagon, Ada, delight.ai and Intercom's Fin, sell the first two at volume and price the outcome. The self-serve agents, Chatbase, Botpress, Tidio and Algomo, sell the same first two layers to a company that will never take a sales call. Our comparisons page sets all eighteen side by side. This post is about the third layer, routing, because it is the one that decides whether the other three are safe to switch on.
Five conversations to keep out of automation
First, money beyond the written policy. An agent that approves the refund your policy covers is doing its job; an agent that guesses at the exception is spending your money without asking you. Second, anything that smells of law: chargebacks, data-deletion requests, the message that mentions a lawyer. Third, safety and medical situations, where the only correct automation is a fast handover. Fourth, the furious customer who is also a valuable one: that conversation is relationship work, and the point of automating everything else is that a person is free to take it. Fifth, the case with no written rule yet. The agent's job there is not to improvise a rule; it is to notice that it has none.
None of these five is rare, and none is hard for an agent to recognise. What they have in common is that the cost of a wrong answer is not a second message from the customer; it is money, liability, a person's safety, or a relationship you cannot buy back. The automation rate you are sold is a count of conversations. These are the ones where counting is the wrong measure.
What customer service automation costs when it goes wrong
In 2024 a Canadian tribunal ordered Air Canada to honour a bereavement discount its chatbot had invented, and rejected the airline's argument that the chatbot was, in the tribunal's words, "a separate legal entity that is responsible for its own actions." The ruling is short and worth reading in full, because it settles the question every deployment eventually asks: what your agent says is what your company said. Gartner predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, and "inadequate risk controls" is one of the reasons it names. The projects that die this way do not die because the model was weak. They die because nobody wrote down where it must stop.
How the handoff to a human should work
A chatbot human handoff is where most automation fails quietly, because the vendor demo ends when the agent says it is transferring you. What matters is what arrives on the other side. In Algomo three things happen when a conversation crosses one of your boundaries. The transcript travels: the person picks up the same conversation, with what was asked, what the agent checked and what the policy says already in front of them, so the customer never repeats themselves. Your team is notified by email and in Slack the moment it happens, with a link into the conversation. And the takeover is live: a person types into the same chat the customer is already in, and the agent stops speaking until they are done. The visitor sees one conversation, not a queue number.
Two things do not happen, and you should know before you buy. Algomo does not create a ticket or a case in your helpdesk; the conversation lives in Algomo and your team works it there, from the notification. And it is web chat only: no phone line to fall back to, no outbound message once the visitor has left the page. If your escalation path runs through Zendesk tickets or a phone queue, the like-for-like table against Intercom Fin says who does that and at what price.
Why every vendor's automation rate needs a denominator
Decagon's Duolingo case study reports 80% of chats deflected. Sierra writes that Chime went from resolving half of its conversations to more than 70%. Ada's homepage says its agents autonomously resolve over 80% of support inquiries. We believe all three numbers, and the pattern behind them: most support volume is repetitive, and a competent agent absorbs it. But a resolution rate is a numerator sold without its denominator. The question no vendor page answers is what the agent does with the conversations it should never have taken in the first place, because that is where the money and the lawsuits are.
Once the boundaries are explicit, the resolution rate finally means something: of the conversations the agent was allowed to take, how many did it finish. That number can be audited, because the list of what it was not allowed to take is written down next to it. A smaller honest number beats a larger vague one, and it improves the right way: by writing better rules as your edge cases surface, not by waiting for the next model release. It is also why we meter what the agent did rather than what it claims: a conversation that actually helped someone costs five credits, one that went nowhere costs nothing, and the verdict is one you can see and contest per conversation.
Automation boundaries are configuration, not limitations
In Algomo the boundary is a sentence you write, not a workflow you build. "Refunds above the published policy go to a person." "Anything that mentions a lawyer goes to Elena, immediately." You state the rule in plain language and the limit holds, which is the same mechanism the rest of the agent runs on. And when the agent hands a conversation over, it hands over the work it already did: what was asked, what it checked, what the policy says. The person starts from the middle, not from hello.
The escalation is not the failure mode. An agent that escalates the right conversation is the product working exactly as configured, in the only way that lets you trust it with the rest. Our service agent page shows the boundaries beside the actions, which is how they should be read.
Customer support automation for small teams
Most of what is written about customer support automation assumes a support department, with a manager who reads the resolution dashboard and a budget line for the vendor. A five-person company has neither, and it is the company that needs the boundaries most, because the person who takes the handover is also the founder. The good news is that the economics run the other way at that size. Algomo's Free plan is the whole agent, for one person and one site, with enough credits for about twenty useful conversations a month and nothing to pay until you choose a monthly amount, $50 to $4,300, which is then the most any one charge can be; no overage, no top-ups. The pricing page has the ladder.
For a small team, the setup we recommend is the one this post argues for. Write the five boundaries first, in your own words, so the agent knows where to stop. Put it on the live site, so it answers the real questions from the pages and the account data it can already see. Then read the handovers for a week. The conversations it passed to you are the list of rules you have not written yet, and writing them is the entire ongoing cost of the automation.
Questions, answered
What should not be automated in customer service?
Five kinds of conversation: refunds or credits beyond your written policy, anything with legal weight such as chargebacks, data-deletion requests or a mention of a lawyer, safety and medical situations, a valuable customer who is angry, and any case with no written rule yet. The agent should recognise each of these and hand it to a person with the transcript, not improvise.
When should a chatbot hand off to a human?
When the conversation crosses a boundary you wrote down in advance, not when the customer gets frustrated enough to ask. The handoff should carry the transcript and what the agent already checked, notify your team by email and Slack, and let a person take over the same chat live. A handoff that starts the customer over from hello is a failed one.
How much of customer service can be automated?
Vendors claim a lot: Decagon's Duolingo study reports 80% of chats deflected, Sierra says Chime resolves more than 70%, and Ada's front page claims over 80% of support inquiries resolved autonomously. Treat these as vendor claims about their own customers. The honest number depends on what you exclude first: of the conversations the agent is allowed to take, most can be finished, and the share you exclude is a decision about your policy, not about the model.
What is customer service automation?
Software that answers customers and acts on their accounts without a person in the loop, plus the routing that decides which conversations a person should take, and the tools that help the people who take them. In 2026 that means an AI agent on your site or in your helpdesk that reads your policies and your customer's account, answers, acts within the rules you set, and hands over the rest with the transcript attached.
Write the second list first
If you set up Algomo this week, our advice is to write the second list first. Not what the agent should do; what it must never do. It takes ten minutes, it is the part of the setup your lawyer would approve of, and it is the reason you will let the agent take everything else. If you want to see how that configuration is done from a coding agent rather than a dashboard, our post on MCP for customer support walks through it.
[ next step ]