A Closed Loop, Described Long Before the Tooling Existed

Most of what I am asked about this quarter is retrieval. Put the policy wording, the claims history and the product rules into a vector store, sit a copilot beside the person handling the contact, let it draft the reply and cite what it drafted from. Good work, and it lands quickly. As a design it is also considerably older than the tools now being bought to deliver it.

One artefact keeps coming up while I read back through old operating-model material. It is a proposal written for an international health insurance group, the better part of a decade ago, for the digital and automation half of a service transformation, a workstream carrying GBP 30M of declared value at stake. On one page of it, somebody drew a customer service operation that never stops re-deciding what it is doing: not a project plan with a review gate at the end, but a cycle, with the arrows closed.

A cycle, not a funnel

Almost every service design I have been handed is a funnel. Contact arrives, gets routed, gets handled, gets closed, and a monthly report says how the closing went. Improvement is a separate activity at a different tempo, consuming the report rather than the events. The design in this proposal has two halves, and the moves run in a ring.

At the point of contact, the operation was to act on what had already been worked out about the member, their segment and any campaign they sat in, adjust what it offered against data monitored as it arrived, and personalise the interaction while the interaction was still happening. Between contacts, it was to evaluate how service was performing and how satisfied members were, work out which enquiries should become self-service by looking at what people were actually enquiring about, and set service levels while allocating the budget that pays for them.

The two halves were then wired to each other in both directions, which is what makes this a cycle rather than two workstreams on the same slide. What the contact side saw, and what it learned from what it saw, flow up to the deciding side. Revised member data and revised rules flow back the other way. Nothing waits for a review board.

Say that in current vocabulary and nothing in it sounds unfamiliar. Sense, act, learn, decide again. The design is unremarkable, which is why it is worth reading now: nobody in that room needed a language model to think of it, and nothing in it was blocked by the absence of one.

What the cycle was supposed to run on

The input was a member profile assembled from two very different sources: the organisation's own records, meaning CRM, transaction history and products held, and behaviour, meaning enquiries the member had made, browsing history, click data and calls.

The second list is the interesting one, because none of it is produced deliberately. It is exhaust, a by-product of running the channels at all, in the way the gap between a call arriving and a headset lifting exists whether or not anyone has decided it is a metric. A design that closes its own loop needs the exhaust, because the exhaust is the only thing generated at the same rate as the contact. Records get updated when someone completes a transaction. Behaviour gets written continuously, by everybody, including the members getting nothing done.

The clock was the missing part

On the same page sat the diagnostic, and it is blunt. Service improvement had been aimed at the contact centres while the digital estate and self-service facilities fell behind market standards. The current setup did not allow information to be gathered continuously across all customer touch points, and only a few satisfaction scores were captured at all.

Hold that against an ambition covering more than 90 percent of member interactions and the mismatch is not subtle. The deciding half was asked to evaluate performance and satisfaction continuously, find self-service candidates in the enquiry population, and re-set service levels and budget on the latest data. The estate could supply a handful of scores and no continuous record of what members were doing.

The proposal does not draw that conclusion; it lists the design and the diagnostic beside each other and moves on. Reading the two as one problem is mine, and it is not a strained reading, because the two halves imply different clocks and the drawing makes no attempt to reconcile them. Budget allocation moves annually in almost every organisation I have worked in, service levels move when a contract is renegotiated, and satisfaction scores here moved when somebody ran a survey. The contact side, meanwhile, was to adjust its offer against data monitored in real time.

A cycle whose slow half turns once a year is not a slow cycle. It is a plan with an arrow drawn back to itself. The return path exists on the page and carries nothing.

The same loop, at the shortest interval it has

A second design in the same material makes the cadence point better than any argument about budgets. On the global service model, the recommendation is to monitor customers on the self-service sites in real time, identify the ones visibly having trouble, and offer them support through a chat dialogue.

That is the identical ring, compressed until it fits inside a single session. Watch behaviour, notice a failing outcome, act on it, learn from whether the intervention worked. It needs nothing the rest of the cycle does not also need, only at a tempo of seconds rather than months, and it fails the same way: an operation that cannot gather information continuously across its touch points cannot see the member who is stuck, and one that has not decided in advance what stuck looks like cannot act on the sighting. That second condition is not a volume problem and not a modelling problem. It is somebody having written down what the system may conclude and what it should do about it, a definitional act no amount of capture substitutes for.

The intelligence was never the constraint

The same page carries the proposal's own proof points, and they settle whether the analytical half was reachable. A customer analytics capability built for a European insurer predicted churn at 80 percent accuracy, and the prediction was wired to something: proactive service aimed at the segment it flagged. Analytics applied to weak points in a cross-channel mortgage journey at a European bank lifted conversion by 15 percent. Both predate this proposal, so the cycle was not waiting on a model. What was absent was the recording, the agreed definitions, and any mechanism that made the deciding half turn more than a few times a year.

+90%

Member interactions targeted by the digital experience

GBP 8M

Value at stake on the digital component

80%

Churn-prediction accuracy, engagement cited in the proposal

A few

Satisfaction scores captured across all touch points

Why this is the live question now and not then

The economics have inverted. When that proposal was written, the deciding half of the cycle was expensive: analytics capability was scarce, models took quarters, and the honest way to run improvement was periodically, by people, from reports. Now the modelling end is close to commodity. Retrieval over an organisation's own text is a few weeks of work, copilots sit beside handlers and draft, and early autonomous experiments, carefully scoped and watched, are running in narrow parts of service operations.

What has not become cheap is everything the loop needs in order to close. Instrumented touch points that write behaviour continuously. One agreed definition per counted thing, so two people producing the same figure produce the same figure. Lineage, so a feature can be traced to the system that emitted it. An evaluation set with real cases in it, so a change to the deciding half can be shown to have improved something rather than asserted to have. MLOps discipline, so the revised rules flowing back down are versioned and reversible rather than edited in place. That list is where a RealAI Platform engagement opens, and it is deliberately unglamorous.

A governance clock runs alongside this. The EU AI Act has been agreed, and organisations in this sector will in time be asked to show how automated decisions affecting members were made. The evidence that question needs is the evidence the loop needs to function: what was seen, what was decided, what changed, when. Build the return path properly and the record is a by-product. Build it as a diagram and you will reconstruct the record later, from memory.

The drawing asked the operation to re-decide continuously and the estate could report occasionally. A cycle running on an annual signal is not a slow cycle. It is a plan with an arrow drawn back to itself.

I keep returning to this page because it is a control. It shows what people already knew how to want, stripped of any excuse about the technology not existing. Nobody involved lacked the idea. They lacked a way to make the ring turn faster than the reporting calendar, and to know between turns whether it had turned at all. So, before the next service programme is scoped: a loop that closes onto a quarterly report is a review cycle with better graphics. A loop that closes onto a continuously written record of what members did and what was done for them, with definitions somebody signed and a way to check the difference, gives the tooling arriving now something to work on.

Figures are as stated in a proposal written for an international health insurance group covering the digital and service-model half of its transformation: its declared value at stake, its diagnostic findings and the comparable engagements it cited. A proposal states ambitions, targets and recommendations, not delivered results, and the figures above should be read as such. Reading the design and the diagnostic on that page as a single cadence problem is ours.