An AI Business Case That Includes Integration and Ongoing Operations

A credible AI business case does not stop at a licence, model, or prototype. It includes the work required to connect a system to real workflows, the people and controls needed to operate it, and the evidence that would justify continuing investment. Without those elements, a projection can look attractive while leaving the largest costs and the hardest delivery decisions out of view.

This guide turns that problem into a repeatable decision process. It is intended for mid-market leaders who need to compare an AI proposal with other uses of engineering capacity and capital, not to produce a forecast with false precision. The worked example is explicitly hypothetical; its figures illustrate how to structure assumptions and are not a price estimate or a prediction.

Prerequisites

Before starting, name an executive sponsor, a workflow owner, and a technical lead. The sponsor can make a funding decision; the workflow owner understands current volumes and service outcomes; the technical lead can estimate integration and operational work. One person may fill more than one role in a small organization, but the accountabilities still need to be explicit.

Bring a recent view of the current workflow: volume, elapsed time, handling effort, rework, exceptions, service levels, and the systems involved. Use a representative period that includes normal variation rather than selecting an unusually busy or quiet week. If the organization cannot access these measures, treat that as a discovery task, not as permission to invent a baseline.

Agree on the decision the business case must support. It might ask whether to fund a limited implementation, whether to expand an existing pilot, or whether to stop. These are different decisions. A pilot budget should buy evidence about specific uncertainties; a scale decision should require evidence that the workflow works reliably enough to justify the full operating commitment.

Finally, identify constraints that could change the design: data access, contractual terms, retention needs, review obligations, latency, availability, and the systems that must exchange information. For a deeper procurement and technical evaluation of an AI agent, use Buying an AI Agent: Questions for Security, Procurement and Engineering. This business case uses those constraints as cost and feasibility inputs rather than attempting to replace that assessment.

Tip: Keep a dated assumptions log. Record who supplied each input, its period and unit, how certain it is, and what evidence would improve it. A named estimate is easier to challenge and update than a spreadsheet cell with no history.

Step 1: Define the decision and the workflow boundary

Describe the workflow in terms an operator would recognize. State what triggers the work, what information is available at that point, who or what acts next, and what counts as a completed outcome. “Use AI to improve customer operations” is too broad to cost or measure. “Prepare a draft response to eligible service requests, with a staff member reviewing it before it is sent” is a testable boundary.

Be precise about what the proposed system may do and what remains outside its remit. Distinguish information retrieval, classification, drafting, recommendations, and actions that change a customer record or trigger a transaction. The more consequential the action, the more important it is to specify the checks, fallbacks, and human responsibilities before estimating benefits.

Draw the current process and the proposed process side by side. Include the intake channel, data lookup, decision points, handoffs, exception paths, and final recording of the outcome. The comparison makes integration visible: a proposal that appears to automate one task may depend on several upstream data sources and downstream updates.

The diagram below is a compact funding path, not a system architecture. Each branch represents a decision based on evidence gathered in the numbered steps; “revise” means correct a defined gap before requesting the next funding decision, not keep a pilot alive indefinitely.

flowchart TD
accTitle: AI business case decision path
accDescr: Define a workflow, estimate full ownership, test measurable value, and decide whether evidence supports funding, revision, or stopping.
    A["Define workflow"] --> B["Map integration"]
    B --> C["Estimate ownership"]
    C --> D["Set measures"]
    D --> E["Test assumptions"]
    E --> F["Fund, revise, or stop"]

A common scope failure is counting the visible AI task while excluding the surrounding work. For example, a draft may save handling time but still require staff to open a separate interface, copy data, correct a response, and update the system of record. The right unit of analysis is the complete workflow outcome, not the model interaction in isolation.

For help choosing which workflow deserves investigation first, see How to Choose the First Workflow for Enterprise AI Automation. Keep this article’s decision narrower: once a workflow is under consideration, determine whether the total investment and measurable result justify proceeding.

Step 2: Establish a baseline and name the value measure

Select one primary business outcome before choosing supporting metrics. Depending on the workflow, it could be cost per completed case, time to resolve, throughput within a service window, error-related rework, or conversion through a defined sales stage. The measure should correspond to a real operating or financial decision, not simply model activity such as the number of generated drafts.

Record how the outcome is measured today, where the data comes from, who owns its quality, and how often it can be reviewed. If the baseline is not trustworthy, first fund a short measurement effort or use a clearly bounded pilot to establish one. A business case built on an unknown starting point cannot later distinguish real improvement from a change in counting.

Separate gross time released from cash savings. If a team spends fewer minutes on a task, the business does not automatically realize an equal reduction in payroll. The time may instead support more volume, reduce overtime, improve service, or be absorbed by other work. State which outcome is intended and what operational change would make it real.

For a labour-related estimate, calculate current annual handling effort as eligible annual cases multiplied by average handling minutes, divided by 60. Then apply a conservative estimate of the share of time that could actually be removed or productively reassigned. Do not apply a reduction to all cases if only a subset is eligible, and do not treat a draft that still needs substantial correction as a fully automated case.

Value may also come from fewer avoidable errors, increased capacity, shorter delays, or reduced exposure to a known operational failure. These benefits should be expressed in a unit the responsible function can validate. If the organization cannot credibly estimate the financial value of an avoided event, describe the outcome and track it separately rather than inventing a probability-weighted saving.

Warning: Do not count the same benefit twice. If released capacity is already valued as additional throughput, it cannot also be counted as a full labour-cost reduction unless a separate staffing or budget change supports that claim.

When a pilot spans locations, How to Measure an AI Operations Pilot Across Multiple Sites separates site-level effects from changes in the overall task mix.

Step 3: Map integration and delivery work before estimating the benefit

Build a task inventory from the proposed process map. Include access to relevant data, data cleanup, identity and permission design, connections to existing systems, user experience changes, logging, evaluation, rollout, training, and the operational handoff. A proposal may not require every item, but each should be considered and either estimated or marked not applicable with a reason.

For each integration, record the system owner, data needed, direction of exchange, expected frequency, failure response, and how a successful update will be confirmed. A workflow that reads information has different failure consequences from one that writes a record or sends a message. For an external effect, define the exact action boundary and the control that prevents a retry or duplicate request from creating an unintended second effect. Do not assume exactly-once execution.

Estimate internal effort by role and phase rather than using one undifferentiated engineering allowance. Separate discovery, implementation, test and evaluation, workflow changes, deployment preparation, and transition to operations. Ask each role owner to state the assumed capacity and dependencies. The estimate is more useful when it exposes a scarce specialist or a business-side dependency than when it offers a falsely precise total.

Include the cost of adapting the process. Staff may need a new review step, managers may need exception queues, and the workflow owner may need to revise policies or operating procedures. These tasks are not incidental if the proposed value depends on people using the new process consistently.

Use three estimate categories: committed, likely, and uncertain. Committed items are known work with an identified owner; likely items are grounded in the process map but need confirmation; uncertain items are unresolved assumptions that could materially affect scope. A funding request can then distinguish a capped discovery or pilot from a later implementation commitment.

A useful integration estimate also names the conditions that would change it. A clean, well-defined source field may be straightforward to use; inconsistent records, undocumented dependencies, or a required change to a core workflow may create additional work. Do not convert those possibilities into a generic contingency without explaining what the contingency covers and who decides whether it is needed.

Step 4: Price the ongoing operating model, not only the launch

List recurring costs by who performs the work and what triggers it. Possible categories include software or service consumption, hosting and data movement, monitoring, evaluation, support, incident response, changes to prompts or workflow logic, vendor administration, and periodic review of whether the system remains fit for its intended task. Include internal staff time even when it does not appear as a new invoice.

Estimate the operating burden at a realistic workload. A small pilot may generate few exceptions and little support demand; a production workflow may see more variation, busy periods, user questions, and failures in connected systems. State the expected range of cases and the support coverage assumed. If the system is needed outside normal business hours, explain who detects and handles a failure then.

Make service dependencies explicit. Identify which party is responsible for the AI component, the integration, the source data, and the business process. For each dependency, note the observable failure, the person who receives the alert, the fallback procedure, and the condition for restoring normal use. A system with a polished demonstration but no owner for a failed handoff is not operationally ready.

Include change over time. A workflow may change when the organization updates its forms, policies, product catalogue, or record structure. Assign an owner to review material changes and an estimate for the work needed to re-evaluate the system after them. Do not assume the first implementation will remain accurate or appropriate without maintenance.

Treat usage-related costs as a function of workload and design, not as a constant copied from a prototype. Record the assumed number of eligible cases, average interactions or processing steps, exception rate, and any periods of higher demand. Where a supplier’s commercial terms or consumption are not yet confirmed, label the estimate as a placeholder and require validation before a larger commitment.

FinOps describes unit economics as relating costs to business units of value, with assumptions and indirect costs included in the view (FinOps Foundation). For this business case, that means putting a cost beside a completed workflow outcome and documenting what the measure omits, rather than presenting an unexplained monthly technology total.

Step 5: Build a complete, phased ownership estimate

Keep one-time investment separate from recurring operation. The one-time view should show discovery, integration, workflow design, evaluation, change management, initial rollout, and any other identified delivery work. The recurring view should show the run costs and staff responsibilities that continue after launch. Make the period and assumptions visible so readers do not mistake a monthly amount for a full-year total.

The following table is a structure for the estimate, not a price list. Fill each row with a source, owner, time period, and confidence level. If an item is genuinely not applicable, say why; if its value is unknown, show that uncertainty rather than entering zero.

Use a period long enough to show the launch and the operating pattern, but do not select a horizon that makes a weak proposition appear attractive. Show the initial investment and subsequent operating periods separately. If value takes time to ramp, reflect the ramp rather than crediting a full run-rate benefit from the first month.

For a simple operating view, define net benefit for a period as validated value realized minus all attributable costs in that period. Cumulative cash payback occurs only when cumulative realized value exceeds cumulative cash outlay. If the organization includes allocated internal time in the business case, show that view alongside the cash view so decision-makers can distinguish budget impact from the economic use of capacity.

Avoid claiming a precise net present value unless finance agrees the assumptions and discounting method. A detailed financial measure cannot repair unreliable inputs. For many mid-market decisions, a phased cash view, ranges, and clearly named assumptions are more decision-useful than a single highly polished return percentage.

Step 6: Work a hypothetical case from the workflow outward

Consider a fictional service organization evaluating AI-assisted preparation of responses to incoming account requests. The intended change is limited: the system may assemble a draft from approved internal information, but a staff member checks it and sends the response. It does not independently commit the company to a contract or change a customer account. This example exists to demonstrate the calculation sequence, not to predict what another company would experience.

Assume the workflow owner reports 12,000 eligible requests per year and a measured average of 18 minutes of handling effort per request. That is 3,600 hours annually before considering exceptions. In an initial planning scenario, assume a reviewed draft reduces active effort by four minutes on 60% of eligible requests. The arithmetic implies 480 hours of gross annual time released: 12,000 multiplied by 60%, multiplied by four minutes, divided by 60.

That 480 hours is not yet a dollar saving. The company must decide whether the capacity can be used to handle more requests, reduce overtime, improve response time, or make another verifiable change. Suppose the business owner proposes to use it to absorb forecasted request growth without adding equivalent seasonal coverage. Finance should check that plan against staffing schedules and demand; if the work cannot be reassigned, the case should not book a payroll saving.

Now add the full ownership estimate. The technical lead identifies initial data and workflow integration, evaluation, and rollout work. The service owner estimates recurring support and monitoring time. The operating lead estimates human review time and exception handling. Finance adds any confirmed external charges. The first-year value is then compared with launch plus operating costs, while later periods include recurring costs and the value the operation can actually realize.

Create three scenarios by changing uncertain inputs, not by changing every assumption until the preferred answer appears. A conservative case might use a lower eligible share, smaller time reduction, slower adoption, and higher exception handling. A planning case uses evidence-supported central assumptions. An upside case uses improvements that have a plausible mechanism and a named owner, not an aspirational target with no operational explanation.

The scenario should also show when the workflow is unavailable or unsuitable. If staff must revert to the existing process for a day, the business case should not pretend that work disappears. If a subset of requests requires specialist judgment, keep those cases out of the expected automation benefit unless the design and evidence support handling them.

Step 7: Set a test that can change the funding decision

Choose a pilot population that reflects the intended operating conditions while keeping the boundaries manageable. Define which cases are eligible, which are excluded, who reviews outputs, and how the current process is available when the new path fails. Specify the duration or sample logic in advance with the workflow owner; do not stop as soon as a few examples look convincing.

Set acceptance measures across business outcome and operational quality. A business measure could be active handling time per completed eligible case. Supporting measures might include correction effort, exception share, completion rate, queue delay, and the rate of incorrect or unusable drafts. Select only measures that can influence the decision. A long dashboard is not a substitute for a decision rule.

Record a baseline and a comparison method before the pilot begins. If volumes, staff mix, or request complexity vary, capture those differences rather than attributing every change to the AI intervention. The evaluation should separate model or system output quality from the final business result: a plausible draft does not prove that a request was resolved faster, more accurately, or at lower cost.

Write decision thresholds as observable conditions. For example: expand only if the measured time improvement survives review effort, the exception process is manageable, and the operating owner can support the workflow within the estimated capacity. Revise if one named technical or operational issue is preventing a fair evaluation. Stop if the outcome measure fails to improve, the required controls make the workflow uneconomic, or the essential dependency cannot be delivered within the approved boundary.

Tip: Decide who can pause the workflow and what happens to in-flight work before the pilot starts. A pause procedure should name the manual fallback, the person who communicates the change, and how pending cases are reconciled.

Step 8: Stress-test the case and inspect failure paths

Run a sensitivity check on the assumptions that have the greatest effect on the decision. These are often eligible volume, actual time saved after review, adoption, exception rate, integration effort, and support burden. Change one assumption at a time to see where the case stops meeting its threshold; then test a combined downside scenario to understand whether several modest disappointments could make the proposal fail.

A counterexample is useful. Suppose the tool produces drafts quickly, but staff spend almost as long correcting them as they did writing from scratch. The visible AI activity may rise, yet net handling time does not fall. If the business case counted generation speed rather than end-to-end effort, it would overstate benefit. The corrective action is not to reinterpret the metric; it is to revise the design, test a different task, or stop if the underlying value is absent.

Trace a plausible operational failure from first symptom to business consequence. A source system may be unavailable, a record may be incomplete, or an output may not match the required format. Who notices? Does the case wait, return to the ordinary queue, or proceed with a staff review? How is the outcome recorded? Who investigates whether the problem is temporary or systematic? Estimate the staff time and delay that this path creates, especially if it is likely to be common.

Also test the economics of partial adoption. If only one team uses the process, fixed integration and support work may be spread across too few cases. If adoption depends on changing established habits, model the ramp and identify the manager responsible for training and follow-through. Do not assume a product will be used simply because it is available.

A proposed design must account for external actions and retries. If the workflow sends a message or changes a record, approval should happen before execution, bind to the exact proposed payload, and expire rather than remaining valid after the underlying facts change. The business result still needs separate verification; a model’s claim that an action succeeded is not proof that the external system reached the intended state.

Step 9: Assign ownership and present a decision-ready worksheet

A business case should end with named owners, not a general statement that “the team” will monitor results. Assign the workflow owner to validate the outcome measure and review operational fit. Assign the technical owner to maintain the integration and report failures. Assign the service owner to monitor recurring effort and changes. Finance should validate how reported operational improvements translate into budget or capacity decisions.

The following worksheet is designed to be copied into a planning document and completed in a decision meeting. It is not a downloadable template. Keep answers short enough to inspect, and attach the underlying measurement or estimate where a reviewer needs to verify it.

Buyer worksheet

Decision requested: What funding or commitment is being requested now, and what is explicitly deferred?

Workflow boundary: What triggers the process, which cases are eligible, what is the completed outcome, and which actions remain with a person?

Baseline: What is current volume, handling effort, quality, and elapsed time? Identify the source, owner, and measurement period.

Value claim: Which primary outcome should change? Who can verify it, and what operational or financial action makes that change valuable?

Integration: Which systems and teams are affected? List data dependencies, read/write actions, failure responses, and estimated effort by role.

Operating model: Who handles support, exceptions, monitoring, changes, and fallback? How much time is expected, and during what coverage period?

Estimate: Separate one-time delivery, recurring operation, internal capacity, confirmed external charges, and unresolved costs. Record the period and confidence for each.

Pilot evidence: What population and comparison will be used? Which outcomes and quality measures can change the decision? Who reviews them and when?

Decision rules: What evidence permits expansion, what specific gap permits a revision, and what result requires stopping?

Reversibility: If the initiative stops, how does work return to the existing process, and what data, integration, or supplier commitments remain?

Responsibility matrix

If no one can take responsibility for a material operating task, treat that as an unresolved cost or a delivery blocker. Do not bury it in a risk register with no decision date. A named owner may be a role rather than an individual during early planning, but that role must be staffed before the workflow moves into production use.

For organizations that need senior technical direction to shape the estimate and delivery decision, fractional CTO leadership may be relevant. The immediate next step is to assemble the workflow owner, technical lead, and finance partner for a scoped review of one proposal—not to commission a broad AI programme before the decision is clear. For a wider view of the roles involved, see Fractional CTO, AI Advisor, or Delivery Partner: Which One You Actually Need.

Summary: fund evidence before funding scale

An AI investment case is strongest when it starts with a bounded workflow and a trustworthy baseline, then traces the proposed change through integration, human work, ongoing support, and measurable business outcomes. Gross time released is not the same as cash saved, a model output is not the same as a completed business result, and an initial implementation estimate is not the full cost of ownership.

Use phased decisions. Fund discovery when the workflow, baseline, or integration remains uncertain. Fund a bounded pilot when it can answer a specific question that changes the next decision. Fund broader operation only when the benefit has been measured end to end, the downside case is understood, and someone owns the work after launch.

The practical test is whether the organization can explain what changes, how the change will be measured, who will operate it, and what evidence would cause leaders to stop. If those answers are specific, the case can be challenged and improved. If they are missing, the responsible decision is to resolve the uncertainty before treating a projected return as a commitment.

WANT TO TALK THROUGH YOUR SITUATION?

Talk it through with us. Thirty minutes, no slides.