Zero issues is the wrong goal. A product that generates no issues is a product that isn’t innovating. Instead, the aim should be that every issue a human handles is net new.

That bar is higher than it sounds. Net new doesn't just mean the problem has never been seen before. It means an AI, given everything the organisation knows, can't interpret what's happening, can't identify the cause and can't pose a solution. Not to the customer, who might otherwise have been appropriately guided and sent on their way, and not to the support engineer, who might otherwise have been handed a draft fix to put into the docs, into the product or in front of an engineering team, to prevent the issue in future.

Only when all of that fails is an issue genuinely worth a person's attention and everything else is repeat manufacture. If a human is working a case that AI could have interpreted, something upstream has failed. Either the answer wasn't available to the customer, or it wasn't available to the agent, or the product shouldn't have produced the problem in the first place.

This is why it helps to think of support as a factory. Factories should be judged by what they do with what comes through the door: how quickly it identifies what it has received, how reliably it converts that into something finished and how ruthlessly it feeds every defect back into the line so the same fault isn't made twice, improving efficiency and reducing shrinkage.

Support organisations have all the characteristics of a factory and very little of the discipline. Cases arrive from many different sources with inconsistent labelling. They're worked by hand. They close, and their lessons evaporate. Meanwhile, AI gets bolted onto the front door as a bouncer rather than being built into the line.

Support should be the most AI-native function in the company. Not because the technology is fashionable, but because support sits in the only place where the gap between what the product promises and what the customer experiences is visible, in volume, every single day. AI belongs during the ingress, handling and retro of every engagement, and each stage exists to answer the same question. Could a machine have dealt with this?

Ingress

Every case begins with metadata, and metadata is typically only captured once. Miss it at the door and rarely is it retrofit.

Most teams do a passable job on the web form and then forget everything else. A case raised through the portal arrives with a product area, a contact and a body whereas a case raised by an account manager over Slack probably arrives naked. Those are frequently the highest-signal issues in the building, and they're the ones nobody can report on six months later.

AI closes that gap without asking customers to jump through hoops. A model can infer the product area, the affected endpoint, the environment, the likely severity and whether this resembles something it's already seen, all before a human has read a word of it. The goal is enrichment, not interrogation.

This matters because categorisation is the raw material for everything downstream. Routing, agentic handling, trend analysis and the prevention conversation with product all inherit the quality of the labels applied at ingress. Most importantly, it's what lets the machine make the call at all. An agent can only tell you it doesn't recognise a problem if it has been given enough to recognise one in the first place. Starve it of context and everything looks net new, which is indistinguishable from nothing being net new at all.

Deflection Is a Signal, Not a Success

The temptation is to point an AI agent at the knowledge base, watch the deflection rate climb and declare the project a success. It's a vanity metric, and a misleading one.

A high deflection rate means a large number of customers needed help with something the product could have told them itself. The agent answered, which is good. The reason they got stuck is still sitting there, unchanged, generating more deflections tomorrow. A deflected case isn't a case avoided. It's a case that should never have existed.

Deflected cases deserve a retro of their own. Cluster them, rank them by volume and revenue then sort them into two piles.

The first is known list of fixes for engineering. The error message that doesn't say what to do next. The default parameter that surprises everyone. The empty state with no call to action. With accurate customer metadata, these can be triaged however the business would like.

The second is a known list of fixes for the support team to own, and here is the crux: the team must be trusted to actually ship them. If every documentation correction, error string and piece of UI copy has to queue behind a product manager's roadmap, nothing will move. The loop only closes when the people who can see the defect are allowed to pick up a spanner.

Handling

A case that reaches a human should arrive with the machine's working shown. What it thinks is happening, what it checked, what it ruled out and where it lost confidence.

The slow part of handling a case is rarely the thinking. It's retrieval and reproduction, which means finding the account, the configuration, the last ten events and the state of the integration, followed by working out which debugging step to try next.

Both can be automated, and both must be delivered into the support tool of choice. If an engineer has to leave the case to gather context, the improvement doesn't land and the data never makes it back onto the record.

Just as importantly, these improvements should be delivered by the support team wherever possible. The people working cases already know the three queries they run every time and the five checks that resolve half a dozen cases in the queue each morning. If there's a constraint preventing this from living in the product, give the team the means to turn them into an agent skill, along with a review process that makes it safe.

When context assembles itself and the routine debugging has already run, the engineer opens a case already standing at the edge of what's known. That's where you want their day to start, and it's the difference between a team that enjoys hard problems and a team that dreads the queue.

Retro

Every closed case has already paid for itself once. The second payment comes from what the team learns and it only arrives if somebody asks the question: why couldn't this have been handled without a human?

There are broadly four answers.

It's a product shortcoming. The product behaved as designed yet the design is wrong, misleading or missing. No amount of knowledge would have saved this one. It goes to engineering with the volume, the trend, the customer names and the revenue attached.

There's a human-friendly knowledge gap. The answer existed but wasn't evidenced. Patch the playbook.

There's an agent-friendly knowledge gap. This is the most common and the most neglected. The answer existed somewhere, but not in a form an AI agent could retrieve, scope or trust, so it couldn't interpret the issue or propose anything useful. Patch the documentation, including the short-term gotchas, incident notes and live edge cases that would never make it into formal documentation.

Separating the types of knowledge gap matters, because they have genuinely different fixes. A paragraph a seasoned engineer reads correctly can be hopelessly ambiguous to an agent, and the reverse is true just as often.

Lastly, we have net-new issues. The context was there, the documentation was good and the machine still couldn't make sense of it. Here, the retro isn't a correction, it's an addition. The issue becomes knowledge, the knowledge reaches the agent and the product, and the next time it appears it won't be net new to anyone.

Not every team can afford the capacity to retro every case by hand which is exactly why this is where AI earns the most and is deployed the least. A model can read every closed case in a quarter, propose the clusters, name the gaps and draft the articles. The human effort shifts from finding the problem to deciding what to do about it.

Stopping the Line

The uncomfortable part of the factory analogy is that, often, factories stop the line. When a defect appears, production halts rather than producing a thousand more of the same fault.

Support teams almost never stop the line. They absorb. Absorption looks like excellent service, and in the moment it is, but it's also an unrecoverable cost the support team pays on behalf of the product. It's also what keeps talented people working cases a machine could have closed, which is the fastest way to lose the people capable of solving the ones it can't.

During ingress, handling and retros, the same case can be seen three times and each pass should leave something behind. If a case leaves nothing behind but a closed status, the factory has hand-built one unit and learned nothing.

A support team which deals exclusively with net-new issues isn't a quieter support team. The cases that remain will be harder, stranger and more interesting than anything in the queue today, and they'll need people who are sharp, rested and genuinely expert. Getting there and staying there means building and maintaining a line that handles everything else.