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.)
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.