There's a pattern to AI disappointment in small businesses, and it almost never involves the AI being bad at language. It goes like this: somebody buys a clever tool, connects it to one system, asks it a question that spans three, and gets a confident answer that's wrong. Trust evaporates, the subscription gets cancelled, and the conclusion drawn is "AI isn't ready".
The AI was fine. The question was unanswerable with the data provided.
"Which customers are most profitable?" needs revenue, cost of delivery and time spent — three systems in most businesses. "Are we going to run out?" needs stock, sales rate and inbound purchase orders. "Who should we chase?" needs invoices, payments and the conversations already had. A tool wired into your accounting package can see one slice of each of these, and language models are obliging by nature: ask them a question they can't answer and they'll answer the nearest one they can.
The unglamorous middle layer
Between your software and anything intelligent sits a layer nobody puts on a website: one place where your data is joined up, consistent and current. Warehouse, hub, single source of truth — the name doesn't matter. What matters is that "customer" means the same thing everywhere, and that all the facts about a customer can be looked at together.
This is dull, and it is the whole ballgame. With it, an ordinary language model can answer real questions about your business. Without it, the most advanced model available can only be eloquent about a fragment.
- Identity. The same customer is "J Smith Ltd" in one system, "Smith (John)" in another and a numeric ID in a third. Until they're resolved into one entity, every cross-system number is wrong.
- Definition. Sales including VAT, excluding VAT, gross of discount, at order date, at invoice date. All defensible; all different. Pick one, write it down, use it everywhere.
- Time. Answering "how does this month compare" requires history. Many systems only show you the current state, so if nobody is keeping snapshots, your comparisons start the day you begin.
What "joined up" actually requires
Less than people fear, and in a specific order.
A place to put it
A single database that you own. Not a spreadsheet — spreadsheets can't be refreshed reliably or queried by other software, and they acquire manual edits that quietly become the real numbers. A managed Postgres database costs less per month than a phone contract at small-business scale.
A way to get data in
Most modern business software has an API. Some has only a scheduled export. A few have nothing usable, and it's much better to discover that before you've planned a project around it. Two questions to ask of every system: can it be read programmatically, and can it tell me what changed since last time? The second is what makes hourly refreshes cheap instead of brutal.
A canonical model
The step that gets skipped. Decide what your core entities are — customer, order, product, job, invoice, payment — and map each system's version onto them. This is where identity resolution and definitions get settled, and it's mostly a business conversation rather than a technical one.
History
Keep the snapshots. Stock levels, pipeline stages, account statuses: recording what was true each day costs almost nothing and is the only way to answer "when did this start?" later. Nobody regrets having kept it; plenty of people regret not starting sooner.
Then, and only then, the intelligent part
Once the layer exists, the AI work becomes surprisingly modest — and surprisingly reliable. Three things account for most of the value:
Explanation. Numbers moved; write the two sentences saying why, grounded in the actual rows. This is what turns a report from a scoreboard into something you act on.
Language over structure. Ask a question in English, get an answer from your own data. The model's job is translating the question into a query and the result into a sentence — not knowing anything about your business from memory.
Drafting. The chase email, the reorder nudge, the follow-up. The model writes; a person approves. This is where the hours actually come back.
Notice what's absent: nothing here asks the model to remember your data, to be right about your prices from training, or to make a decision unsupervised. The data layer does the remembering. The model does the reading and writing. That division is why the results hold up.
Doing it in the right order, cheaply
You don't need everything connected before anything works. The sequence that de-risks it:
- Pick the five questions you want answered every week. Write them as sentences. This decides everything downstream — you'll be amazed how much you don't need.
- Work out which systems hold those answers. Usually two or three, not eight.
- Connect those systems only. Read-only. Resist the urge to be comprehensive.
- Get one report working end to end. Boring, correct, arriving on schedule.
- Check the numbers by hand once. Genuinely once, properly. Trust is built here or not at all.
- Then add the intelligent layer on top of data you already believe.
Each step produces something useful on its own, which means you can stop at any point without having wasted the previous one.
- Where does the data live, and whose account is it in?
- If we stop paying you, what do we keep?
- What happens when a number looks wrong — can we trace it back to the source row?
- Is access read-only, and what exactly could this write to?
- What can't this answer? (A supplier with no answer to that hasn't thought about it.)
What the middle layer actually looks like
Worth demystifying, because "data warehouse" makes it sound like a project with a steering committee.
At small-business scale it's one Postgres database, a handful of scheduled jobs that read from each source system, and a set of tables holding your core entities — customers, orders, products, invoices, payments — plus a table recording every sync run so gaps are visible.
That's genuinely it. The hosting costs less per month than a phone contract. The complexity isn't in the infrastructure; it's in the decisions about what the entities are and how each system's version maps onto them.
Two design choices carry most of the weight. First, keep the raw data as it arrived as well as the cleaned version — when a number looks wrong, being able to see exactly what the source system sent settles the argument in minutes. Second, never edit the warehouse by hand. The moment someone corrects a figure directly, it stops being a reflection of your systems and becomes a third version of the truth.
- Roughly 20% — connecting to systems and moving data
- Roughly 30% — identity resolution, mostly clerical, mostly one-off
- Roughly 30% — agreeing definitions, which is a business conversation
- Roughly 20% — checking it against the source until people trust it
Only the first fifth is what most people picture when they imagine this work, which is why the timelines get underestimated.
Identity resolution, practically
This is the step that sounds hardest and is mostly a list to work through.
Start with the automatic matches: company registration number, VAT number, email domain, postcode plus name similarity. In a typical small business those resolve 80–90% of records without anyone looking.
The residue is a list — usually a couple of hundred rows — where a human says "those two are the same". That's an afternoon, once, and it wants to be done by someone who knows the customers rather than someone technical.
The part that gets forgotten is what happens next. Without a decision about which system owns the customer record going forward, the identities you've just resolved will diverge again within a year. Resolution is the one-off; ownership is what stops it recurring.
Proving it before trusting it
Trust is the whole asset, and it's won or lost in one exercise.
Pick a completed month. Produce your five numbers from the new layer. Then produce the same five by hand from the source systems, with somebody who knows the business watching. Where they differ, find out why — and the answer is nearly always a definition, not a bug.
Do that once, publicly, and the reporting is believed from then on. Skip it and every future disagreement reopens the question of whether the system can be trusted, which is exhausting and eventually fatal.
It's also the point at which the definitions get finalised properly, because nothing surfaces an undeclared assumption faster than two people reconciling a figure that ought to match.
The unfashionable conclusion
The best AI project most small businesses could run this year is a plumbing project with a language model bolted on at the end. It's less exciting than the demos, and it's the reason some businesses get compounding value from this technology while others have a folder of cancelled subscriptions.
Sequence beats sophistication. Join the data up, agree what the words mean, keep the history — then the clever part is almost easy.