Decision Four: Can the Company Win and Keep Customers?

Task

Run the Stage 4 gate review.

Summary

Decide whether the subscription business is stable enough to support more sales channels.

Execution Plan for the Stage Four Subscription-Business Gate Review Article

Executive Summary

The attachment is no longer unspecified. The operative assignment is S4-15: “Run the Stage 4 gate review.” Its required output is a publication-ready, research-backed Markdown article that helps a leadership team decide whether it has credible proof of repeatable subscription acquisition, activation, retention, and renewal. The recorded outcome is a Go or No-Go decision, not an arbitrary industry score.

The central execution challenge is not simply writing about software-as-a-service metrics. It is building a defensible decision method that distinguishes:

• measured results from assumptions;
• repeatable performance from a few successful customers;
• customer activity from customer value;
• revenue growth from economically sustainable growth;
• immature cohorts from genuine retention evidence;
• an operationally ready subscription business from one still dependent on founders, exceptions, or manual recovery.

The supplied presentation and workbook provide useful internal context on time to value, conversion gates, churn, user feedback, expansion, and subscription workflows. The presentation frames subscription growth as an end-to-end system that includes value delivery, packaging, onboarding, conversion, retention, expansion, and operational feedback. The workbook operationalizes portions of that system through worksheets for access gating, emotional-anchor campaigns, scarcity tactics, and feedback prioritization. Those materials should inform the research questions and artifact design, but the final article must independently verify every publishable point through permissible public sources because the assignment explicitly prohibits using or mentioning one named source family.

The recommended approach is a balanced, five-to-seven-business-day execution using approximately 24–36 person-hours. It should produce a 2,500–4,000-word article supported by roughly 10–14 strong sources, a compact gate-review model, one public example, one useful Mermaid diagram, and a documented claim-and-citation audit. A faster approach is possible, but it creates material risks around source quality, metric interpretation, attachment coverage, and the prompt’s absolute source prohibition.

Instruction Model and Success Criteria

The first task is to convert the prose prompt into a testable requirements model. The attached assignment contains several different kinds of instruction, and they must not be treated as interchangeable.

These requirements come directly from the attached task record and editorial instructions.

Several items remain genuinely unknown and must be marked as such rather than invented:

A crucial interpretation rule is that the gate decision is an outcome, not a benchmark. Public SaaS companies themselves use different definitions of annual recurring revenue and net retention, and filings warn that similarly named non-GAAP metrics may not be comparable. Stripe likewise allows businesses to configure parts of their monthly recurring revenue, churn, and active-subscriber definitions, illustrating why a gate review must freeze definitions before evaluating performance.

Parsing, Validation, and Execution Method

The work should proceed through a controlled sequence in which every requirement is tied to evidence, drafting, and validation.

flowchart LR
    A[Inventory instructions and files] --> B[Build requirement matrix]
    B --> C[Extract business questions]
    C --> D[Define evidence and metrics]
    D --> E[Research primary and open sources]
    E --> F[Evaluate and triangulate evidence]
    F --> G[Draft the article]
    G --> H[Run source, metric, and prohibition audits]
    H --> I{All requirements satisfied?}
    I -->|No| J[Correct gaps]
    J --> H
    I -->|Yes| K[Publication-ready Markdown]

Text description: instructions and supplied materials are translated into requirements and research questions; evidence is gathered and assessed; the article is drafted; automated and manual checks loop until every requirement is satisfied.

Establish the instruction hierarchy. Create a one-page hierarchy that places the current user request first, followed by the S4-15 task record, writing and source rules, methodology context, and other supplied materials. Any lower-level instruction that conflicts with a higher-level instruction must be excluded. The assignment itself supplies this conflict-resolution order.

Inventory and inspect every supplied file. For the presentation, extract slide text, notes, diagrams, tables, and repeated conceptual structures. For the workbook, inspect sheet names, labels, formulas, example values, instructions, and relationships among sheets. The current workbook includes operational structures for conversion gates, campaign effects, feedback loops, and churn-related observations; example rows must be treated as examples, not company evidence.

Create a requirement-traceability matrix. Give each requirement a unique identifier and record:

Separate context, hypotheses, and publishable evidence. The supplied materials suggest several useful themes: time to first value, product-use signals, access gates, conversion paths, churn, customer feedback, expansion, and viral growth. These become research hypotheses. They do not become article claims until confirmed by allowed public sources.

Translate the task into research questions. The research should answer, at minimum:

1. What is a business gate review, and what makes its decision credible?
2. What evidence demonstrates repeatable acquisition rather than isolated selling success?
3. How should activation be tied to first customer value?
4. How should retention and renewal be measured by cohort, segment, plan, and contract term?
5. Which costs belong in customer acquisition cost and payback analysis?
6. How should onboarding, implementation, support, and customer-success effort enter the economics?
7. What data maturity is needed before drawing conclusions?
8. How should management handle conflicting signals?
9. What constitutes a Go, a No-Go, or—where governance permits—a conditional decision?
10. What proof must be retained in the decision record?

Define metrics before looking for favorable results. The article should require a metric dictionary that states the event, population, time window, exclusions, source system, calculation, and owner for every measure. This is essential because subscription platforms allow configuration choices that materially affect recurring-revenue and churn calculations, while public-company definitions also vary.

Test the end-to-end customer journey, not isolated dashboards. Acquisition, buying, onboarding, activation, product use, support, billing, retention, and renewal should be evaluated as one connected service. Official service-design guidance recommends combining analytics with user research, support data, backend information, and financial data rather than relying on digital analytics alone. AWS’s SaaS guidance similarly treats tenant onboarding as an orchestrated process involving all components needed to provision and configure a customer, whether self-service or provider-managed.

Use cohorts and adequate observation periods. Overall averages can mix customers acquired under different offers, prices, channels, and onboarding processes. The research literature treats retention as a time-dependent process and shows the value of examining subscriber duration and customer heterogeneity. The article should therefore require acquisition cohorts segmented by relevant characteristics and explicitly label immature cohorts.

Triangulate important findings. Each major conclusion should ideally have two kinds of support. For example, the definition of net retention can be grounded in a current regulatory filing, while interpretation limitations can be supported by another filing or open research. Product experimentation claims should use controlled-experiment research rather than anecdotal conversion advice. Microsoft’s research emphasizes that experiments can establish causal effects through randomization, while also warning that data-quality failures and metric misinterpretation can reverse apparent conclusions.

Draft around the decision, not around a metric catalogue. The article should begin with the recognizable situation of a company whose subscription revenue is growing but whose leaders cannot tell whether growth is repeatable or supported by sound economics. It should then explain the operating principle, evidence model, review process, public example, tradeoffs, and final decision record.

Run a two-pass quality review. The first pass checks evidence, definitions, calculations, citations, examples, and prohibitions. The second pass checks clarity, structure, tone, repetition, and whether the conclusion leaves the reader with a clear decision.

Objectives, Deliverables, and Source Strategy

The following objectives should control the work. “Unknown” means the underlying company-specific evidence is not presently available; it does not mean the requirement is optional.

Recommended source families. The final source set should be selected by claim, not by reputation alone.

Gate-review research shows that useful gates require explicit criteria, deliverables, decision roles, and attention to commercial feasibility and risk rather than a ceremonial presentation. The concept should be adapted carefully: research on innovation gates does not itself establish SaaS performance thresholds, but it supports a disciplined evidence-and-decision process.

Search strategy. Use layered searches rather than one broad query.

Every candidate source should receive a quick appraisal score for authority, accessibility, recency, directness, methodological quality, conflict of interest, and relevance. A vendor source may define its own system correctly, but it should not be used to establish a universal business benchmark. Stripe’s documentation, for example, is authoritative for Stripe’s metric behavior, not proof that every subscription business should use the same settings or targets.

Output Templates and Examples

The primary deliverable is the article, but the work benefits from reusable artifacts covering specifications, plans, code checks, tests, and user guidance.

Gate-review evidence record

# Stage Four Gate Decision

**Review date:** YYYY-MM-DD
**Decision:** Go / No-Go
**Decision owner:** [Role]
**Review participants:** [Roles]
**Evidence period:** [Start date] to [End date]
**Customer segments covered:** [Segments]
**Segments excluded:** [Segments and reasons]

## Decision summary

[State what the evidence supports, what it does not support, and why the
decision follows.]

## Evidence reviewed

| Area | Definition | Result | Cohort or period | Source system | Confidence |
|---|---|---:|---|---|---|
| Acquisition | [Definition] | [Value] | [Cohort] | [System] | High/Medium/Low |
| Activation | [Validated value event] | [Value] | [Cohort] | [System] | High/Medium/Low |
| Retention | [Logo and revenue definitions] | [Value] | [Period] | [System] | High/Medium/Low |
| Renewal | [Eligible and completed renewals] | [Value] | [Period] | [System] | High/Medium/Low |
| Economics | [CAC, payback, margin definitions] | [Value] | [Period] | [Systems] | High/Medium/Low |

## Conditions and exceptions

- [Named condition, owner, deadline, and consequence]
- [Known segment or data limitation]

## Risks accepted

[Risk, rationale, accountable owner, and monitoring action.]

## Next review

**Date:** YYYY-MM-DD  
**Required new evidence:** [Evidence]

Technical specification for the evidence pipeline

Example project plan

Automated compliance check

from __future__ import annotations

import re
from dataclasses import dataclass
from pathlib import Path


@dataclass(frozen=True)
class CheckResult:
    name: str
    passed: bool
    detail: str


def lint_article(path: str) -> list[CheckResult]:
    text = Path(path).read_text(encoding="utf-8")
    words = re.findall(r"\b[\w’-]+\b", text)

    # Construct prohibited patterns from the exact variants defined in the
    # assignment. Keep the production list in a controlled configuration file.
    prohibited_patterns = [
        r"\bPROHIBITED_VARIANT_A\b",
        r"\bPROHIBITED_VARIANT_B\b",
        r"\bPROHIBITED_VARIANT_C\b",
    ]

    results = [
        CheckResult(
            "Task identifier",
            "**Task ID:** S4-15" in text,
            "Required task identifier is present.",
        ),
        CheckResult(
            "Word count",
            2500 <= len(words) <= 4000,
            f"Detected {len(words)} words.",
        ),
        CheckResult(
            "Sources section",
            "\n## Sources" in text,
            "Required Sources heading is present.",
        ),
        CheckResult(
            "Mermaid limit",
            text.count("```mermaid") <= 2,
            f"Detected {text.count('```mermaid')} Mermaid blocks.",
        ),
        CheckResult(
            "No placeholders",
            not re.search(r"\b(TODO|TBD|PLACEHOLDER)\b", text, re.IGNORECASE),
            "No draft placeholders detected.",
        ),
    ]

    for index, pattern in enumerate(prohibited_patterns, start=1):
        match = re.search(pattern, text, re.IGNORECASE)
        results.append(
            CheckResult(
                f"Prohibited source pattern {index}",
                match is None,
                "No match." if match is None else f"Match found: {match.group(0)!r}",
            )
        )

    return results


if __name__ == "__main__":
    checks = lint_article("s4-15.md")
    for check in checks:
        status = "PASS" if check.passed else "FAIL"
        print(f"{status}: {check.name} — {check.detail}")

    if not all(check.passed for check in checks):
        raise SystemExit(1)

The production configuration must contain the actual prohibited spelling variants from the assignment. The generic placeholders above prevent this planning report from reproducing them unnecessarily.

QA test cases

User-documentation template

# How to Prepare for the Subscription Gate Review

## Purpose

This review determines whether the subscription business is repeatable enough
to support the next planned investment or sales channel.

## What each team must provide

**Sales:** opportunities, wins, losses, cycle time, discounts, and selling effort.  
**Marketing:** spend, source, campaign, lead quality, and attributed customers.  
**Product:** activation event, time to first value, usage, and cohort retention.  
**Customer success:** onboarding work, support effort, risk, renewal, and expansion.  
**Finance:** recognized revenue, recurring-revenue reconciliation, margin, acquisition
cost, and payback.  
**Data:** definitions, lineage, exclusions, quality checks, and known gaps.

## Before the meeting

Confirm that every metric has an owner, definition, period, source, and segment.
Reconcile customer and revenue totals. Label hypotheses and immature cohorts.

## During the meeting

Review evidence, not presentation quality. Record disagreement, uncertainty,
exceptions, conditions, and the accountable decision owner.

## After the meeting

Publish the decision record, assign corrective actions, and schedule the next
review only when the missing evidence can reasonably exist.

Risk, Timeline, and Resource Options

The main risks are analytical and governance risks, not merely writing risks.

A gate should not produce false precision. Academic work on quality gates supports explicit criteria and decision processes but also identifies the need for flexibility and customization. Retention research similarly indicates that customer duration and heterogeneity matter, so one blended churn rate should not control the decision.

The following estimates are planning assumptions, not industry benchmarks. Costs use a hypothetical blended professional rate of US$125–$200 per hour and exclude purchase of proprietary data, legal review, or original customer research.

The fast approach should not skip any mandatory instruction. “Lower assurance” means fewer corroborating sources and less specialist review, not permission to omit attachments, citations, or the prohibition audit.

gantt
    title Balanced execution schedule
    dateFormat  YYYY-MM-DD
    axisFormat  %b %d

    section Intake
    Inspect files and map requirements     :a1, 2026-08-03, 1d
    Build research questions and metrics  :a2, after a1, 1d

    section Research
    Primary and official research         :b1, after a2, 2d
    Open research and challenge sources   :b2, after a2, 2d
    Evidence appraisal and synthesis      :b3, after b1, 1d

    section Production
    Draft complete article                :c1, after b3, 1d
    Source and subject review             :c2, after c1, 1d
    Compliance and editorial QA           :c3, after c2, 1d

Text description: the balanced approach uses the first two days for requirements and research design, two days for source work, one day for synthesis, and approximately three days for drafting and review. Activities can overlap when separate researchers are available.

The balanced team should include one research writer with SaaS literacy, one part-time subject reviewer familiar with subscription operations and economics, and one research editor or data reviewer. The thorough approach may add an accounting reviewer when recurring-revenue reconciliation or recognized-revenue claims become material.

Validation, QA, and Final Checklist

Validation should test both substantive correctness and instruction compliance.

Evidence validation. For every proposed gate criterion, verify the definition, population, observation period, segmentation, source system, exclusions, data owner, and decision relevance. Reconcile billing, customer, and finance counts. Confirm that acquisition data includes channel and selling effort; activation represents customer value; retention is cohort-based; renewal uses eligible customers; and economics include the labor required to sell, onboard, implement, support, and retain customers.

Source validation. Open every cited source. Confirm that it is freely accessible, that the citation supports the nearby claim, and that dates and measurement periods are reported accurately. Regulatory filings should be used for the filing company’s definitions, not as universal standards. Official product documentation should describe the documented platform, not prove broad market effects. Academic findings should be translated carefully and bounded by their data and setting.

Metric validation. Compare every metric name with its exact formula. Public filings demonstrate that retention calculations may include expansion, contraction, churn, phased activation, or other company-specific elements. Subscription analytics systems may also classify trials, zero-value subscribers, discounts, pauses, and cancellations differently depending on configuration. The article must therefore explain definitions rather than merely name metrics.

Experiment validation. When the article recommends testing onboarding, pricing, or conversion changes, it should distinguish correlation from causation. Randomized experiments can estimate causal effects, but trustworthy results require correct assignment, adequate power, valid metrics, and data-quality checks.

Editorial validation. Read the article aloud. Replace abstract phrasing with concrete actors, actions, evidence, costs, and decisions. Remove biography, promotional language, generic motivation, and unnecessary explanation of the broader methodology. Keep adjacent tasks brief.

Decision validation. A credible decision record should state:

• what was reviewed;
• which customers, plans, channels, and periods the evidence covers;
• what the evidence proves;
• what remains an assumption;
• what evidence is missing;
• which risks are accepted;
• who owns the decision;
• whether the result is Go or No-Go;
• any named conditions, owners, and deadlines;
• when the decision will be revisited.

A Go should mean that evidence is sufficiently consistent, mature, traceable, and economically credible for the company to depend on the subscription system in its next decision. It should not mean every metric is perfect. A No-Go should mean that an important capability is unproven, unreliable, uneconomic, or still too dependent on exceptional manual effort. Missing evidence is itself a legitimate reason not to claim readiness.

Final production checklist

• Every supplied file has been inspected beyond its filename.
• The requirements matrix covers the task, evidence, dependency, measure, target, format, voice, sources, visuals, and prohibitions.
• S4-01 through S4-14 are represented in a dependency register.
• Missing dependency outputs are marked unknown rather than reconstructed.
• The article begins with a recognizable subscription-business problem.
• The operating principle is stated in plain language.
• Acquisition, activation, retention, renewal, support, and economics are connected.
• Activation is defined as a validated customer-value event.
• Retention and renewal are separated.
• Metrics are shown by cohort and relevant segment.
• Immature cohorts and censored observations are identified.
• Acquisition cost includes the relevant selling and channel costs.
• Onboarding, implementation, support, and founder effort enter the economic assessment.
• The gate criteria distinguish proof, interpretation, assumption, and unknown.
• The Go/No-Go decision method is explicit.
• No working target is presented as a universal industry benchmark.
• Approximately 8–15 strong sources are actually used.
• Primary and official sources carry the most important claims.
• At least one or two open academic sources are used where the literature supports the topic.
• Every quantitative, company, legal, historical, and research claim has an inline citation.
• Every source is freely accessible and has been opened.
• The public example teaches one clear lesson and does not become a company profile.
• No confidential, private, or example workbook data is published as fact.
• The final text passes the exact case-insensitive prohibited-source scan.
• The title block exactly includes **Task ID:** S4-15.
• The summary is 40–70 words.
• The article is roughly 2,500–4,000 words.
• No more than two useful Mermaid diagrams appear.
• Every diagram is explained in surrounding prose and has a text description.
• The final section is ## Sources.
• The source list contains only sources actually used.
• No research plan, attachment discussion, prompt commentary, outline, placeholder, or chain of thought remains in the article.
• The ending leaves the reader with a clear decision and the evidence required to support it.