Prism

Exception Handling

Prism Customer Success Handbook — Section 2.11

What this page is — and isn't

Playbooks tell the CSM what to do when something triggers. This page states what Prism permits when a customer doesn't follow the process at all — the decisions that would otherwise get made ad hoc, differently each time, under pressure.

The test applied throughout: if an item became a list of steps, it belonged in a playbook and was moved there. What remains is policy — what's allowed, who decides, and what gets recorded.

The general principle: the process exists to serve the customer's outcome, not the reverse. Every exception below resolves toward keep the customer moving — but with the deviation recorded, because unrecorded exceptions become invisible norms.

Onboarding exceptions

The customer skips or refuses kickoff

Permitted. Proceed to onboarding without it; send the success criteria and credentials requirements in writing instead, and ask for written confirmation.

Recorded as an activity, because the demo gap and buyer≠implementer risks (1.5 Customer Journey Map) are now unmitigated. An account that skipped kickoff and later stalls should show that in its record.

Not permitted: treating written confirmation as equivalent. It isn't — it's the fallback. Push once for the meeting before accepting the substitute.

No implementer is ever named

The practice lead signs and nobody is assigned to do the work.

This is a stall, not a delay. Escalate to the practice lead after two unanswered attempts; do not begin milestone-nudge automation against an unnamed person. Automated nudges to nobody generate the appearance of coverage without the substance.

If no implementer is named within 30 days, the account is flagged At-Risk regardless of what the health model says — there is no path to value without someone to walk it.

Credentials never arrive

The credentials wall (1.5 Customer Journey Map, stage 2), unresolved.

CSM escalates to the practice lead, not to the credential holder. The credential holder usually doesn't report to the buyer and has no stake in the project; pressing them directly rarely works and can damage the relationship with the person who actually bought.

If unresolved past 45 days, treat as a stalled onboarding: At-Risk state, Low Adoption playbook.

Success plan exceptions

A Mid-Market or Enterprise account refuses a success plan

Permitted. Do not force the artifact.

But capture the objectives anyway, in the CSM's own record, from whatever the customer has said. The plan's purpose is knowing what the customer is trying to achieve; the document is just where that's usually written.

Consequence, recorded honestly: Success Plan Progress cannot be scored for that account. Rather than scoring it zero — which would be false — the account's composite is computed on the remaining categories, reweighted proportionally. A refused plan is missing data, not bad performance. (Reweighting on missing categories is a v2 build item.)

The plan exists but the customer won't review it

Plan currency decays as designed. This is not an exception to correct — it's a signal working correctly, and it will pull the health score down. If it persists past two review cycles, it's a stakeholder engagement problem, not a documentation problem.

Relationship exceptions

No executive sponsor can be identified

Permitted to proceed, flagged as structural risk.

For Enterprise, this is a renewal risk on its own, independent of health — an Enterprise renewal with no identified budget holder is unforecastable, and the forecast category cannot be Commit. State it plainly in the forecast reason.

For SMB, frequently normal — the practice lead often is the sponsor. Not an exception at all.

Champion departs with no successor

Playbook 3.4 Champion Departure handles the response. The policy question is what happens if no successor is found:

  • After 60 days with no replacement relationship, the account is At-Risk regardless of usage or health score
  • Forecast cannot be Commit without a named relationship — no exceptions, however good the usage numbers look

Product usage without a human relationship is a well-known false comfort: it looks healthy right up until the renewal decision reaches someone who has never heard of us.

The customer goes fully unresponsive

Not the same as quiet. Unresponsive means no reply across multiple channels and attempts.

Policy: three attempts across at least two channels, spaced over three weeks, then one direct note to a different contact at the account. If still nothing, At-Risk state and the account moves to exception-based coverage regardless of segment — no further scheduled outreach until they surface.

Continuing to send unanswered emails is not coverage. It logs activity that implies contact where none exists, which corrupts the engagement signal.

Commercial exceptions

Renewal date passes without signature

Policy: the customer keeps working. Service is not interrupted for a paperwork lag on an account that intends to renew.

Authority: the Director of CS approves any grace period beyond 30 days, and Finance is notified whenever a renewal date passes unsigned. Forecast category stays as-is; passing the date is not itself evidence of intent.

Procurement or security review blocks signature

Expected, not exceptional — for Enterprise, plan for it in the renewal motion timeline rather than treating it as a surprise.

The policy point: procurement delay is not a forecast downgrade. A Commit account stuck in procurement is still Commit. Downgrading on process friction rather than customer intent is how forecasts become noise.

An open escalation exists inside the renewal window

The escalation takes precedence. Do not run a renewal conversation over an unresolved P1 — asking someone to commit to another year while their reports are broken is the fastest available way to lose an account that was going to renew.

Resolve or materially stabilize the escalation first, then re-enter the renewal motion. If the renewal date genuinely can't wait, the Director of CS joins the conversation.

The customer asks to downgrade or reduce scope

Permitted and preferred over churn. A reduced contract is a retained relationship with a path back.

Sales owns the commercial transaction (2.5 Cross-Functional Interfaces); CS owns understanding why, which is the part that matters — a downgrade driven by their business contracting is very different from one driven by unused capability, and only the second is a CS problem to fix.

Recorded as contraction with a reason, not as a renewal win.

Coverage exceptions

An SMB account demands high-touch service

Policy: no, with warmth. Service level is set by the coverage model, not by who asks loudest (2.4 Account Prioritization Framework).

What is permitted: honoring a customer-requested call (2.2 Meeting Standards & Working Norms), pointing to education content, and — if the account genuinely warrants more — reviewing whether its segment assignment is wrong. Segment is a judgment, and a mis-segmented account should be re-segmented rather than served off-model.

What isn't: quietly running an SMB account at Mid-Market intensity. That's capacity taken from accounts the model says need it more, and it's invisible until something else breaks.

An account is mis-segmented

Permitted to re-segment. Segment is assigned by ARR band with a support-and-motion overlay (1.2 CS Operating Model) — an account whose complexity genuinely doesn't match its band should be moved, with the reason recorded.

Re-segmentation changes health weighting and therefore the composite score. Note it on the account so a step-change in health reads as a methodology change rather than a real shift.

Recording exceptions

Every exception above is logged as an activity with its reason. Two purposes:

  1. The account record explains itself later. An account that stalled after skipping kickoff, or a health score that jumped after re-segmentation, should be legible to whoever looks at it in ten months.
  2. Patterns surface at the quarterly system review (2.3 Operating Rhythm). One refused success plan is a customer preference. Six is a sign the artifact is asking for something customers don't value, and the design should change.

Exceptions that are never recorded become invisible norms — the process technically says one thing while the function actually does another, and nobody can tell which is which.