The track record page is the least examined sheet in any bid document. It sits near the back, it carries four bullets and a client mark, and the room reads it as reassurance rather than as evidence. One of them has stayed with me, because its four bullets are not achievements. They are an order.
The document is a capability statement and proposed approach put to an international health insurance group by a firm bidding for the design work. Near the back, among the prior engagements, is a page describing work the same firm had already done for the same group: strengthening the operations, the capabilities and the capacity of the medical assistance centre that answers members wherever in the world they happen to be, in support of the group's international growth.
Four things were delivered, and the page states them in sequence. A realisation road map, described as the strategic journey. Then the target operating model for the assistance centre. Then process optimisation. Then the selection and implementation of the core IT platform underneath it.
The system came fourth, and the page records it as selected and implemented rather than deferred, descoped or left as an option for a phase that never gets funded.
The challenge
The centre already existed. The ask was not a greenfield build; it was operations, capabilities and capacity, sized to carry growth in a business selling to members spread across many countries and time zones. That shape of ask normally arrives pre-solved. Growth means volume, volume means throughput, throughput means the case system is the bottleneck, and by the time anybody writes a document there is already a platform shortlist and a steering committee date.
What makes the page worth reading is that the shortlist is the fourth thing on it rather than the first. The argument that a medical assistance centre is a service design before it is a system carried far enough to reach the deliverables, and the order they are listed in is the only trace of it that survives.
- 4
- Stages before the platform was chosen
- 1
- Firm carrying all four
- 0
- Outcome figures on the page
The approach
Each stage in that sequence produces the input the next one needs, and the dependency runs one way only.
The realisation road map fixes what the centre is for and in what order it changes. The target operating model then settles who does what, in which location, with which handoffs and which accountabilities. That model is the requirement document a platform selection needs and almost never has, because in the ordinary sequence the requirement is written by people reading vendor feature lists, which produces a specification shaped like the market rather than like the operation.
Process optimisation comes third, before implementation rather than after it, and that placement is doing more work than it looks. A system freezes whatever it is handed. Configure a platform around a process nobody has improved and you have bought a very expensive commitment to the current way of working, plus a change request queue for every improvement somebody thinks of afterwards. Improving first is cheaper because paper is cheaper.
Only then the platform, chosen against a model and a set of processes that already exist in writing and have already survived one argument.
This is not the analytics argument I have made elsewhere. In Do Not Buy the Analytics Platform Before You Have Run One Case the environment is priced as an option and the live question is whether the buyer needs to buy it at all. Here the platform was never optional. A medical assistance centre without a case system is not a centre. The order in this engagement is about what state the requirement is in on the day the buying decision is taken, not about whether the buying happens. Ordering the platform last and skipping it are different arguments, and only one of them survives contact with an operation that has to answer a call at three in the morning.
Ordering the platform last is not the same argument as not buying one. The fourth stage still closed. What changed is that the requirement arrived at the vendor as a model somebody owned rather than as a feature list somebody had been shown.
What the order did not settle
The same page carries a second engagement, and it is the more useful half.
Later, the same firm helped the group assess its ability to understand customers in the ultra-high-net-worth segment, and to deliver a compelling customer experience across all relevant channels.
Hold that against the four stages. The operating model had been built. The processes had been improved. The platform had been selected and implemented. And the group still had to commission a separate piece of work to establish whether it understood one of its most valuable member segments, and whether it could serve that segment everywhere the segment turned up.
That sequence is the finding I would put in front of anybody about to buy a service platform this year. Four stages executed in the correct order produce a working operation. They do not produce customer understanding, because customer understanding is not an output of an operating model and it is not an output of the system that runs one. A case platform records what happened to the members you already serve, in the way you already serve them, through the channels you already staff. It is a faithful mirror of the current design, which is exactly why it cannot tell you that the design is wrong for the segment you have the least room to misread.
The channel half of the same question makes the point from the other side. Serving a segment across all relevant channels is not a system property. It is a decision about which channels are relevant to which members, and it has to be taken before the platform is asked to support it, or paid for afterwards in integration work.
The outcome
Nothing on the page says the centre got faster, cheaper or better. There is no outcome figure of any kind on it: no handling time, no cost per case, no satisfaction score, no headcount. The page names four deliverables, one platform and one follow-on assessment, and stops.
I would not read that silence as failure. Track record pages omit numbers for ordinary reasons, and confidentiality is the usual one. What the silence does fix is what the page can be used for. It is evidence of method and of continuity. It is not evidence of result, and a reader who carries it out of the room as proof that the order works has taken away something the page never claimed. That is worth saying plainly, because the same page shape is now standard in AI vendor material: a named sequence, a named platform, a client mark, and no measured outcome anywhere on it.
There is one more thing the page tells you, and it is structural. The bid this page sits inside proposes to redesign the group's global service model. So the firm showing you the four stages had already built the operating model and the platform underneath the very function it was now proposing to redesign. Two readings are available and both are true. The generous one is continuity: nobody knows this operation better than the party that designed it. The useful one is that a design done in the right order still came back onto the table. The four stages bought a centre with an owned model and a chosen platform underneath it. On the evidence of the page, they did not buy a settled answer. The diagnostic elsewhere in the same bid, which found the group's contact centres sub-scale at under a hundred seats and stand-alone in every region, is what correct sequencing looks like once the business around it has moved on.
Reading this against an agentic shortlist
The order on that page maps onto the decision most data and IT managers are being asked to take right now, with the platform stage renamed. An agentic service layer, a copilot for claims handlers, an assistant that drafts member replies. All of them are stage four, and all of them are being sold as stage one.
Three things I would take from the record rather than from the principle. Write the target operating model for the function before the shortlist, and make it specific enough that somebody can disagree with it in a meeting. Improve the process before you automate it, because automation is the most expensive way ever invented to preserve a bad handoff. And book the customer-understanding work as its own line with its own budget, scheduled alongside the platform rather than behind it, because this engagement is the evidence that it does not arrive as a by-product of the build.
The last one is the departure from the record rather than a repetition of it. Here the customer question was asked after the platform was in. It could have been asked before, and the answer would have shaped what the platform was bought to do.
Source: a single track record page inside a capability statement and proposed approach written for an international health insurance group by a firm bidding for the design work. The four stages and the later customer-understanding assessment are described on that page as prior delivered work; the page names the platform, which is withheld here, and gives no outcome measure of any kind. The bid itself was a proposal. The reading of the sequence, of what the fourth stage did and did not close, and of what the incumbency means for how the page should be weighed, is ours.