Skip to main content

C3. Repeatable Customer Success (consistent outcome)

Construct: ICP customers achieve the outcome they seek in a consistent, cohort-replicable way, without depending primarily on heroic/concierge effort.

Qualifiers:

  • Outcome ≠ activity (usage by itself does not define success).
  • The outcome must be decisional (it changes customer decision/routine/commitment).
  • The outcome/proxy must be discriminatory: it clearly separates those who exhibit choice behavior relevant to the model (e.g., renewal, expansion, repurchase, committed recurring usage, effective referral) from those who do not.

Application

The ICP achieves an outcome (not an activity) consistently by cohort, and this happens without depending on team “concierge/heroics.” The outcome must be decisional (changes routine/decision/commitment), and the proxy must be discriminatory (clearly separates those who later make relevant choices — renew/expand/repurchase/refer — from those who do not). The “outcome vs activity” distinction and the use of cohorts are exactly what help avoid “vanity metrics.”

Examples

Example 1 — Financial close (B2B SaaS) Unit (C1 summarized): SMEs with lean finance teams → “close month-end without chaos” → reconciliation+reporting SaaS (simple pricing/implementation) vs spreadsheet+accountant.

Agent/DMU: user=finance; buyer/decider=owner/CFO (sometimes the same person)

  • Outcome (not activity): “month-end close in D+X days with low discrepancy” (something that changes owner/finance routine).
  • Activity that does NOT define success: logins, number of reconciliation clicks, time in app.
  • Decisional: customer changes process (“now I close in 2 days”), reduces dependence on accountant/spreadsheet, stops hiring overtime during close.
  • Discriminatory proxy (proposed): ‘cohorts hitting D+X for 2–3 cycles’ should separate renewal/expansion vs churn/downgrade.

Does not work (breaks C3): only “works” with weekly consulting from your team (manual setup, manual data pulling) — that is concierge success, not repeatable.

Alignment note: here the “value” is the delivered outcome (north star/outcome), not usage.

Example 2 — Compliance / audit (long cadence) Unit: companies with audit requirements (SOC2/ISO etc.) → “pass audits with less effort” → evidence+controls platform vs spreadsheets+consulting.

Agent/DMU: user=GRC/Compliance (operates evidence); buyer/decider=Security/Compliance leader; gatekeeper=Procurement/Legal.

  • Outcome: “audit completed with no critical findings and reduced internal effort” (decision: “let’s standardize this here”).
  • Activity that does NOT define success: “registered users,” “uploaded documents,” “filled checklists.”
  • Decisional: customer institutionalizes the routine (becomes an official process, not a ‘project’), reduces consulting, keeps evidence alive.
  • Discriminatory proxy (proposed): renewal in the next cycle + expansion to another framework/BU (e.g., SOC2 → ISO) after completing the audit.

Does not work: you “save” the audit with heroic effort (build docs for the customer, answer auditor on their behalf). They pass, but it does not become a cohort-replicable routine.

“Concierge MVP / heroics” is useful for learning, but explicitly non-scalable as a repeatable success mechanism.

Example 3 — Customer support (ICP operational outcome) Unit: mid-size e-commerce with ticket spikes → “maintain SLA with the same team” → automation/routing/assisted responses vs hiring BPO + manual macros.

Agent/DMU: user=CS Ops/Support lead; buyer/decider=Head of CX/COO; gatekeeper=IT/Security (if present).

  • Outcome: “% of tickets within SLA with same headcount (or lower cost)” — this changes staffing/vendor decisions.
  • Activity that does NOT define success: number of automations created, login time, number of response suggestion clicks.
  • Decisional: manager stops hiring temporary staff/BPO at peak because the system holds SLA; changes playbook.
  • Discriminatory proxy (proposed): after 1–2 peaks, sustained SLA should separate renewal/expansion vs return to BPO/spreadsheet.

Does not work: outcome appears only when your team adjusts rules daily and “pilots” the operation — success depends on you, not on the offer.