Jump to section
Every firm has a wiki. Most of them are in people's heads. Someone knows the password for the court filing portal. Someone knows why the client in File 47 gets called by their middle name. Someone knows the twelve steps for a particular type of real estate closing, and that person is currently on leave. The difference between a firm that functions well when people are away and one that quietly seizes up is whether that knowledge has been written down somewhere findable.
This is a guide to building a firm wiki that people will actually open, which is a harder problem than it sounds.
Why most firm wikis die
The typical firm wiki fails for one of three reasons. It was built once and never updated, so it became wrong faster than people stopped trusting it. It was built by one person and reflected that person's mental model of the firm, which made it useful for that person and confusing for everyone else. Or it was too ambitious: a thousand-page knowledge base nobody maintains because maintaining it feels like a second job.
The version that survives is smaller, more opinionated, and owned by specific people who update it as part of their regular work, not as an extra task. Start with ten pages, not a hundred. The goal for the first version is usefulness, not completeness.
Tip. The best time to write a wiki page is immediately after you do a task for the first time. The steps are fresh, the exceptions are visible, and the person who will benefit most from the page is the version of you that existed thirty minutes ago.
What a small firm wiki actually needs
Not everything belongs in a wiki. A wiki is the right place for information that is stable for at least a few months, that is referenced more than once, and that more than one person needs. Daily task assignments, client-specific updates, and the contents of individual files belong in your practice management system, not your wiki. If you are building on top of A1 CMS, matter notes and client records live there; the wiki covers the firm-level knowledge that sits above any individual file.
Here is what most small firms find useful to have in one place:
Pages worth building first in a firm wiki
Choose a format people will actually use
A shared folder of Word documents is not a wiki. It is a folder. The difference is search, linking, and the ease of updating. A good wiki lets you search across everything, link from one page to another, and edit a page without downloading, changing, and reuploading a file.
For most small firms, the simplest option is a shared Notion workspace, a Confluence space, or even a well-organized Google Sites instance. The specific tool matters less than two things: it must be searchable, and it must be the same tool everyone already uses for everything else. A wiki that requires a separate login that half the team rarely touches is not a wiki anyone will consult in a pinch.
Whatever tool you choose, write the first ten pages before you announce it. A wiki with ten useful pages already in it gets adopted. An empty wiki with a plan to fill it in later does not.
Note. The best firm wikis are opinionated. They say "this is how we do it here," not "here are some options." A page that describes three possible ways to handle a trust transfer is less useful than one that says "we handle trust transfers this way, in this order, using this form." Save the options for the conversation; put the decision in the wiki.
Building a maintenance habit
A wiki without a maintenance habit becomes wrong. Not all at once, but one outdated page at a time, until people learn not to trust it and stop checking. The solution is to make updates a natural part of existing workflows rather than a separate task.
Two practices that work: first, when someone does a task and finds the wiki page is wrong or missing, they update it before they close the task. Not later. Now. Second, at each weekly review, one person scans the pages that were most recently referenced and confirms they are still accurate. The scan takes ten minutes. The trust it builds is worth more than that.
The SOPs people actually use piece covers a related habit: keeping your standard operating procedures short enough that someone will actually consult them rather than doing it from memory. The two work together well. SOPs cover the steps; the wiki covers the context around the steps.
Start with what gets asked most often
If you are not sure where to start, spend one week noting every question a colleague or new staff member asks that could have been answered by a written page. By the end of the week, you will have a list of your first five pages. Write those. Then note the next five most-asked questions. Write those.
A wiki built from real questions is a wiki people will consult, because they know from experience that the answer is in there. That is the whole trick: build from demand, not from a top-down plan of what you think should be documented.
For the broader context of building a firm that runs well on written processes, the standard operating procedures guide and the delegation log approach are both worth reading alongside this one. The full Firm Operations section covers the organizational habits that make all of this sustainable.
