Your Frontline Teams Already Know What's Not Working

Ask the people delivering the service every day and they will usually tell you where work becomes difficult. They know which steps cause confusion, which information is regularly missing, which process takes longer than it should and which customer question keeps coming back.

They know which handovers cannot be relied upon.

They know which system fields they have learned not to trust.

They know which tasks depend on one experienced person remembering what to do.

They also know where the official process stops working and the workaround begins.

Frontline employees are often the first people to notice that something is going wrong. Long before an issue becomes a formal complaint, appears in a report or reaches a leadership meeting, someone close to the service has probably already seen the warning signs.

The question is whether the organisation has asked them.

Most organisations have plenty of service data.

There may be reports showing response times, resolution times, customer satisfaction, complaints, productivity and performance against agreed targets.

That information matters. It can show patterns, measure outcomes and help leaders understand whether performance is moving in the right direction.

But much of it tells us what has already happened.

Frontline teams see what is happening now.

They hear customers asking the same question several times a day. They notice when a new process creates more work rather than less. They see when information does not move properly between departments and when customers have to repeat something they have already explained.

They are also the people dealing with the consequences.

A missed step elsewhere may arrive with them as an urgent request.

An unclear promise may become a difficult customer conversation.

A weak handover may leave them trying to reconstruct information that should have travelled with the work.

A system problem may mean completing the same task twice just to make sure nothing is missed.

Each example can look small when viewed on its own. Repeated across a team, a customer base or an entire year, it can represent a significant amount of lost time and unnecessary effort.

By the time that impact becomes obvious in the numbers, the people delivering the service may already have been managing it for months.

There can be a noticeable difference between a process as it is documented and a process as it is delivered.

On paper, the work may move cleanly from one stage to another. Responsibilities appear clear. Information is captured once and passed to the next person. The customer receives an update at the right time.

In practice, someone may be maintaining a separate spreadsheet because the system does not show what they need.

A colleague may be sending themselves reminders because there is no dependable trigger for the next action.

A team may be checking every handover manually because too many have previously arrived incomplete.

Customers may be calling for updates because the process does not clearly identify who should contact them.

The service continues because employees find ways to keep it moving.

That resourcefulness can hide the extent of the underlying problem.

From a distance, the process may appear to be working because the task is eventually completed. What is less visible is the chasing, checking, correcting and compensating happening around it.

This is why “What's not working?” is a more useful question than it may first appear.

It encourages people to describe the work as it really happens, rather than confirming whether they know what the process is supposed to be.

The answers might include:

These comments are not simply complaints. They are service evidence.

Most businesses have workarounds.

Some are visible and widely accepted. Others sit quietly inside individual teams.

They may be spreadsheets, personal checklists, saved email templates, Teams messages, duplicate records or manual checks that have never formed part of the official process.

The immediate response can be to remove them and tell people to follow the agreed way of working.

Sometimes that is necessary. Uncontrolled workarounds can create inconsistency, risk and an unhealthy reliance on individual knowledge.

But removing the workaround without understanding why it exists can make the service harder to deliver.

People usually create these methods because something they need is missing.

The system may not provide enough information.

The process may not account for what happens in practice.

Ownership may be unclear.

A handover may be unreliable.

An important check may never have been included.

The official route may take so long that employees have found another way to help the customer.

The workaround may not be the right answer, but it can still point towards the right problem.

A useful question is not simply, “Why are people doing this differently?” It is: what problem is this workaround helping them overcome?

That answer may reveal a system limitation, a training gap, an unclear responsibility or a process that was designed without enough input from the people expected to deliver it.

Not every frustration needs to become a transformation project.

People will have individual preferences. Services will occasionally experience unusual problems. No process will remove every exception.

The value comes from listening for patterns.

If several people describe the same difficulty, it is worth investigating.

If customers repeatedly ask the same question, the communication may not be clear enough.

If one team is continually chasing another, the handover or ownership may need attention.

If employees are duplicating information, the systems or processes may not be properly connected.

If the service depends on one person's memory, the business may be carrying more risk than it realises.

The original comment may sound minor: “We always have to check that manually.”

But what sits behind it?

How often does the check happen? How long does it take? What would happen if nobody completed it? Why is the information not trusted? How many people are repeating the same task?

A five-minute check completed by one person may not appear significant.

The same check completed several times a day, across a whole team, becomes something different.

The same is true of customers having to call for an update, employees re-entering information or account managers stepping in to recover trust after an avoidable failure.

Transformation opportunities are not always announced by one dramatic event.

They are often found inside ordinary sentences that people have repeated for so long that nobody stops to examine them.

Asking frontline teams what is not working should not result in an unstructured list of everything people would like to change.

The issues need to be understood in context.

How frequently does the problem occur? Who is affected? Does it create more effort for the customer?

How much employee time is spent managing it? Does it cause delay, rework or avoidable contact?

Is there a financial, quality or operational risk? Does the issue sit within one team, or does it appear at a point where several departments meet?

What happens when the person who normally compensates for it is unavailable?

These questions help separate an isolated frustration from a repeat service issue.

They also make prioritisation easier.

A problem does not have to be dramatic to deserve attention. Something small that occurs hundreds of times can create more cost and pressure than a larger issue that happens once a year.

Customer impact matters. Employee impact matters too.

When employees have to repeatedly chase information, correct preventable mistakes or apologise for decisions they did not make, it affects their ability to provide a good service.

The customer and employee experience are often showing different sides of the same operational problem.

There is a risk in asking people what is not working.

Once the question has been asked, employees need to see that their answers went somewhere.

That does not mean every suggestion must be implemented or every issue fixed immediately. Businesses have competing priorities, limited resources and dependencies that cannot always be removed quickly.

But there should be a visible response.

What has been heard? What needs more evidence? What has been prioritised?

Who owns the next step? What cannot be changed yet? When will the issue be reviewed again?

Without that feedback, people can stop raising problems.

They may continue using the workaround, managing the additional effort and helping customers around the gaps, but they no longer explain what is happening.

The organisation may then assume that fewer issues are being reported because the service has improved.

Sometimes the opposite is true.

People have simply decided that raising the same problem again is not worth their time.

Silence is not always evidence that everything is working.

It can also be evidence that the feedback loop has failed.

Useful service insight is easily lost.

It can remain in meeting notes, email chains, individual documents and informal conversations. The same problem may then be rediscovered several times by different people without ever becoming owned.

There needs to be a consistent place to capture what teams and customers are experiencing.

That does not require an unnecessarily complicated system.

A continuous improvement register can be enough, provided it records the problem clearly, the available evidence, the impact, the owner and what is expected to happen next.

The important part is visibility.

People should be able to see that an issue exists, that it has not been forgotten and that someone is responsible for progressing it.

This also helps connect everyday operational issues with the wider transformation agenda.

Not every improvement needs a large programme, a new platform or a lengthy business case.

Sometimes a clearer handover, a better system prompt, an agreed owner or the removal of one unnecessary step can make a meaningful difference.

But those opportunities are easy to miss when improvement is designed at a distance from the people doing the work.

Transformation often begins with discussions about technology, automation, operating models and future-state processes.

Those conversations have their place.

But before deciding what the organisation should introduce, it is worth understanding what is already making the service harder than it needs to be.

The people on the front line usually know.

They see where customers become confused.

They know where information goes missing.

They recognise which process only works because someone steps in and holds it together.

They are often the earliest indicators of a service issue, because they encounter the first signs before the full impact reaches the data.

So before designing the roadmap, choosing the platform or deciding what needs to change, start with the people closest to the work.

Ask them: what's not working?

Then listen carefully to the answers, look for the patterns and make sure what you hear has somewhere to go.