Maciej Nuzia · Customer support

I automate customer support with a clear line: when a person takes over

Simple status questions, document requests and cases that require a decision all reach the same queue. Automation can check data, prepare a reply or set a ticket’s priority. It can pass harder cases to an agent with the full conversation and what it has already established. The line between automation and a person depends on the support process.

Before I count anything, I want to read real tickets, including the ones written in anger.

The queue

One queue holds simple questions and urgent problems

A question about a delivery, then one about a refund. Somebody answered that same question yesterday, for somebody else and in slightly different words. A few messages down sits a customer left with a broken order, writing about it for the third time. The inbox stacks both of them one under the other, in the order they arrived.

  • the same question arrives by email, by chat and through a form, sometimes from one person
  • the answer depends on who happens to be watching the inbox that day
  • a new hire writes carefully, because they do not know what may be promised to a customer
  • the customer tells the story a second time, because the earlier conversation stayed in another window

Who it is for

Good candidates are replies to the questions that come up most often

Replies written from memory are the part of the inbox that can be handed over. In some companies that is most of the day; in others it is a handful of messages between more serious cases. The archive shows the difference straight away, so I go through it before quoting anything.

  • Online stores handling their own returns
  • SaaS products with support inside the app
  • Subscription businesses
  • Platforms supporting two languages
  • Tenant and resident service desks
  • Companies whose customers write after hours

A shared inbox usually holds work that is not a customer ticket at all: orders to retype, summaries to put together. That part I describe on the page about process automation.

Tickets

What automation can do before passing on a ticket

A first reply with something in it

The customer gets a case number and one sentence saying how the automation read their message. When it read it wrong, the customer corrects that straight away, before anyone starts working on the case.

Where a ticket lands in the queue

A ticket that stops a customer from paying goes ahead of a question about opening hours. Position in the queue follows the weight of the case; the hour it was sent drops to second place.

Order and return status

When somebody asks about a parcel or about money for a return, the automation looks it up where that data actually lives and replies with the number. That question comes back at every company that ships anything.

Questions that come back every week

The answer is built from what the company has written down: the returns policy and the warranty terms. The mechanism itself I describe on the page about RAG for business.

Handing the case to an agent

The agent gets the whole conversation: what the customer wrote, what the automation replied, and the point where it stopped being sure.

A month of topics in one list

Tickets group into topics, and a month of them shows which subject takes up the most room in the inbox. It happens that somebody then adds one sentence to a product page and the topic disappears from the inbox.

In order

The scope of automation depends on the questions and support rules

01

I read the ticket archive

I take the tickets from the last few weeks and read them as they came in: typos, half sentences, sent at half past eleven at night. Out of that comes a list of the cases that keep returning, and a separate list of the ones everybody answers their own way.

02

What the automation may promise a customer

We write down together the cases it never touches: disputed billing and anything that ends in money going back. I also ask who signs that list off, because it sets the automation's reach, and it is what I come back to whenever something is unclear.

03

The tone the company writes in

I take the replies from whoever in the team writes them best and pull the rules out of them: how long, how formal, when to apologize and when to explain. What of that goes into the automation is yours to confirm before launch.

04

How often the customer asked for a person

The automation answers on its own within one category of tickets, the narrowest one on the list, and a way through to an agent sits in every reply. That count tells you the most: it climbs wherever the answer misses the point of the ticket. The conversation about a second category starts by going through exactly those tickets.

Technologies

The way in is your helpdesk API

I pick the model by where the answer lands. In a draft for an agent a slip costs a moment of reading; in a message going straight to a customer it costs more.

  • OpenAI API
  • Claude / Anthropic
  • RAG
  • Helpdesk integrations
  • Node.js
  • Python
  • PostgreSQL
  • Webhooks
  • AWS

In plain sight

An incorrect automated reply can reach the customer

A reply sent too soon

A bad answer in support does not stay inside the company: the customer takes a screenshot and passes it on. So the automation writes only about what it has in writing, and at the first sign of uncertainty it gives the case to an agent. A promise that is not in the materials is one somebody has to answer for later.

A customer locked in with a bot

The worst version of this project is an automation that cannot say it is passing the case to a person. The way through to an agent is visible from the first message, and it works when the customer asks for it in their own words, halfway through a sentence about something else.

Tickets that come from a real fault

When people write because something in the product is broken, the automation can confirm that the fault is known. The number of those tickets goes down along with the repair. I will show them in the topic breakdown; the repair stays on your side.

FAQ

When automation replies and when an agent takes over

Will AI replace the support team?

The team stays with the cases where something has to be decided, negotiated or apologized for. The automation takes the tickets that come back word for word. How those two groups split differs from company to company and comes out of the ticket archive, so I give you that figure once I have read it. It happens that after that reading I suggest dropping the idea: with an inbox where every ticket is different, there is nothing for it to take over.

What does this connect to?

To whatever your helpdesk exposes: an API and webhooks. Zendesk, Intercom and Freshdesk have both. With a tool built in-house, my first question is what there is to connect to, because that decides whether the automation can stand next to the queue at all. Sometimes a file export is the only way in.

How does the automation know to hand a case over to a person?

Three ways. The first is the list of cases it never touches, written down with you before launch. The second is its own uncertainty: when the materials hold no answer, the ticket goes to an agent with the conversation attached. The third is the customer asking for a person, and that request is enough on its own.

Should the customer know they are not writing to a person?

I think so, and that is how I set it up. Pretending to be a person falls apart at the moment the automation trips, and it trips sooner or later. When it is clear from the start who is writing, the request for an agent comes earlier and is less likely to end in disappointment.

What happens to customer data?

The model gets the text of the ticket and the materials it should build an answer from. Card numbers and other sensitive fragments can be masked before anything is sent, and whole categories of cases can stay away from the model entirely. Where the rest of it runs follows from what is allowed to leave your network. Tickets with an attachment have their own rules here: often only the text of the message goes to the model, and the file stays in the helpdesk.

Two messages

Start with a few real messages

A conversation can start from two or three real messages from last week, together with what you replied to them. After those I know what we are talking about. The estimation tool will price the same case if you would rather see numbers first.