Most consultants approach the knowledge base backwards. They look at Notion, Intercom or Help Scout and try to adapt a product-support tool to client work.
The mismatch is structural. Help documentation answers "how does this feature work" for thousands of users who share one product. A consulting client has the opposite problem: one engagement, a handful of people, and questions that are entirely specific to them. Your client does not need to learn your product. They need to find what was decided in week three.
Help-desk platforms are built on assumptions that do not survive contact with consulting work.
They assume one audience. A help center is public or it is for all customers. Consulting documentation must be scoped per engagement — client A should never see client B's strategy memo, and permission systems built for a shared product treat that as an edge case.
They assume stable content. Help docs are written once and revised occasionally. Engagement documentation changes weekly and its value is largely in the sequence of changes — what the recommendation was in March versus what it is now.
They assume the reader is self-serving. Help centers exist so the user does not contact you. Consulting documentation exists so the conversation you are already having is better informed. Optimizing for deflection is optimizing for the wrong outcome.
They assume search is the entry point. Clients do not search your documentation. They open it when you point at it, or when they are looking for one specific thing they half-remember.
What clients actually look for
Across engagements, client questions cluster into four categories — and only one of them resembles a help article.
| What they want |
How often |
Where it usually lives |
| "What was decided about X?" |
Most common |
Buried in a call or email |
| "Where is the latest version?" |
Common |
Three places, two stale |
| "What do you need from me?" |
Common |
Your head |
| "How does this process work?" |
Least common |
A document nobody opened |
Generic tools are built almost entirely for the bottom row. The top three are what clients ask, and they are questions about this engagement, not about a process.
The structure that works
Organize by engagement, then by decision — not by topic.
1. A current-state summary at the top. One screen: what phase the engagement is in, what shipped, what is in flight, what is blocked and on whom. If a client has to scroll to learn where things stand, the page has failed.
2. A decision log, newest first. Each entry: the date, the decision, who made it, and what it changed. This single artifact prevents more disputes than any contract clause, because "we agreed in March" becomes checkable rather than arguable.
3. Deliverables with version history visible. Not a folder. A list where the current version is unambiguous and the prior ones are still reachable.
4. Open items, with owners and dates. Split explicitly between what you owe them and what they owe you. The second half is where engagements slip, and a shared list converts chasing from nagging into reference.
5. Process documentation — last. How you run discovery, what a phase gate means, how change orders work. Genuinely useful, rarely urgent. Putting it first is the most common structural mistake.
What this is worth
A practice running five engagements typically fields three to five "where is / what was" questions per client per month. Each costs about 8 minutes once you include finding the answer and writing the reply — call it 20 questions and 2.7 hours a month.
At $150 an hour that is roughly $400 a month, or $4,800 a year, spent reconstructing information you already produced. The documentation does not eliminate those questions, but it moves most of them from "ask the consultant" to "open the link."
The larger effect is harder to price. Clients who can see status do not generate the "just checking in" email, and a meaningful share of client anxiety is simply not knowing where things stand.
Where to keep it
The practical constraint is that documentation nobody can find is documentation nobody reads.
If your clients already log into a portal for deliverables, invoices and messages, the engagement record belongs behind that same login. A separate Notion link is one more URL they have to keep track of, and the thing you are trying to fix is exactly that proliferation.
If you do not run a portal and are not ready to, a per-client Notion page beats nothing by a wide margin. Structure matters more than platform — the ordering above works in any tool. What does not work is a shared wiki organized by topic, because topics are not how clients hold an engagement in their heads.
The one thing to avoid: do not let the documentation become a second system you update separately. If keeping it current is a discrete chore, it will be current for about six weeks. It has to be a byproduct of doing the work, or it decays.
ConsultBase gives every engagement its own client-facing record — status, decisions, deliverables and open items — behind the same login clients already use. Start your free trial to stop answering the same four questions.