Our first monthly report was forty pages and told me almost nothing about whether the arrangement was working. Volumes processed, calls answered, tickets closed. All accurate, none of it answering the question.

I run shared services. Measuring business process services well is mostly about choosing fewer numbers and picking ones that cannot be optimised at your expense.

Volume processed rewards processing volume. If work can be split into two items, it will be, and nobody has done anything wrong.

Calls answered rewards answering. Not resolving, and certainly not preventing.

Tickets closed rewards closure. A ticket closed with a workaround counts the same as one closed with a fix, and the workaround is faster.

None of that requires bad faith. Providers respond to what you measure, which is the entire reason to choose the measures carefully.

Every activity measure describes what the provider did. None describes what the customer got.

We added one measure from outside the process. How long from a customer's first contact to the thing being done, including every queue and handoff.

That number was roughly three times the provider's reported handling time. Neither figure was wrong. Only one described the customer's day.

Business process services reported entirely on internal handling time will look excellent while your customers wait.

End to end cycle time. From the customer's first contact to the thing being done. Not the provider's handling time, which excludes every queue.

First time right. What proportion needed rework. This is the measure that exposes speed bought at the cost of quality.

Repeat contact rate. How often the same customer comes back about the same thing. A resolved query does not generate a second call.

Cost per completed outcome. Not per transaction. An outcome that took three transactions cost three times what the unit price suggests.

Exceptions. How much work falls outside the standard path, and whether that number is falling.

Five numbers on one page. The forty page pack still exists and nobody opens it.

We failed to do this the first time and spent two years unable to prove anything.

Our second arrangement was preceded by six weeks of measurement. Volume, cycle time, error rate, cost, and exception rate, taken before anybody transitioned.

That baseline is the only reason we can say what changed. It cannot be reconstructed afterwards, and every provider will have a different view of what the starting point was.

This is the measure nobody asks for and the one I would keep.

Exceptions are work that does not fit the standard path. Every process has some. A rising rate means either the process no longer matches reality, or the standard path is being defined narrowly so that difficult work falls outside the service level.

Ours rose quietly from six per cent to nineteen over eighteen months. Nothing in the reporting flagged it, because exceptions were handled outside the measured process.

That discovery led to a renegotiation and a considerably better arrangement.

Every monthly report includes something that regressed, with the reason.

We asked for this after realising our packs contained only good news, which made them read as marketing rather than as information.

The first honest answer was that a change we requested had increased handling time, which was true and partly our fault. That conversation was more useful than any positive report we had received.

A standing item, answered each quarter.

Providers usually know exactly what is wrong and have never been asked. Ours has produced three items we funded and two we declined, and the declining was fine because it was an informed decision.

Several of our measures did not improve until engineering work happened.

Cycle time was constrained by two systems not exchanging data, so a step waited overnight for a batch. No amount of process improvement touched it.

That work sat with a DevOps services company handling our integrations, in a different budget entirely. Once we reviewed both in the same meeting, roughly a third of our remaining improvements turned out to be technical. That DevOps services company now attends our quarterly review.

Providers now report automation rates, and the number needs unpicking.

Ask what was automated and what happened to the saving. Under an hours based contract, automation reduces the provider's revenue and tends not to appear.

The terminology also needs pinning down. Somebody will ask about the difference between chatbots and AI agents when both appear in a proposal. A chatbot responds to a person. An agent takes a goal and acts on its own, reporting afterwards.

For measurement purposes the difference matters. Deflected contacts and autonomously completed cases are not the same achievement, and reporting them as one number obscures both.

Two pages. It gets read, which the forty page version never did.

How often should we review?

Monthly for the numbers, quarterly for the relationship. Annual reviews give an arrangement three quarters to drift.

Should the provider report their own numbers?

They can, against definitions you wrote. Business process services reporting on terms they defined themselves will always look reassuring.

Who should own the measures?

Us, defined before the contract. Business process services measured against definitions the provider wrote will produce reassuring numbers.

What if a measure looks bad?

Ask why before asking who. Most bad numbers I have investigated had a cause upstream of the provider.

Should measures be tied to payment?

Some, carefully. Tie payment to outcomes rather than activity, or you will get more activity.

A good report tells you something you did not know and would rather not hear.

Ours does now, about once a quarter, and the arrangement is considerably healthier for it. Business process services reported entirely in green for two years are not being measured. They are being presented.