The senior office coordinator gives two weeks' notice on a Tuesday. By Friday afternoon you've realized she's the only person who knows why the property manager calls back faster on Thursdays, which vendor invoice goes to which approval chain, and what the unwritten escalation order is when the front-door access system fails. Almost none of that is written down. It lives in her head and in a few sticky notes on her monitor.
Every operations team has this shape sitting somewhere. The bookkeeper who knows which line item the executive director quietly redefined four years ago. The senior tech who remembers that the rooftop unit's serial-number plate is wrong because the manufacturer swapped the parts during a recall. The receptionist who has memorized which insurance carriers always need a second fax.
This post is about turning that working memory into something a workspace can hold — before the person leaves, not after.
What "institutional knowledge" actually is
When operators say institutional knowledge, they usually mean four overlapping things:
- Process detail nobody documented because it felt obvious to whoever did it — the actual order of the close-of-month checklist, which reports get pulled before which review meeting, why the Tuesday backup is named differently
- Decision history — why we stopped using the lower-cost vendor, why the board approved the policy with one specific carve-out, what the alternative was and why it lost
- People context — which client always wants the call before the email, which inspector tends to flag the same three things on every visit, which colleague at the partner agency you actually escalate to instead of the org-chart contact
- Quirks and workarounds — the printer that needs the toner cartridge installed twice before it registers, the report that crashes if you don't filter the date column first, the signature page on the lease that has to be initialed in blue ink
None of this is hidden on purpose. It's just never been written down because the person who knows it doesn't think of it as knowledge — it's just what they do. Adjacent shapes are covered in Build a Company Wiki from Casual Notes and Standard Operating Procedures, Without the Wiki Maintenance Tax.
Start with the page-per-topic shape
In Docapybara, every workflow, vendor, system, and recurring process gets its own markdown page. Page nesting goes as deep as the org actually thinks. A small operations team might end up with:
Operations → Vendors → one page per vendor (account number, primary contact, escalation contact, return policy, recent issues)Operations → Recurring Processes → Close of Month, Quarterly Board Packet, Annual Audit PrepOperations → Systems → Property Access Control, Phones, Printer/CopierOperations → People → Outside Counsel, Auditors, Insurance BrokerDecisions → one page per material decision the org has made
Plain markdown means the pages stay searchable, exportable, and copyable years later. If someone joins the team in 2028, they can read the same pages without needing the original author to interpret a proprietary format.
A working interview, captured as audio
The most efficient capture method for the kind of knowledge that lives in someone's head: sit with them for forty-five minutes, walk through the topics they own, and record the conversation. Audio with speaker labels keeps the back-and-forth attributable — when the senior coordinator answers a question, the answer is tied to her voice, not buried in your handwriting.
Drop the recording on the page. The transcript drops in alongside, with each speaker labeled. Now you have two things: the source-of-truth conversation and a readable text version you can pull excerpts from.
The next move is to ask Capy, the assistant inside the workspace, to do the work of converting an interview into a structured page. "Read this transcript. For each vendor she mentioned, create a sub-page with the contact info, the escalation pattern, and any past issues she described." The agent reads the transcript, drafts the pages, and you review. Forty-five minutes of conversation becomes a folder of structured pages in the time it takes to grab coffee.
A live database for the things that change
For the parts of institutional knowledge that change frequently — open vendor issues, renewal dates, certifications, recurring deadlines — embed a :::database::: directive directly inside the relevant page. The database lives next to the prose context. Sort by renewal date, you see what's coming up. Filter by status, you see what's open.
Six column types cover most of what an operations team tracks: text, number, date, select, checkbox, link. A vendor-renewals database might have Vendor, Contract End, Notice Required, Owner, Status, Last Reviewed. A certifications database might have Person, Cert Name, Issuer, Expires, Renewal Started.
When the senior coordinator is walking you through which contracts auto-renew on which dates, you're building the database in real time on the same page she's narrating. By the end of the conversation, the database exists and the surrounding prose explains why each row matters.
Decisions deserve their own pages
A decision page is short — the question that was asked, the alternatives considered, the call that was made, who made it, when, and what the trigger was. Maybe a paragraph each. The discipline of writing one is what protects the org from re-litigating the same question every two years when memory has faded and the original participants have moved on.
A useful prompt: at the end of any month where a real decision was made — vendor change, policy update, scope expansion, tool migration — ask Capy to draft the decision page from your meeting notes. "Read the leadership notes from this month. Pull anything that looks like a material decision and draft a one-page record for each: question, alternatives, decision, owner, date."
You review and adjust. The drafts are usually 80% there because the agent is reading what was actually said in the room, not inventing structure. The agent-acts-on-docs differentiator behind this is laid out in Claude Code for Documents.
The departure interview that produces actual artifacts
When the person giving notice has two weeks left, the standard departure-interview format produces a tidy HR document and zero operational handoff. A working alternative:
- Day 1 of notice — sit with them, audio-record a walk through their actual workflow week. Don't aim for completeness. Aim for what does a normal Wednesday look like end to end.
- Same day — drop the transcript on a
Departure Handoff: <Name> page. Ask the agent to extract every workflow they mentioned, every vendor they touched, every tool they opened, and every person they coordinated with.
- Days 2–4 — review the agent's extraction. For every workflow, ask the agent to draft a written SOP from what was said in the interview. The departing person reviews the drafts, corrects misunderstandings, fills gaps.
- Days 5–10 — for the items that are too complex for prose alone (the close-of-month checklist, the quarterly board prep), do a working session where they actually run the process and you record over their shoulder. The recording becomes the canonical version.
- Last week — the departing person does a final pass on their pages and signs off that the captured version matches reality.
The output is a folder of pages, sub-pages, and inline databases that survives the departure. It's not perfect. It's vastly better than the standard alternative, which is they leave and we figure it out.
Old PDFs and binders count as institutional knowledge too
Most established orgs have years of accumulated paper — vendor contracts, policy binders, training manuals, the dusty operations runbook from 2019 nobody updated. They count as institutional knowledge if anyone still relies on them. They count as a problem if nobody can find anything in them.
Drop the PDFs into the workspace. Each one is converted to markdown, which means the agent can read across all of them. Now when you ask "what does our master service agreement with the cleaning vendor say about the response time for water damage?", the agent pulls the relevant clause as text. The original PDF is one click away if you need to see the signed version.
For a small operations team this is often the single highest-leverage hour of work. The institutional memory that was locked in PDFs nobody opened becomes searchable in an afternoon. The HR-side analogue of this — the employee handbook stitched together from the notes you already have — is covered in Building an Employee Handbook From the Notes You Already Have.
The handoff page that lives forever
For each major area of the operation, end the documentation push with a single high-level handoff page. The shape is short:
- One paragraph: what this area is and why it exists
- A list of links to the sub-pages and databases that hold the detail
- A list of the three to five people inside and outside the org who matter for this area
- A list of the three to five questions a new owner of this area is most likely to need answered first
- The current owner's name and the date the page was last reviewed
This is the page someone reads on day one when they inherit the area. It points at everything else. It tells them what they're looking at. It gives them a finite set of places to start.
When the person who wrote it leaves, the page stays. When the next person inherits it, they update the owner and the date. Two years later someone else inherits it and updates again. The institutional knowledge has a place to live that isn't a single human's memory.
Try Docapybara free
Pick the one role on your team where the most context is at risk — the senior coordinator, the bookkeeper, the long-tenured tech, the founder who still does sales. Sit with them for forty-five minutes, record the conversation, and let the workspace do the structural work of turning what they said into pages, sub-pages, and databases. Try Docapybara free, bring one departure-risk role and a stack of the binders nobody opens, and see what gets captured before the next handoff.