I’ve watched a lot of businesses try to break down their silos by buying something.

A new system. One platform. Everything in one place. The idea makes complete sense on paper. Get everyone working from the same information, connect the customer journey end to end, and the silos disappear.

Then six months later, the silos are still there. They’ve just moved. Instead of living between separate systems, they now live inside one. Same territory, same gaps, same “that’s not our bit” conversations, only now everyone is technically using the same software.

That is the trap. And it catches out good businesses, not just disorganised ones.

Every silo is protecting something

Here is the part that took me a while to properly understand. A silo is not usually a technology problem. It is a behaviour or part of a workflow that made sense to someone at some point.

Someone built that spreadsheet because the system did not give them what they needed. Someone kept job history in their own folder because they got burned once when it went missing. A team stopped sharing information freely because the last time they did, they got blamed for something that was not theirs. Silos are rarely built out of laziness, or politics for its own sake. They are built as protection. Protection of time, of reputation, of control, of a way of working that someone relies on to get through the day.

So, when you introduce a new system and expect the silo to disappear, you are asking people to give up something that has been serving them without anyone noticing. And if you have not dealt with why it existed in the workflow, they will not give it up. They will just recreate it inside the new tool.

The journey is connected, the behaviour isn’t

I have seen this play out clearly with many customers. A contractor brings scheduling, jobs, quoting, and invoicing into one system. On paper the customer journey is now joined up. In practice, the sales team still keeps its own view of what has been promised to the customer, because they do not trust that the detail will survive the handover. The engineers still rely on a WhatsApp group, because that is where the “real-time stuff” happens. The finance team still holds things up at invoicing, because they have learned that the job data they receive is often incomplete.

Nothing is technically in a silo anymore. Everything is in the system. But the behaviour is exactly the same, and the customer still feels the joins. They still get asked for the same information twice. They still get a quote that says one thing and an invoice that says another. The fragmentation never really lived in the software. It lived in the way the teams protected themselves from each other.

This is where I would gently challenge the usual thinking. The common assumption is that a fragmented customer journey is a tech-stack problem (too many systems involved), and that consolidating the stack fixes it. Consolidating the stack is often the right move, and I am not arguing against it. A single system genuinely does remove a lot of friction, and trying to stitch together a disjointed set of tools is usually harder and more fragile than moving to one. But the stack was only ever half the problem. The other half is what the silo was protecting, and no amount of software will address that on its own.

What actually brings a silo down

So, what really connects a customer journey across departments? The system gives you the ability. It is the shared understanding that makes it real.

When the sales team can see that scope and evidence carry through cleanly, they stop keeping their own version. When engineers can see that logging something in the app saves them a phone call later, the WhatsApp group starts to fade. When finance can trust the job data, invoicing stops being the place where everything backs up. The silo comes down when the reason for it goes away, not when the software tells it to.

Where education does the real work

This is where education does the heavy lifting, though not the kind of education people usually mean.

Most rollout training teaches people how to use the system. Which buttons, which screens, which fields. That gets you adoption, which is really just people technically doing what they have been told. It does not get you behaviour change, because it never touches the reason the silo existed in the first place.

The education that actually breaks silos, the education I’ve taught and stand behind, does something different. It shows people why the next step matters to the person after them. It helps the engineer see what happens downstream when the job is logged properly, and what happens when it is not. It helps the office understand the pressure the engineer is under in the van, in the rain, with a customer waiting and another job still to get to. It builds a shared picture of how the work moves through the whole business, so people stop optimising for their own bit and start seeing the joins. That is when adoption turns into best practice. And best practice is really just a lot of people trusting that doing it the right way will not come back to bite them, trusting the workflow.

So where would I start

If I were advising a business heading into this today, I would not start with the system. I would start by asking why each silo exists. What is each team protecting, and what would they need to see before they would be willing to let go of it. That conversation tells you more about whether your rollout will stick than any feature list.

Then I would make sure the education is not just “here is how the software works,” but “here is how your workflow connects to everyone else’s, and here is what changes for you when it does.”

Because the silo was never really the enemy. It was a symptom. It was people doing something sensible inside a system that was not serving them properly. Fix the system and you remove the excuse. Deal with the behaviour, and the trust underneath it, and you remove the reason. Do both, and the silos do not just move into your new platform. They actually go.