Outcome-based pricing starts with agreeing what success means

A business investing in automation should be able to describe what it expects to gain. That might be fewer hours spent entering the same information, invoices ready for approval sooner or more work completed accurately by the existing team.

Those outcomes give the investment a purpose. A count of AI requests or tokens tells you how much technology was used. It does not establish whether the work became faster, more accurate or less costly to handle.

At Four Labs, part of our fee is tied to the measured result. We agree with each client what success means and how to check it.

The exact fee structure is agreed for each engagement, before work begins. The proposal sets out the work, the evidence we will use and how the result affects the price.

Agreeing what to measure before reviewing the result. Editorial illustration, not a client session.

Start with the process that needs to improve

An outcome needs a clear beginning and end. “Save the team time” leaves too much open. “Reduce the staff time required to produce the weekly operations report, while keeping every required entry complete and accurate” gives both sides a process to examine.

For invoice processing, the outcome might be to shorten the time between receiving an invoice and having a checked record ready for approval. That scope includes extracting the details, matching supporting records and resolving exceptions. Payment authorisation could remain with the finance team.

The people doing the work should help define the outcome. They know which suppliers send unusual documents, which fields need a second check and where an apparently simple task depends on an unanswered email.

Four Labs would work with those people and the person responsible for the business result. Together, we would agree the process, its boundaries and what must remain under human control. That gives us a basis for deciding what to build and whether the proposed improvement is worth pursuing.

Decide which workflow deserves attention first

Before agreeing to build, we should compare the opportunities. A task can be easy to automate and still make little difference to the business. Another may have substantial value but depend on records or approvals that are not ready.

We would look at how often the work happens, the effort and delays involved, the cost of mistakes and what an improvement would let the team do. Alongside that, we would assess data quality, access to existing systems, the effort needed to introduce a change and the consequences of a wrong action.

The people who will own the new process need a say in this choice. A manageable first workflow with a clear owner and a measurable result gives both sides a way to test the working relationship. Higher-risk or less-ready work can wait until its dependencies are resolved.

Sometimes the useful first step is a clearer approval rule, better source data or removing an unnecessary handoff. We should be willing to recommend that work before adding AI. The client's investment needs to address the cause of the problem.

We would keep a shared list of further opportunities and revisit it after reviewing the first deployment. The order should change when the evidence or business priorities change.

Establish a baseline both sides can trust

Before setting a target, we need to know how the process performs today. A baseline records the starting point over a period both sides consider representative.

For invoices, we might record the number received, the staff minutes spent handling each one, the elapsed time to a checked record and the number requiring correction. We would include time spent chasing missing information and dealing with exceptions.

Staff handling time and elapsed time measure different things. An invoice might require twelve minutes of active work but spend three business days waiting between steps. Reducing the wait could help the business without removing twelve minutes of work. We should keep both measures visible.

The baseline also needs context. A month with unusually few invoices or mostly familiar suppliers may give a misleading picture. We would agree which records to include, how to handle unusual cases and whether different types of invoice need separate comparisons.

If reliable records do not exist, measurement becomes part of the initial scope. We can agree a period of time tracking or a sample review before making a performance commitment. An estimate should stay labelled as an estimate until there is evidence to support it.

Agree success before judging the result

A useful agreement defines a primary outcome and the quality conditions that must hold alongside it.

For example, faster invoice entry has limited value if staff then spend longer correcting the records. A time target should sit beside an accuracy measure, the required checks and a clear definition of a completed invoice.

Both sides should be able to read the agreement and answer the same practical questions:

• Which process and types of work are included?
• What are the baseline, target and measurement period?
• Which records will we use, and who will check them?
• What counts as an error, an exception or unfinished work?
• Which quality and approval requirements must still be met?
• How do measured results affect fees, and what happens if targets are missed?

We would also agree when to review the results. A short test may show whether the automation can handle selected cases. Assessing its value requires enough ordinary work, exceptions and human review to judge how it performs in use.

Changing the target after seeing the results would weaken the agreement. If the process changes, both sides should approve a revised scope and measurement method for future work, with a record of the reason.

An illustrative invoice-processing example

The figures below are hypothetical baselines and targets. They are not Four Labs customer results, forecasts or promised improvements.

Suppose a finance team processes 1,000 invoices in a month. Its agreed baseline shows an average of twelve minutes of staff handling per invoice and three business days from receipt to a checked record ready for approval.

The team and Four Labs might consider these targets:

Here, first-pass accuracy means the proportion of reviewed invoices whose required fields are all correct before any correction. We would agree the fields, the review method and how the sample represents the full workload. We would check the same way before and after the change.

Duplicate checks and payment approvals would remain required. Invoices waiting on missing information would stay in the record, with their status and age visible. We would report overdue and unfinished cases alongside completed ones so the average cannot improve by quietly dropping difficult work.

If the handling-time target were achieved across 1,000 comparable invoices, the four-minute reduction would release about 67 staff hours that month. That calculation assumes the new handling time includes checking, correcting and managing exceptions.

Those hours represent capacity the team could use elsewhere. They do not automatically become cash savings. The business might use the time to reduce a backlog, handle more invoices or avoid overtime. We would agree which of those effects is relevant and what evidence would support a financial value.

We would also account for implementation, support, software and operating costs when assessing the value of the change. A faster process still needs to justify what it costs to run.

An illustrative example of reducing manual work

Consider a separate team that gathers updates from emails and spreadsheets to produce a weekly operations report. The following figures are also hypothetical, not customer results or promised improvements.

Suppose the baseline is thirty staff hours a week across gathering, preparing, checking and correcting the report. A possible target is twenty hours, with all required entries included and the rate of material errors no higher than the agreed baseline.

The team could agree what counts as a material error, such as a missing job or an incorrect completion date, and use the same checks during the review period. Late reports and corrections made after distribution would remain visible.

Automation might gather the updates and prepare a draft while a person resolves conflicting information and approves the report. The ten-hour target reduction would have to include that person's review time, along with any extra work contributors do to supply the data.

If people spend less time assembling the report but colleagues spend more time fixing its inputs, we need to count both. The agreed scope should capture the total work needed to produce a usable report.

Connect the price to verified value

Part of Four Labs' fee depends on the measurable improvement we help deliver. The client and Four Labs agree the connection between the result and the fee in the proposal.

Each proposal sets out implementation costs, ongoing service costs, the performance-linked component and how each charge is calculated. Technology costs and any usage limits also need to be clear.

For an outcome-linked component, the agreement would specify which result qualifies, how quality affects qualification, when it is assessed and any limits on the fee. It would also explain the treatment of partial results, missed targets and disputed measurements. This gives the client a way to understand its costs before committing.

An agreed target remains subject to the work, data and conditions of the engagement. We do not guarantee a particular result. The commercial terms need to describe who carries which costs and risks, including during implementation and testing.

AI usage still matters when managing operating costs. A higher token count, on its own, gives us no reason to say the client received more value. The evidence should show what changed in the business process and whether that change meets the agreement.

Make the partnership accountable in everyday work

A financial stake needs a working process behind it. Four Labs would be responsible for the agreed design, implementation, testing and reporting. The client would identify a process owner, provide the agreed access and records, and make the business decisions that remain with its team.

Those responsibilities should be written into the scope. If a result depends on someone approving an invoice or supplying missing data, we need to know who owns that step and how its timing will be recorded.

Both sides should be able to inspect the evidence behind a performance report. We would review the baseline, current results, volumes, quality checks and exceptions together. A smaller workload or a change in supplier mix could affect the numbers even if the automation had not improved.

Where a comparison cannot fairly separate the effect of our work from other changes, we should record the uncertainty and apply the agreed treatment. We should not assign every improvement to the automation or remove difficult cases after the fact.

If a target is missed, the review should identify what happened. The cause might be an implementation defect, poor source data, a change in the work or a dependency neither side accounted for. We would agree corrective work and a review date, then apply the commercial terms already in place. Any revised scope or fees would need agreement.

The client can then judge whether continuing, changing or stopping the work makes sense. Part of our fee depends on that result, so we keep examining the evidence after delivery. The proposal should define the support, review cadence and responsibilities that continue after deployment.

Operator is our main product for running business workflows around a team's messages, rules and approvals. We assess its fit after understanding the process and the outcome. Our work with a client includes choosing where to start, testing the change with the team and reviewing its performance within the agreed scope.

Bring one process to the first conversation

Choose a recurring process your team wants to improve. Bring an example of the work, the records you have today and the name of the person responsible for it.

We can work through the desired outcome, what would count as a useful improvement and what evidence we would need. From there, we can define a scope and proposed commercial terms for you to review.

Talk to Four Labs about an outcome you want to measure.