On-time delivery from 71% to 94%, without buying a single extra truck.
Four warehouses180 vehicles2,600 staff
The situation
What we found
On-time delivery sat at 71%. Warehousing, transport and sales each reported healthy numbers, and each blamed one of the others.
Loading disputes were constant. A vehicle left, a customer received short, and there was no record of what had actually gone onto the truck.
Warehouse staff spent a large share of the shift looking for stock that the system said was there.
Access to bonded and high-value areas was controlled by a card, and cards were routinely shared during busy shifts.
Fishbone: sort the causes before arguing about the cure
The same late certificate, with every plausible cause grouped by category. Six categories, revealed one at a time. The highlighted item in each is the one worth acting on.
The effect we are explainingCertificates are issued three weeks late
People
Only one officer authorised to approve
New staff trained by sitting next to someone
No cover when the approver travels
Process
Eleven approval points, six unexplained
Work goes backwards when a document is missing
No target turnaround at any step
Systems
Four systems holding four versions of the record
Data re-keyed by hand between them
No alert when an item exceeds its target
Measurement
Turnaround reported quarterly, if at all
No distinction between working and waiting time
Nobody owns the number
Environment
Peak demand in two short windows a year
Applicants travel far, so they come in person to chase
Materials
Application form asks for documents applicants rarely hold
Forms accepted incomplete, then chased later
Fishbone does not tell you the answer. It stops the meeting from settling on the first cause somebody names loudly — which is usually People, and usually wrong.
Illustrative
Root cause
Sort the causes before arguing about the cure.
Three departments each blamed the other two. A fishbone stops that argument by putting every plausible cause on the table at once, grouped, before anyone proposes a solution.
Plan, Do, Check, Act: the smallest useful improvement loop
Four quarters. The discipline is not in the diagram — it is in actually completing the fourth quarter instead of starting something new.
Plan — Agree the change and how you will know it workedPick one thing. Write down the number you expect to move, and by how much. If you cannot name the number, you are not ready to start.
Do — Run it small, and run it for realOne department, one branch, one category. Long enough to see a pattern; small enough that being wrong costs very little.
Check — Compare what happened with what you expectedNot “did people like it” — did the number move? And if it moved, are you confident the change is why?
Act — Standardise it, or change it, or stopAll three are acceptable outcomes. Only one is not: carrying on because it was announced.
Most improvement programmes do Plan and Do enthusiastically, skip Check, and never reach Act. That is why so many changes are announced twice.
Illustrative
The workflow
The same service as a workflow, exceptions and all.
The despatch workflow, with the disputes designed out
Every exception below used to be an argument at the end of the month.
1
Order picked against a directed route
The picker is told where to go rather than searching. Stock location is live, not a morning snapshot.
Warehouse pickerRTLS location
2
Pallet built and tagged
The pallet gets an identity, and its contents are written against it once.
Warehouse pickerUHF pallet tag
3
Pallet crosses the loading bay portal
Contents and time recorded automatically as it goes onto the vehicle.
No staff involvementDoorway reader portalAutomatic
If the load does not match the orderThe discrepancy is raised before the vehicle leaves, which is the only moment it is cheap to fix.
4
Vehicle departs against a sealed manifest
The manifest is what the portal read, not what somebody typed.
TransportDespatch systemAutomatic
5
Delivery confirmed at the customer
Received quantity recorded against the same pallet identity.
DriverHandheld reader
If the customer receives shortThe gap is traced to a bay, a time and a vehicle within minutes rather than being written off at month end.
6
One number reviewed weekly
On-time delivery, by route and by customer, with the owner in the room.
Delivery ownerPerformance dashboard
Illustrative scenario
The work
What we put in
What we put in, and in what order
The diagnosis said the problem was between departments. The design had to be too.
1
Stage one
One owner for the end-to-end delivery
Not a new department — a named executive whose number is on-time delivery, not warehouse productivity or fleet utilisation.
2
Stage two
Tag the pallets and cages, not the products
UHF tags at pallet level, which is where the disputes happen. Product-level tagging would have cost ten times more and answered a different question.
3
Stage three
Loading bays that record what actually left
Reader portals on every bay door. What went onto the vehicle is now a fact with a timestamp, not a signature on a note.
Loading disputes fell by 90%
4
Stage four
Locate stock instead of searching for it
Real-time location across the warehouse floor, so a picker is directed rather than sent looking.
Picking time down by a third
5
Stage five
Access that matches the person
Facial recognition on bonded and high-value areas, with fingerprint confirmation on stock adjustments.
6
Stage six
One weekly meeting on one number
Thirty minutes, three departments, one measure: did the customer receive it on time? Everything else is secondary.
Illustrative scenario
The result
What changed
Two quarters later
Same fleet, same warehouses, same headcount.
On-time delivery71%
Loading disputes each monthAround 60
Share of a picker’s shift spent searchingAbout a third
Who owned on-time deliveryNobody
Time to resolve a short deliveryWeeks, if ever
Three departments, three sets of healthy numbers, one unhappy customer.
On-time delivery94%
Loading disputes each monthSix
Share of a picker’s shift spent searchingUnder 10%
Who owned on-time deliveryOne named executive
Time to resolve a short deliveryMinutes
The largest single change was the one that cost nothing: naming an owner.
Illustrative scenario
The technology
What each piece is actually for
The technology, in plain words
Chosen after the fishbone, not before it. Two categories of cause needed technology; three did not.
UHF pallet and cage tagsLong-range tags at the level where disputes actually happen. Tagging individual products would have cost far more and answered a different question.Warehouse and despatch
Loading bay portalsReaders at the bay door recording what physically went onto the vehicle, with a timestamp.Every loading bay
Real-time locationLive positions on the warehouse floor, so pickers are directed instead of searching.Warehouse floor
Handheld readersDelivery confirmed against the same pallet identity at the customer’s premises.In-cab and at delivery
Facial recognitionAccess to bonded and high-value areas that cannot be handed to a colleague during a busy shift.Restricted areas
Fingerprint recognitionA deliberate confirmation on every stock adjustment, attached to a person.Stock adjustments
Illustrative scenario
About this case study.
Large Enterprise is a fictional organisation. The situation, the figures and the outcomes are
illustrative — they show how BTS Consulting approaches a problem of this shape and
what the technology involved actually does. They are not a record of a delivered project,
and nothing here should be read as a client result.
More case studies
The same approach, different sector
A state university
Higher Education
A university where every department held its own version of the student, and nobody could say where the laboratory equipment was.
Tell us where performance is being slowed, hidden or lost. We will help you define the problem, identify the priority actions and build a practical path forward.
