The meeting starts well enough. Someone asks how many active customers there are this month. Sales says 340. Accounts says 312. Five minutes follow trying to work out who's counting what — and the meeting never quite gets back to the point it was called for.
What happens next is what matters. Nobody's going to investigate which of the two figures is right. Both people leave the room trusting both systems a little less, and next time they bring a number they've already checked by hand.
The symptom has a name: the parallel spreadsheet
Go and ask your teams what spreadsheets they keep on the side. You'll almost always find them, and almost always well kept: the customer list sales updates by hand because the system has duplicate records, the order tracker logistics rebuilds every Monday, the hours log someone put together because nobody trusts the official report.
These files aren't laziness or stubbornness. They're the reasonable response of someone who needs information they can trust and can't find it where it's supposed to be. The trouble is that, once they exist, they start competing with the systems — and they win, because whoever keeps them knows exactly what's in there.
Nobody decided to end up here
No company chooses to have three versions of the same number. You get there gradually, and each step seemed sensible at the time it was taken.
An invoicing package got bought. Later, a sales management system, because the invoicing one wasn't built for tracking proposals. Then a customer service tool, because sales wasn't the place for that. At each of these points, someone had to decide where the customer “lives” — and the decision got put off, because there were more urgent things going on.
Years later, the customer exists in all three. With different addresses, the name spelt two different ways, and a status that's only up to date in one of them.
Why training and dashboards don't fix it
The usual reaction to this problem is to buy a visualisation tool and train teams to “make decisions based on data”. It's well-meant money, badly spent.
A good-looking dashboard pulling from an inconsistent database produces inconsistent charts, with the added problem that they now look official. And people asked to trust numbers they themselves know are wrong won't trust them — they'd be wrong to. Their scepticism is competence, not resistance to change.
Where the repair starts
You don't sort it all out at once, and it's just as well: whoever tries to fix the whole company in a six-month project usually runs out of steam by month three.
- Pick a number that hurts. The one that's already caused arguments in meetings. Just one.
- Decide where it's born. One system becomes responsible for creating and maintaining it. One, not two.
- Connect the others to that source. Instead of each one keeping its own copy, they fetch it from where it's true. This is integrations and APIs work.
- Retire the parallel spreadsheet. But only once the official version is right — and tell people you can go back if it fails.
Once this is done for one number, do it for the next. The list is usually shorter than it looks: five or six figures explain most of the arguments.
Trust comes back slowly
Don't expect the team to believe the new report straight away. Distrust took years to set in, and it doesn't leave with an internal announcement.
What undoes it is repetition: the number adds up this week, adds up the next, adds up when someone tries to catch it out. After two or three months, the parallel spreadsheet stops being opened without anyone giving the order. That's the sign it's taken hold.
And it's only from that point that it makes sense to think about automating decisions or putting artificial intelligence to work reading the operation. Before that, all you do is speed up the error.
Do all your systems say the same thing?
Tell us what systems you have and where the numbers don't add up. We'll look at the whole picture and tell you where to start — and what it costs.