A faster task can be useful without reducing cost. More proposals can be useful without increasing sales. A better forecast can be useful without changing inventory.
The business case needs to show what happens between the technical improvement and the financial result. Measure that connection during the work, so the investment decision can use observed evidence.
Decide what the test needs to prove.
A model can work well on a sample of data while leaving important business questions unanswered. Will the information arrive in time? Can people use the result? How much checking is required? What will it cost to run?
| Technical proof of concept | Proof of value in real work | |
|---|---|---|
| Main question | Can the technology do the task? | Does using it improve the business outcome? |
| Work included | A defined technical task | Enough of the surrounding process to test the effect |
| People | Feedback or evaluation as required | People using, reviewing and acting on the result |
| Measures | Accuracy, completion, speed and technical cost | Quality, effort, time, operating cost and the intended benefit |
| Decision | Whether the approach is technically feasible | Whether to expand, revise, narrow or stop |
Both are useful. A proof of concept may have successfully answered its technical question. The next test should cover the conditions that remain uncertain.
At Become, a minimum viable capability (MVC) means the smallest credible version of a business capability that can test value in real conditions. It combines the necessary technology, information, human decisions, process, controls and measures. The term describes the scope of the test; it does not require a miniature version of the entire finished product.
For an illustrative quotation assistant, that might mean receiving a representative enquiry, accessing relevant pricing, producing a draft, supporting review and recording the time and corrections involved. Establishing whether the team can return a reliable quote sooner at an acceptable cost matters more than a polished interface.
Start with the result and the baseline.
Choose the outcome you expect to improve: additional sales, higher contribution, lower operating cost, reduced working capital or another relevant result. Define what you mean. “Productivity” could describe faster completion, more output, better quality or fewer paid hours; those are different outcomes.
Measure a representative period before the change. Depending on the work, record demand and customer mix, completion time, staffing, exceptions, quality, conversion, cancellations and cost per completed outcome.
Separate observations from estimates. Note changes in prices, staffing, demand or incentives that could affect the comparison. An improvement occurring during an AI test does not establish that AI caused all of it.
Test the assumptions that could overturn the case.
List the assumptions most likely to change the investment decision:
- the required information is available when the work happens;
- users can trust the result enough to act on it;
- checking and corrections do not consume the time saved;
- quality is sufficient for the customer or business need;
- the capability improves a consequential part of the process;
- running and support costs leave a worthwhile benefit.
If review effort carries most of the uncertainty, measure it directly. If customer acceptance matters, a technical benchmark alone will not answer the question.
Choose a limited, representative set of work, including incomplete information and unusual cases. Make each human decision clear: what someone sees, what they check, when they intervene and what expertise they need. Record the effort contributed by the project team as well as future users. Hidden manual preparation or repair can change the economics of wider use.
Use enough integration to create a credible test. A temporary manual connection can be appropriate if its effort is visible and the implications for a working service are understood. Agree acceptable quality, operating burden, costs and the conditions that would invalidate the case before results arrive.
Follow one improvement through the business.
Consider an illustrative capability that flags order exceptions before dispatch. Its proposed value depends on people resolving those exceptions in time.
| What needs to happen | What to measure |
|---|---|
| The system identifies the relevant orders | Useful detections and missed exceptions |
| The team can act in time | Review effort, actions taken and time to resolution |
| Those actions improve fulfilment | Orders completed, cancellations and repeat contacts |
| Better fulfilment improves the economics | Additional fulfilled sales, associated costs and contribution |
Measure unwanted effects too. False alerts can create extra work. Rushed interventions can cause errors. The value case needs the net effect on the completed outcome.
Keep three kinds of productivity benefit separate.
Time saved.
The task takes fewer minutes. Record the saving after review, corrections and exception handling. This is an operating improvement; it does not automatically reduce expenditure.
Capacity released.
The team can do more useful work. Establish whether demand exists, whether the saved time is usable and what additional work actually gets completed. Scattered minutes may not translate into a complete extra task or shift.
Cost removed or avoided.
Paid hours, overtime, contractor spend or planned recruitment change. Record the decision, timing and any transition costs. Show avoided future expenditure separately from a reduction in current spending.
Pricing every minute at a salary rate can estimate the scale of an opportunity. It should not be reported as a realised saving unless the corresponding financial change has occurred.
Include what it costs to run.
Licence fees and model usage are only part of the cost. Include data preparation, integration, support, monitoring, human review, training and ongoing improvement. Make one-off build and transition costs visible alongside recurring operating costs.
Separate costs that rise with volume from those that remain fixed. Record how shared costs are allocated so that several initiatives do not each claim the same saving or exclude a cost someone still has to pay.
For a revenue opportunity, calculate the contribution from additional sales after the associated costs. Revenue alone overstates the benefit available to cover the new capability’s cost.
Choose a comparison that fits the work.
A matched group, staggered introduction or suitable before-and-after comparison can help distinguish the effect of the change. Where appropriate, random allocation provides a stronger comparison. Sensitive work may first need observation or testing before recommendations influence decisions.
Document the limitations. A seasonal shift, a new price or a staffing change may explain some of the movement. Use a credible range where the evidence cannot support a precise attribution.
Agree the method with a Finance partner and a named business owner. Technology teams can measure system performance; the business owner needs to ensure that the changes required to create value happen.
If the pilot disappoints, find the real constraint.
First recover the original investment case. If it never specified the revenue, cost, capacity, quality or customer measure expected to change, establish that before committing to more work.
A faster task may sit inside a process still limited by waiting, approvals, demand or product availability. Follow the work from the initial need to its completion. Identify where delays, errors or lost opportunities accumulate, then check whether the capability changes that part of the process.
Examine whether the test concealed operating effort through clean sample data or close project-team support. Compare those conditions with ordinary work before treating a demonstration as evidence for wider use.
People may still complete the old reports, checks and approvals alongside the new process. Responsibilities or incentives may discourage acting on a recommendation. Name the owner of the business result, the work that should stop or change and the authority needed to do it. Confirm how people recover when the capability cannot help. The guide to scaling AI and its operating model explains those responsibilities.
| Finding | A proportionate response |
|---|---|
| The business case is weak | Reassess, narrow or stop the opportunity |
| The benefit is credible but a technical condition fails | Test or fix that condition before expanding |
| Review and exceptions consume the benefit | Redesign the capability or revise the economics |
| The capability works but surrounding processes prevent use | Resolve ownership, process or incentive changes |
| Representative use supports a worthwhile result | Plan expansion with operating costs and responsibilities included |
Report the decision the evidence now supports.
Bring together the baseline, observed change, full cost, remaining assumptions and recommended action. Distinguish realised financial effects from forecasts, capacity benefits and strategic or risk benefits that have not been converted into a P&L figure.
Include user behaviour, checking and exception effort, and the requirements for reliable day-to-day operation. A useful capability may improve service or quality without removing cost; describe that result accurately.
The next step may be expansion, a narrower build, a process change or a further test of one unresolved assumption. Stopping can also be a useful result. State what would justify the next investment, who is responsible and when to review it. Completing a pilot does not commit the business to a larger programme.