Deck: Two artifacts, two jobs. Getting them mixed up is why steering asks a question your team cannot answer on the spot.
What this article solves
CRM implementation documentation captures every decision, configuration choice, and scope change made during delivery, with links to the tickets and calls that produced them. A client wiki is a reference layer for end users after go-live. Conflating the two leaves your delivery record full of gaps and your client portal full of noise.
Who this is for: TPMs, delivery leads, and implementation consultants who own the record of what was built and why.
On a Tuesday morning, a steering committee asks why the lead-routing logic in Salesforce was changed from round-robin to territory-based assignment. The change shipped three weeks ago. The ticket, CRM-2847, is closed. The Confluence design doc still shows the original round-robin spec. The discovery call notes, captured in Fathom, mention the territory model once, in passing. The consultant who made the call is on a different account now.
The delivery manager opens the client wiki. It explains how reps use territory assignment. It does not say who decided to switch, when, or why.
That is the gap. Not a missing document. A missing record.
Two artifacts, two jobs
CRM implementation documentation is the delivery record. It answers: what was decided, by whom, on what date, and traceable to which source. It lives from discovery through handoff. Its primary reader is the delivery team, the client's project sponsor, and anyone who picks up the engagement later.
A client wiki is the usage reference. It answers: how do I do my job in this system. It lives after go-live. Its primary reader is an end user, a sales rep, a service agent, a new hire on the client side.
Both matter. Neither replaces the other. The failure mode is treating one document as both.
What belongs in implementation documentation
Implementation documentation is a living record of the engagement, not a snapshot taken at close. It should contain:
- Configuration decisions: why territory assignment replaced round-robin, linked to the Fathom call clip or the Jira comment where the client approved the change
- Scope changes: what moved out of scope, what was added, and the steering decision that authorized it
- Integration choices: which objects sync, which do not, and the technical rationale
- Custom work: what was built outside standard configuration, who owns it, and what breaks if it changes
- Open items and blockers: what is still unresolved at any given point in the delivery
The key word is traceable. Every entry should link back to its source: a ticket, a call transcript, a PR, a signed change order. If it cannot be sourced, it is an opinion, not a record.
What belongs in the client wiki
The client wiki is built for someone who was not in the room. It should contain:
- Process guides: how the territory model works day-to-day for a sales rep
- Field definitions: what each custom field means in the client's language, not the platform's
- Role-based how-tos: what a manager sees versus what a rep sees
- FAQs from training: the questions that came up in enablement sessions
- Admin reference: how to add a user, update a territory, reset a queue
This content does not need a decision trail. It needs clarity and maintenance. When the process changes, the wiki page updates. When a field is renamed, the definition updates. It is reference material, not evidence.
Why teams collapse them into one document
The pressure is real. Clients ask for "documentation" and mean the wiki. Delivery teams produce "documentation" and mean the implementation record. Both get dropped into the same Confluence space or Google Drive folder, and within a month neither serves its purpose.
The implementation record goes stale because nobody updates a wiki-style page when a ticket closes. The client wiki becomes cluttered with internal rationale that confuses end users. And when steering asks a question like the one above, the delivery manager is searching across three tools for an answer that should have been one click.
This is where the record-keeping model matters. For forward-deployed and agentic delivery work, ScopeDocs is the living record agents and humans share before anyone takes action for the client: source-linked to the ticket that created the decision, the call that authorized it, and the PR or config change that executed it.
In practice
A mid-size consultancy is three months into a HubSpot CRM implementation for a professional services firm. The client's RevOps lead joins the weekly sync and asks whether the deal stage taxonomy was ever finalized after the February workshop.
The TPM opens the delivery record. There is an entry for deal stage taxonomy, dated February 14th, linked to a Fathom clip at the 22-minute mark of the workshop recording and to Jira ticket CRM-1094, which shows the client's VP of Sales approved a six-stage model in a comment on February 17th. The rationale: the original eight-stage model was too granular for their current pipeline volume, per the VP's note.
The answer takes thirty seconds. The client wiki, separately, has a clean page titled "Deal Stages" that explains each stage to the sales team. It does not reference the February decision. It does not need to.
Two artifacts. Two jobs. Neither one is the other.
Checklist: separating your implementation record from your client wiki
- Every configuration decision in the implementation record links to a source artifact (ticket, call clip, signed doc)
- Scope changes are entered at the time they occur, not reconstructed at close
- The client wiki contains no internal rationale or delivery team notes
- End users can find process guidance without reading through decision logs
- The delivery record is updated when tickets close, not only when a milestone is reached
- Handoff includes both artifacts, clearly labeled by audience and purpose
- New consultants joining mid-engagement can read the implementation record and understand what was decided without asking the team
Related ScopeDocs resources
- Guide: Source-linked delivery documentation for CRM and ERP implementations
- Product overview: how ScopeDocs connects your delivery toolchain
- Blog: How to document configuration decisions during an ERP implementation
- Blog: Client handoff documentation that actually holds up
- Integrations: what to connect first
- Tag: CRM and ERP implementation documentation
The implementation record and the client wiki are not competing documents. They serve different readers at different moments in the engagement. Capture the delivery record once, link it to its source, and keep it current through close. That is what ScopeDocs is built to hold.