Client
A UK probation delivery provider managing community licence supervision for offenders released from custody, operating across several regional teams
Sector
Justice & Offender Management
Engagement
Recall alert platform linking case management, licence recall decisions and police and ports watch-list systems into one shared operational view - multi-quarter programme.
What the client needed
When a probation officer decides an offender on licence has breached their conditions badly enough to warrant recall to custody, that decision is only useful once it reaches the police officer who might stop that person on the street, and the ports and border systems that would flag them if they tried to leave the country. Before this engagement, a recall decision travelled from the probation officer's case notes through a duty manager's sign-off, into an administrative team that keyed it into the national police computer during office hours, and from there into a separate overnight batch feed that reached ports and border watch lists the following day. A recall authorised on a Friday afternoon could sit unflagged to frontline police until Monday, and the client's own case reviews had identified instances where a recalled offender was stopped by police for an unrelated matter and released, because the recall had been authorised but hadn't yet reached the system the officer was checking against.
How we worked
- Integrated directly with the probation service's case management system so a recall decision, once signed off by a duty manager, triggered an alert workflow immediately rather than waiting for administrative keying.
- Built a secure interface to the national police alert system that issued a flag the moment a recall was authorised, replacing the office-hours manual entry step entirely.
- Extended the same trigger to the ports and border watch-list feed, removing the separate overnight batch cycle that had previously added up to a full day of extra delay on its own.
- Added a duty manager dashboard showing the live status of every recall in flight - authorised, transmitted, confirmed received by each downstream system - so a gap or failed transmission was visible immediately rather than discovered later.
- Ran the new alert path in parallel with the existing manual process for a full quarter, with every case independently checked against the old process before the manual path was retired.
- Worked with the client's information security and data protection teams throughout, given the sensitivity of offender risk data moving between justice and border systems in near real time.
Measured results
All figures verified with the client. Specific site, personnel and offender case detail withheld in line with our standard confidentiality terms and justice sector data-handling requirements.
- The time from a recall being authorised to a live alert reaching both police and ports and border systems fell from most of a working day, and up to a full weekend in the worst cases, to under twenty minutes in the large majority of cases.
- The parallel-running quarter surfaced a small number of cases where the old manual process had introduced transcription errors between the case file and the police system - errors the new direct integration removes by design, since there is no manual re-keying step left in the path.
- Duty managers report substantially more confidence that a recall they've authorised has actually reached frontline systems, rather than relying on a downstream team to confirm it separately.
- The live status dashboard has already caught two transmission failures - a lapsed system credential and a network interruption - within minutes rather than the failures going unnoticed until a later audit.
- The client is now assessing whether the same real-time trigger pattern can apply to licence variation notifications more broadly, not just recalls.
"Authorising a recall was never the slow part - our duty managers were making that call quickly and correctly. The slow part was everything after the decision was made, all the handoffs between our system and everyone else's that had to happen before a police officer on the street could actually see it. We weren't short on judgement. We were short on plumbing."
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
A recall decision sits at the intersection of three separate organisations' systems - probation's own case management, the national police computer, and ports and border watch lists - none of which were originally designed to talk to each other in real time. The brief was explicit that the platform had to work within each system's existing security accreditation and data-sharing agreements rather than ask any of the three organisations to change how their own core system operated. That constraint shaped the entire build: this was an integration and orchestration problem, not a case of replacing any of the underlying systems of record.
Justice sector data-handling requirements governed every design decision. Offender risk information carries its own statutory handling rules, and a recall alert needed to carry enough detail for a police officer to act on safely while staying within strict need-to-know boundaries at every step of its journey between systems. Agreeing the exact data fields that could flow automatically, versus those that still required a human to review before release, took as long as building the integration itself.
Why a full quarter of parallel running, not a pilot
Given what a missed or delayed recall alert could mean in practice, the client was unwilling to retire the existing manual process until the new automated path had been checked case by case against it for a sustained period. We ran both processes side by side for a full quarter, with every recall during that window independently verified as having reached police and ports systems correctly through both routes before the manual process was switched off. That parallel-running period is also what surfaced the transcription errors the old manual process had been quietly introducing - errors nobody had previously had a systematic way to detect, because there was no independent second process to compare the manual one against until this engagement built one.
Designing for visibility, not just speed
Speeding up the alert path was necessary but not sufficient - a fast alert that fails silently is arguably worse than a slow one that someone is watching. The live status dashboard was built specifically so a duty manager could see, at a glance, whether every recall in flight had actually been confirmed received by each downstream system, rather than assuming success once the alert had been sent. That design decision paid for itself directly: the dashboard caught a lapsed system credential and a separate network interruption within minutes of each occurring, both of which would previously have gone unnoticed until a later audit uncovered a gap that, by then, could have been open for days.
Lessons learned
The first lesson was that removing delay and building visibility are two different problems, and a platform that only solves the first one still leaves an organisation exposed to a silent failure it can't see until an audit finds it.
The second lesson was that a multi-agency integration lives or dies on data-handling agreements as much as on the technology - the security and data protection conversations with police and border teams were as significant a workstream as the software itself, and needed to run from day one rather than being addressed once a technical design was already fixed.
The third lesson was that a sustained parallel-running period, run for long enough to build genuine confidence rather than to hit a project milestone, is what actually earns the right to retire a manual safety-critical process - and it often finds problems in the old process that nobody was looking for.
If your organisation is weighing how a safety-critical decision moves between systems that were never designed to share it in real time, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.