How to build a business case for enterprise AI: first use case, ROI and real costs

A good business case for enterprise AI is small and specific. It names one process, measures what that process costs today, sets a target the AI must hit and counts every cost, including the ones that arrive after launch. If you cannot state the expected value in one sentence, the use case is not ready.

How to pick the first AI use case

The first project has two jobs: deliver value, and teach your organisation how to run AI work. Choose something that can do both. Score each candidate from one to five on:

• Value: how many hours, errors or delays it removes, or how much revenue it protects.
• Feasibility: whether the data exists, can be reached and is good enough.
• Risk: what happens when the AI is wrong, and whether a person can catch it first.
• Ownership: whether a business leader will own the result and change the process.
• Visibility: whether people will notice when it works.

Don't start with the hardest, most political problem in the company, and don't pick a trivial one either. A process that one team runs every day, with clear rules and a known cost, is usually the right size. For ideas, see enterprise AI use cases by department.

Measure today's baseline first

You cannot show a return without a starting point. Before any build work, record how the process performs now:

• Volume: how many cases arrive each week or month.
• Effort: minutes of staff time per case, and whose time it is.
• Speed: time from request to outcome.
• Quality: error rate, rework, complaints or rejections.
• Revenue effect: money lost to delays, leakage or missed leads, if any.

Pull these figures from your systems where you can, and sample cases by hand where you cannot. A rough baseline agreed with the process owner beats a precise one nobody trusts.

How to measure the value of enterprise AI

Most value falls into three types. Choose the one that matters most for this process and make it the headline number.

Time saved

This is hours of routine work removed, multiplied by the cost of that time. Be honest about where the time goes. If it is not moved to more useful work, the saving stays on paper. In a claims recovery project for a large health system, automating routine authorisations saved 15k hours and let staff focus on complex appeals.

Faster decisions

Shorter cycle times win customers and bring cash in sooner. For an SME lender, our automated underwriting workflow made credit decisions 4.2x faster and increased automated processing by 62%, while borderline cases still went to an underwriter.

Revenue recovered or protected

Some AI work finds money that is being lost. The same claims project delivered a 42% recovery lift by matching EHR evidence to payer rules and logging every decision.

Agree the success measure and the target with the business owner before you build. If the target moves after launch, the project can look like a failure even when it works.

Costs to plan for

The model is rarely the biggest cost. Budget for these as well:

• Discovery and data work: finding and cleaning the data, and getting permission to use it.
• Integration: connecting AI to the CRM, ERP, ticketing tool or document store. This is often the largest share of the build.
• Evaluation: building a test set and checking quality before and after launch.
• Security and compliance: access controls, data handling and a review of how personal data is used.
• Running costs: model usage, hosting, search indexes and monitoring, which all grow with volume.
• People time: subject experts who review outputs, and someone who owns the system after launch.
• Change management: training, updated procedures and support while the team adjusts.

Running costs deserve their own line. Most model providers charge by usage, so a feature that is cheap in a pilot can become expensive at full volume. Model the cost per case at expected and peak volume before you commit, and plan to send simple tasks to smaller, cheaper models.

Build, buy or partner?

There is no single right answer, so decide per use case.

• Buy when the task is common across companies, such as meeting notes or general writing help, and an off-the-shelf tool meets your data rules.
• Build when the process is specific to your business, touches your core systems or is part of what makes you different. You own the logic and can change it.
• Partner when you want to build but do not have the AI, data and integration skills in house, or need to move before you can hire.

Many companies mix the three. They buy general tools for staff, then build or partner on the one or two processes that matter most. If you partner, check who owns the code and models at the end. At Coretus, clients own 100% of the code, designs and IP, written into the service agreement.

How to present the business case

Keep it to one page that a finance director can read in a few minutes:

1. The process, its owner and today's baseline.
2. The target, and how it will be measured.
3. The scope of a first phase, and what is out of scope.
4. Full costs: build, running and people time.
5. The main risks, and the human review that controls them.
6. The decision point: what result justifies the next phase.

Where to start

List three to five candidate processes, score them, and collect baseline numbers for the top one. If you want help shaping the first phase, a project-based engagement suits a clearly scoped first use case, delivered through agreed milestones. For a longer programme, a managed engineering squad gives you a ready team on a flat monthly fee.

Once the case is approved, the implementation steps from pilot to production cover what happens next.