The Process Leak: When Good Employees Are Trapped in Bad Systems

woman frustrated at laptop in 202604302001.webp

A customer is promised one thing by sales, told something different by customer service and delayed while operations waits for information.

Each employee may have completed the task assigned to them. Sales secured the customer. Customer service answered the inquiry. Operations followed the procedure.

Yet the overall experience failed.

From inside the organisation, the individual activities may appear reasonable. From the customer’s perspective, they form one confusing and frustrating journey.

The customer does not experience the organisational chart. They do not separate the sales department from operations, finance, technology or customer service. They experience one organisation—and hold that organisation responsible for the complete outcome.

When the experience begins to deteriorate, management frequently turns first to the frontline. Employees are reminded to communicate better, attend another customer-service training session or demonstrate a more positive attitude.

Sometimes that intervention is necessary. Individual competence, judgment and behaviour matter.

But training an employee to smile, apologise or communicate politely will not resolve an inaccurate database, an approval bottleneck, a broken handoff or a process that gives three departments different versions of the truth.

What appears to be a people problem may actually be a process leak.

The experience is created before the interaction

Customer experience is often discussed as though it begins when an employee speaks to a customer.

In reality, much of the experience has already been determined.

Before the employee answers the telephone, the organisation has decided—deliberately or by default:

  • What information the employee can access.
  • Which decisions they are authorised to make.
  • How many approvals are required.
  • Which department owns the customer’s request.
  • Whether systems share accurate information.
  • How exceptions are handled.
  • How quickly another team must respond.
  • Whether the employee can see what the customer was previously told.
  • What performance measures will influence the employee’s priorities.

The frontline interaction is often the point where the customer encounters the consequences of these earlier decisions.

An employee may recognise the correct solution but lack the authority to provide it. They may want to give the customer an accurate update but be unable to see the status of the request. They may be measured on call duration even though resolving the issue properly requires more time.

The employee becomes the visible face of a problem they did not create and may not have the power to correct.

What I mean by a process leak

A process leak occurs when the design or operation of an internal process causes avoidable loss in the customer journey.

That loss may appear as:

  • A delayed sale.
  • An abandoned application.
  • Repeated customer contact.
  • A missed delivery commitment.
  • An unresolved complaint.
  • A refund or rework cost.
  • A failed renewal.
  • Reduced trust.
  • Employee time spent correcting preventable problems.
  • A customer who quietly chooses another provider.

Not every inefficient process produces a customer or revenue leak. Some internal inefficiencies have little effect outside the organisation.

The concern arises when an internal breakdown changes the customer’s outcome, increases the effort required to obtain it or creates commercial exposure for the business.

The leak is therefore not merely “the process is slow.” It is the measurable or probable loss created because the process is slow, fragmented, unclear or unreliable.

Process and people cannot be separated completely

It would be too simplistic to argue that every service failure is caused by the system and that employees bear no responsibility.

Employees can disregard clear procedures, communicate poorly, withhold information or fail to exercise reasonable judgment. Performance management and training remain necessary.

But the opposite assumption is equally dangerous: that recurring customer failures are simply the result of careless employees.

When the same problem occurs across several employees, departments, branches or periods, I become less interested in who made the latest mistake and more interested in the conditions that keep producing it.

A useful diagnosis asks two separate questions:

  1. Did the employee have the capability, information, authority and incentive required to deliver the expected outcome?
  2. Given those conditions, did the employee exercise appropriate judgment and perform responsibly?

This prevents management from using “the system” to excuse poor performance—or using the employee to conceal poor design.

Where process leaks commonly develop

Process leakage rarely results from one dramatic failure. It usually emerges through a series of small breakdowns that accumulate across the journey.

1. The promise and the delivery process are disconnected

Sales teams are encouraged to win business. Operations teams are expected to manage feasibility, cost and risk.

When these functions are poorly aligned, customers may be promised timelines, features or outcomes that the delivery process cannot reliably support.

Sales believes it has successfully converted the opportunity. Operations receives a commitment it did not help shape. Customer service later has to explain why the promise cannot be fulfilled.

The problem is not necessarily that one department is acting in bad faith. Each may be responding rationally to its own targets.

The leak develops because the organisation has not aligned the promise it makes with its capacity to deliver.

Management should therefore examine:

  • Who determines what can be promised?
  • Do customer-facing employees have current information about operational capacity?
  • How are exceptions approved?
  • Are failed commitments traced back to their source?
  • Do sales and operations share accountability for the final customer outcome?

A promise should not be treated as successful merely because it secured the sale. Its value depends on whether the organisation can fulfil it.

2. Handoffs transfer work but lose context

Many customer journeys require several departments. The existence of handoffs is not the problem. The problem is what disappears during them.

A customer explains their need to one employee. The request moves to another department, but the context does not move with it. The customer is asked to repeat the information. Documents are requested again. A commitment made earlier is no longer visible.

Internally, the case was transferred.

From the customer’s perspective, responsibility was abandoned.

A reliable handoff should transfer at least four things:

  • The customer’s need.
  • The information already collected.
  • The commitments already made.
  • Ownership of the next action.

If any of these elements is missing, the receiving employee must reconstruct the case—often with the customer doing the work.

3. Nobody owns the complete outcome

Processes are frequently divided into tasks, with each department responsible for one part.

The customer, however, needs an outcome.

This creates a common accountability gap. Every task may have an owner while the end-to-end journey has none.

One team receives the request. Another verifies it. A third approves it. Someone else communicates the decision. When progress stops between these stages, each department can correctly say that it completed its part.

The customer is left with a problem that belongs to everyone in theory and no one in practice.

End-to-end ownership does not mean one person must perform every task. It means someone remains accountable for ensuring that the customer’s need progresses across departmental boundaries.

4. Information exists but is not reliably available

An organisation may possess the information employees need while still failing to make it usable.

Customer records may sit in separate systems. Payment information may take time to reach service teams. Product terms may be stored in outdated documents. Important updates may circulate informally through email or messaging groups.

Employees then rely on memory, personal relationships or manual workarounds.

Some experienced employees learn how to navigate these gaps. Newer employees struggle. Customers receive different answers depending on who assists them.

What appears externally as inconsistent employee competence may actually reflect inconsistent access to information.

The diagnostic question is not simply whether the information exists. It is whether the right employee can find and trust it at the moment a customer needs help.

5. Queues disguise delay as work

A request may require only a few minutes of actual processing but take several days to complete.

The difference is waiting time.

The request sits in an inbox, awaits approval, moves between teams or remains unattended because its status is unclear. Each department may complete its own activity quickly once the case reaches it, while the customer experiences a long overall delay.

This is why departmental turnaround time can look satisfactory even when the end-to-end journey is slow.

I would therefore distinguish:

  • Work time: How long the task requires when someone is actively handling it.
  • Wait time: How long the request remains inactive between actions.
  • Total journey time: How long the customer waits for the complete outcome.

In many journeys, the greatest delay is not created by difficult work. It is created by the spaces between work.

6. Exceptions expose the real process

A standard process may work well when every customer provides the correct information, every system functions and every request follows the expected path.

Customer experience is often tested when something unusual happens.

A payment is made but not reflected. A document is missing. The customer’s circumstances do not fit a standard category. A technology failure interrupts the journey. An approval is required from someone who is unavailable.

If the organisation has no clear way to manage exceptions, employees improvise. Outcomes then depend on individual experience, influence or persistence.

An organisation should not judge its process only by how it handles the ideal case. It should examine what happens when reality departs from the design.

7. Feedback remains with the people who see the problem

Frontline employees often know where the process fails.

They know which form confuses customers, which approval causes repeated delays and which system forces them to duplicate work. Customers also reveal process weaknesses through questions, complaints, abandoned applications and repeated contact.

Yet this evidence is rarely assembled into a form that management can act upon.

A customer’s comment remains in an employee’s notebook. A workaround becomes accepted practice. A recurring complaint is resolved case by case without changing the process that creates it.

The organisation continues to pay for the same failure because each occurrence is treated as a new incident.

Feedback becomes valuable only when it moves from observation to evidence, ownership and corrective action.

The cost extends beyond the visible complaint

A process leak rarely produces only one consequence.

Consider a customer who calls because a request has been delayed. The organisation may record one complaint, but the full cost could include:

  • The original processing delay.
  • The customer’s additional effort.
  • Time spent by the frontline investigating the case.
  • Time spent by a supervisor authorising an exception.
  • Rework by the responsible department.
  • The cost of apologising, refunding or compensating the customer.
  • Reduced confidence in the organisation.
  • A lower likelihood of renewal or repeat purchase.
  • Negative commentary shared with others.
  • Employee frustration caused by repeatedly managing preventable failures.

If management measures only the complaint, it sees the symptom but not the accumulated exposure.

This is why process leakage must be evaluated across customer impact, operational cost and commercial consequence.

Follow the work, not only the procedure

Many organisations have documented procedures that appear logical on paper.

The more revealing question is whether work actually happens that way.

Employees frequently develop informal practices to compensate for weaknesses in the official process. They maintain personal spreadsheets, call colleagues directly, use private messaging groups or skip steps that appear unnecessary.

Some workarounds help customers in the short term. But they also make performance dependent on particular individuals and conceal defects in the formal system.

When I review a process, I therefore want to compare three versions:

  1. The intended process: What the policy or procedure says should happen.
  2. The operating process: What employees actually do to move the work forward.
  3. The customer journey: What the customer ultimately experiences.

The gaps between these three versions often reveal where leakage is occurring.

How I would diagnose a process leak

A useful review begins with a real customer case, not an abstract flowchart.

Select several completed, delayed, abandoned and failed cases. Trace each one from the customer’s first action to the final outcome.

At every stage, ask:

  • What was expected to happen?
  • What actually happened?
  • How long did the work take?
  • How long did the request wait?
  • What information was required?
  • Where did information have to be entered again?
  • Which commitments were made to the customer?
  • Who owned the next action?
  • Which approvals were necessary?
  • Where did the case move backwards?
  • What exception or workaround occurred?
  • When did the customer have to make repeated contact?
  • What customer, operational or financial consequence followed?

The purpose is not to find someone to blame. It is to identify where the design makes failure more likely and where individual behaviour still requires attention.

Useful indicators may include:

  • End-to-end completion time.
  • Time spent waiting between departments.
  • Handoff failure rates.
  • Number of customer contacts required for one outcome.
  • Percentage of cases returned for missing or incorrect information.
  • Rework and correction rates.
  • Unresolved exceptions.
  • Commitments missed.
  • Cases without a clearly recorded owner.
  • Complaints or cancellations linked to process breakdown.
  • Employee time spent on manual workarounds.
  • Revenue delayed, lost or placed at risk.

These measures help the organisation connect internal process performance to customer and commercial outcomes.

Redesign before retraining

Training is valuable when employees lack knowledge, skill or judgment.

But if employees are being trained repeatedly to compensate for the same structural problems, the organisation should stop and examine the process.

Before scheduling another service workshop, leadership should ask:

  • Do employees have one reliable source of information?
  • Are roles and decision rights clear?
  • Can the frontline resolve common issues without unnecessary escalation?
  • Are service promises aligned with operational capacity?
  • Does every handoff transfer context and ownership?
  • Can exceptions be identified and managed consistently?
  • Are teams measured on the complete customer outcome or only their departmental task?
  • Is recurring employee and customer feedback used to redesign the process?

Better employee performance and better process design should reinforce one another.

A capable employee operating in a poorly designed system will eventually become frustrated or develop workarounds. A well-designed system operated without care or judgment will also fail.

The objective is to create conditions in which good performance is both possible and repeatable.

Leadership owns the spaces between departments

The most persistent process leaks often sit between formal areas of responsibility.

No department sees the whole loss because each one sees only its part of the journey. The delay belongs to one team, the repeated call to another, the rework to a third and the eventual lost customer to no one in particular.

This fragmentation allows the organisation to report acceptable departmental performance while producing a poor overall outcome.

Leadership must therefore create accountability across boundaries.

That means identifying who owns the end-to-end journey, establishing shared measures and ensuring that one department’s success does not create failure elsewhere.

A sales team should not be celebrated for promises that operations cannot fulfil. An operations team should not meet its internal target by allowing customer cases to wait outside its measured processing period. A contact centre should not reduce call duration by transferring unresolved work to another queue.

Local efficiency is not success if the customer journey still fails.

Better experiences come from better operating design

Customer experience is not created solely through warmth, courtesy or communication.

It is produced by the organisation’s ability to coordinate people, information, decisions and work around the customer’s need.

In my work on Customer Leakage Intelligence, I am particularly interested in the point where an internal inefficiency becomes an external customer problem—and where that problem creates avoidable cost, lost trust or commercial exposure.

When the same customer failure keeps returning despite repeated reminders and training, I do not begin by asking why employees have not tried harder.

I ask:

What is it about the way work is designed that allows this problem to keep happening?

The answer may reveal missing information, conflicting targets, unclear ownership, an unreliable handoff or a process that works only when experienced employees find a way around it.

Good employees should not have to rescue customers from the organisation’s systems.

The real test of process design is whether it enables ordinary employees to deliver a reliable outcome consistently—even when the journey crosses departments, an exception occurs or the original plan goes wrong.