Practical AI operations guide

Build an AI Automation Business Case on Gross Profit

An AI project can help generate more enquiries without earning enough to pay for itself. Build the decision around the gross profit those additional customers can produce, the capacity to serve them and the full cost of running the workflow.

Use this practical worksheet to separate measured results, illustrative assumptions and decisions still to be tested. It is an operating model for a project discussion, not financial or tax advice.

Discuss this workflow (03) 9003 0111

Workflow diagram: Identify extra outcomes, then Deduct direct costs, then Include operation costs, then Test the assumptions.. Select the diagram to view it full size.

Decisions to make before you start

Incremental

Count only the change

Existing sales and enquiries that would have converted anyway do not become an AI benefit.

Gross profit

Deduct direct delivery costs

Revenue alone leaves out the labour, materials and other direct costs needed to fulfil the additional work.

Capacity

Check that work can be delivered

A full diary or constrained team can prevent extra demand becoming profitable sales.

Complete costs

Include build and operation

Review, support, software, training and exception handling belong in the decision alongside the initial implementation.

What makes this decision useful

Use the evidence from your own operation. The examples below are illustrative working methods, not reported client results.

Start with an observable business outcome

Choose the outcome that makes the workflow worth considering: more completed profitable jobs, less paid overtime, fewer avoidable credits or faster collection of existing receivables. These are different types of value and need different evidence. A count of conversations or generated documents may help explain activity, but it does not establish the financial result. Write the chain from task completion to commercial outcome before entering a benefit number.

Keep revenue and gross profit separate

A sale requires delivery. For a contractor that can include job labour and materials; for another business the direct costs will differ. Ask the finance owner how gross profit is defined in the business and apply that definition consistently. The project model should show revenue and the associated direct costs on separate lines. Otherwise an attractive sales figure can conceal a project whose additional work barely covers its own operating burden.

Model the next customer rather than the average slogan

Different customers have different job sizes, repeat behaviour and servicing costs. Use a plausible mix drawn from your records, then examine the incremental customers the workflow is likely to affect. A general average from all historic customers may overstate the value of small enquiries arriving after hours. Keep the calculation grounded in the actual service and acquisition path rather than a broad claim about customer lifetime value.

Make uncertainty visible before spending

Distinguish measured inputs from assumptions and from information you do not yet have. A range of plausible outcomes is more useful than a single precise figure assembled from guesses. Identify the assumption that changes the decision most, such as conversion or available delivery capacity, and design the pilot to test it. This gives the business a reason to invest in learning before committing to a larger rollout.

Build the working method

Each part produces something that another person can inspect and use.

What happens without the project

Define the counterfactual

Describe the current result and the realistic alternative. If staff already return missed calls the next morning, do not assume every missed call is a lost customer. If an existing booking feature could solve the issue, include that option. The incremental benefit is the difference between plausible alternatives, not the difference between the proposed system and an imaginary business that does nothing to recover enquiries.

From enquiry to completed sale

Map the conversion path

Separate incoming enquiries, eligible prospects, booked appointments, accepted quotes and completed paid work. Choose the stages that fit your service. Record drop-offs and avoid multiplying overlapping conversion measures. A booking is not necessarily a completed job. Where the workflow affects only the first stage, keep later-stage assumptions explicit and ask how the business will verify them after the pilot.

Revenue less direct costs

Calculate direct contribution

Use the finance team's agreed cost treatment for the type of work being modelled. Include the direct effort and materials needed to deliver additional sales. Do not silently use the gross margin from a different product line. If a capacity step requires another vehicle, shift or subcontractor arrangement, show that change separately so the model does not assume an unlimited supply of work at the existing cost structure.

A bounded customer value

Treat repeat business carefully

Repeat purchases can make a customer more valuable, but use an observation window supported by records. Show retention, repeat frequency and fulfilment costs rather than multiplying a first sale by an arbitrary number of years. Where the evidence is weak, report the first transaction and a separate repeat-business scenario. This prevents an uncertain lifetime assumption from doing all the work in an otherwise unconvincing business case.

The cost of keeping it useful

Include operating costs

Add recurring software charges, usage, monitoring, human review, exception resolution and planned maintenance. Keep one-off discovery, implementation and training visible. If costs depend on call volume or document volume, model the same workload used for benefits. A system that produces more activity may also create more review and service work, and that cost belongs beside the expected benefit rather than outside the project spreadsheet.

What the pilot must demonstrate

Set the decision threshold

Agree the minimum acceptable quality, the affordable downside and the business outcome that would support expansion. Express the pilot question using observable events. For example, determine whether a defined enquiry group produces additional completed jobs with acceptable handling effort. Do not use a percentage improvement alone where the underlying number is small. A modest pilot can justify further testing without proving the full annual forecast.

How to handle the situations that complicate the result

Task	Traditional	A more useful record	Notes
A phone agent books appointments	Every booking is called revenue	Follow through to completed work	Track whether the appointment was attended, whether work was accepted and what was actually delivered. Keep cancellations and duplicates visible. The booking metric remains useful, but it is an intermediate step in the business case.
An employee gains spare time	Wage rate becomes a cash saving	Identify the actual cost change	If paid hours remain unchanged, describe released capacity and the work it supports. Count a cash benefit only when a relevant expense genuinely falls, such as approved overtime that is no longer required.
Customers order repeatedly	First sale is multiplied indefinitely	Use supported repeat behaviour	Set a defined period and show the assumptions behind repeat purchases. Do not borrow lifetime values from a different customer segment. Shorter observed evidence is preferable to a larger unsupported forecast.
An invoice is paid sooner	The invoice total is new profit	Describe a timing benefit	Faster payment changes when cash arrives, not necessarily the amount of revenue earned. Keep working-capital effects separate from incremental gross profit and avoid adding the whole invoice to project benefits.
Staff recover missed calls	Every missed call is treated as lost	Compare actual recovery paths	Some callers would have returned or received a callback. Estimate the additional outcome caused by the new process, and preserve uncertainty when attribution cannot be established from the available data.
Demand exceeds capacity	Every lead is counted as fulfilable	Apply delivery constraints	Check the diary, equipment, staff and geographical limits. Extra enquiries may need different handling when capacity is full. A model should not promise profit from work the business cannot responsibly deliver.
The project reduces mistakes	All historic errors are assumed preventable	Count the relevant avoidable category	Identify which errors the proposed control can actually detect or prevent. Keep residual error risk and review effort in the model. A broad historical loss figure is not automatically an available project saving.
A pilot has a strong week	One week is multiplied across a year	Build a labelled scenario	Explain seasonality, task mix and the limited observation period. Keep the measured week visible and show the assumptions required to extend it. A forecast is useful without being described as a proven result.

Where the conclusion can go wrong

Double-counting the same benefit

A staff hour used to service an additional customer cannot also be counted in full as a removed wage cost. Likewise, improved conversion and recovered missed calls may describe the same sale. Create a benefit map that links each value line to a distinct change, then check whether the lines overlap. When in doubt, keep the narrower claim until the business can show that the benefits are separate.

Using margin from the wrong work

An overall company margin can be a poor guide to a particular job type. Additional small urgent jobs may involve travel, overtime or subcontractor costs that routine work does not. Use the relevant job category and document any approximation. The purpose is not to produce a perfect accounting model, but to avoid making the decision depend on an obviously unsuitable average.

Treating a model output as an outcome

A dashboard may report that a conversation was successful because the agent completed its script. That does not establish a qualified lead, an accepted quote or a paid job. Define the business event outside the model's own judgement and check it in the system where the work is recorded. Self-reported success should never be the only evidence supporting the financial benefit.

Ignoring the owner of extra work

More enquiries can create a queue for a team that is already busy. Name who follows up, who prepares quotes and who delivers the service. If no one can absorb the extra work, the next investment may be process or capacity rather than more acquisition. Include the cost of any required capacity change before deciding the automation will pay for itself.

Mixing inclusive and exclusive amounts

Keep the treatment of GST consistent with the finance owner's model and label the basis. Do not compare a revenue figure on one basis with costs on another. This guide does not determine the organisation's tax treatment. The practical control is to have finance review the assumptions and definitions before the model is used to approve expenditure.

Hiding downside behind an average

A single expected-value number can conceal a plausible loss-making scenario. Show what happens with lower conversion, higher review effort or constrained delivery capacity. Decide what would cause the pilot to stop and what expenditure is committed before that decision. A bounded downside can make a test reasonable even when the upside is uncertain, but the limit must be real.

Illustrative calculation: additional service jobs

This is an invented planning example, not a customer result or a quoted service price. A service business estimates that a proposed enquiry workflow could produce six additional completed jobs in a month. Each job would generate $800 in revenue and require $500 in direct delivery costs under the assumptions agreed with its finance owner.

The extra revenue would be six times $800, or $4,800. Direct costs would be six times $500, or $3,000. Incremental gross profit would therefore be $1,800. Calling the whole $4,800 a return from the automation would leave out the work and materials needed to deliver the jobs.

For illustration, the business then allows $700 per month for the combined recurring system and operating cost. That leaves $1,100 of monthly benefit before the one-off implementation cost and any other costs not represented in the simplified example. These numbers are assumptions for explaining the arithmetic, not a statement about Yes AI pricing or typical customer outcomes.

If only two extra jobs are completed, the same assumptions produce $600 of incremental gross profit. Against the illustrative $700 recurring cost, that scenario is $100 negative before setup costs. The important question is therefore whether six extra completed jobs are credible, not whether the software can handle six conversations.

The business checks that its team has the capacity to deliver the extra jobs and that those customers would not have booked through the existing callback process. It keeps any expected repeat business outside the base case until records support it. The pilot is then designed to test the uncertain conversion step and the actual review workload.

A simplified recurring break-even point is the $700 operating cost divided by $300 gross profit per extra completed job, or about 2.33 jobs. Because jobs are whole units in this example, three would cover that recurring cost under these assumptions. This is not full project payback: implementation, timing, quality and other relevant costs still need consideration.

What the decision sheet should show

Put the proposed workflow and the alternative at the top. Then list eligible monthly volume, present completion rate, proposed incremental change, revenue per relevant outcome, direct delivery cost, available capacity, recurring project cost and one-off cost. Label every input as measured, estimated or unknown. Add the source and date so stale assumptions are easy to find.

Keep separate lines for incremental gross profit, actual cash savings, released capacity and timing benefits. Do not add them into one total without checking whether they overlap or use incompatible units. The decision owner should be able to explain which benefit pays for which cost and what evidence would invalidate that conclusion.

End with the decision, its owner and the next evidence check. A sensible outcome may be a narrow pilot, a simpler process change or no build. The value of the worksheet is that it makes those choices explicit before the business commits to a larger project.

How Yes AI can help with this work

Turn the proposal into testable assumptions

Yes AI can help translate a broad opportunity into a small set of operational assumptions: eligible volume, current handling, expected change, direct effort and the evidence needed. The result is a model that your finance and operations owners can challenge. We do not need to invent a market average when your own records can provide a more relevant starting point.

Find the important missing evidence

A business case may have detailed software costs but no reliable estimate of how many missed enquiries were genuinely lost. We can identify which uncertainty matters most and propose a way to measure it. Sometimes the next step is a short review of existing records rather than a new system. The evidence collection should be proportionate to the decision and the potential downside.

Scope an operational pilot

Where a test is justified, we can define a limited workflow, human review rules and a clear completion measure. The pilot can be designed to observe the business event that matters rather than only technical activity. Any production integration, ongoing support and expansion remain subject to the agreed scope and evidence from the test.

Recommend a simpler alternative

A revised callback procedure, a clearer form or better use of existing software may address the problem with less cost. If the projected incremental benefit is small or the business lacks delivery capacity, a custom AI build may not be sensible. We can explain the alternative and the condition that would make a later automation project worth reconsidering.

Put the method into practice

Agree the scope before collecting evidence, then make a decision that the evidence can actually support.

Write the value chain

Start with the operational change and follow it through to the business outcome. Mark each link that is measured, assumed or unknown. Keep activity metrics such as calls handled separate from completed profitable work. Confirm that the proposed change is the part of the process causing the current problem.

Agree the cost definitions

Have the finance owner specify the relevant revenue basis, direct costs, recurring expenses and one-off implementation treatment. Use the same definitions in every scenario. Add a note for inputs that are estimates so later readers do not mistake a planning figure for an actual result from the accounts.

Build a bounded base case

Use a realistic workload and apply the current conversion and delivery constraints. Add the proposed incremental change and the full operating cost. Show a conservative scenario and the assumptions that would improve or worsen it. Keep the calculation simple enough that a manager can reproduce it without the author present.

Test the uncertain step

Choose a pilot that can observe the assumption most likely to change the decision. Preserve comparison data and include quality checks. A test of call handling cannot by itself prove long-term customer value, so keep the conclusion at the level the evidence supports and name any further measurement required.

Reconcile before expanding

Compare the pilot's outcomes with destination-system records and actual handling effort. Update the business case, including costs that only became visible in operation. Decide whether to continue, revise or stop. Record the reason so a future stakeholder can understand why the business committed to the next stage.

Turn this guide into your next steps

Use these steps to prepare your own review. Tick a step once you have recorded its evidence. Ticks are temporary and are not saved or sent to us.

Bring one example of the process you want to improve. We can help define the scope, checks and next decision. Consultation options and any fee are shown before you book.

Discuss this workflow

FAQ

What is the difference between revenue and gross profit here?

Revenue is the sale value. Gross profit deducts the direct costs of delivering that sale, using the business's agreed accounting definition. The project also has operating costs and may create other expenses, so gross profit is not the same as net profit or cash flow. Show the layers separately and have the finance owner confirm that the model matches the work being evaluated.

Can released staff time be included in the case?

Yes, but describe what the capacity will be used for and avoid calling it a cash saving unless an expense changes. Capacity can be valuable when it allows needed work to happen, yet a collection of small gaps in a diary may not support the intended activity. Keep the capacity result separate from financial benefits that depend on an actual cost reduction or additional profitable work.

How should we estimate customer lifetime value?

Use a defined observation period, the relevant customer segment and direct fulfilment costs. Show repeat-purchase and retention assumptions explicitly. If reliable records are not available, use first-transaction gross profit for the main decision and present any repeat-business benefit as a separate scenario. A longer time horizon should not be used simply to make a weak project appear attractive.

Is a break-even calculation enough to approve a project?

It is a useful reference, but it does not establish whether the required volume or quality is achievable. Compare the break-even requirement with actual eligible demand, conversion and delivery capacity. Include the downside of errors and the cost of ongoing review. A project can have an appealing break-even number while depending on assumptions that the business has no evidence for.

What if the project mainly reduces risk?

Describe the control and the relevant failure category rather than assigning a dramatic financial benefit without evidence. You may be able to use observed correction costs or documented losses for that category, while retaining uncertainty about future frequency. Risk reduction can justify work, but the reasoning should remain separate from speculative sales growth or labour savings.

Can a supplier guarantee the projected return?

A supplier can commit to a defined scope and acceptance criteria, but this guide does not promise a financial return. Outcomes also depend on demand, staff follow-up, delivery and the assumptions in the model. Ask what evidence supports each claimed benefit and which factors remain outside the workflow. Prefer a bounded test with explicit review points to an unsupported guaranteed-growth claim.

When is the business case too uncertain to proceed?

It may be too uncertain for a full rollout while still supporting a small evidence-gathering step. Identify the unknown that changes the decision and whether it can be tested at an acceptable cost. If the downside cannot be bounded, the required data is unavailable or the business cannot deliver additional work, resolve that condition before committing to implementation.

Bring the workflow you need to improve

Book a consultation to work through your current process, the evidence available and the smallest useful next step. Any implementation is scoped before work begins.

Book an operations consultation (03) 9003 0111

All discussions held in confidence. Australian-based consultants.