When pensions administration fails, adding people is the worst thing you can do
Yesterday, Capita and the Cabinet Office issued a joint statement apologising for service failures in the Civil Service Pension Scheme.
Members reported:
difficulty accessing the online portal
incomplete pension records
long call waiting times
delays to quotes and payments
In some cases, the consequences were severe enough to cause financial hardship.
The statement explains that when Capita took over administration on 1 December, it inherited a backlog of 86,000 cases, many already overdue. That backlog, it says, drove higher-than-expected call volumes and more complex queries, compounding the problem.
The recovery actions are familiar:
prioritising bereavement, ill-health and hardship cases
deploying a surge team of 150 additional staff
providing interim hardship support
appointing senior oversight to manage recovery
The apology is sincere.
The concern is genuine.
But the approach is wrong.
Not morally wrong.
Systemically wrong.
What this statement gets right — and what it misses
The statement does something important: it names the impact on members.
It acknowledges distress, worry, and real hardship.
That matters.
But when it comes to fixing the problem, it focuses almost entirely on capacity:
more people
more prioritisation
more oversight
more project activity
This assumes the issue is volume.
It isn’t.
What members are experiencing is the predictable outcome of how pensions administration systems are designed — not how hard people are working inside them.
The backlog is not the cause. It’s the evidence.
An 86,000-case backlog did not appear on day one of the contract.
Backlogs form when a system:
breaks work into specialist functions
measures activity instead of end-to-end flow
allows errors, rework and clarifications to return as new demand
absorbs regulatory change as “projects” rather than redesigning the work
Over time, demand caused by the system itself overwhelms the system.
The backlog is not the problem to be cleared.
It is the proof that the system has been failing for some time.
Changing the supplier does not change that.
Why adding 150 people will make things worse
This is the hardest point for leaders to accept.
When flow is broken, adding people increases:
hand-offs
queues
training load
variability
Every additional person becomes another interface the work must pass through.
The result is:
longer end-to-end times
higher contact volumes
more chasing
more “urgent” cases
You may clear correspondence faster in one area — but the system generates replacement demand elsewhere.
This is why surge teams feel productive and yet leave the organisation no better off six months later.
The system is still producing demand faster than it can absorb it.
Prioritisation is a humane response — and a damning one
Ring-fencing bereavements, ill-health retirements and hardship cases is absolutely the right thing to do for members.
But systemically, it tells us something uncomfortable:
the normal system cannot cope with normal demand.
When you must carve out exceptions to make the system work, you no longer have a stable system.
You have triage.
Triage saves lives.
It does not fix hospitals.
Treating McCloud as “extra work” guarantees rework
The statement describes McCloud remedy activity as a distinct project running alongside recovery.
This is a classic mistake.
Regulatory change is not additional demand.
It is predictable demand placed on the same system.
By separating it:
data is handled twice
members make multiple contacts
inconsistencies increase
failure demand is injected back into BAU
Projects do not fix operational systems.
They overload them.
What I would do instead
If I were asked to help recover this service, I would not start with people, targets or plans.
I would start with study.
1. Study demand properly — before doing anything else
I would ask:
Why are members contacting us?
How much of that demand exists only because something failed earlier?
Which cases should not exist at all?
In pensions administration, this almost always reveals that 30–60% of work is avoidable.
Remove that demand and you free capacity immediately — without hiring a single person.
2. Redesign the work around end-to-end flow
Instead of functional queues and specialist silos, I would redesign around:
one case, one flow
minimal hand-offs
clear ownership from start to finish
When work flows, urgency disappears.
When urgency disappears, quality improves.
When quality improves, demand falls.
This is not about working harder.
It is about stopping the system from creating work for itself.
3. Change the measures that are driving the wrong behaviour
I would stop measuring:
calls answered
cases processed
SLA compliance
And start measuring:
end-to-end time
right-first-time completion
customer effort
demand caused by failure
People respond perfectly to the measures they are given.
The current measures reward activity — not service.
4. Absorb regulatory change into the system
McCloud-type work should not sit beside BAU.
It must be designed into it.
That requires:
simplifying case logic
reducing specialist dependencies
designing capability for variety, not averages
The system must be able to cope with change as normal — not as a crisis.
Does this actually work?
Yes.
Across pensions, claims and other complex service systems, organisations that redesign in this way typically see:
backlogs fall by 30-50%without surge staffing
end-to-end times collapse from months to days
contact volumes reduce as failure demand disappears
staff stress fall as work becomes predictable
Not because people suddenly perform better —
but because the system stops working against them.
The uncomfortable truth
The failures members are experiencing are not the result of poor effort, poor intent, or poor leadership.
They are the logical outcome of a system designed for:
contracts
control
activity
and projects
rather than flow, capability and customer effort.
Until leaders are willing to redesign the system itself, every recovery plan will simply create the conditions for the next apology.
If you’re interested in learning more about the Customer Effort Method approach to pensions admin here’s a case study
Disclaimer
This article reflects the personal views and professional opinions of the author.
It is provided for general information and discussion purposes only and does not constitute legal, regulatory, financial, or professional advice.
No reliance should be placed on this article as a substitute for specific advice tailored to individual circumstances.
Stuart Corrigan is listed as the Most Influential Consultant 2026 and is an Amazon #1 Bestselling Author.
https://www.loweffort.com/
