Before You Automate the Service, Make Sure It Works

There are some genuinely exciting opportunities. Used well, the technology can reduce repetitive work, give customers quicker access to information, support employees and make services much easier to use.

It sounds obvious, but I think it is an important place to start. Most businesses have processes that look perfectly reasonable when you see them documented. The problem is that the documented process and the way the service actually operates are not always the same thing.

Talk to the people delivering the service every day and you will often hear a different version.

They know which team normally has to be chased. They know which information is regularly missing. They know the part of the process that causes customers to call back. They know which knowledge article is out of date and which workaround everybody uses because the official process does not quite work.

Sometimes a process works simply because experienced employees have become very good at compensating for its weaknesses.

That matters when you start thinking about automation.

Before deciding what can be automated, I would spend time understanding how the service really works.

I would speak to the people delivering it and ask them what keeps going wrong. Where do customers get stuck? What do employees repeatedly have to fix manually? Where do handoffs break down? Which parts of the process rely on somebody knowing something that isn't actually documented anywhere?

Those conversations can tell you a huge amount.

Imagine there is a handoff between two teams that regularly causes problems. The first team completes its part and transfers the work to the second, but nobody has clearly defined who owns the customer communication during that transition.

Sometimes the first team updates the customer. Sometimes the second does. Sometimes both assume the other has done it and the customer hears nothing.

You could automate that handoff and make the transfer happen almost instantly.

But you would still have exactly the same ownership problem.

The technology might have improved the speed of the process while the customer continues wondering what is happening.

That is why I would want to understand and fix the service design before deciding how technology should support it.

Knowledge is another area where this becomes particularly important.

Experienced employees often know when documentation is wrong or out of date. They know that the official process changed six months ago but the knowledge article never quite caught up. They know that a particular customer or situation is an exception. They know when following the written instructions literally is likely to create another problem.

Over time, people learn to compensate for those gaps.

AI will increasingly rely on that information to support employees and, in some cases, answer customers directly. That makes the quality of the knowledge behind the service incredibly important.

If the information is poor, the answer can be poor too.

Before introducing AI into that part of a service, I would want to understand who owns the knowledge, how regularly it is reviewed and whether employees actually trust it.

I would also ask employees where they regularly ignore the documented guidance and why.

That question could uncover far more than a knowledge-management issue. It may reveal that the process itself has changed, that exceptions have never been properly designed for, or that the documented version of the service simply does not reflect reality anymore.

One of the things that interests me most about automation is how much judgement experienced people apply without necessarily realising they are doing it.

Someone working in a service role for several years can often spot when something does not look right. They may recognise that a customer is becoming frustrated before a complaint is raised, understand that an escalation is commercially sensible even if the technical criteria have not quite been met, or realise that several apparently separate issues are probably connected.

None of that necessarily appears on a process map.

It has developed through experience.

That is why understanding the human part of the service matters before deciding how much of it should be automated.

There will be plenty of opportunities for AI to support that judgement, surface useful information and remove repetitive tasks. But first you need to know where judgement is currently happening.

Otherwise, there is a risk of removing one of the things that was quietly holding a weak process together.

There is another question I think businesses should ask before automating customer contact.

Why is the customer contacting us?

If hundreds of customers are asking the same question every month, building an automated way to answer it might seem like the obvious solution.

Sometimes it will be.

But I would still want to know why they need to ask.

Perhaps the information on the website is unclear. Perhaps an automated email does not tell customers what happens next. Perhaps they cannot see the status of their request. Perhaps a process regularly fails and the contact is simply the customer trying to find out what has happened.

If you automate the answer, you may reduce some of the workload involved in responding.

If you fix the reason customers are asking, you may remove the contact completely.

That is a much more valuable improvement.

It reduces effort for the customer and for the business at the same time.

I am very supportive of self-service when it genuinely makes the customer's life easier.

There are plenty of situations where customers would rather get an immediate answer than wait for somebody to become available. They may want to make a change, find some information or complete a simple task at a time that suits them.

That is good service.

The problem comes when self-service simply creates another layer for the customer to work through.

Most of us have probably experienced some version of this. You ask a chatbot a question, it cannot quite understand what you need, it sends you to an article that does not answer the question, you eventually submit a form and then, when you finally speak to somebody, you have to explain everything again from the beginning.

From the business's perspective, several parts of that journey may have been automated.

From the customer's perspective, getting help became harder.

That distinction is important.

If we are measuring whether automation has improved a service, I would want to look beyond the number of interactions handled automatically. Did customers get the right answer more quickly? Did repeat contact reduce? Did resolution improve? Did complaints fall? Did customer effort reduce?

Those outcomes tell us whether the experience actually improved.

The more technology you introduce into a service, the more important I think end-to-end ownership becomes.

One team might own the technology, another the process, another the knowledge and another the customer relationship. Each team can be doing its own part well while the overall experience still has gaps.

Someone needs to look across all of it.

What happens when the automation cannot deal with the request? Can the customer reach a person easily? Does the person receiving the escalation understand what has already happened, or does the customer have to start again?

Who monitors the interactions that fail? Who looks at the reasons customers keep dropping out of the automated journey? Who connects that information with complaints, frontline feedback and operational data?

Those are service questions rather than technology questions, and they still need somebody to own them.

In fact, I think they become even more important as services become more automated.

There are going to be some huge opportunities for AI and automation in service delivery, and I think businesses should absolutely explore them.

But I would start with the service rather than the technology.

Understand what is not working today. Talk to the people who deliver it. Look at where customers are having to make repeated contact. Follow the handoffs. Check the knowledge. Find the workarounds. Understand where ownership becomes unclear and where experienced employees are compensating for weaknesses in the process.

Then decide what should be fixed, what could be removed completely and where automation would genuinely make things better.

That also gives you a much clearer way of measuring success afterwards. You know what problem you were trying to solve, so you can see whether the change actually solved it.

AI can bring enormous capability into service delivery. The businesses that get the most from it will, I think, be the ones that understand their services well enough to know where that capability will genuinely add value.