BBned was a Dutch broadband infrastructure provider, part of the Telecom Italia group. The provisioning process — the sequence of steps that turned a customer order into a working connection — was genuinely complex. It spanned multiple departments, integrated with Telecom Italia systems internationally, and required precise coordination to execute correctly.
The organisation also had high staff turnover. People left, and when they left, they took the knowledge of how things actually worked with them. What remained was incomplete documentation, tribal knowledge concentrated in a few long-tenured individuals, and a constant onboarding overhead as new staff pieced together understanding from scratch. I was brought in to fix that.
The Problem
Knowledge problems in complex operations have a particular character. The knowledge that matters most is procedural and contextual — not just what the steps are, but why they're done that way, what breaks when you skip them, how to handle the edge cases that aren't in any manual. That kind of knowledge is hard to extract from people who hold it and hard to make useful for people who need it.
There was also a motivation problem. The people with the deepest knowledge were the busiest. Contributing to documentation felt like extra work with no immediate return. A system that no one maintains is worse than no system at all — it becomes a source of incorrect guidance. Any solution had to address not just the content problem but the contribution problem.
Designing the Knowledge Base
The first step was to design the domain structure — how knowledge would be organised, what categories made sense, and how a new employee would navigate to what they needed. I mapped the provisioning process end to end across all four departments, identified the knowledge domains that corresponded to each stage, and designed the wiki hierarchy to match how work actually flowed.
The structure mattered as much as the content. A wiki that's hard to navigate doesn't get used. The domain design had to reflect the mental models of the people doing the work, not an abstract taxonomy. I worked through this with the teams directly — the people who'd be using it had to recognise their own work in the structure.
I also designed templates. For each domain type — process steps, system integrations, incident procedures, escalation paths — there was a standard format. Templates reduced the friction of contributing and produced consistent, comparable entries that were easier to trust.
Getting Buy-In
The employees were sceptical. They'd seen tool rollouts before. New systems introduced with fanfare, mandated from above, and then left to decay. The default assumption was that this would be the same.
I didn't counter that scepticism with a mandate. I countered it with a pilot. I worked with a small group who were willing to try — people who felt the knowledge problem most acutely in their daily work. We documented their domain together. I did a lot of the initial writing, working from conversations and observations rather than asking them to do it themselves.
The pilot produced something visible: a genuinely useful set of pages that new colleagues could immediately use. That was the proof of concept. Other departments asked to be included. By the time we formally launched across all four departments, the sceptics had mostly been converted by colleagues they trusted rather than management they didn't.
The design approval step was also important. Before anything was published, the relevant team reviewed and signed off on the content. This gave people ownership of what was written about their work. It also caught errors early. And it meant that when the knowledge base was live, the people whose work it documented had already endorsed it.
Full Adoption
Adoption in a knowledge management context means one thing: people use it when they need to know something, and they update it when they learn something. Both halves are required. A read-only archive that no one updates becomes outdated quickly. A system where people contribute but no one reads is just writing into the void.
We achieved both by making the knowledge base part of the daily workflow. The onboarding process for new staff explicitly routed through it. When a process changed, the relevant pages were updated as part of the change. When incidents occurred, the resolution and the learnings went in. The wiki stopped being a separate tool and became part of how the work was done.
The international dimension added a layer of complexity. BBned's systems connected to Telecom Italia infrastructure, and incidents involving those connections required procedures that crossed organisational and national boundaries. I worked with stakeholders at Telecom Italia to document those procedures — what to do, who to contact, what the escalation paths were. That documentation lived in the same knowledge base and followed the same structure. It became one of the most consistently used sections.
If your organisation is losing knowledge every time someone leaves, and previous documentation efforts haven't stuck, let's talk.