NHS 24’s Future Programme: The Call-Handling System That Failed at Launch
NHS 24's Future Programme showed how weak procurement, changing scope, insufficient systems-integration capability, and inadequate live-use training can derail a healthcare call-handling platform.
NHS 24 set out to replace the technology behind Scotland’s urgent-care phone service
NHS 24’s Future Programme began as a major effort to replace frontline applications, redesign clinical workflows, and modernize the technology behind telephone triage. The service could not simply shut down while a new platform was built; Scotland still needed urgent-care calls answered every day. Audit Scotland described the programme as both ambitious and complex, combining service redesign with new clinical and patient-handling technology.[1] That combination created dependencies among software, telephony, staff training, contracts, and live operational performance.
A call-centre system is a real-time clinical system
Seconds of additional handling time become queue growth at national scale, and queue growth can become a patient-safety risk when callers need urgent assessment.
Procurement and contract design problems appeared early
Audit Scotland identified flawed procurement and contract preparation, unrealistic timescales, weak contract management, changing scope, and over-reliance on suppliers for testing.[1] These are familiar public-sector IT failure patterns, but in NHS 24 they interacted. An incomplete or weak contract makes it harder to enforce delivery; moving requirements increase cost; limited internal technical capability makes the buyer more dependent on the same suppliers it must challenge.
The planned launch kept moving while programme cost increased
The programme’s implementation date slipped repeatedly from its original target. By 2015, Audit Scotland estimated total programme cost at £117.4 million, 55 percent above the £75.8 million outline business case.[2] Later projections rose further as old and new systems had to run in parallel.[3] Delay is especially expensive in replacement programmes because organizations pay to maintain legacy systems while continuing to fund the unfinished successor.
Double running turns schedule risk into recurring cost
Every postponed cutover can mean another month of duplicated licenses, infrastructure, support teams, and programme staffing.
Testing exposed technology problems but did not guarantee live operational readiness
Parliamentary evidence later described a period in which the system struggled under expected concurrent load and required major remediation.[4] By 2015, dress rehearsals and business-continuity tests appeared more promising. Yet technical readiness did not fully predict how quickly staff could navigate the system during real out-of-hours call volumes. This is a critical distinction: passing performance tests and scenarios does not prove that trained humans can sustain target throughput under live pressure.
The November 2015 launch was paused because call handling deteriorated
When the new patient-contact system was introduced, NHS 24 experienced a dramatic deterioration in call-handling times, according to later parliamentary review of Audit Scotland’s findings.[5] Leaders reverted to the old system in the interests of patient safety. This was the correct safety decision, but it exposed a readiness gap: the platform may have technically functioned, while the human-system combination could not yet process calls quickly enough.
Rollback is a safety feature
The ability to return to the old system prevented a difficult launch from becoming an irreversible operational crisis. Replacement programmes should preserve that option deliberately.
Training quality mattered more than nominal training completion
Scottish Parliament evidence emphasized that staff had not received enough preparation and floor support to operate the system at required speed.[4] Training metrics can mislead if they measure attendance rather than competence. A clinician who has completed a course may still be slow in real workflows, uncertain about exception handling, or unable to recover when a screen behaves unexpectedly.
The programme eventually became a case study in digital governance
Audit and parliamentary reports focused on governance, systems-integration capability, contract management, and the need to challenge supplier assumptions. The Scottish Parliament later cited NHS 24 in a broader review of public-sector ICT projects.[5] The lesson was not that government should avoid complex systems. It was that buyers must retain enough technical and operational expertise to understand what suppliers are delivering and whether it fits the service.
The customer cannot outsource accountability
Vendors can build components, but the health organization still owns the end-to-end outcome experienced by patients and staff.
Why NHS 24 belongs in software-failure history
The Future Programme demonstrates how software failure can emerge from procurement, programme management, training, integration, and operational readiness rather than one defective algorithm. The technical system existed, yet the first live-use attempt could not safely sustain the service’s demands.[2][4]
The enduring engineering lesson is to test the complete sociotechnical system. Simulate real call volumes, measure task time, train for exceptions, preserve rollback, and ensure the organization—not only suppliers—understands integration and failure modes. In healthcare, a system is ready only when staff can use it safely at the speed patients require.
The programme also illustrates why rehearsal must include realistic human throughput, not merely functional success. A call-handling workflow can technically return the right screens while still taking too long under winter demand. Teams need load tests that include representative staff, complex callers, interruptions, escalation, and recovery from mistakes. Those exercises should produce explicit cutover thresholds so leaders know in advance when to continue, pause, or roll back.
Works Cited
- 01
- 02
- 03Audit Scotland — 2015/16 Audit of NHS 24 audit.scot
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.