Client
A UK regional train operating company running passenger services across a multi-county franchise, with its own control room and a contracted replacement bus provider network
Sector
Transport & Infrastructure
Engagement
Consolidated disruption decision platform linking signalling status, engineering possessions and replacement transport capacity, plus a decision-support workflow for control room duty managers - multi-quarter programme.
What the client needed
When a line closes unexpectedly, whether for a signalling fault, an obstruction, or a possession overrunning into first service, the duty manager's job is to decide fast whether to hold trains, terminate services short, or call in replacement buses - and every one of those calls depends on information that, at our client, lived in three different places answerable only by phone. Signalling status came from the infrastructure operator's own systems, viewable but not queryable from the train operator's side. Engineering possession plans sat in a separate scheduling tool maintained by the works planning team, updated on a schedule that didn't reliably reflect real-time overruns. Replacement bus capacity depended on a phone call to whichever contracted provider covered that stretch of line, with availability changing hour to hour and no shared view of it. A duty manager facing a live disruption was, in effect, running three simultaneous phone calls before a single passenger-facing decision could be confirmed, and the client's own post-incident reviews kept surfacing the same finding: the disruption itself was rarely the slow part, confirming what to do about it was.
How we worked
- Built a live feed from the infrastructure operator's signalling and possession status systems into a control room dashboard, replacing manual status checks with a continuously updated view.
- Integrated engineering possession plans directly against the live train describer feed, so an overrunning possession surfaced as an active alert rather than a discrepancy someone had to notice.
- Built a shared capacity view with the client's contracted replacement bus providers, so available vehicles and driver hours were visible to the control room before a call was needed, not discovered during one.
- Designed a structured decision workflow for duty managers - hold, terminate short, or replacement bus - that pulled the relevant live data for each option automatically rather than requiring the manager to gather it manually under time pressure.
- Ran the platform in shadow mode alongside the existing phone-based process for a full disruption season before cutting over, comparing decisions and timings side by side.
- Trained control room staff through simulated disruption scenarios rather than documentation alone, since the tool only pays off if it's trusted in a live incident, not just understood in principle.
Measured results
All figures verified with the client. Specific site, route and staffing detail withheld in line with our standard confidentiality terms.
- Median time from a disruption starting to a confirmed passenger-facing decision fell from over an hour to under ten minutes for incidents that reached the replacement bus stage.
- Engineering possession overruns are now flagged to the control room automatically against the live train describer feed, rather than surfacing only once a train was already held at signal.
- Replacement bus providers report call volume from the control room during live disruptions dropped by more than half, since baseline capacity is now visible without a call.
- Shadow-mode running surfaced two recurring gaps in the previous phone-based process that had gone unnoticed in prior post-incident reviews, both since corrected in provider contract terms.
- The platform's possession-overrun alerting is now being extended to the client's separate engineering planning team, beyond its original control room scope.
"We weren't slow because nobody knew what to do. We were slow because knowing what to do meant three separate phone calls before anyone could confirm it. Now the calls happen after the decision, to execute it, not before, to make it."
Working on something similar?
If this engagement looks like the kind of problem you are facing, we would be glad to compare notes by email.
Context and constraints
Train operating companies sit in an unusual structural position: they run the service passengers see, but they don't own the infrastructure their service depends on, which means a disruption decision routinely needs data from a separate organisation's systems, on a timeline that organisation didn't design around the train operator's needs. Our client's leadership was upfront that this wasn't primarily a technology gap, it was an information-sharing relationship that happened to need better tooling to make the sharing fast enough to matter operationally. That framing shaped scope discipline throughout: every integration decision was tested against whether it got a genuinely live signal into the control room, not against whether it looked complete on an architecture diagram, and where the infrastructure operator's own systems only offered a periodic export rather than a live feed, we said so plainly rather than building a dashboard that implied real-time status it didn't actually have.
Getting the possession-overrun alerting right took longer than anyone initially expected, because the naive approach - comparing planned possession end times against the clock - produced a stream of false alerts for possessions that were running to a revised plan the works planning team already knew about but hadn't yet re-entered into the scheduling system. We ended up building the alert against the live train describer feed instead: an overrun only fires when a signal block that should have reopened hasn't, which is a slower signal to build but a genuinely trustworthy one, and false-positive-free in a way the naive version never was.
Building a decision workflow duty managers would actually use live
A decision-support tool that gets ignored during a real disruption in favour of the phone habits everyone already trusts isn't a useful outcome, so we ran the platform in shadow mode for a full disruption season, comparing its recommended data against what duty managers actually gathered by phone, before asking anyone to rely on it operationally. The shadow period surfaced two gaps in the old process that nobody had previously had reason to notice: a replacement bus provider's stated capacity figures were consistently overstated during peak driver-shift-change windows, and possession plans updated after a Friday afternoon cutoff frequently didn't reach the control room's phone contact list until Monday. Both are now built into the platform and the provider contract terms directly, neither would have surfaced without watching the same disruption play out through two systems side by side.
Sharing data across an organisational boundary, not just a system boundary
The signalling and possession integration required agreement from the infrastructure operator, not just a technical connection, and getting that agreement in place before building anything against it was the single highest-leverage step in the programme's early months. A live feed built against an assumption of continued access that was never formally agreed is a fragile foundation for a control room tool people are meant to trust during an actual emergency, and we treated the data-sharing agreement as a prerequisite deliverable in its own right, not paperwork to be sorted out in parallel with development.
Lessons learned
The first lesson was that in a disruption decision, the bottleneck is rarely deciding what to do, it's confirming the facts needed to decide with confidence - three phone calls in sequence will always be slower than one dashboard, no matter how decisive the person on the calls is.
The second lesson was that an alerting signal built against a plan, rather than against live ground truth, will generate exactly the kind of false positives that erode trust fastest - the possession-overrun alert only became reliable once it was rebuilt against the train describer feed rather than a scheduling document.
The third lesson was that a cross-organisational data-sharing agreement is itself a deliverable with its own timeline and risk, and treating it as a formality to finalise alongside development rather than a prerequisite to clear first is a reliable way to build a dashboard on access that was never actually secured.
If your organisation is facing a similar combination of decisions that depend on data owned by a different organisation and a control room process that's slower than the disruption itself deserves, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.