Almost every owner of a small company has the same item on the list these days: find out where AI would change the business. Someone has already tried a chat window for emails and summaries, someone is thinking about connecting AI to work orders, quotes or invoices, and most people are asking where to start.
Agencies usually answer with an AI audit, an analysis of your processes and data showing where AI makes sense. For a mid-sized company with several departments and legacy systems this is a broad audit, which runs for weeks and costs tens of thousands of euros, and the scope fits such a company. A small company, from a team of 5 to one of 50, has fewer departments, fewer systems and a shorter path from decision to delivery, so a smaller audit fits better.
We call the smaller one a one-process audit. It takes about two weeks, costs a small share of the pilot it decides on and ends with a clear answer: which single process deserves a pilot, and whether the answer is yes or no. How it works and who should still buy the broad audit follows below.
Why a broad audit does not fit a small company
What a broad audit is built for
A broad audit, the kind written for a mid-sized firm, has to rank use cases across several departments, check the data in several systems, build a business case for each shortlisted idea and sometimes prove one of them with a prototype. Every one of those pieces multiplies with the number of departments and systems involved, so the effort and the price grow with them.
A small company has one or two of each. The owner knows which team loses the most hours, there is one accounting tool and one place where customer data lives, and the person who would run the pilot sits two desks from the person who pays for it. The scope shrinks, so the price should shrink with it.
The audit should cost less than the pilot's downside
The audit exists to protect a pilot budget, so it has to be small next to it. A field service company we worked with wrote 34 pages of requirements on its own, and when we priced the wish list it came to almost EUR 100,000 and nine months of work. A company in this position needs a one-process audit to cut the list down to the first useful piece, and if the audit itself costs a large part of the list, nothing was gained.
Our rule is simple: an audit should cost a small share of the cheapest pilot it recommends. When the audit costs more than the thing it is supposed to de-risk, the company is buying comfort, and comfort is expensive.
What drives the price of an audit
Four things move the price:
- The number of departments in scope.
- The number of systems whose data has to be read.
- Whether the work includes a working prototype.
- How many people have to be interviewed.
A self-check takes an afternoon and costs nothing but time. A one-process audit, covering one process in one system, fits into about two weeks. A broad audit, covering the whole company with every department ranked against every other, takes several weeks and is priced accordingly. The step up is not linear, because each added department brings its own systems, its own vocabulary and its own people to schedule.
The invoice is not the only cost. Someone on your team will spend hours in interviews, pull exports from your systems and read the final readout, and for a small company those hours come from people who also run your operations.
Using a tool is not the same as fixing a process
Most small companies already use AI somewhere, usually as a chat window where someone rewrites an email or summarises a document. This is useful, and it is also the easy part. The hard part starts when AI has to work with your own records: it knows nothing about your clients, prices or rules until they are written down somewhere it has access to. The gap between using a tool and attaching it to a process is where most small-company AI projects stall, which is why the audit should pick a process and not a department.
What a one-process audit should cover
The framework below is a proposal and not a price list. The hours are there to size the work and are illustrative assumptions, so replace them with your own numbers.
Week one: six processes, one score each
Start with a list of six candidate processes, not twenty. Ask the owner and the team leads where hours disappear every week: reading and sorting inbound requests, matching invoices to orders, drafting quotes, writing service reports, answering the same customer questions, compiling the monthly report. For each one, write down who does it, how often, which system holds the data, and what an error costs.
Then score the six on four criteria, from 1 to 5 each: weekly volume, how much of the data already sits in a system and not on paper or in someone's head, the cost of a wrong output, and whether one named person owns the process. The example below is illustrative.
| Process | Weekly volume | Data in a system | Cost of error (5 = low) | Named owner | Total |
|---|---|---|---|---|---|
| Sorting inbound requests | 5 | 4 | 4 | 4 | 17 |
| Matching invoices to orders | 4 | 5 | 2 | 5 | 16 |
| Drafting quotes | 3 | 3 | 3 | 4 | 13 |
| Work order triage | 4 | 3 | 3 | 3 | 13 |
| Monthly report | 2 | 4 | 4 | 2 | 12 |
| Onboarding documents | 1 | 2 | 4 | 3 | 10 |
Keep the rejected rows and write one line on why each lost, because it stops the same idea from coming back every quarter.
Week two: one process, real records
Pick the top scorer and spend the second week on it alone. Pull 50 to 100 real records, such as actual requests, actual invoices or actual work orders, and read them with the person who handles them daily. You are looking for three things: how messy the input is, how many cases follow a rule and how many need judgment, and what the right answer looks like when a human gets it right.
Interviews produce optimistic answers because people describe the process as designed. Real records show the process as it runs, with the missing fields, the PDF scans and the exceptions everyone handles from memory. This step costs a few days and decides most of the outcome, so skip nothing else before you skip this.
The week ends with four deliverables on two pages:
- The business case for the one process, including the monthly run cost after go-live.
- A stop rule agreed before any pilot starts.
- A go or no-go.
- For a go, a 90-day plan with one owner.
A no-go is a good result. It costs you a small audit fee and saves the pilot budget.
What a one-process audit cuts, and what you lose
The one-process audit drops the org-wide readiness score, the stakeholder interviews across departments, the working prototype and the multi-system data analysis. You lose breadth. A process in a department nobody interviewed was possibly the better pick, and you get no demonstration of the model on your data until the pilot starts. The scoring table limits the damage because the five rejected rows stay on file and you rerun the exercise in six months with new numbers.
Who should still buy a broad audit
A broad audit earns its price in four situations:
- The company has several departments competing for the same budget and needs one defensible ranking.
- The candidate process touches several systems whose data does not line up.
- The use case sits near regulated decisions such as hiring or credit, where scope grows quickly, and our guide to EU AI Act transparency obligations shows how fast.
- The board wants a working prototype before approving anything.
If two of those four apply to you, pay for the broad audit.
Four cases from practice
We run AI strategy and discovery next to custom software, integrations with ERP and payment systems, and our own product, Serwizz, a CMMS for maintenance and service teams. The one-process audit grew out of work with service, marine and manufacturing companies, and four of those cases showed us what it must not skip.
Yacht service and refit: involve everyone in the process
A yacht service and refit company has about fifteen technicians, mechanics and electricians, and around 150 boats and 350 work orders a year pass through its workshop for roughly 120 clients. When we started, the same service was recorded in three places: on the company's paper form, on a paper the client signs on the boat and in the engine manufacturer's electronic report. Management assumed one boat meant one work order, and the workshop manager corrected this: a yacht stays from September to June and carries five parallel jobs under the same order, among them engines, generator and stabilisers, each with different people. An app built on the first picture would have been a faster wrong process, so before the first line of code we ran a workshop with management and technicians and fixed the data model on paper. Today the technician writes the report on a phone every day, and one PDF with the client's signature and all the hours comes out at the end of the job. This is why the audit reads real records together with management and with the people who handle them every day.
Production institution: start where it hurts most
An institution with production sites and more than 200 employees had a time and attendance system, an HR department, accounting and an accounting program which did not talk to one another, so the manager who contacted us carried the information between the four himself. They came with a maintenance list, a machine database per site, fault reports, certificates and service reminders, but when we went through what hurt most, it turned out to be the monthly hours calculation for more than 200 people, assembled by hand from several sources. We started there and left maintenance for later. This is why the audit begins by scoring six processes instead of accepting the one the owner arrives with, since the answer to what to digitise first is often not the one you came with.
Charter and yacht service: AI cannot bill what nobody wrote down
A charter company which also manages and services yachts, with several offices along the coast, had a problem with data and not with paper: a technician would head to a boat without knowing who would be billed for the hours, the boat owner, the shipyard if the job was under warranty or a company within the same group, and the same boat at the same berth sometimes had two different payers. Work orders travelled between offices by email as PDFs, and we developed nothing new and only agreed on how the data is entered: an office is a client, a boat is an asset and a warranty is a flag on the work order. We started a pilot with two technicians in one office so the rules would settle on a small team, and after a few weeks the administrator wrote to management: continuing with PDFs would bury them in paper again, while a colleague had opened the app the same day and had everything in front of him in real time. What they care about most is how many hours went to regular work and how many to warranty, per boat, client and owner, and AI answers the question in seconds over their data, but only since the warranty flag exists on every order. This is why the scoring table has a separate column for data.
Tax advisory office: four questions before the first licence
A tax advisory office rolled out AI this autumn, and the whole team received their licences on the same day, which was the fastest part of the project while everything else took much longer. At the first meeting we heard everything sits on a local server mirrored one to one to the cloud, and later it turned out nobody in the office knew whether everything was mirrored or only part of it, or where the copy goes. Web search did not work for the whole team, because the organisation's administrator has to switch it on and nobody knew who held the role, while client data was scattered across the server, a task tool and email. Four questions came out of this, and they need an answer before the first licence is bought:
- Where is the data?
- Who is allowed to see what?
- Who manages the settings?
- What is the source of truth for client data?
If one of them has no answer, this is the first job and it is not a job for AI, because a licence is a one-day cost and most of the work of introducing AI goes into clearing up these things. The four questions are the last item on the list at the end of this post.
A work order process in Serwizz shows the same logic from the other side: a company running work orders there already has the structured history an AI feature needs, while a company running them on paper needs the system first. We have not published a fixed price for an audit of this size, and this post does not claim one. We scope it with you on a first call, based on the number of processes, systems and people involved, and apply the rule from the start of this post: the audit costs a small share of the pilot it decides.
Bring this list to your first conversation
A small company does not need the broad audit a 500-person company buys. It needs one process, two weeks, real records and a decision, and any proposal built for several departments is the right tool for a different company.
Before you talk to anyone, gather six things:
- A list of the six processes where hours disappear.
- The name of one owner per process.
- A sample of 50 to 100 real records from your top candidate.
- The names of the systems holding the data, with someone who has access.
- A figure for the monthly hours the process costs today.
- Answers to the four questions from the tax advisory office story.
With those in hand, any audit, ours or someone else's, finishes faster and costs less. If you want a second opinion on the scope, read our AI strategy guide for small businesses and our post on AI-driven digital transformation, then reach out to book a discovery session.
