99% adoption. 150+ employees.
14 months. $0 budget.
I built the knowledge system for Mural Consulting, a 150-person certified Microsoft partner, & 99 out of 100 people were still using it every week two years after launch.
The $0 is literal: one paid Notion account, free guest access for everyone else. The method carried the result. The spending was a single seat.
The situation
Mural Consulting had hundreds of SharePoint folders holding documentation nobody trusted. Duplicate SOPs & HR policies that said different things depending on which folder you opened. Eight teams, each with its own version of the truth.
Onboarding was sink-or-swim. New hires learned the job by finding out who knew the answer.
Why this usually fails
Rollouts like this fail at adoption, & they fail quietly. The platform works fine. The launch email goes out. Six weeks later everyone is back in their old folders & you own a graveyard with a search bar.
The old change-management rule of thumb gives about 70% of the work to people & process, & the rest to the tool. That is roughly what this cost me. Choosing Notion took an afternoon. The other 14 months went to humans.
What I actually did
Started with 15 people before asking for 150
The first build was for my own technical support team, April to May 2021. Fifteen people is small enough to rebuild the information architecture when it turns out wrong & big enough that the result means something. I wasn't asking executives to fund a theory. I walked in with a working system & a team that already used it, which is what got the company-wide deployment approved.
Interviewed all 8 team leads one at a time, plus the department heads
One-on-one, before designing anything. Half of this was requirements gathering. The other half was that people defend a system they helped shape & abandon one that arrives finished. Every team got a homepage template their lead could edit themselves, which came directly out of those conversations.
Built the 90-day onboarding curriculum first
Day-by-day for weeks one & two, weekly through day 61, monthly after that. New hires are the users with the sharpest need & the least political baggage, so the onboarding path is where a knowledge system proves itself fastest. It drew the most positive feedback of anything I shipped. The line I heard back most often was that the 90-day resource was invaluable.
Got the CEO to move official announcements onto the platform
This one move did more for adoption than everything else I built. Once company announcements lived there, the platform was required tech stack rather than a recommendation. You cannot mandate your way to 99% on your own authority as an ops manager. You can make the mandate worth having by getting the announcements to move.
Ran training every week for two years
Not a launch week plus a job aid. Weekly sessions I delivered personally, plus optional office hours for anyone who wanted help without an audience. One-time training only reaches the people in the room that day, & a 150-person company hires. Two years of weekly sessions is why adoption held instead of sliding once the launch push ended.
Demoed it with a Stardew Valley page
The culture was gaming-heavy, so my demo was a personal page about a farming game rather than an SOP library. People stopped evaluating a documentation tool & started picturing what they'd build. Small thing. It moved more people than the business case did.
What didn't work
I did not plan for resistance & it cost me
This is the part I got most wrong. I assumed a better system would sell itself to people drowning in bad folders. It did not. Users had SharePoint structures they had built & defended for years, & a new platform read as more work rather than less. I had to go teach myself change-management practice in the middle of my own rollout, rebuild the approach around real feedback loops & an adjusted training plan, then go get the executive mandate. It worked, & it should have been in the project plan on day one instead of improvised under pressure.
I was the entire maintenance team
Solo administration of an enterprise knowledge base for 150+ people is a single point of failure with a name & a calendar. I documented maintenance procedures, trained department content owners, & set escalation paths, & it held for two years. It was sustainable & fragile at the same time. The content-owner network was the right answer & I built it late.
I never measured the before
No baseline on time spent searching, no baseline on onboarding duration. I went straight to building because the problem was obvious. That means the time-savings numbers below are the softest claims on this page, & the weakness is mine. If you cannot state the before, your ROI case is a story with numbers in it.
The handoff never happened
The company closed due to external market factors, which ended the planned knowledge transfer. Better contingency documentation earlier would have left something behind. That one is worth carrying into every project you expect to outlive you.
How it was measured
The 99% is weekly active users. Not seats provisioned, not a launch-week spike. The target written into the charter was 90% within six months of company-wide launch.
It held for two years. Adoption was tracked from the May 2022 company-wide launch until the company closed, & it never fell off after the novelty period. Sustained usage is the only adoption number worth quoting.
Time savings came to 3–4 hours a week for team leads & 1–2 hours a week for agents, from the benefit-realization reporting I ran through the sustainment phase. Read those as reported figures, for the reason in the section above.
The two I stand behind without any qualification are counts rather than estimates: 100% new-hire onboarding completion, maintained for two years, & zero critical documentation gaps identified in the first 90 days after launch.
What I'd do differently now
Change management goes in as a core workstream at initiation, with its own plan & its own hours, rather than as the thing I scrambled to learn once the rollout was already live. Distributed content ownership gets designed during the design phase, so the owner network exists before the load arrives. Baseline metrics get captured before anything deploys, so the ROI case is arithmetic instead of narrative. Succession planning starts at kickoff rather than at closeout, because the project that outlives you is the one you didn't plan to hand off.
The bigger change is what the tooling can carry now. The work that made solo maintenance fragile in 2021 was mechanical: reading the whole repository, finding the page that had drifted, working out what the team was actually doing instead, & chasing the one person who knew. That is agent work now. An agent can read every page on a weekly cycle, compare documented process against current practice, & hand a human owner a short list to approve or fix. Content maintenance stops being one person's evenings & becomes a queue with a review step.
It also gave me the lens I audit with. Documented process & real practice separate at a measurable rate after any tool change, & the gap compounds quietly until someone follows the SOP & gets the wrong answer. I call it compliance decay. In 2021 I had no name for it. I was watching it happen in a SharePoint folder & rebuilding the whole thing by hand.
If you've bought the AI tools & the work hasn't changed, that's what the audit is for.
See what it covers →