Put an Expiration Date on Every Client Exception

The expensive promise usually sounds harmless

"Send us that report every Friday." "Keep the founder on this call for now." "Can you hold the old rate until the next renewal?" "Please use this supplier even though it falls outside the normal shortlist."

Any one of those choices may be smart. The client may be working through a transition. Your team may be correcting a service problem. A temporary price concession may protect a good relationship. The mistake is not making an exception. The mistake is approving one without deciding when it ends.

Small advisory firms are especially exposed because exceptions often live in the founder's memory. The client remembers the promise. The team sees only the new behavior. Three months later, temporary custom reporting looks standard, the founder is still on every call, and nobody can explain why the account receives work that other clients do not.

That is not flexibility. It is an undocumented operating cost.

Separate an exception from changed scope

Every unusual request does not belong in the same process. Start by naming what is changing.

A scope change alters an active project's deliverables, fee, timing, responsibilities, or acceptance terms. Use a proper scope change decision before the work starts.

A service exception changes how you support a client outside the normal model. That could mean an extra report, a faster response target, a different meeting cadence, special routing, added founder involvement, a one-time price concession, or a temporary ownership arrangement.

A preference does not change a commitment at all. Calling every request an exception creates a giant list nobody respects.

Use a simple test: Does this request change what the client receives, what the firm charges, who must be involved, or how the team normally works? If yes, it deserves a decision record. If it changes active project scope or signed terms, route it through the applicable commercial process too.

Record the whole decision, not one note

"Special reporting approved" will not help the next advisor understand the tradeoff. An exception record needs enough context to make the next review possible.

• The client, request, requester, and date
• The normal service, price, process, or ownership rule being changed
• The business reason for the exception
• The exact boundary, including what is still not included
• The internal cost, capacity, risk, or commercial effect
• The internal approver and any client confirmation
• The owner responsible for operating the exception
• The start date, review date, and expiration date

Keep the signed contract, proposal, client activity, and active work connected to that record. Your signed terms and applicable requirements control the obligation. If the exception changes legal, regulatory, security, or commercial commitments, use the right qualified reviewer instead of treating an internal approval as permission to ignore them.

Current MSP guidance from NinjaOne uses the same practical fields for client-specific exceptions: scope, justification, owner, review date, and expiry date. Its examples focus mostly on technical and security exceptions. The operating lesson carries over to service and commercial promises: a deviation needs to be visible where the work happens and reviewable before it goes stale.

Make the owner different from the approver when it matters

The person fulfilling an exception should not automatically have authority to renew it.

An account manager may own the Friday report. The practice leader may be the person who decides whether the reporting stays free. An advisor may coordinate a special supplier path. The firm owner may need to approve the commercial exposure. A project coordinator can operate a temporary meeting cadence without deciding that the founder attends forever.

This distinction matters because the delivery owner experiences the immediate client pressure. Saying yes can feel easier than reopening the commercial conversation. The approver should see the broader account, capacity, pricing, and precedent before extending the exception.

Use the ownership boundary from the account and opportunity ownership process. Name who runs the work, who protects the relationship, and who can change the commitment. One person can hold several roles. Just make it a deliberate choice.

Choose the review date before the expiration date

An expiration date without a review date creates a last-minute scramble. Put the decision far enough ahead that the firm can speak with the client, change staffing, reprice the work, update documents, or return to the normal service model.

The review should answer four questions:

1. Does the original business reason still exist?
2. What did the exception cost or consume?
3. What does the client expect now?
4. Should the firm end, renew, standardize, or reprice it?

End it when the temporary need is gone. Renew it for a defined period when the reason still holds. Standardize it when repeated demand shows the normal service model is wrong. Reprice it when the client values the work and the current commercial model does not support it.

Do not use "reviewed" as a fifth answer. A review that leaves the same exception open without a new decision, owner, and date is just an overdue exception with meeting notes.

Let automation route the decision, not make it

Reminders are useful. Approval workflows are useful. Automatic renewal of an exception is usually not.

Salesforce's current approval-process guidance says the business process should be planned before the automation is configured. Its model defines the approval steps, the approvers, and what happens after approval or rejection.

That is the right order. First decide which exceptions require review, who can approve each type, what evidence they need, and what each outcome changes. Then automate the reminder, routing, task creation, status update, or notification.

Otherwise the software will make a weak process move faster. A reminder can tell the owner that a pricing exception expires in 30 days. It cannot decide whether the relationship value justifies another six months of discounted work.

Review exception patterns across the portfolio

One exception is an account decision. Repeated exceptions are firm-level evidence.

Add an exception view to the weekly operating review for anything overdue, ownerless, high-risk, or close to expiration. Use a monthly portfolio review for the pattern behind them.

Look for one client carrying several exceptions, the same custom report appearing across accounts, repeated pricing concessions, founder attendance that never steps down, and service promises that do not match the client's assigned model.

Then fix the source. Update the standard package. Tighten the approval boundary. Add a paid option. Change the client service model. Improve the service pricing. Train another owner. Some exceptions should disappear. Others are telling you what the firm should sell next.

Audit the promises your team calls temporary

Pull ten active clients and ask every advisor which commitments are "just for now." Search for custom reports, special meetings, response promises, discounts, unusual supplier routes, founder involvement, and ownership workarounds.

For each one, find the reason, approver, owner, cost, client expectation, review date, and expiration date. If any field depends on asking the person who remembers the conversation, the exception is not under control.

Advisor OS CRM connects organizations, contacts, activity history, tasks with due dates, proposals, approval workflows, pipeline, suppliers, and reporting. Use that shared context to keep the exception beside the client relationship and put the review into the team's normal work.

The free Advisor OS agency scorecard can help you spot where client delivery still depends on private memory and founder intervention.