The Support Agent That Took My Worst Job Away

Why is support expensive even when the problems are easy?

Before AI, my worst nightmare at work was support and maintenance.

At a former company, for years I was the engineer with most tickets solved. We typically had between 1.200 and 1.500 support requests a year, out of which I was personally involved in solving more than 200. 1.200 to 1.500 might not seem so impressive when divided by about 250 working days a year – it results in 5 to 6 tickets per working day. On average.

In reality, we never had less than 1 or 2 tickets a day, but on peaks, we had up to 20. It was like a support center – phones kept ringing, emails kept coming. While trying to solve a ticket, you were constantly interrupted by other tickets. And the brunt of that tsunami had to be taken by a single person. Let me explain why.

Why does support always land on one person?

In order to ensure productivity of our developers, we organized our support in 3 lines. The first line could be manned even by sales, not necessarily by engineers. The first line had the job of responding to all non-technical requests, for example how to use our software for mutual and pension funds. The second line was in charge of technical issues which should be solvable by any engineer. When we needed specialist support – this was the third line of defense – then and only then we interrupted the developer responsible for the functionality in question.

At least in theory.

The second line was shift based. The engineers of our small team had to be on the second line typically one day in 5 to 7 working days. Furthermore, the engineer on the second line was often the first line as well, in order to achieve maximum efficiency. So when we had a 20-ticket-a-day peak from our example, it is needless to say this person was overburdened. He or she needed help. A lot of it.

How much of your support work is not even in the contract?

The structure of the tickets was the second cause of frustration. Our maintenance contract guaranteed flat rate customer support. But even so, on average about 45% of tickets were outside of the contract scope.

For example, customers would often ask us to correct their own data entry errors. They would ask about a suspicious piece of data, only to find out it was themselves who entered it – after our tedious data lineage investigation. We did system support as well. When our app couldn't reach the server due to an issue in their local network, we would get "app does not work" tickets. My favorite for the end – we supported them with stuff not related to our app, mostly teaching them their own job. Why spend time on internal onboarding and education if you can simply forward a rookie to the vendor's support service?

But the decision was to handle all the tickets since we were trying to expand at the time – so we did. This resulted in almost doubling the number of tickets we had to solve.

Have a look at your own support statistics before you read on. In my experience, everybody who does this exercise for the first time is surprised by the same thing. Not by how many tickets there are, but by how many of them you never agreed to handle.

Why does being good at support get you more support?

There were good sides as well. We somehow managed to discipline the users to use only the support email and the fixed phone line. There were not many calls on personal mobile phones – that being said, we were very responsive on the fixed line, which probably helped. When a user would somehow manage to add somebody to chat, the user would get immediately blocked so he doesn't see when the engineer is online. There was no way a developer would get constantly interrupted by chat while working.

This leads us to the crescendo of my rant. Why would anybody want to chat with a specific person rather than with the support service?

The reason is simple, although very unfair in its essence. The users were simply selecting people who had a good history of solving their issues. So the better you were in support, as a "reward" you would get even more support.

And this sense of injustice continued in my own company as well. Even though I am the owner. Or perhaps just because of the owner's sense of responsibility.

Flexible working hours are a real benefit and I would not take them away from anybody. But a client who starts work at eight does not care about them, and somebody has to answer that client at eight. Personal leave with short notice is normal and human. But the functionality that person owns is still in production, and somebody has to talk to the client who is using it. Both times, it was me. So instead of having people doing support and maintenance for me, once again it was me taking the brunt.

Even on the projects where we were part of a consortium of vendors, it was me who would get interrupted by support phone calls. Not the formal support contact of the carrier company in the consortium, but me. Why? Well, because I am "the guy who usually solves the stuff". Utterly unfair and extremely frustrating.

What changed when we automated support and maintenance with agentic AI?

But all of that was until 2026. AI, agentic AI in particular, changed everything. At VIS Solutions we decided to automate support and maintenance with our agentic AI platform, and the system has been running in production ever since.

Before, we struggled to organize responsive support 8 hours a day, 5 days a week. Now we have responsiveness 24 / 7.

Before, you would be forced to talk about complex issues on the phone. Even when you were not in front of the computer to see what the h… they are talking about. Now, the agent has instantaneous access to the client's data and past tickets. No more surreal "I don't have a clue what this person is talking about" situations.

So how does it actually work?

Does customer support automation require clients to change how they ask for help?

Every request enters through a single agent, whatever channel it arrives on — email, chat on our real number, and voice on the phone, all live today. The client does not learn a portal. The client does not fill in a ticket form. They write to support the way they have always written to support.

That matters more than it sounds. Every support tool a vendor has ever bought asked the client to change their behaviour, and every one of them leaked – because the client's actual behaviour is to write to the person who helped them last time. The agent meets them where they already are. And unlike that person, it is never in a meeting.

What does the agent do before it answers a support request?

The first thing it does is work out who is asking.

Before it reads what the problem is, the agent establishes who wrote in and which company they belong to, then pulls that client's profile and their recent tickets into the conversation. This is the whole difference I described above. The agent is never in the "I have no idea what this person is talking about" position, because the client's history is in front of it before it answers the first sentence.

The client list is the permission list. There is no second register of approved individuals for somebody to maintain. A user at a known client gets help the first time they write, without anybody adding them anywhere first. That is a deliberate call. A support system that makes a new employee wait for onboarding before it will talk to them has already failed the one case where speed actually matters.

Where a channel cannot prove identity – a phone call, a chat message – the agent asks for a work email and sends a short code to it. Same principle: verify the company, not the person.

Why is an agent that asks one question better than one that answers immediately?

Business users write cryptic support requests. Everybody who has ever run a support desk knows this.

So the agent's first job is understanding the problem, not solving it. It is instructed to ask one short clarifying question rather than assume, and it is bounded, so it never turns into an interrogation. When somebody reports that something stopped working, it asks the one question that covers when it started, what changed recently and what the error said. Once. If the user does not know, it moves on – because business users usually do not know, and pressing them is exactly how a support channel gets abandoned.

This is the most under-appreciated design decision in the whole system. An agent that answers confidently from an incomplete request is worse than no agent at all. It produces a wrong answer with your company name on it, at machine speed, at three in the morning. Getting a model to ask one good question and then stop is considerably harder than getting it to answer.

How does an AI agent decide who handles a support ticket?

Once the agent understands the request, it classifies it into one of ten types – the same taxonomy we derived from thousands of real tickets. That classification is not a report field. It is the decision about who handles the ticket, and everything downstream follows from it.

Read the first three rows again, because that is where the money is. The three categories the agent closes entirely on its own are precisely the ones that were never in the contract in the first place. That 45% from the beginning of this article.

The first thing support automation pays for is the work you were already doing for free. Not the hard engineering. The unbillable tide.

What should an AI support agent never be allowed to do?

This is the part I would want to read if somebody else had written this article. The interesting engineering here is not what the agent does. It is the six things it is not allowed to do, and the reason behind each one.

Why no fix — and no verdict on whether a bug is real — happens without a human

It never decides whether a bug is real. Every bug report goes to the coding agent, without the support agent forming an opinion first. The reason is commercial, not technical. An agent that tells a paying client "that is not a bug" and turns out to be wrong has done more damage in one sentence than a week of correct answers will repair. That judgement is made further down, with the code in front of it.

No fix reaches production without a human approving it. The coding agent diagnoses the problem, writes a minimal fix, runs the tests and opens the change for review. Then it stops. A person approves it. Always.

It never guesses which system a ticket belongs to. Every supported product is registered explicitly. If a bug report cannot be matched to exactly one registered system, the agent tells a human instead of picking the closest match. There is nothing worse than a confident fix to the wrong codebase.

Why the agent queries a restored backup instead of production data

It has no way to write to a client's production data. Not a restricted path – no path at all. The agent's only contact with production is downloading the latest backup. Every query it runs, it runs against a restored copy. When data genuinely has to change, it works out the exact change, writes it out with instructions, and sends it to a human to apply.

That last one came with a benefit nobody designed for. Restoring the backup in order to answer support tickets means the client's disaster recovery procedure gets exercised continuously, as a side effect. Most organisations test their restore path once a year, badly, under audit pressure. This one gets tested every time the data is refreshed. Conservative designs tend to pay you back like that, and rarely in the way you expected.

Why pricing and unknown senders stay with humans

It does not quote prices. Change requests go to a human, every single time. An estimate has to cover your cost, stay profitable and still not lose the client. That is three judgements at once, and I would not hand them to an agent today. Ask me again next year.

It reads everything and answers only clients. Anybody can write in, and the agent will read and classify it. But it will only reply to a domain it recognises as a client. The failure mode is deliberately "we did not answer", never "we answered the wrong person". And while we build confidence in it, every reply the agent sends is copied to a human – not to approve it, just to see it.

Can one support agent serve several clients without them affecting each other?

Bringing a new client onto the system means adding their details and their documentation. It does not mean building anything. A client without a specialist configured does not break – their data questions escalate to a human, which is safe and visible rather than quietly wrong.

That sounds like an implementation detail. It is not. The reason support platforms rot is that every new client's special case becomes a change to the shared system, and after twenty clients nobody can touch anything. Here they are not changes. A client's specialist can only see that client's data – it checks, and it refuses anything else – so onboarding the tenth client cannot destabilise the first nine.

We run this for VIS's own support, and for a government educational agency we support as part of a consortium led by our partner company. Two very different clients, on the same system, with no shared blast radius. That is the property an enterprise buyer is actually evaluating when they ask whether something will still work in two years. These deployment scenarios demonstrate the maturity and reliability of intelligent automation systems in production.

What changes for the manager who used to run support?

The main difference is that now it is me who is monitoring and managing support and maintenance, not doing it.

I have a dashboard, available on my mobile phone even when I am not in front of the computer. It shows currently open tickets with the main dimensions – client, criticality, ticket type. I can see the tickets that had to be taken over by humans, if any. And if I need more, I am one click away from the table with everything we keep about every ticket, open or not.

Instead of being buried in particular issues, I can focus on improving the agent and the process as a whole. I can keep an eye on key clients. I can analyze current bottlenecks and focus on removing them.

There is a quieter change underneath that one, and it is the one I would put in a business case. For the first time, the load is measurable. Which clients generate it. Which type of request. Which hour of the day. What fraction of it needed a human at all. You cannot improve a support process that you have only ever experienced as a series of interruptions – and for most of my career, that is exactly what support was.

Where should you look first in your own support desk?

Have a look at your own support desk with that in mind. Somewhere in it there is a person everybody writes to directly, and about half of what reaches them was never in a contract. You know who it is. It might be you.

Next in this series, I will go through all ten ticket types one by one – which of them an agent can close, which of them it must never touch, and the guardrails that make the difference.

Your own support desk almost certainly has the same pattern: one person carrying the load, tickets arriving on channels that person has to monitor, and roughly half the work never in the contract. That load is measurable, but only once something else carries it. The next piece in this series breaks down all ten ticket types – which ones an agent closes on its own, which ones it must never touch, and the guardrails that make the difference. To see what comes next in this series, join the newsletter.