Customer Support Automation

Start with one ticket category#

The instinct is to build an assistant that handles everything. It produces a system that handles nothing well.

Pick the highest-volume category where the correct answer is knowable from data you already have — order status, refund eligibility, password and access issues, subscription changes. Automate that completely, including the action in the underlying system. Then take the next one.

Resolution means taking the action#

The distinction that determines whether this is worth doing:

Assistance saves an agent a few minutes. Resolution removes the ticket. The engineering difference is integration and permissions — which is most of the work, and the reason demos are easy and production is not.

What we measure#

Resolution rate without human involvement, escalation-after-resolution rate (did the customer come back because we got it wrong), time to first response, and cost per resolved ticket. Satisfaction is tracked but it lags; the escalation-after-resolution number is the honest early signal.

Escalation is the part that decides whether customers hate it#

Every unpopular support bot is unpopular for the same reason. Not because it was wrong once, but because it would not let the customer out.

Four rules, and they are not negotiable in anything we build.

A visible route to a person, always. Not buried, not after three failed attempts, not conditional on the model agreeing that escalation is warranted. If a customer asks for a human they get one.

Escalate with the context attached. The agent that picks it up sees the full conversation, what was attempted, and what the system already knows about the account. Making the customer repeat themselves after a failed automation is worse than never having automated.

Escalate on repetition, automatically. If the customer rephrases the same question twice, the system is not converging and should hand over without being asked. Looping is the single most damaging behaviour.

Escalate on sentiment, not just on content. An angry customer with a technically answerable question is still an escalation. The cost of getting this wrong is asymmetric and the threshold should reflect that.

Authority belongs outside the model#

The security question people ask is about prompt injection. The answer that matters is architectural rather than linguistic.

You can improve a model's resistance to manipulation with careful prompting, and you should — see guardrails. You cannot make it reliable, because natural language has no privilege boundary and a sufficiently creative customer will find a phrasing you did not anticipate.

So the refund ceiling, the irreversible actions and the account-level restrictions are enforced in the integration layer, where the model has no say. The agent requests; the integration decides. A customer who talks the model into agreeing to a fifty-thousand rupee refund gets an agreeable message and no money, and the attempt appears in the logs.

Where this shows up by sector#

• Retail and eCommerce — order status, returns and refunds, where volume spikes on sale days are the whole business case.
• SaaS and technology — account, billing and configuration queries, and sometimes the same engineering shipped as a product feature rather than a cost centre.
• Logistics — track-and-trace enquiries, which are high volume and carry no decision at all.
• Financial services — dispute and chargeback triage, with tighter authority limits and a heavier audit requirement than anywhere else.