Client
A UK air navigation service provider responsible for controlled airspace and approach control across a major regional airport group
Sector
Aviation & Transport
Engagement
Live airspace incident coordination platform linking controller incident logging, drone and obstruction reporting and NOTAM issuance into one shared operational view - multi-quarter programme.
What the client needed
When a controller spotted a drone, a stray balloon or another unauthorised object in controlled airspace, the response ran through several separate systems built at different times for different purposes: an internal incident log to record what was seen, a phone call or radio relay to notify adjoining sectors and the airport's own operations desk, and a manual submission into the national NOTAM system to formally restrict or close the affected airspace. Each step depended on whoever was on shift knowing the full chain and having every contact detail to hand, and the provider's own post-incident reviews found the average time between a controller first logging a sighting and a live NOTAM actually reaching airlines and other airspace users ran to around 50 minutes - most of it spent relaying the same basic facts through three or four separate channels rather than assessing the incident itself. In the events that mattered most, aircraft were still operating on outdated information for the better part of an hour after controllers already knew something was wrong.
How we worked
- Built a single incident logging screen for controllers that captured a sighting once and fed every downstream system from that single record, rather than requiring the same facts to be retyped into a log, a phone call and a NOTAM submission form.
- Integrated directly with the national NOTAM issuance system's submission interface, so a controller-confirmed incident could generate a structured, pre-populated NOTAM draft ready for sign-off rather than a blank form completed from memory under pressure.
- Connected the platform to the airport group's operations desks and adjoining sector control rooms, so a live incident became visible to everyone who needed to know at the moment it was logged, not after a round of individual phone calls.
- Built an explicit supervisor authorisation step before any NOTAM left the system, since the brief was clear that no airspace restriction should be issued automatically without a qualified controller's sign-off.
- Ran the platform in shadow mode alongside the existing process for a full quarter, comparing its timings and NOTAM drafts against what controllers actually did, before it became the primary tool.
- Trained controllers and supervisors across every control position on the unified workflow, since the timing gain only holds if a sighting is logged the same way regardless of who is on shift.
Measured results
All figures verified with the client. Specific site, personnel and airspace sector detail withheld in line with our standard confidentiality terms and aviation security requirements.
- Average time from a controller logging an airspace incursion to a live, distributed NOTAM fell from around 50 minutes to approximately eight minutes.
- The shadow-quarter comparison found the platform's pre-populated NOTAM drafts required only minor supervisor edits before sign-off in the large majority of tracked incidents, rather than being built from scratch each time.
- Controllers report materially less time spent relaying the same incident facts across separate phone calls and systems during a live event, leaving more attention for the airspace picture itself.
- The shadow period surfaced a specific gap in one adjoining sector's contact routing that had gone uncorrected through several handovers - now fixed rather than silently relied upon.
- The provider is extending the same unified incident view to ground-based obstruction reporting, where the priority shifts from airspace restriction speed to runway inspection scheduling.
"We had good controllers, a good NOTAM system and good relationships with the airports. What we didn't have was one place where logging what a controller saw automatically started the notification and the paperwork, so the 50 minutes were mostly people repeating themselves down a phone line. Now that repetition is gone, and the time we saved goes straight back into the judgement call that actually needs a human - how serious this incursion is, and what we do about 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
Airspace incident response has a particular timing pressure that most operational data problems don't: the underlying event - an object entering controlled airspace - is usually seen within seconds by the controller responsible for that sector, but the value of that early sighting depends entirely on how quickly everyone else who needs to act on it actually finds out. The brief was explicit that the platform had to sit across the provider's existing controller workstations, the national NOTAM system and the airport group's own operations desks rather than replace any of them, since each had been independently certified and validated over years of operation, and the problem was in how information moved between them, not in any single system itself.
Aviation safety authorisation requirements shaped the build as much as the coordination problem did. A NOTAM issued in error, or restricting airspace more broadly than an incident actually warranted, carries its own operational and safety cost - diverted traffic, wasted capacity, and reduced trust in future restrictions. The platform was built to produce a pre-populated NOTAM draft based on the logged incident, not to submit one automatically, and to require a qualified supervisor's explicit sign-off before anything left the system, regardless of how complete or urgent the draft appeared.
Building a NOTAM draft controllers would actually trust
The harder design problem wasn't connecting the incident log to the NOTAM system - that integration, once agreed with the national provider, was comparatively straightforward - it was producing a draft complete and accurate enough that a supervisor would sign it off in seconds rather than rewriting it from scratch under pressure, which would have erased most of the time saving. We worked with controllers and supervisors together to define exactly which fields could be safely pre-populated from a structured incident log and which needed a human judgement call every time, rather than assuming more automation was automatically better.
A full quarter before removing the fallback
We ran the platform in shadow mode alongside the existing process for a full quarter before it became the primary tool, deliberately comparing its draft NOTAMs and notification timings against what controllers using the old process actually did. That extended shadow period, rather than a shorter trial, is what surfaced a specific and consequential gap: one adjoining sector's contact routing for out-of-hours notification had gone uncorrected through several staff handovers, meaning the existing manual process was quietly relying on individual controllers remembering to call around it. A shorter pilot measured in weeks would likely have missed that gap, since it only became visible once enough incidents had been logged to expose a routing path that wasn't being exercised regularly.
Lessons learned
The first lesson was that a genuinely time-critical airspace safety decision - one where the underlying information already exists but is split across systems built at different times for different purposes - calls for a unified view with an explicit human authorisation step, not a fully automated trigger, because the cost of an unnecessary or inaccurate restriction is not symmetrical with the cost of a supervisor's few seconds of review.
The second lesson was that a pre-populated NOTAM draft is only as trustworthy as the judgement about which fields to automate, and getting that judgement wrong in either direction - too little automation, or too much - would have undermined the platform either through slow adoption or through drafts controllers stopped trusting enough to check properly.
The third lesson was that running a full quarter in shadow mode, rather than a shorter uptime pilot, is what it took to surface a contact-routing gap that only showed up under specific, infrequent conditions rather than during routine operation - the same lesson we've seen hold in other safety-critical coordination programmes we've delivered.
If your organisation manages a time-critical safety decision currently split across systems built at different times, we would be glad to discuss what a programme like this might look like for you. Email sales@halfteck.com.