Ask a small business owner about their data and you'll often get an apology. Not enough of it, not clean enough, not the sort of thing you could do anything clever with. There's usually a sense that proper analysis is something that happens in bigger companies with data teams.
It's almost never true. A business turning over a couple of million pounds is generating a genuinely rich dataset: every transaction, every customer, every product, every job, every payment, usually going back years. By any historical standard that's an enormous amount of operational detail — far more than most large companies had twenty years ago.
The problem isn't volume, and it usually isn't quality either. It's that the data lives in five places and no single place can see across it.
Why fragmentation is so disabling
Every interesting question in a business spans systems. That's not a coincidence — it's what makes them interesting.
Which customers are most profitable? Revenue lives in the accounts package. The cost of serving them lives in the job or time system. The discount lives in the order. Three systems, so no system can answer it.
Is that marketing spend working? Spend is in one place, enquiries in another, orders in a third, and typically nothing carries an identifier across all three.
Are we about to run out? Stock in one system, sales rate in another, inbound purchase orders in a third, and the lead time in somebody's head.
Which of our services actually makes money? Needs revenue by service line and time spent by service line, which are almost never recorded against the same categories.
Each of those is answerable with data the business already owns. None is answerable from inside any single tool it currently pays for — which is why the answer is usually a spreadsheet and a spare evening, and therefore why it happens quarterly at best rather than weekly.
You don't have a reporting problem, a BI problem or an AI problem. You have an identity and definition problem: the same customer has three different names across your systems, and the word "sales" means four different things depending on who you ask.
Fix those two and most of the "we haven't got the data" complaints evaporate — because it turns out you had it, in pieces, all along.
The two things that actually block it
Identity
"J Smith Ltd" in the accounts, "Smith (John)" in the CRM, customer 4471 on the till, and "Smiths" in the delivery spreadsheet. Until those are resolved to one entity, every cross-system number is wrong — and being wrong is worse than being absent, because people act on it.
Identity resolution sounds technical and is mostly clerical. Some of it can be automated by matching on company number, postcode or email domain. A residue always needs a human to look at a list and say "those two are the same". That residue is usually a couple of hundred rows, not thousands, and it's a one-off job with an ongoing trickle.
The important decision is which system owns the customer record going forward. Without that, you'll resolve the identities once and they'll diverge again within a year.
Definition
Sales including VAT or excluding it. Gross of discount or net. At order date or invoice date or payment date. Does a deposit count when taken or when the work is delivered? Is a credit note a negative sale or an adjustment to a previous period?
All of those are defensible. All of them produce different numbers. And until one is written down, every report is arguable rather than actionable — which is the state most small-business reporting is permanently in.
This is a business decision, not a technical one. It takes a conversation and a document, and the document is worth more than any software you buy afterwards.
What "joined up" actually costs
Less than people expect, because the technology stopped being the hard part several years ago.
A managed Postgres database costs less per month than a phone contract at small-business scale. Most modern business software has an API, and the ones that don't usually have a scheduled export. Sync logic is a well-trodden problem.
The real work is in the mapping: deciding what your core entities are — customer, order, product, job, invoice, payment — and how each system's version corresponds to them. That's a few days of thinking, once, and it's the part that determines whether the whole thing is trustworthy.
What's genuinely expensive is the alternative: paying a senior person to reconcile systems by hand indefinitely, and making decisions on a picture that's always a few weeks old.
The bit that gets skipped: history
Many systems only show you the current state. What's in stock now. What stage each deal is at now. Which customers are active now.
That makes a whole class of questions unanswerable. How long does a deal typically sit at proposal stage? Was stock cover getting worse before we ran out? When did that customer's ordering actually start slowing?
The fix is trivially cheap and only works in advance: record a snapshot of the things that matter, daily. Storage is effectively free at this scale. Nobody has ever regretted having kept it; plenty of people have discovered they needed it and started from zero.
If you do nothing else after reading this, start keeping snapshots. In a year's time you'll be able to answer questions that are currently impossible, at a cost of approximately nothing.
The order that works
- Write the five questions you want answered every week, as literal sentences in the words you'd actually use.
- Find which systems hold those answers. Usually two or three, not eight — the questions do the scoping for you.
- Agree what the words mean. One line per term, written down, circulated.
- Resolve identity for the entities in those questions. Usually just customers and products.
- Connect only those systems, read-only, and check the numbers by hand once — properly, against the source.
- Start keeping history from day one.
Notice how little of that is software. Steps one to four are decisions, and they're the reason these projects succeed or fail. The connecting is the easy bit, and it's the bit everyone starts with.
The failure mode of doing it the other way round
Connect everything, build a dashboard, hope insight falls out. This is the standard approach and it produces a predictable result: a technically impressive system that nobody trusts, because the first time two numbers disagreed nobody could say which was right.
Trust is the whole asset here. A joined-up data layer that people believe changes how a business is run. One they're sceptical of is worse than nothing, because it adds an argument to every meeting.
Trust comes from the boring steps: agreed definitions, resolved identities, and one careful manual reconciliation at the start that everyone witnesses.
The part that's genuinely new
Once the data is joined and the words are agreed, the interpretation layer that used to need a person with time and access can be automated. Not the judgement — the reading. Which product moved, which accounts went quiet, whether the overdue balance is one customer or a general slide, what's different about this week.
That's what makes the joining-up worth doing now rather than eventually. The plumbing was always the hard part and it hasn't got much easier. What's changed is the size of the prize for finishing it — and, for the first time, the fact that finishing it puts a competent analyst's output within reach of a business that could never justify employing one.