How to Scope Your First AI Project: A Guide for UK Service Businesses

Most first AI projects don’t fail because the model is bad. They stall because nobody agreed what the project was for, what “working” means, or what happens after the demo.

If you run a service business, the stakes are particular. Your expertise is what clients pay for. A tool that drafts a wrong recommendation, or misreads a client’s data, lands on your reputation, not the software’s. So the first project needs to be small, measurable and reviewed by your people.

This is how we’d scope it.

Start with a workflow, not with “AI”

“We should be using AI” isn’t a project. “Our account managers spend most of Monday pulling numbers from three systems into a client report” is.

Before thinking about models or tools, write down one workflow your team already does:

• What starts it. An email, a form, a new month, a client request.
• What goes in. Documents, account data, notes, messages.
• What comes out. A report, a reply, a decision, an updated record.
• Who does it today, and who checks it.
• What takes time, and what goes wrong.

If you can’t describe the workflow on one page, it isn’t ready for AI yet. It might be ready for a simpler piece of software first.

What makes a good first AI project

Some workflows suit a first AI project far better than others. Look for these signs.

Work your team already checks

The best first projects put AI where a person already reviews the output. The AI produces a first draft, a summary or a suggestion, and your expert accepts, edits or rejects it. That keeps quality in your hands and gives you an honest measure of whether the AI is helping.

Enough volume to matter

A task that happens twice a month won’t repay the effort, however clever the result. Pick something your team does daily or weekly.

A known right answer

You need past examples where you know what good looks like: last quarter’s reports, previous client replies, completed reviews. Without them you can’t test the system, and “it seems quite good” becomes the success measure.

Mistakes that are caught and reversible

Keep the first project away from anything that goes straight to a client unreviewed, moves money or makes a decision with legal weight. Start where a wrong answer costs someone a few minutes to fix.

Data you can actually reach

AI is only as good as the information it can read. If the data sits in a system with no API, in personal inboxes or in spreadsheets nobody trusts, the first job may be an integration rather than AI. That’s often the more valuable piece of work anyway.

Typical candidates in a service business include:

• Drafting a first version of a recurring client report from account data
• Summarising a long thread or document set before a client call
• Finding the right answer in your own policies, past work or knowledge base, with a link to the source
• Triaging incoming requests into the right queue with a suggested next step

Agree what “good” looks like before anything is built

This is the step most projects skip, and it’s the one that decides whether the project ends with a clear answer.

Measure today’s process first

Record how the workflow performs now: how long it takes per item, how often it’s wrong or reworked, and which mistakes matter most. Compare the AI against your real process, including its mistakes, not against perfection.

Write acceptance criteria you can check

Acceptance criteria turn “is it working?” into something you can test. For a first AI project they usually cover:

What you’re checking	How you check it
Quality	Your reviewers score outputs against a set of real past examples
Critical mistakes	A short list of errors that fail the project outright, such as a wrong figure in a client report
Time saved	Review time per item with the AI’s draft, compared with doing it from scratch
Coverage	How much of the work the system handles, with the rest routed to people as now
Running cost	Cost per item at realistic volume

Set the targets from your own baseline. Agree them with the person who owns the workflow, write them down, and don’t move them after seeing the results.

Build a test set from real work

Pull a representative sample of past items, including the awkward ones. Have the people who do the work today mark what the right output would be. Keep part of that set aside and use it only for the final check, so you’re not marking the system on examples it was tuned against.

This is what we mean by building evaluation into the product. It’s not a one-off test. It’s how you’ll know, months from now, whether a model change or a new prompt made things better or worse.

Keep a person in the loop, by design

Human review shouldn’t be bolted on. Design it into the workflow from the start:

• A clear review step. Outputs appear where your team works, with the source information alongside, so checking is quick.
• Accept, edit or reject. Every decision is recorded, which gives you a running measure of quality.
• A route for the uncertain cases. When the system isn’t confident, or the input is unusual, it hands over to a person rather than guessing.
• The old process still works. If the AI step is down, work still reaches someone.

You can loosen review later, once the record shows the system getting particular kinds of work right. Some work should keep a person in charge permanently. In a service business that’s usually anything a client relies on as your professional judgement.

Set a scope, a fee and a decision date

A good first project is deliberately narrow:

• One workflow, one team, one kind of input
• A defined fee for a defined piece of work
• Agreed acceptance criteria, written down before the build starts
• Working software deployed in your systems, not a slide deck or a sandbox demo
• A review at the end, with a decision on what’s worth doing next

That last point matters. There are three good outcomes: carry on and build out, make one specific change and test again, or stop. Stopping with clear evidence is a good result. It’s much cheaper than discovering the same thing a year into a bigger build.

Plan for what happens after the first phase

Passing the acceptance criteria shows the approach works. Running it every day needs a bit more:

• Monitoring, so you know when quality or cost drifts
• A safe way to update prompts and models, tested against the same examples
• Access controls, so the system only sees what it should
• A named owner on your side
• An agreed arrangement for ongoing development, with clear priorities and capacity

Scope that as its own step. Don’t let the first phase quietly become the production system without anyone deciding it should.

How we approach a first AI project

Aquila is a small, independent software studio run by two brothers, Scott and Lewis. We design and build client platforms, connected workflows and practical AI for service businesses, and you work directly with us from the first conversation to supporting the finished product.

Our first phases follow the shape in this guide: one useful workflow, a defined fee and agreed acceptance criteria, then working software in your systems and a review together on what’s worth building next. Where AI is part of the work, evaluation and human review are built into the product rather than added at the end. The BoostSR platform we designed, built and continue to develop is an example of the kind of client-facing software we build.

Talk through your first project

Bring a workflow that takes too long or a product idea you want to test. We’ll talk through whether it’s a good first candidate, what the acceptance criteria could be, and what a sensible first phase would look like.

Book a free consultation