Relief from Friction

When a Simple Change Needs Three Departments

A small change, such as a new bank detail or a revised delivery address, can take weeks when three teams must agree. Where the delay comes from and how to shorten it.

Mellorca Moments2026-11-01

Some requests sound small. A supplier changes their bank account. A customer moves to a new delivery address. A team wants one extra field on a form. In a small business, someone makes the change in a minute. In a larger one, the same request can pass through finance, operations and IT, and each of them has a reason to look at it before it goes ahead.

This piece looks at why simple changes collect several approvals, what the waiting costs the people involved, and how a business can keep the safeguards without the delay. It is a hypothesis drawn from general process and workflow guidance, not a finding about any particular South African employer.

Why one change needs three teams

Approval chains are rarely designed in one go. They accumulate. A payment goes to the wrong account once, and finance adds a check. A system update breaks a report, and IT asks to see every change. A delivery goes astray, and operations wants to confirm the address. Each addition made sense on the day it was introduced.

The trouble is that the chain is built from the worst day, then applied to every day. A change that carries almost no risk goes through the same three desks as one that carries a lot, because nobody has a way to tell the two apart at the start. The questions are usually reasonable. The trouble is that they are asked in sequence, by people who each see only their own part.

Three patterns tend to appear:

  • Sequential handoffs. Each team waits for the one before it, so waiting times add up even when each review takes minutes.
  • Repeated questions. The same background has to be explained to each team, because the request carries no shared record of what has already been checked.
  • Unclear ownership. When a request stalls, nobody is responsible for chasing it, so the person who raised it becomes the courier.

What workflow documentation offers

Modern workflow tools were built for exactly this problem. Microsoft's documentation on approvals in Power Automate describes how a request can be routed to several approvers at once or in sequence, with a record of who decided what and when. The distinction is useful even without any tool. Approvals that can happen in parallel do not need to be queued one behind the other, and a recorded decision does not need to be asked for twice.

The UK Health and Safety Executive's management standards on change make a related point from the human side: people cope better with change when they are told what is happening, consulted, and given a way to raise concerns. The standards were written about organisational change, yet the principle carries over to the small requests that make up most of daily work. Being left to wait without information is a cost in itself, and the World Health Organization's guidance on mental health at work likewise names poor communication and low control among the working conditions that can harm wellbeing.

An illustrative case

Consider an illustrative example, not a real case: a Pretoria building-supplies distributor with a head-office team of thirty. A regular customer asks to move their account to a new delivery address and to add a second contact for invoices. The sales coordinator raises the request by email.

Finance asks for proof of the address and wants to confirm the change with the customer. Operations asks whether the new address is inside the existing delivery zone. IT asks whether the second contact needs access to the customer portal, and for what. Each question arrives on a different day, from a different person, and two of them overlap. Twelve working days later the change is made. In the meantime a delivery has gone to the old address, and the sales coordinator has spent more time chasing the change than the customer spent asking for it.

The human tax: time and energy

The obvious cost is time, and not only the elapsed days. The person who raised the request carries it in their head the whole time, checking for replies and rewording the question for each team. That follow-up is real work that appears on no timesheet.

The second cost is energy. Waiting for permission to do something that should be routine is draining in a particular way. The task cannot be finished, so it cannot be forgotten, and it competes for attention with everything else. People who work in such a chain also learn to avoid raising small changes at all, which leaves errors in place that would have been cheap to fix.

The reviewers are affected too. A finance clerk who receives a dozen low-risk requests a day, each needing a manual look, has little room to concentrate on the one request that is truly suspicious. Treating every change as risky is a good way to lose sight of the ones that are.

What could realistically change

The goal is not to remove checks. A changed bank detail is a well-known route for payment fraud, and finance is right to look at it. The goal is to match the checking to the risk and to stop making people carry the request from desk to desk. The piece on why approval chains make capable people wait explains how capable staff come to be stuck in these queues, and when a request disappears into a queue nobody can see describes the visibility problem from the requester's side.

Practical next actions

  1. Map one real change. Pick a recent small request and trace it from start to finish, noting each handoff, each question and each waiting period. The map usually shows that the checking took minutes and the waiting took days.
  2. Sort changes by risk. Agree two or three categories, such as low-risk, financial and system-affecting, and decide which teams must see each. A new contact name need not travel the same road as a new bank account.
  3. Run reviews in parallel. Where the reviews do not depend on each other, send the request to every team at once, with a shared note of what is being asked and by when.
  4. Keep one record. Give the request a single place where questions and answers are kept, so that nobody has to be asked twice and the requester does not become the courier.
  5. Name an owner and a deadline. One person is responsible for moving the request along, and each team has a stated response time. The note on the lunch break eaten by approval requests shows why approvers also need a predictable rhythm for dealing with them.

The business outcome

A business that matches checks to risk spends its careful attention where it matters. Low-risk changes happen quickly, customers see their requests honoured within days, and the high-risk ones receive a proper look from people who are not buried. Errors from stale data fall, because it is no longer easier to leave a wrong detail in place than to correct it. The business also learns which of its checks actually catch problems and which only add delay, which is useful information for any future redesign.

The human dividend

The dividend is time: the hours spent chasing returned to the work the person was hired to do. Alongside it comes lighter mental load, because a request that is moving, visible and owned does not have to be held in memory. What people do with those hours is theirs to choose, whether that is deeper work on a customer, a proper lunch or an earlier finish.

The trade-offs

  • Faster can mean riskier. Simplifying a chain removes some eyes from a request, so the risk categories must be drawn carefully, particularly around payment details.
  • Parallel review needs discipline. If every team answers late, parallel routing only shows the delay more clearly.
  • Tools do not fix unclear rules. Automating a confusing process produces a faster confusing process, so the rules should be settled first.
  • Some approvals are legal or contractual. They cannot be dropped, though they can often be scheduled and made visible.

Why it matters

Approvals exist to protect the business, and many of them earn their place. But a protection that costs everyone a fortnight for a trivial change is worth redesigning. When checks follow the risk, and requests travel on their own rather than on a person's back, the safeguards stay and the friction goes.

Sources and further reading

Related Mellorca reading

Article summaryA small change, such as a new bank detail or a revised delivery address, can take weeks when three teams must agree. Where the delay comes from and how to shorten it.