A professional-services firm was losing a piece of how it actually operated every time someone resigned. The fix was not better notes. It was a system that holds the knowledge so it stops depending on who happens to still be employed.
The problem
The firm ran on tribal knowledge. The real procedures, the ones that governed how work actually got delivered, lived in the heads of a handful of long-tenured people. There were documents in theory, but the operative version of any given process was whatever the person who owned it remembered to do. When that person was out, work either stalled or got done a slightly different way each time.
Every resignation was a continuity event. A departure did not just remove a pair of hands, it removed a body of undocumented judgment: the edge cases, the workarounds, the reason a step exists in the order it does. The firm would spend the notice period trying to extract what it could, usually under time pressure, usually incompletely. Whatever did not make it into someone's inbox or a stale shared drive was simply gone.
Onboarding carried the same tax in reverse. New hires learned by sitting next to whoever was free, which meant ramp time was slow and the version of a process a new person learned depended entirely on who trained them. Two people hired into the same role could end up running the same task two different ways, neither of them obviously wrong, both of them undocumented. This is the classic pattern we describe in our writing on custom automation systems for small companies: the bottleneck is not effort, it is that critical operating knowledge is locked inside individuals instead of inside the system.
The approach
We started by treating institutional knowledge as an asset the firm owned, not a favor individual employees did when they had time. The deliverable was a searchable internal documentation and SOP platform: a single place where every procedure lives, is findable, and stays current, rather than a folder of orphaned files nobody trusts.
Capture was deliberately video-first. Asking busy senior people to write polished procedure documents is how knowledge-capture projects die. Instead, the people who actually do the work record themselves doing it and narrate the why as they go. Those recordings become the source of truth, with structured written SOPs derived from them, so the firm captures not just the steps but the judgment behind the steps. The friction of contributing dropped, which is the only way capture survives past the first month.
On top of the library we built structured onboarding flows: role-based paths that walk a new hire through the exact procedures their job requires, in order, drawing from the same single source the rest of the firm uses. A new person no longer depends on catching a free colleague. They follow a defined path, and the path stays identical regardless of who is or is not in the building. This is the build-versus-buy call we lay out in internal tools versus SaaS: build or buy, and it is representative of the broader custom business software work we do for operationally complex firms.
The outcome
The operational pattern this produces is continuity decoupled from individuals. When someone resigns, the procedures they ran do not leave with them, because the firm already holds the recordings and SOPs that define those procedures. A departure becomes a staffing question instead of a continuity crisis. New hires ramp faster against a defined path rather than against whoever is free to train them, and they learn one consistent version of each process instead of a personal variant. Institutional memory now survives turnover by design, which is the entire point of the build.
We do not publish invented savings figures for anonymized work, and we will not here. What the methodology applied in a build like this reliably produces is structural: less dependence on any single person, a shorter and more consistent new-hire ramp, and a body of operating knowledge that outlives the people who created it. If your firm feels this same exposure, it is worth reading our take on building automation systems around real operational gaps, browsing our other selected work, or starting from the Warren & Sabb homepage to see how we approach it.