93,000 Cases Stuck in a 'Design Phase': The Helpdesk Lesson in Capita's Pension Backlog

Per The Register (October 2026), the PCS union claims that Capita — the outsourcer administering the Civil Service Pension Scheme — is set to miss yet another legal deadline to correct the pension records of roughly 93,000 civil servants affected by the McCloud remedy. The detail that should make every operations leader wince is not the size of the backlog. It is the union's charge that, years in, the remediation work is “still stuck in the design phase” while the people affected wait.

Read that with your IT manager hat on. A large backlog of important cases. A deadline with legal force. Multiple teams and systems that must coordinate. And — allegedly — no processing at scale, because the programme is still designing. Swap “pension corrections” for “ticket backlog” and you have just described half the helpdesks in this industry. This post is about the failure pattern underneath that headline, and how to make sure it never describes your queue.

The Problem in Depth

1. Detection and resolution live in separate worlds

The disease behind any mega-backlog is rarely laziness. It is architecture. In most IT shops:

• The monitoring tool (PRTG, Zabbix, SolarWinds) fires alerts into an email distribution list or a Slack channel.
• The helpdesk (ConnectWise Manage, Freshservice, Jira Service Management, HaloPSA, Zendesk) only finds out when a human copies the alert into a ticket — or when an end user calls.
• The RMM (NinjaOne, Datto RMM, N-able) holds remote access and patch state but has no idea what the helpdesk is doing with the case.
• Reporting means exporting three CSVs and praying the device names line up.

Every one of those boundaries adds delay and destroys context. An alert that took the monitor 60 seconds to detect takes 25 minutes — on a good day, when someone is watching — to become a ticket, and longer to triage, because the ticket arrives naked: no alert history, no device health data, no hint whether this is the third time this month.

2. Nothing owns the clock

This is the part that maps most directly onto the Capita story. SLAs exist on paper, but nothing enforces them. There is no timer visible on the case, no warning at 50% of the window, no automatic escalation at 75%. Enforcement is a manager exporting a spreadsheet every Monday and squinting at it. Cases age silently. “Stuck in design phase” is what that looks like at programme scale: no burn-down anyone trusts, no owner change on aging work, no escalation that actually fires.

3. Manual triage does not scale — and it burns people out

80–150 tickets a day is a normal load for a mid-size internal IT team; an MSP tech juggles 8–12 clients across a dozen consoles. When every ticket requires human creation, human triage, human context-gathering, and tool-hopping, the queue only grows. End users chase (“any update on this?”), every chase adds a touch, technicians burn out on swivel-chair work between five tabs, and the IT manager cannot produce an SLA report anyone believes — because the helpdesk numbers and the monitoring numbers are measuring different universes.

A scenario every sysadmin knows: a file server's D: volume crosses 90% at 14:07. Zabbix emails the team, into a list nobody reads during afternoon firefighting. At 16:40 a user calls: “the share is slow.” Ticket created 16:52. Triage starts 17:10. The tech spends 20 minutes discovering what monitoring already knew three hours earlier. Result: roughly 3 hours of avoidable degradation, one annoyed user, one rushed fix, and a monthly SLA report that says everything was fine.

How AlertMonitor Solves This

AlertMonitor's premise: the gap between “monitoring detected it” and “helpdesk is working it” should be structurally zero — not “as long as someone is watching.”

Alert-triggered tickets, auto-assigned. When a monitored alert fires — disk over threshold, service stopped, endpoint offline, printer unresponsive — AlertMonitor creates the ticket instantly and routes it based on the device, the client, and the alert type. Disk alerts on client A's file servers land in the infrastructure queue at P2; printer alerts at client C go to the service desk. Nobody forwards an email.

Context-rich tickets. The ticket is not “server slow.” It carries the full alert history for that device, current health data, patch state, and its position in the network topology. Triage drops from 10–20 minutes of archaeology to a 30-second read.

One-click remote access. From the ticket, the tech jumps straight into the endpoint. No hunting for the right RMM console, no credential scramble, no VPN dance.

SLA clocks that run themselves. Timers start at ticket creation — meaning at detection, not at first human touch — and run automatically. Breach risk is visible live, and escalation fires by rule, not by memory. The Monday spreadsheet becomes a dashboard you can defend in a client QBR or a steering meeting.

One data model across monitoring, RMM, helpdesk, and patching. “Which of client B's endpoints have this alert history, what is their patch compliance, and who owns them” becomes a filter, not a three-tool investigation.

The before/after on that file server incident:

Same incident, unified stack: disk crosses 90% at 14:07, ticket exists at 14:08 with 30 days of disk-growth history attached, tech remotes in at 14:12, volume cleaned or extended by 14:40. The user never notices. The SLA report writes itself.

Practical Steps You Can Take This Week

1. Map your top recurring incident types to automatic alert rules. Pull last quarter's tickets and count by category. Five usually dominate: disk space, service down, device offline, backup failures, printer issues. Each should map to a monitored condition that creates a ticket on its own. If your monitoring cannot create tickets, that integration is the first thing to fix — it pays for itself in week one.

2. Put staged escalation on every priority. Example policy: P1 (server or endpoint down) — respond in 15 minutes, resolve in 4 hours, notify the team lead at 50% of the window, reassign at 75%. P3 (single printer) — respond in 4 business hours, resolve within 2 business days. The specific numbers matter less than the principle: the timer is visible on the ticket and escalation is automatic.

3. Attach diagnostics to runbooks so triage is copy-paste. When an alert-ticket lands, the responding tech should run a canned first check, not start from zero. For a disk alert:

# Disk sweep across affected servers - run before you remote in
$servers = 'FS01','FS02','SQL01','APP01'
Get-CimInstance Win32_LogicalDisk -Filter 'DriveType=3' -ComputerName $servers |
  Select-Object SystemName, DeviceID,
    @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
    @{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
    @{n='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
  Sort-Object FreePct | Format-Table -AutoSize

For a service-down alert:

# Verify current state of suspect services before touching anything
Get-Service -ComputerName APP01 -Name 'Spooler','W32Time' |
  Select-Object MachineName, Name, Status, StartType

Linux endpoints in the same estate deserve the same discipline:

# Is the service actually running, and what did it log recently?
systemctl status cups --no-pager
journalctl -u cups --since '2 hours ago' --no-pager | tail -50
df -h | awk 'NR>1 && $5+0 >= 85 {print $6, $5}'

4. Check patch and reboot state from the ticket before dispatching anyone. A surprising share of “weird” tickets end at “install pending updates and reboot.” Make that the first check, not the last resort:

# Is a pending reboot blocking the fix?
$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired'
)
foreach ($p in $paths) {
  if (Test-Path $p) { Write-Output ('PENDING REBOOT: ' + $p) }
  else { Write-Output ('clear: ' + $p) }
}

5. Review burn-down from live dashboards, not exports. Once tickets create themselves and SLA clocks run automatically, the weekly review is a two-minute look at open-by-age and breach-risk queues — and it is the same data the business sees. No reconciliation. No arguing about whose spreadsheet is right.

The Deadline Is Only Real If Something Enforces It

The uncomfortable lesson in the Capita/PCS story is not that outsourcers are slow. It is that a huge backlog with a legal deadline can still drift for years when no system owns the clock — and the affected people learn about it from a union press release rather than a status page. Your end users experience your ticket queue exactly the same way: they do not know it exists until they are the one waiting.

You cannot fix 93,000 pension records with a monitoring platform. But the failure pattern — important work sitting in a queue, invisible, untimed, unowned — is precisely what alert-to-ticket automation, context-rich tickets, and automatic SLA enforcement eliminate. Detection is the easy part. The win is the bridge from detection to resolution, measured automatically.

Related Resources

AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources