Deck: Before the first steering meeting catches you without an answer, here is the Monday-morning setup that keeps your delivery record current from kickoff through go-live.
What this article solves: A source-linked delivery record connects every configuration decision, requirement, and change request to its origin: the ticket, the call summary, the approved RFC. This guide walks ERP practice leads through the setup steps so the record stays current automatically and any consultant or pod can answer a client question with evidence, not memory.
Who this is for: Practice leads and delivery managers running ERP or CRM implementations who need a traceable, current-state record across multiple pods and client engagements.
The wiki that described last quarter's system
The steering committee meeting was at 9 a.m. on a Tuesday. Forty minutes in, the client's CFO asked why the approval-routing field in the procurement module had been customized rather than left to the standard workflow. The practice lead pulled up the engagement wiki. The last edit timestamp read six weeks prior, which was two change requests ago. The wiki described a configuration that no longer existed.
Nobody in the room had a wrong answer. They had three different answers, each sourced from a different artifact: a Jira ticket, a Confluence page, and a memory of a workshop call. The meeting paused while someone went to find the correct one.
That pause is the cost. Not the confusion itself, but the time spent reconstructing a decision that was made, documented somewhere, and then orphaned from every other source that moved on without it.
Why the delivery record breaks down (and when)
ERP implementations generate decisions constantly. A field gets renamed. A workflow gets split into two. A client approves a deviation from the standard process in a call that produces a Fathom summary but no Jira ticket. By week six, the engagement wiki describes the system as it was configured before the last sprint.
The problem is not that teams stop documenting. It is that documentation and delivery run on separate tracks. The ticket closes. The PR merges. The wiki does not know either happened.
A source-linked delivery record fixes this by treating every artifact as a node: the discovery call, the requirement, the ticket, the configuration decision, the approved change request. Each node points to its source. When the source changes, the record reflects it.
Step-by-step: building the record from day one
Follow this sequence at engagement kickoff. Each step takes under an hour. The compounding value comes from doing them in order.
1. Connect your existing tools before you create anything new.
Start by connecting the tools your team already uses: Jira or Linear for tickets, Confluence or Notion for documents, GitHub for any custom development, Fathom or Google Drive for call recordings and notes. ScopeDocs is the living record agents and humans share before anyone takes action for the client, pulling from those sources rather than asking your team to maintain a parallel system.
2. Create one engagement record per client, not per workstream.
A single engagement record anchors everything: the client name, the ERP product and version, the go-live date, and the pod structure. Resist the instinct to create separate records for finance, procurement, and HR workstreams. Those become siloed. One record with tagged sections keeps the full picture visible to any consultant who joins mid-engagement.
3. Log the first configuration decisions during discovery, not after.
The highest-value decisions happen early: which standard processes the client will follow, which they will deviate from, and why. Capture each deviation as a decision entry with three fields: what was decided, why it was decided, and where the approval lives (the call summary, the signed-off RFC, the ticket number). If the approval lives in a Fathom transcript, link it. If it lives in a Jira comment, link that.
4. Tag every ticket and PR that touches a configuration decision.
Establish a tagging convention in week one. In Jira, a label like config-decision or approved-deviation marks tickets that carry a binding choice. In GitHub, the same convention applies to PRs that implement a customization. These tags become the filter that surfaces the decision trail when a steering committee asks why something was built the way it was.
5. Assign a decision owner for each open item.
Every logged decision needs one name attached to it. Not a team, not a pod. One person who can confirm the decision is still current. This is the lightweight governance step that prevents the wiki-drift problem: when a change request comes in, the decision owner updates the entry and links the new approval artifact.
6. Run a weekly five-minute record review.
At the end of each sprint or week, one team member checks three things: Are there closed tickets that contain a configuration decision not yet logged? Did any approved change requests alter a previously logged decision? Are there open questions in the client Slack channel that have since been answered and should be captured? This review takes less time than the steering meeting pause it prevents.
7. Export the decision trail before go-live readiness review.
Two weeks before go-live, generate a filtered view of every logged configuration decision, its source artifact, and its current status. This becomes the readiness review artifact. If the CFO asks about the approval-routing field, the answer is in the record with a link to the RFC that approved it.
In practice
A mid-size manufacturing client is three months into an ERP rollout. The finance pod and the procurement pod each believe they have the approved configuration for multi-currency handling. The finance pod is working from a Confluence page. The procurement pod is working from a Jira ticket that superseded it after a change request in sprint four.
The delivery manager opens the engagement record, filters on config-decision and multi-currency, and finds two entries. The first is the original decision from discovery. The second is the change request entry from sprint four, linked to ticket ERP-1147 and the Fathom summary of the call where the client approved the revision. The procurement pod is current. The Confluence page is stale. The manager updates the Confluence page to point to the engagement record entry, closes the loop in the #erp-finance-pod Slack channel, and the pods align before the next build session.
No reconstruction. No meeting pause. The answer was already there.
Setup checklist
- Connect Jira (or Linear), Confluence (or Notion), GitHub, and Fathom to the engagement record before sprint one
- Create one engagement record per client with go-live date, ERP product, and pod structure noted
- Log at least three configuration decisions during discovery with source links attached
- Establish a ticket-tagging convention for config decisions and approved deviations
- Assign a named decision owner to every open configuration entry
- Schedule a five-minute weekly record review into the team's sprint cadence
- Generate the decision trail export two weeks before go-live readiness review
Related ScopeDocs resources
- Guide: Source-linked delivery records for ERP and CRM engagements
- ScopeDocs product overview
- How to run a client handoff that doesn't lose the delivery context
- Why ERP configuration decisions need a traceable record
- All posts on requirements traceability
- Integrations: what to connect first
The configuration decision your CFO asks about on Tuesday was made on a Wednesday six weeks ago. It lives in a ticket, a call summary, or an RFC. The only question is whether your delivery record links those artifacts together and keeps them current. That is what a source-linked record does, and it is what ScopeDocs is built to maintain across every engagement your practice runs.