No Cure, No Pay

The proposal I want to describe is seven slides long, and the most interesting thing on it sits on the cover. The line there is that the work is offered performance-based. Not the method, not the credentials, not the size of the prize. The pricing is the headline, and everything after it reads differently for it.

The client is a large European cooperative banking group. The subject is its internal incident handling chain: a request arrives, a service desk takes it, it moves through internal departments and sometimes out to a supplier and back. The analytical work was done and had gone well. What had not happened was the collection of the money.

The number was never the problem

The chain analysis is the kind of work we would now file under process mining. It reconstructed the end-to-end path of an incident across departmental boundaries and put per-step performance on one surface, which is the visibility no single department's own reporting can produce. What it exposed is unglamorous in the way real operations findings usually are.

Heavy bouncing between the customer and the service desk because asset tags were missing from monitors, so nobody could tell which machine the caller was standing in front of. Suppliers routing warranty questions through the incident management process, which is not what that process is for and which looked unremarkable from inside any one department. Incidents forwarded to departments that had nothing to do with them, each hop a step, each step costing something.

Every one of those pathologies crosses a boundary, which is why the chain view found them and departmental reporting had not. The saving was expressed the honest way, as a step count first and a euro figure second: 300,000 steps out of the chain, 3.3 million euros a year. Divide one by the other and you get roughly eleven euros per step removed, which is my arithmetic and not the document's. It tells you what kind of change is being asked for. Eleven euros a step is not a system replacement. It is thousands of people each doing a slightly shorter version of what they already do.

Then the programme did what these programmes do. The realisation organisation was set up, the resources were freed, and the document records flatly that not all the preconditions for successful realisation were being met, so the collection was running behind.

What a contingent fee does to a proposal

At that point the proposing firm offered two interventions on a no-cure-no-pay basis, priced against the benefit target the analysis had already stated.

A caveat about what I am claiming. This is a proposal. I do not know from these slides whether it was accepted, and a target with a fee attached is still a target, not a delivered outcome. What I can read off the document is what the pricing did to the proposal.

Look at what got proposed. Not a second analytical pass. Not a deeper cut of the chain data. Not a platform, not a dashboard rebuild. Two behavioural interventions, aimed at managers and the people doing the work rather than at the steering layer, and framed as boosting the existing team rather than replacing it.

That restraint is not modesty. It is what happens when the fee sits behind the realised benefit. A firm paid for effort can propose another measurement exercise and be honestly useful, because a better measurement is a real deliverable and somebody else turns it into money. A firm paid out of the movement in a number that already exists cannot. Its deliverable is no longer a finding but the difference between this quarter's step count and last quarter's, and every hour spent producing a new number is an hour not spent moving the old one.

So the contingent fee acts as a filter before it acts as an incentive. Whatever survives it is, by construction, something the proposer believes will show up in a measurement they have already agreed to be judged by.

The measurement becomes the proposer's problem

The second thing a fee at risk does is force the proposer to specify the measurement, because vagueness in the measure is now expensive to them rather than to the buyer.

You can see this in how tightly the first intervention is written. It is a performance dialogue: a recurring session in which managers and their teams look at the data and decide what to do. Ordinary enough as a heading. The specification underneath it is not.

Every improvement action has to carry its own benefit potential on the realisation dashboard alongside progress against the objective. Not a status, not a colour. The value it is supposed to release and the distance still to go. Every issue raised goes through the same six questions before it leaves the room: what is happening, why, what must be done, who will do it, when is it done, how do we measure progress. Read those as fields on a record rather than conversation prompts and the design is clear. A problem cannot be raised without acquiring an owner, a date and a method of measurement.

The agenda is exception-based, and the document says so in the negative. Walking the complete dashboard and discussing every indicator is named as an anti-pattern; only the indicators deviating from the norm get discussed. So is prioritising by ease, and the note beside unclear ownership is blunt: then nothing ever happens.

The shape of the specification tells you as much as its content. Across its three dimensions, the content of the session, the process of running it and the social dynamic inside it, there are eight stated do's and nine stated don'ts. The format is defined as much by forbidden behaviour as by required behaviour, and the pairs line up: root causes from facts against decisions on gut feeling, prioritised actions against easy-first, focus on processes against finger-pointing at people.

That is what somebody writes when they will be paid out of what the ritual produces. It also arrives with a stated precondition the proposer does not control: sponsorship at board level, called a precondition rather than a benefit, in plain words. A firm billing for days has no reason to write that sentence. A firm billing for outcomes has every reason to write it before signing.

A fee at risk does not make a proposer smarter. It removes an entire category of proposal from the table, the category where the deliverable is another number and someone else has to turn it into money.

The reach arithmetic behind the fee

The second intervention only makes sense once you see the exposure. The chain teams reached about sixty people. More than two thousand were directly involved in the incident management process. The step count that had to fall by 300,000 was produced by the second group, and the programme could touch the first.

Set against that gap, a communications intervention stops looking like the soft part of the proposal and starts looking like the only affordable way to cover the distance. The design is deliberately cheap: existing channels only, no new infrastructure. Intranet posts, the weekly team start-ups management already runs, seeded internal content, and management itself carrying success stories outward. The message is specific rather than inspirational, and its sharp end is a behavioural expectation about the step counts an incident is closed on.

A second strand carries the same logic: the proposal sources its internal change carriers by open call to all staff rather than from the talent list management already keeps, on the argument that the people already on that list are not necessarily the ones motivated to put extra into a transformation.

3.3M euro/yr

Conservative saving potential identified, per the analysis

300,000

Steps to come out of the end-to-end incident chain

~60 vs 2,000+

People reached by the chain teams versus people in the process

2

Interventions offered, both behavioural, neither analytical

What I would take into a machine learning programme

I read this document as an operations artefact and then as a warning about the way we buy machine learning work today.

The pattern is the same and the ratios are worse. The deployment end has never been cheaper. A model gets stood up, a benefit case gets written, a number lands in a slide, the programme is declared a success on the strength of that number existing, and the money is somebody else's problem. Feature stores, lineage and the rest of the MLOps apparatus make a number trustworthy, and every one of them stops short of making it collected. The straight-through processing case, the triage case, the early and cautious language-model pilots now crossing my desk: all sold on a projected benefit nobody has agreed how to observe after go-live.

So the test I would apply is the one this proposal applies to itself. Ask the vendor, or your own team, to put a meaningful part of the fee behind the realised benefit, measured on an instrument agreed before the work starts. You learn three things quickly. Whether the benefit case is believed by the people who wrote it. Whether the measurement is specified well enough for anyone to be paid against it, which is usually where the conversation stops. And what the proposal becomes once the analytical options are priced out of it, because that residue is the work that always mattered.

It is a question RealAI's Platform team puts in the first meeting rather than the last. Not which use case you want to run, but which number you want to move, and who is standing next to it when it does not.

Drawn from a short performance-based proposal to a large European cooperative banking group, on the benefit realisation of a completed step-level analysis of its internal incident handling chain. It produced a diagnosis, two recommended interventions and a pricing construct, not delivered results. Figures are as stated in it, except the per-step rate, which is my own division. Reading the fee construct as a filter on what gets proposed is ours.