Industry: Insurance services My role: Discovery lead and delivery strategist Work completed: Executive discovery, opportunity prioritisation, delivery planning and solution-design briefs Solution stage: Operating model and roadmap designed; production implementation outside this account
The business had plenty of ideas for AI. It also had staff repeatedly chasing updates, managers opening files to check whether anything had happened, and a core system that made some changes much harder than others.
Adding an assistant to each problem would have been one way to approach it. It would also have left the business with a growing collection of tools to integrate, govern and teach people to use.
I led the discovery and delivery-planning work to connect those individual opportunities into a more coherent operating model: shared capabilities, explicit human responsibilities and a staged path from existing workflows to AI-assisted operations.
My contribution
I facilitated executive discovery, shaped the follow-up investigations and wrote briefs commissioning platform feasibility and the technical vision. I owned the delivery approach and plan, including how to pair visible progress with longer-term capability building.
This was a multidisciplinary engagement. An AI architect owned the architecture and concept demonstration; colleagues contributed commercial management, value modelling and people-and-change expertise. My role was to connect the operational problems, technical constraints and delivery sequence into a plan the business could assess.
Discovery changed the definition of the problem
The initial work produced an opportunity register spanning several operational functions. Deep dives then tested the assumptions behind those opportunities.
One example was file linking. The initial opportunity assumed people were linking records manually. Further investigation established that automatic linking already existed; the problem was narrower than the register suggested. That changed what needed to be solved.
Follow-up work revealed a broader coordination problem. Staff worked through age-ordered lists without a shared view of other open items for the same counterparty. Calls were recorded, but people still typed the resulting notes. Managers inspected records manually to find gaps or stalled work.
These were connected workflow problems. The opportunity was to organise information and action across a file's lifecycle, rather than accelerate each isolated task.
The design: shared capabilities with clear jobs
The roadmap grouped related use cases into four capabilities. These were defined parts of the design, with different responsibilities and dependencies.
| Capability | What the design covered | Human responsibility |
|---|---|---|
| Contact and follow-up | Consolidating open items, prioritising follow-ups and preparing updates | Staff conduct conversations and handle situations requiring judgment |
| File state and exceptions | Bringing together file history and surfacing stalled or unexpected activity | Staff decide what action to take |
| Rules and entitlement | Retrieving relevant rules with their source; separating assistance from later enforcement | People interpret and verify answers before consequential decisions |
| Quality and workforce | Supporting review and planning as a later delivery stage | Leaders retain accountability for quality and workforce decisions |
This made the division of work explicit. The agent was not simply handed a job title and left to get on with it. The design described which information it prepared, where a person intervened and what required approval.
Integration constraints shaped the sequence
The platform investigation drew an important distinction between reading information and writing actions back to the operational record.
That mattered because an automated action needed to leave a visible trail. Sending an update was only part of the job; the people managing the file also needed to know that it had happened.
The design therefore separated improvements that could work with existing access from automation dependent on reliable write-back. I commissioned the feasibility work needed to clarify those boundaries rather than treating integration as something to sort out after the roadmap was agreed.
A related architecture hypothesis kept the existing system as the record of truth, with supporting capabilities alongside it. The brief also set a boundary around that approach so it did not quietly become a project to build an entire replacement platform.
The delivery plan started with a baseline and a better queue
The first stage specified a measurement baseline and a consolidated, human-operated follow-up list. It did not depend on autonomous calling or complete integration.
A better list is not the flashiest part of an AI vision. Here, it had a specific job: establish how much contact each file required and give staff a coordinated view of the work before adding more automation.
Later stages introduced a prioritised queue, a limited pilot of proactive updates and a rules assistant. Rules retrieval came before automated enforcement because finding an answer for a person to assess and executing a rule require different levels of assurance.
The plan paired near-term improvements with foundational work. It also considered the behaviour changes landing on each team, rather than scheduling everything solely around engineering capacity.
What the engagement produced
The completed discovery work produced an opportunity register, prioritisation and a more precise understanding of workflow constraints. The design work produced a capability-based roadmap, delivery sequence, platform-feasibility brief and an explicit division of responsibilities between people and AI.
We also created a narrated concept demonstration using fictional scenarios to illustrate the longer-term operating model. That demonstration was a concept prototype, not a deployed system.
The concrete output of my work was a delivery approach that connected the AI vision to the first operational steps: what to build together, what to sequence separately, what needed technical validation and what should remain with people. Operational savings and adoption belong to the implementation phase and are not claimed here.