Epismo
Alias
View only

Deliver a Customer Business Review

Use when a CS or consulting owner must prepare and conduct a periodic business review focused on outcomes, value delivered, risks, and upcoming priorities. This includes evidence collection and customer discussion, not automatic commercial upselling. Do not use for a routine status meeting that has no outcome review.

Don't just read it. Run it.

Start the work here, keep the important context together, and hand it off to people or AI.

Use playbook

Starting inputs

account *

Customer account identifier.

string

audience

Stakeholder audience: operational, executive or mixed.

string

reviewPeriod *

Time period for the business review.

string

successPlanRefs

Prior goals, adoption metrics, baseline, outcome documentation and past reviews.

array

Steps

  1. 1

    Reconstruct promised outcomes and baseline

    Collect the latest success plan, business objectives, implementation scope, last review's commitments and applicable product or operational baselines. Define the customer's metric, the unit, observation period, target and provenance. Distinguish originally committed outcomes from evolving wishes or proxy measures. Review open issues and decision history to identify commitments that materially affect trust. If no baseline exists, say so and present a plan to establish one. Gate: the review is anchored in what the customer sought to achieve, not product activity alone.

    V2 practical protocol:
    Outcome scorecard format: goal | defined metric/unit | prior agreed baseline and date | target and date | actual and observation period | source | data quality | variance | customer validation. Require matching time windows and populations for any trend comparison; if targets were never agreed, mark "not established" rather than backfilling them after seeing results. Identify contractual outcomes, aspirational goals and activity measures separately. Flag what requires customer confirmation before public attribution.

    Skills anthropics/knowledge-work-plugins sales/skills/customer-health github
  2. 2

    Analyze results, adoption and constraints

    Gather actual usage, workflow outcomes, service quality and support data from authorized sources. Compare with target and prior period only when units and populations match. Separate correlation from causal claims about the product's impact. Quantify attributable savings or revenue only with documented assumptions; avoid inventing ROI. Identify adoption gaps, underused segments, unresolved blockers and positive surprises. Gate: every highlighted metric carries a timeframe, source and caveat, and no unsupported improvement is reported as fact.

    V2 practical protocol:
    For each measured change calculate both absolute difference (actual − baseline) and relative percentage only if the denominator is meaningful and nonzero. Label evidence tier: A = directly measured from reliable source with comparable periods; B = modeled from stated assumptions and observed drivers; C = customer reported without independent verification; U = unknown. For time savings, report task volume, measured duration change, adoption and whether saved hours are realized. For adoption, use active eligible users/eligible population with a defined period, not raw logins. For ROI, show costs and attribution assumptions; avoid attributing every business change to product activity. Quantify negative results and missing data in the same scorecard.

  3. 3

    Choose the decisions worth the customer's time

    Develop a short narrative: what the customer attempted, what changed, what value is proven, what remains constrained, and what options exist next. Separate executive choices from operational updates. Prepare specific asks for the sponsor, user owner or technical lead, along with evidence and trade-offs. Avoid turning the meeting into a feature tour or sales pitch. Gate: each major slide or section exists to support an outcome conclusion or customer decision.

    V2 practical protocol:
    Build an executive storyline in five beats: customer goal, verified progress, economic or operational consequence, constraints/risks, decision or trade-off for the next period. Create 3–5 headline messages, each tied to a scorecard cell and its evidence tier. Distinguish operational audience detail from executive asks; move technical activity counts to appendix unless they explain value. Minimum deliverable: executive summary (≤150 words), outcome table, two evidence-backed wins or misses, and the decisions sought. Do not force a slide deck when a written memo is sufficient.

  4. 4

    Conduct the review and record the customer's judgment

    Present the facts and uncertainties candidly; invite disagreement on baselines, attribution and realized value. Confirm whether customer priorities have shifted and which outcomes matter next. Capture decisions, changed targets, explicit objections and unresolved questions from actual meeting evidence. Do not infer approval from a polite conversation. Gate: the customer's assessment and priorities are represented fairly, including negative signals.

    V2 practical protocol:
    Before presenting, make a "challenge list" of the three weakest claims, their sources and how to answer questions about causality, population, gaps or a changed baseline. During the actual review, capture the customer's corrections, disputed attribution and priorities, preserving the distinction between "presented", "agreed" and "rejected". Do not declare a meeting conducted from a prepared deck alone. Where evidence is disputed, record the updated analysis task instead of repeating the original claim as fact.

  5. 5

    Set the next measurable success focus

    Reflect only agreed priorities in a concise next-period success plan with objective, leading measures, relevant baseline, responsible roles and review cadence. Distinguish approved customer commitments from drafts. Share the report or edit systems only under appropriate permissions. Close when the review has yielded a clear, evidence-grounded appraisal and next-period priorities, not because a decorative deck was produced. Gate: the final review is defensible and usable at the next checkpoint.

    V2 practical protocol:
    Next-period success focus: choose at most three outcomes, each with metric definition, baseline/source, target or learning threshold, business owner, dependency and review date. Record which are customer-approved versus suggestions. Final review artifact should be readable without deck narration: achievements, misses, attributable value tier, unresolved issues and decisions. No mandatory separate handoff document or generic wrap-up step.

Used in public cases

Published work that started from this playbook.

Used in public cases →