Use a CRM Client Decision Log to Keep Delivery Moving

A useful CRM decision log records the question, the authorized decision-maker, the available evidence, and the work that depends on the answer. It also distinguishes an approved decision from a temporary assumption. Without that distinction, a consultant can build the correct configuration for a policy the client never accepted.

Keep the log small enough to review during an ordinary delivery call. Put consequential choices in it: record ownership, required fields, matching rules, stage definitions, exception handling, and release conditions. Leave routine task progress in the delivery board. The log should explain why the work has its current shape and what can safely happen next.

Write a question someone can actually decide

“Confirm routing” is too broad. A better question is: “When an existing account submits a new enquiry, should the current account owner retain it, or should the regional queue assign it again?” The second version identifies a collision between two rules and makes the consequence visible.

State the current behavior, the disputed case, and the intended business outcome. Attach a synthetic example or a link to approved evidence. Avoid putting client record exports into a shared decision table merely to make the question look complete.

Separate factual uncertainty from policy uncertainty. If nobody knows whether the configured connector preserves an owner field, assign a bounded technical check. If the behavior is known but sales leaders disagree about account ownership, the next action is a client decision. A longer technical investigation will not settle that disagreement.

Use a record with enough context to survive the meeting

The following template works in a spreadsheet, document, or client-approved project tool. Use a stable identifier so requirements, tests, and meeting notes can refer to the same decision.

Field	What to record
Decision ID and question	A stable reference and one specific choice
Context and evidence	Current rule, disputed case, evidence links, and unknowns
Options	Viable choices with consequences and constraints
Recommendation	The consultant's reasoning, clearly labeled as a recommendation
Decision owner	One person with authority for this business rule
Needed before	The dependent task or release gate and its relevant deadline
Status	Proposed, awaiting evidence, awaiting approval, approved, or superseded
Outcome and approval evidence	Exact accepted rule, approver, and approval reference
Dependencies and follow-up	Affected specifications, tests, documentation, and actions
Review condition	What new evidence or process change would reopen the question

Use separate fields for the person preparing the recommendation and the person approving it. Attendance at a workshop is not enough to establish authority. If the decision crosses finance and sales policy, ask the client to name the accountable approver and required consultees before treating the answer as final.

Show real alternatives and their consequences

For the fictional routing question, the delivery team might present three options. Retain the existing account owner; reroute all new enquiries by region; or retain the owner unless an approved exception applies. The third choice needs a precise exception definition, such as an inactive owner or an explicitly transferred account.

Explain each option in terms of implementation and operations. Retaining owners requires dependable account matching and a route for unavailable owners. Regional reassignment needs a client policy for existing relationships. Conditional retention adds cases that must be tested and maintained. None of these is automatically the right commercial policy.

Do not invent effort estimates to make a preferred option win. State which parts have been examined and which depend on access or representative data. If an option requires a platform capability that has not been checked, identify that dependency and the small verification step needed before commitment.

Make the dependency more useful than an arbitrary due date

A decision becomes actionable when the client understands the work it holds up. “Answer by Thursday” supplies less context than “Routing acceptance tests cannot be finalized until account-owner precedence is approved.” Add the latest useful decision point in the actual plan, together with what changes if that point is missed.

Continue independent work where it is safe. The team may be able to prepare synthetic test accounts or document current routing without choosing the new rule. Keep that work bounded. Do not build all alternatives in anticipation of approval unless the client has explicitly scoped that exploration.

For a blocked item, record what can proceed, what must wait, and who will escalate. A blocked decision should not quietly become an implementer's default. Use the dependency-map method when a single answer affects several deliverables or reviewers.

Put an expiry on temporary assumptions

Sometimes discovery must continue before the client can decide. Record a provisional assumption with the permitted use and the point where it expires. For example: “Use existing-owner precedence in the sample-data demonstration only. Production routing remains blocked pending sales operations approval.”

This wording makes the demonstration useful without turning it into an accepted production policy. Link the assumption to the demo, field map, and draft tests that rely on it. When the answer arrives, revisit those artifacts instead of only changing the status cell.

Do not interpret silence as approval. If the approver is unavailable, follow the client's delegation route or report the effect on the plan. A substitute needs the relevant authority; being the fastest person to reply is not a sufficient reason to accept their instruction.

Capture the answer so it can be implemented

An outcome should state the accepted behavior, including meaningful exceptions. “Option C approved” becomes ambiguous if the options change later. Record the rule itself and retain the version of the supporting material that was reviewed.

For the fictional example, a useful result would name the matching condition, the owner-retention rule, and what happens when no active owner is available. It should also identify whether the rule applies to existing records, future events, or both. Those are different delivery scopes and may require separate approval.

Link approval to its actual evidence location, such as the client-approved meeting record or project comment. Record unresolved details as open items rather than folding them into the approved rule. Convert each affected behavior into an acceptance criterion before implementing it.

Preserve revisions instead of erasing them

A client can change an approved decision. Preserve the previous rule and mark it superseded, then link the replacement. State why the question reopened and which implementation or acceptance evidence is now affected. Editing the old answer in place removes the explanation for behavior already delivered.

Route implementation changes through the agreed change process. The decision log establishes business direction; it does not by itself authorize additional scope or a production release. Identify the affected field map, configuration, tests, documentation, and queued work before promising a delivery date.

Avoid making every new comment a revision. First establish whether the comment supplies missing evidence, corrects a misunderstanding, or changes the policy. That classification helps the client decide whether the current rule should remain in force during review.

Run a short decision review and close the loop

Before the next delivery call, group entries by the next action: evidence needed, client answer needed, approved but not reflected in artifacts, or ready to close. Bring the smallest set of questions that the attendees can resolve. A long list of unrelated open items hides the consequential dependency.

For each approved entry, check that the relevant specification and tests use the same rule. At handoff, point the operator to decisions that shape daily exceptions and identify any provisional assumptions still open. An approved answer with no downstream update is unfinished coordination work.

A practical final check is to ask a team member who missed the meeting to explain the chosen rule, its approver, and the work affected. If they need an oral retelling, improve the record. For help turning one unresolved workflow choice into something a client can inspect, request a sample-data workflow design. The log earns its place when a reader can act on the answer without guessing what the meeting meant.