Twice a day, every local healthcare provider’s operational lead dialled into a system-wide call, chaired by the System Coordination Centre, to report pressure and ask for mutual aid where needed. I chaired that call regularly. The problem was structural: you cannot both chair a call and take detailed notes on it at the same time, and on the calls I ran alone — weekends, mainly — there was no one else to do it either. The notes had to come from watching the recording back afterwards, on top of the rest of the job. Turnaround could run past an hour, sometimes two. For a document meant to alert people to live operational risk, that was too slow to be useful.

The first idea didn’t work

The obvious fix was to hand Copilot the team’s existing Word template and ask it to fill it in directly from the meeting. Copilot couldn’t do it reliably — it wasn’t good at writing structured content directly into a Word template from a transcript. I tried a number of different template formats to find one it could work with. None of them held up.

What worked instead: teach it from examples, not from the template

Rather than fighting the template, I flipped the approach. I gave Copilot examples of human-written notes and asked it to draft a prompt that could reproduce that style and structure from a raw meeting transcript. Then I ran it: take the transcript, generate notes with the current prompt, compare the output against a fresh set of human-written notes from the same call, and refine the prompt based on where it fell short. Repeat.

That loop ran about thirteen or fourteen times before it converged on something reliable — a roughly 125-line markdown prompt that reproduced the template’s headings and formatting closely enough to copy the output straight into the formal document.

The shape of the output

The prompt specified a fixed structure:

  • Header — chair, meeting title, date/time, attendees and who they represented.
  • Immediate escalations — anything safety-critical or a signal patient-quality issue, flagged at the very top, ahead of everything else.
  • A four-part system-wide summary — today’s system-wide pressures, other issues to flag, mitigations for those issues, and any mutual aid requirements or explicit tasks.
  • Day’s events/news — a short section for anything else worth logging.
  • Per-provider sections, one per organisation on the call (typically eight to ten providers): a snapshot against the eight nationally-standard operational metrics, then that provider’s risks for the day, mitigations, and any support being requested.

Weighting detail by pressure, on purpose

The one piece of behaviour I explicitly designed for, from the first version of the prompt, was that the level of detail per provider should scale with how much operational pressure that provider was under — using OPEL (Operational Pressures Escalation Levels), the national scale used across the NHS to describe how much pressure a system or organisation is under. A provider at OPEL 1 (business as usual, no significant issues) might get one or two bullet points. A provider at OPEL 4 (the highest level) would get six to eight. The prompt was explicit that this had to come from genuine content, not padding — it was told directly not to fabricate detail or invent bullet points just to hit a length.

Where it landed: not full automation, and it became a QA step

It never fully replaced a person. Two things it couldn’t do: generate the tables used in our template, and pull the screen-grabs from our operational dashboard that the formal document needed. Both stayed manual.

More importantly, that wasn’t really how it ended up being used. Under business as usual, someone would still write the notes by hand, the normal way, while I ran the automated version in parallel as soon as the meeting ended. I’d then run both sets — the generated notes and the human notes — back through the system and ask it to flag any differences between them, and use that as a quality check before I signed the human notes off. It became a second reader rather than a replacement writer: a way to catch inconsistency in the manual process, not a way to remove the person from it.

That mattered because these weren’t informal notes. They went out to operational leads across the local system, including the provider organisations themselves, and to NHS England for oversight and assurance. They needed to be reliable, and having two independently-produced versions to compare made that easier to stand behind.

It ran in regular use, by me and at least one other member of the team, for the best part of a year — from a few months into my time in the System Coordination Centre through to when I left the ICB in June 2026.


Sources: written from my own recollection. There’s no chat record for this work, because it predates my exported chat history and involved NHS operational data, so the underlying documents, data and the exact prompts aren’t reproduced here.