Client account reassignment commitment register template

A client account reassignment commitment register gives the successor one controlled list of promises made by the consulting firm and the client. It prevents a transition from reducing a precise commitment to “someone said this was handled.” Each entry preserves the exact wording, evidence, ownership, due date, dependencies, disclosure limits, and the successor’s acceptance decision.

The register supports continuity; it does not replace the contract. The signed contract, statement of work (SOW), and approved change controls remain authoritative for scope, fees, deliverables, and commercial obligations. When the register conflicts with an authoritative document, flag the conflict and follow the firm’s contract process rather than silently “correcting” the source.

What the register must capture

Track promises from both sides. Firm commitments may include sending a workshop plan, revising a deliverable, or arranging a specialist review. Client commitments may include providing data, confirming attendees, reviewing an output, or making a decision. One-sided tracking hides dependencies and makes delays look like ownership failures.

Every row needs these fields:

• Stable ID: an identifier that stays with the same promise through owner or successor reassignment; a changed promise gets a new ID linked by supersession.
• Exact commitment: the promise in specific, testable language without adding an interpretation.
• Source/evidence: the contract clause, SOW section, approved change, meeting recap, decision log, or email that supports the entry.
• Owner: the person responsible for completing or coordinating the commitment.
• Counterparty: the person or group expecting the commitment or providing the dependent input.
• Due date: the agreed date, or “unconfirmed” until the parties agree one.
• Status: proposed, confirmed, in progress, blocked, fulfilled, disputed, or superseded.
• Dependency: the input, decision, or prior action required before completion.
• Next review: the date or meeting when the entry will be checked again.
• Disclosure classification: client-shareable, internal, or restricted, based on the firm’s information-handling rules.
• Successor acceptance: accepted, accepted with condition, not accepted, or pending review, plus date and rationale.

Keep “owner” and “counterparty” distinct. If your firm promised a recommendation after the client provides source data, the consultant owns the recommendation and the client data owner is the counterparty. The missing data is a dependency; it does not erase the firm’s commitment.

Copyable client account reassignment commitment register

Copy this template into the controlled workspace used for the account. Add links rather than pasting sensitive source material into the register.

CLIENT ACCOUNT REASSIGNMENT COMMITMENT REGISTER

Account:
Outgoing lead:
Successor:
Register owner:
Reassignment date:
Authoritative contract/SOW links:
Ownership and acceptance event history:

| Stable ID | Exact commitment | Source/evidence | Owner | Counterparty | Due date | Status | Dependency | Next review | Disclosure classification | Successor acceptance |
|-----------|------------------|-----------------|-------|--------------|----------|--------|------------|-------------|---------------------------|----------------------|
| FIRM-001  |                  |                 |       |              |          |        |            |             |                           |                      |
| CLIENT-001|                  |                 |       |              |          |        |            |             |                           |                      |

REGISTER REVIEW
- Contract/SOW conflict found? Yes/No — owner and action:
- Disputed entries — IDs and review route:
- Superseded entries — old ID → new ID:
- Restricted entries reviewed by:
- Successor acceptance completed on:
- Client-shareable extract reviewed on:

Use a stable prefix that shows which party made the promise, such as FIRM- and CLIENT-. Do not recycle identifiers. A durable trail lets a later reviewer understand what changed without comparing overwritten spreadsheets.

For the wider transition context around stakeholders, preferences, and account history, use the client knowledge transfer guide alongside this register. The register is deliberately narrower: it answers who promised what, based on which evidence, and what happens next.

Apply four rules when the account changes hands

Carry commitments forward without rewriting them

An open commitment keeps its stable ID, exact wording, evidence, and history when its owner or successor changes. Add the reassignment and successor acceptance as a dated event, including the previous owner, new owner, acceptance result, rationale, and effective date. Do not create a new promise merely because responsibility moved to another consultant within the same obligated party.

Carry-forward also applies to client promises. If the client still owes an input, keep that item open and confirm the appropriate counterparty. The successor should not assume that silence means the client promise expired.

Record disputes instead of choosing a convenient version

Set the status to disputed when the parties disagree about the wording, completion, due date, or authority for a commitment. Preserve both positions, link their evidence, name the person responsible for resolution, and set the next review.

Do not ask the successor to accept a disputed item as settled. They may accept responsibility for resolving it. A dispute about scope or contractual obligation belongs in the applicable contract or change-control process.

Supersede; never overwrite

When a later agreement changes the promise’s substance, obligated party, output, acceptance condition, or scope, create a new stable ID. Mark the old item superseded, link both records, and cite the evidence for the replacement. Keep the original readable so nobody mistakes an old recap for the current agreement.

If only the due date or operational owner changes, retain the stable ID and add the approved change as a dated event. A move between individual owners does not change which party made the promise; a change in the obligated party does.

Minimize and classify private information

Record only what is necessary to manage the commitment. Link to controlled evidence instead of copying personal, confidential, or commercially sensitive details into a broadly shared table. Follow the firm’s retention, access, and privacy rules for the underlying sources.

The disclosure classification controls what appears in a client-shareable extract. Client-shareable entries can be reviewed with the client. Internal entries stay within the account team. Restricted entries require the designated reviewer before access or disclosure. Classification is not a substitute for authorization; it is a prompt to apply the right review.

Review successor acceptance deliberately

Successor acceptance is not a ceremonial checkbox. For each open firm commitment, the successor should confirm that they understand the exact promise, can access the evidence, have authority to act, and can meet the date given known dependencies.

Use accepted with condition when a specific condition must be resolved, such as access to a working file or confirmation of a client due date. Use not accepted when the successor lacks authority, capacity, or sufficient evidence. Escalate that entry before presenting the reassignment as complete.

For a partner-level transition, pair this review with the governance steps in partner transition and succession planning. For a broader record that survives personnel changes, see how firms can build institutional memory from durable conversation history.

Work through a reassignment example

Suppose Alder Consulting reassigns the Meridian Foods account from Priya to Sam. The SOW covers a procurement diagnostic and an executive workshop. The outgoing lead identifies these entries:

Sam accepts FIRM-014 with a visible condition rather than pretending the attendee dependency is resolved. CLIENT-009 remains a client promise, with Sam responsible for monitoring it. FIRM-011 does not appear in the SOW, so the team records the dispute and routes it to the partner who owns scope decisions. If the parties approve a change, they will create a new entry supported by that document and mark FIRM-011 superseded.

Before the client transition call, the team produces a client-shareable extract containing the first two rows. The internal scope dispute stays out of that extract until the designated owner decides how it should be discussed. Nothing in the register changes what the SOW authorizes.

Close with a controlled review

At reassignment, review all open and recently fulfilled entries with the outgoing lead, successor, and register owner. Ask the successor to read back the highest-risk firm promise, the most important client dependency, and every item they did not accept. Record corrections against the evidence.

After reassignment, review open items on their existing cadence. The register is useful only while its dates, evidence links, status, and acceptance decisions remain current. Preserve fulfilled and superseded rows as history instead of deleting them.