Nobody adopts a system they don't trust

You can buy exactly the right tool and still watch your team go back to the spreadsheet. The tool usually works fine. What’s missing is trust, and trust is what decides whether anything you introduce actually gets used.

I’ve been testing a delivery platform with AI built into it. The underlying system is good. The chat layer on top lost my trust in about 4 questions, and that turned out to be the more interesting problem.

Four questions

I asked who was overloaded this week. It came back with a clean table: 2 people flagged, daily capacity, peak day, hours over, week total. It recommended reassigning work or extending deadlines. Genuinely useful, and exactly what I wanted.

I asked if it could reallocate the work. It said it couldn’t do that automatically and needed specifics from me: which tasks, who to move them to, what the new dates should be. Fair, and honest about its limits.

I asked what my options were. It gave me 4 sensible ones.

Then I asked which team members the work could be reallocated to. It told me it needed to know which specific tasks I wanted to move, and then it could check other people’s capacity.

It had shown me the capacity table 3 questions earlier.

So I gave it what it asked for: the tasks assigned to those 2 people this week. It replied that the member IDs I had provided were incorrect, printed 2 long strings of characters, and asked me to try again with the correct IDs.

I had typed 2 names.

Where the trust actually went

None of that is catastrophic. The product is in beta, the vendor already knows, and this is precisely what beta testing is for. Rough edges at this stage are the point.

But look at what those last 2 answers did.

The first asked me for information it already had. It had the capacity data. It had just shown me the capacity data. Then it declined to use it until I did some work first.

The second blamed me for something I had not done. I typed 2 names in plain English. It reported my “member IDs” as wrong and handed me 2 identifiers I had never seen. It exposed its own wiring and framed the failure as my mistake.

Trust survives a tool saying “I can’t do that”. It has a much harder time surviving a tool that sounds certain while being unhelpful, or one that hands you its internals and calls the problem yours.

And once that happens, a quiet calculation starts running in the background of every future answer: do I believe this, or do I check it? A tool you have to check is a tool that costs you time rather than saving it.

This is much older than AI

Long before any of this, the same problem lived in reporting.

If the data going into a system isn’t captured properly, everything built on top of it is suspect. Every report, every forecast, every decision made in a meeting where someone put a chart on the screen. People work out fairly quickly whether the numbers can be relied on, and they adjust their behaviour to match.

I worked with an event marketing business that was moving off spreadsheets. They had events and contracts sold, with the details living in a different personal spreadsheet for each person who touched them. We put a centralised tool in place so the whole picture could be seen in one spot.

What happened next is the part worth paying attention to.

People pulled the information out of the central tool and back into their own spreadsheets, because that was how each of them preferred to work. Then they didn’t go back and update the central one.

So the single source of truth moved into individual files. And it stayed there, because nobody owned the process.

That loop ran for a long time. The cost showed up first as duplication and rework, and then as something worse: work that couldn’t be handed over. When someone got busy, nobody else could pick it up, because the real version lived in their file and their head. Everyone became their own bottleneck. The long hours followed, over and over.

The tool was fine. It never got the chance to be the truth.

The 4 proofs

This is the part I do deliberately now, on every implementation. Trust gets built by evidence, in 4 passes, each one raising the stakes a little.

1. Proof it’s for them. Not the efficiency case for the business, the specific thing that makes a Tuesday easier for the person being asked to change how they work. Buy-in comes before trust, and nobody grants either to a system that’s obviously for someone else’s benefit.

2. Proof of the workings. Where is it pulling this from, how is it gathering it, what is it actually doing when it produces that number. A system people can see inside is a system they can argue with, and arguing with it is how they come to believe it.

3. Proof on their own work. Not a demo dataset. Their clients, their projects, their last month.

4. Proof against the old way. Run the new system alongside the existing one for a project or 2. This is the one people skip because it feels like duplicated effort, and it’s the one that does the heavy lifting. When the new system produces the same answer as the old spreadsheet, and produces it faster, nobody has to be persuaded. They watched it happen.

Trust gets built by accumulation. A system is right in front of you a few times, and at some point you stop checking.

A standard worth keeping

More of the tools arriving now have been prompted into existence rather than built by people who understand the system underneath. Some of them are very good. Some of them will confidently tell you that your member IDs are wrong.

Your team will get stung by one of these at some point, and after that they will be slower to trust the next thing. That caution is reasonable, and it’s yours to work with rather than against.

So earn the trust before you ask for the adoption. Show the workings, run it beside the old way, and let people watch it be right a few times.

A system nobody trusts is a spreadsheet with extra steps.

Most of the trust problems I see come back to the same gap: no one agreed who owns which part of the process, so no one maintains the thing everyone is supposed to rely on. That’s the first thing I map with clients, and the method is written up here for free: the Rhythms, Roles & Expectations System.