Client
A UK coastguard operations centre coordinating maritime search and rescue across a mixed coastline of open sea, estuary and cliff terrain, tasking a network of volunteer rescue teams
Sector
Public Safety & Emergency Services
Engagement
Integration of vessel tracking, rescue team availability and incident history into a single operational coordination platform, with live access for watch officers and team leaders - phased delivery over two quarters.
What the client needed
The operations centre's watch officers were making time-critical tasking decisions - which rescue team to send, and by which route - using information split across four places: a vessel tracking feed showing AIS positions, a separate radio log tracking which volunteer teams were currently available or already committed elsewhere, a paper-based skills and equipment register held locally by each team, and an incident history system used mainly for post-incident reporting rather than live decision-making. None of the four talked to each other. A watch officer taking an urgent call had to mentally combine a vessel's last known position, an availability picture that was only ever as current as the last radio check-in, and a memory of which teams carried the right equipment for a cliff rescue versus an inshore search - all inside the first few minutes of a call that could be a life-threatening emergency. An internal review after a period of unusually high call volume found that tasking decisions were consistently taking longer than they needed to, not because officers lacked judgement, but because the information they needed to exercise it was scattered across systems built at different times for different purposes.
How we worked
- Built a single tasking view that combines live vessel tracking, rescue team position and availability, and each team's equipment and skills profile on one screen, replacing the four-system lookup a watch officer previously had to perform under time pressure.
- Digitised the team skills and equipment register so it updates from each team's own reporting rather than relying on a watch officer's memory of which team last confirmed what capability.
- Introduced an automatic nearest-capable-team suggestion that ranks available teams by proximity and matching equipment for the incident type, leaving the final tasking call with the watch officer but removing the manual cross-referencing step.
- Built the team-facing mobile view to work over the patchy or absent mobile coverage typical of open coastline and cliff terrain, caching tasking details locally the moment a team is stood up so a lost signal en route doesn't strand them without instructions.
- Rolled out sector by sector, starting with the stretch of coastline with the highest annual incident volume, so the tasking workflow was proven under real search and rescue conditions before wider connection.
- Ran joint training sessions with watch officers and volunteer team leaders together, so a tasking decision made in the operations centre and the instructions received on a team leader's handset were reading from the same live record.
Measured results
All figures verified with the client. Specific team, vessel and incident detail withheld in line with our standard confidentiality terms.
- Time for a watch officer to identify and task the nearest capable rescue team fell from a multi-system lookup typically taking several minutes to under a minute in the majority of live incidents since rollout.
- The proportion of taskings sent to a team that had to be reassigned because it lacked the right equipment for the incident type fell sharply once the digitised skills and equipment register replaced reliance on memory and radio check-ins.
- Team leaders report a consistent, single source of tasking instructions reaching them even in areas of known poor mobile coverage, where instructions previously risked arriving late or not at all.
- The operations centre now uses the platform's incident history directly in post-incident debriefs, replacing a reporting system that had previously been updated well after the fact and rarely referenced operationally.
- Watch officers describe materially higher confidence in team availability data at the point a tasking decision is made, compared with a radio-log picture that was often several minutes out of date.
"Every minute in this job is a minute someone is in the water or on a cliff face waiting for us. We were never short of information - we were short of having it all in front of one person at the moment they needed to make the call. That's the gap this closed."
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.
Why the fix was integration, not new sensors or new data
It would have been easy to scope this as a data-collection problem - more tracking coverage, better radio infrastructure, a new equipment-inventory system built from scratch. None of that was the actual gap. The centre already had good vessel tracking, teams already reported their status, and equipment records already existed somewhere, even if that somewhere was a binder at a team's boathouse. The problem was entirely about getting information that already existed in front of the person who needed it, in the seconds available to use it. We built the integration layer on top of what already existed rather than replacing any of the underlying systems, which is also why the highest-volume stretch of coastline was live within a single quarter rather than a multi-year infrastructure programme.
An automatic suggestion still needed a human in charge of the decision
The nearest-capable-team ranking was the single feature volunteer team leaders were most cautious about during design, and reasonably so - a purely automated tasking decision in a life-safety context is a hard thing to trust, and rightly so. We built it as a ranked suggestion a watch officer reviews and confirms, not an automatic dispatch, which meant the technical challenge was making the ranking fast and visibly explainable - showing why a team was ranked first, not just that it was - rather than making it fully autonomous. That distinction is what got the feature accepted by watch officers rather than worked around.
Coastline terrain decided the mobile design as much as the tasking logic did
A tasking system that only works reliably from inside the operations centre is of limited use to a team already moving toward a cliff edge or a stretch of estuary with no signal. As with comparable public safety engagements, we spent a disproportionate share of the technical effort on making the team-facing view resilient to patchy or absent coverage - caching tasking detail locally the moment a team is stood up, rather than depending on a live connection once they're already committed - rather than on the tasking logic itself. It's the least visible part of this engagement and the part that determined whether teams covering the more remote stretches of coastline got any benefit from it at all.
Lessons learned
The first lesson was that in most time-critical coordination problems, the missing piece is rarely more data - it's getting data that already exists to the person who needs it inside the window they have to act on it.
The second lesson was that automating a suggestion is not the same as automating a decision, and in a life-safety context that distinction determines whether the people relying on the tool trust it enough to actually use it.
The third lesson was that for any service covering genuinely remote or poorly connected terrain, designing for the worst-case connection on the patch, not the best, is what decides whether a field tool gets adopted consistently or only near well-covered areas.
If your organisation coordinates time-critical decisions across information that already exists but isn't reaching the right person fast enough, we would be glad to discuss what a platform like this might look like for you. Email sales@halfteck.com.