For BPO and outsourcing providers
You already operate other people’s functions better than they do. The pressure is not capability — it is that the seat is becoming a worse unit to sell, your clients keep asking for outcome pricing, and quoting one means knowing your true cost per resolved case rather than your cost per hour staffed.
You win on execution and on cost, and the cost half of that is arbitrage: the same work performed by a team you can staff and manage better than your client can. That trade has been good for a long time and it is narrowing, because wage floors move in one direction and clients have learned to benchmark.
So the pricing conversation changes. Clients stop asking what a seat costs and start asking what a resolved case costs — and worse, what an unresolved one costs. Quoting that safely means knowing your own distribution, not your average. The average is the number in the deck; the tail is the number that eats the contract.
Meanwhile the work itself is uneven in a way headcount cannot absorb. A queue that is quiet for three weeks and impossible in the fourth has to be staffed for the fourth, and that capacity sits idle for three. Every provider knows this and every provider prices around it, which is another way of saying the client pays for it.
And attrition is the tax underneath all of it. A team trained for six weeks that turns over inside a year means the cost of knowing how to do the work is paid repeatedly, and the knowledge that leaves is precisely the part that made the exceptions manageable.
Outcome pricing requires the distribution of effort per resolved case — including the tail — and most delivery organisations can produce a cost per hour staffed but not a cost per case resolved.
This is why the shift to outcome pricing feels like risk rather than opportunity. It is not that the work is harder. It is that the pricing model changes which number you must be certain about, and the number you have been certain about for twenty years is the wrong one.
Cost per seat-hour is measurable from a roster. Cost per resolved case is measurable only from the flow: how many touches, how much waiting, how much rework, how often it escalates, how long the exceptions take, and what proportion of cases are exceptions. That decomposition is what lets you quote a fixed price and keep the margin you quoted.
The same decomposition is what tells you which parts of a queue can be handled without a person at all, which parts need your most experienced people, and which parts are only expensive because they wait. Those are three different economics inside one contract, and pricing them as one is why some accounts quietly lose money for a year before anybody can prove it.
Cost per resolved case, with its actual distribution — measured by median, tail and variance per queue — the three numbers a fixed-price bid needs and an hourly bid never required.
Which portion of a queue is waiting rather than working — measured by wait time and blocked time separated from handle time, per case type.
How much of the volume is rework — measured by cases re-entering a step they had already cleared, counted rather than sampled.
Where your most experienced people are actually needed — measured by resolution rate by case class against who handled it, instead of by tenure alone.
Peak absorption without staffing for the peak — measured by queue age through a volume spike, compared against the same spike in a prior period.
Quality coverage beyond the sample — measured by the share of cases with a machine-readable record of what was done, versus the share reviewed by sampling.
Bids you can price with confidence — measured by quoted margin against realised margin at contract close, per account.
that this replaces your delivery organisation, or that automation absorbs the exception work. The exceptions are where your value is, and the point of measuring the routine is to stop spending your best people on it.
You mostly do not own the systems the work lives in, and that constrains everything. This runs against the access your client has already granted you, in the systems they already have you working inside — it does not require them to buy anything, adopt anything, or approve a second vendor relationship.
That matters commercially as well as technically. A delivery improvement that requires your client to procure something is not a delivery improvement you control, and it moves at their procurement speed rather than yours.
Where a client wants their own visibility into the same flow, that is a scoped read, granted by you, into that client’s data only. Multi-client isolation is an architectural boundary here, because in your business a leak across accounts is not an incident, it is an existential event.
You hold data belonging to organisations that compete with each other. Isolation is therefore not a feature discussion, it is the precondition for the conversation, and it is enforced at the architecture rather than by a filter applied at query time — a filter is a line of code somebody can get wrong once.
Operational access is not permission to train. Work performed for one of your clients does not become material that improves anything serving another, inside your book or outside it. That boundary is the one your own clients will ask you to warrant, and you should be able to warrant it without qualification.
Every consequential action carries a receipt naming its authority. In your business that record is not only an audit artefact — it is the evidence that settles a dispute with a client about what was done and when.
You will be reviewed twice: once by your own security function, and then repeatedly by every client whose contract has a flow-down clause. The second review is the expensive one, because it happens per account and on their timetable.
So the documentation is written to be forwarded. Architecture, data flow, isolation model, subprocessor list and the authority model exist as documents you can hand to a client’s vendor-risk team without us joining the call.
Where an obligation depends on a specific contract or data class — a BAA, a residency requirement, a sector rule — it is marked applicability-gated rather than presented as something already in force. That distinction is one your clients’ reviewers are trained to look for.
A single queue in a single account, chosen because its economics are uncertain: either it is priced by the hour and you suspect it should not be, or you have walked away from similar work because it could not be quoted safely.
Observation first, and only observation. It changes nothing about how the queue is worked, grants no authority to act, and produces the thing you cannot currently produce: the distribution of effort per resolved case, with the tail shown separately from the median.
That number is worth having whatever you decide next. It tells you whether the account is priced correctly, which is a question most delivery organisations answer annually and by inference.
Then, and only then, delegate one narrow step — the most repetitive, least judgement-dependent part of that queue — with a written grant and a stopping condition agreed in advance. One step, one queue, one account, reversible the same afternoon.
On some work, yes, and pretending otherwise would waste your time. The honest position is that we sell two different things and you are being offered the platform, not the operator. If that makes the relationship uncomfortable, the contractual answer is a scope and non-solicitation boundary written before anything is connected — and if it still feels wrong, declining is a reasonable decision and we would rather you make it now than three months in.
You are not introducing one. This runs against the access your client has already granted you, inside the systems they already have you working in. Nothing is procured by them, nothing is installed in their environment, and no second vendor relationship is created. Where a flow-down clause requires you to disclose subprocessors, that list exists and is written to be forwarded.
Only if you keep selling hours, and the premise of this page is that the hour is becoming a worse unit to sell. Knowing your cost per resolved case is what lets you quote outcomes, and outcome pricing is where a well-run provider makes more rather than less — because the efficiency accrues to you instead of being passed through as a lower rate at renewal. If your book is entirely hourly and your clients are content, this argument does not apply to you yet.
They do not have to. Start on one queue in one account and measure whether the economics change, before any commitment scales with your headcount. If the measurement shows the queue is priced correctly and worked efficiently, you have learned that for the cost of an observation phase, and the correct decision is to stop.
A dashboard reports what already happened to somebody who cannot change it. The test to apply here is whether the output changes a decision you actually make — the price you quote, the queue you accept, who you route an exception to. If after the observation phase you cannot point at a decision that changed, the programme failed and you should say so rather than renew it.