Services

Automate the repetition, measure the result

Automation projects fail in a predictable way: nobody measured the before, so nobody can say whether the after is better. Six months later the team is still doing the work, plus maintaining the automation, and the business case cannot be evaluated because there was never a baseline.

What repeats most?

Tell us where your team spends repetitive hours. We will estimate what is automatable.

1 / 3
Baseline measured firstObserve before authorityCeilings stated honestly
0%25%50%75%100%wk 1wk 4wk 8wk 12wk 16wk 2091%

The situation

Where the hours usually are

Ranked roughly by how much time they take and how automatable they are, which are not the same ordering.

Bill entry and coding

Highest volume, most automatable. Recurring vendors reach the low nineties within weeks because the pattern is strong and the correct answer is knowable.

Matching

Bank lines to invoices, payments to receivables, receipts to purchase orders. Structured comparison, little ambiguity, and it automates well.

Expense coding

Constrained by receipt quality rather than by the model. Where receipts are captured properly it reaches the mid-eighties; where they are not, nothing helps.

Close tasks

Accruals, prepaid amortisation, recurring journals, and intercompany elimination — rule-based, repetitive, and rarely the thing anyone gets round to automating.

Recurring reporting

The pack somebody rebuilds monthly from the same four exports. Usually the fastest win and the least glamorous.

Chasing

Collections follow-up, missing receipts, unapproved timesheets, expiring documents. Low value per instance, high volume, and universally disliked.

Measure first, or do not bother

The first week of any automation engagement is measurement: how many transactions, how long each takes, how many touches, how many exceptions, who does it. Not estimated in a workshop — measured, from the systems.

It is unglamorous and it is the only way the result can be evaluated afterwards. It also routinely reorders the priority list, because the process everyone complains about is frequently not the one consuming the most hours.

The process people complain about and the process that consumes the most hours are rarely the same one. Measuring is how you find out which is which.

The ceiling is workflow-specific

Our published benchmarks are the honest expectation and they vary widely. Purchase order matching reaches ninety-four percent. Bill coding ninety-one. Expense coding eighty-four, constrained by receipts. Vendor deduplication sixty-nine, because it is genuinely hard. Multi-line allocation sixty-six, because the required context is often not on the document.

A workflow with a sixty-six percent ceiling can still be worth automating — two thirds of a large volume is a lot of hours. But the business case has to be built on that number rather than on an assumption of near-total automation, and it is better to know before than after.

Observe before authority

Every automated workflow runs in observation for two to four weeks, producing a shadow record of what it would have done beside what your team did. Nothing is granted authority until that comparison justifies it.

The disagreements are the valuable output. They are rarely evenly distributed — they concentrate in one vendor, one account, one entity — and that concentration usually points at a data or policy problem worth fixing regardless of automation.

What we will tell you not to automate

Anything running under fifty times a month. Anything where the rules are contested rather than merely undocumented. And anything where the process itself is wrong — automating a bad process produces the wrong answer faster and makes it harder to change later.

That last one comes up often. A meaningful share of automation enquiries turn into process design engagements, which cost less and deliver more.

Where to start

How it runs

01

Measure the baseline

Volume, time per transaction, touches, exception rate, per workflow, from the systems rather than from estimates. One week.

02

Rank by realistic gain

Volume times time saved times achievable rate. The realistic rate is the part most proposals leave out, and it changes the ranking.

03

Observe

Two to four weeks of shadow running, with the disagreements reviewed. Cheap, reversible, and where the surprises surface.

04

Promote and report

Authority granted per workflow, then straight-through rate, exception rate, and time saved reported monthly against the original baseline.

Questions

What people ask.

How much can realistically be automated?
It depends entirely on the workflow. PO matching reaches ninety-four percent, bill coding ninety-one, vendor deduplication sixty-nine. Our benchmarks page publishes the spread including the bottom quartile.
Do we lose control?
Nothing is granted authority until it has run in observation and the shadow record justifies it. Authority is lowered instantly and without justification.
What if the automation is wrong?
Every automated action is reversible and logged with its reasoning. Reversal rate is reported monthly and deterioration lowers authority rather than prompting a defence.
Will you tell us not to automate something?
Regularly. Under fifty runs a month, contested rules, or a process that is itself wrong — those are process problems and automating them makes things worse.
How do you measure success?
Against the baseline measured in week one: straight-through rate, exception rate, and hours. Without that baseline nothing afterwards can be evaluated.

Measure before you automate.

Tell us where the repetitive hours go. Week one is measurement, not a proposal.