What Business Process Services Actually Buy You

I have signed two of these contracts. The first was sold on cost per transaction and delivered exactly that, alongside a slow erosion of how well the process actually ran. The second was scoped differently and has been one of the better decisions we made.

The difference was what we asked to buy. Business process services can supply labour, capability, or an outcome. Those are three different things sold under one name.

Our first arrangement bought hours. A defined number of people, doing our process, at a lower cost per hour.

That worked in year one. Then the process needed changing, and we discovered we had outsourced the doing without outsourcing the thinking. Every improvement required a change request, a quote, and a negotiation.

Nobody had a reason to make it better. The contract paid for hours consumed, so fewer hours meant less revenue.

I would still buy labour occasionally, for genuinely stable work. I would not call it a partnership.

Our second contract bought something different. A team who had run this process for other companies and knew where it usually goes wrong.

They arrived with a view. Three of our steps existed because of a system limitation we had removed two years earlier. One approval had no policy behind it that anyone could find.

That kind of input is what you are actually paying a premium for, and it only arrives if the contract lets somebody say your process is worse than it needs to be.

The strongest arrangements I have seen buy a result rather than an activity.

Invoices processed within a defined time at a defined accuracy. Applications assessed within a service level. Queries resolved at a stated first contact rate.

That structure changes who is motivated to improve. When the provider is paid for the outcome, automation is in their interest rather than a threat to their revenue.

Ours moved to outcome pricing in year two and roughly a third of the volume is now automated. Under the previous contract that would have reduced their income, and unsurprisingly it did not happen.

The boundary is worth writing down before anything transfers.

We keep anything requiring judgement about a customer relationship, anything carrying regulatory weight, and the design of the process itself.

The provider runs the volume. We decide what the work is.

Where I have seen that fail, the process design went with the process. Reclaiming it later was extremely difficult, because by then only the provider understood how the work actually ran.

Good business process services will accept that split readily. A provider who wants the design as well is describing a dependency.

The question that separates providers quickly.

A weak answer describes a transition plan. Systems access, training, shadowing, handover. All necessary and none of it improves anything.

A strong answer names something specific. We would remove that approval step. We would stop the duplicate data entry between those two systems. We would batch that work weekly rather than daily.

Our current provider named four things in the second meeting. Three were right and we had known about none of them.

This surprised me and it has become a standing question.

Much of what makes a process slow is technical rather than procedural. Systems that do not talk to each other. Manual re-keying between them. Reports assembled by hand each month.

Our process partner identified those and could not fix them. That work sat with a DevOps services company we already used for infrastructure. The two had never spoken. A DevOps services company and a process partner rarely meet unless you introduce them.

We now bring them together at the start. About half of our process improvements turned out to be integration work rather than process redesign, and separating the two vendors had been quietly limiting both.

Every provider now leads with automation, and the language deserves unpicking.

Somebody on your side will ask about the difference between chatbots and AI agents, usually because both appear in the same proposal. A chatbot responds to a person. An agent takes a goal and acts on its own, then reports back.

The second is a delegation decision and it deserves the scrutiny you would give a new employee with system access. What can it change? What needs a human? How would we undo an hour of wrong decisions?

We allow agents on a short list of low risk reversible tasks and require a person everywhere else. That has not slowed the savings much and it has removed the scenario that would end the arrangement.

●      Are we buying hours, capability, or an outcome? Say it in the contract.

●      What will you change in the first ninety days?

●      What proportion of this work do you expect to automate, and by when?

●      Who owns the process design, us or you?

●      What happens to the saving when you automate something?

That last question is the one most proposals avoid. If automation reduces their revenue, it will not happen, whatever the slide says.

Who should own the process design?

You should. Business process services run the volume, and the design of the work should stay with the business that lives with the consequences.

Should we start small?

Usually. One process, well documented, with a baseline. Business process services scoped across a whole function at once make the first year a discovery exercise.

How long should a contract run?

Ours is three years with annual checkpoints that have real teeth. Long enough for the provider to invest in understanding the process.

Should we fix the process first?

Enough to know what it actually is. Outsourcing a process nobody has documented means paying somebody to discover it, and their version becomes the truth.

Does this reduce headcount?

Ours moved people rather than removing them. Be honest internally about which one you are doing, because staff work it out quickly and the arrangement depends on their cooperation.

What is the clearest warning sign?

A provider who agrees with everything about your current process. They have either not looked or are not planning to tell you.

Business process services priced on hours give you a cheaper version of what you already do.

Priced on outcomes, with the process design shared and automation in the provider's interest, they give you something better than what you had.

Our first contract saved money and left the process untouched. The second costs a similar amount, handles more volume, and has changed how the work is done. I would not go back to the first structure, and the difference was entirely in what we asked to buy.