Every year, hundreds of health systems in the United States switch their electronic health record system to Epic. Some are moving from Cerner. Some from Meditech. Some from Allscripts. Some are consolidating multiple Epic instances into one.

When this happens, the clinical side gets most of the attention — training doctors, mapping workflows, configuring order sets. But behind the scenes, there’s a massive data problem that nobody talks about until it’s too late.

The Pipeline Problem

Over the years, every health system builds hundreds of data pipelines. These are automated processes that move data from the EHR into reporting systems, analytics platforms, data warehouses, billing systems, quality dashboards, and regulatory feeds.

A typical health system has:

• 200-500 Informatica PowerCenter mappings
• 50-150 SQL stored procedures
• 30-80 HL7 interface feeds
• 20-50 flat-file extracts
• Dozens of custom scripts nobody documented

Every single one of these pipelines reads from tables in the old EHR. When you switch to Epic, those old tables don’t exist anymore. The data is now in Epic’s Clarity database, which has a completely different structure — different table names, different column names, different conventions for how data is stored.

Every pipeline must be rewritten.

Why This Is So Painful

It takes forever. Each pipeline takes a consultant 2-5 days to manually convert. With 500 pipelines, that’s 1,500 days of work — roughly 18 months with a team of 8 people.

It costs a fortune. At consulting rates, that’s $10-20 million in professional services just for the data migration. This comes on top of the $100M+ the health system is already spending on the Epic implementation itself.

It requires rare expertise. To convert a pipeline, you need someone who understands both the old system (Cerner’s data model) and the new system (Epic’s Clarity database). These people are extremely hard to find. On a team of 8 consultants, usually only 2-3 know both systems well enough.

The quality is inconsistent. Junior consultants miss subtle but critical details about how Epic stores data. They sort by the wrong date column. They assume the first diagnosis in a list is the primary one. They use numeric codes instead of text values. These bugs are invisible during development and only surface in production — where they cause billing delays, incorrect quality reports, and compliance failures.

The deadline doesn’t move. Epic go-live dates are immovable. If the data pipelines aren’t ready, the health system operates blind — no dashboards, no reports, no analytics. Revenue suffers. Patient safety suffers.

The Hidden Complexity of Epic’s Data

Epic’s database isn’t just big (18,000-30,000 tables). It’s genuinely strange. It was originally built on a 1960s programming language called MUMPS, and many of those design decisions survive today in the form of patterns that look wrong to anyone trained on modern databases.

For example:

• When a patient has multiple diagnoses for a visit, they’re stored with a LINE number. But LINE 1 is NOT the primary diagnosis — it’s just the first one entered. The primary diagnosis could be at LINE 5. There’s a separate flag field you have to check.
• When you need to sort events chronologically, you can’t use the date column. Multiple events on the same day all have the same date. Instead, Epic has a special decimal number that encodes both the date AND the sequence. You have to sort by that decimal number. This number counts days since December 31, 1840. Why 1840? Because that’s what the MUMPS programming language chose in the 1960s.
• Category values like “Completed,” “Scheduled,” “Canceled” are stored as text, not as numeric codes. There are no lookup tables. You have to match on the exact text.
• ICD-10 diagnosis codes (which you need for billing and quality reporting) are NOT in the diagnosis table where you’d expect them. They’re buried three joins deep through the claims tables.
• A field called INPATIENT_DATA_ID sounds like it identifies hospital admissions. It doesn’t. 95% of records with this field are outpatient visits. It actually enables a workflow tracking feature.

Every migration team discovers these gotchas the hard way. Usually in production. Usually at great cost.

What Clarity Migrate Does

Clarity Migrate converts legacy data pipelines to Epic Clarity automatically. You give it a pipeline file from your old system, and it gives you back a working Epic-native pipeline — tested, validated, and ready to deploy.

The core idea: an AI agent that has been taught everything about Epic’s data model — all 6,630 documented tables, all 55,159 columns, all the naming conventions, all the gotchas — and uses that knowledge to do in minutes what a human consultant does in days.

How It Works — The Simple Version

You:      Here's a Cerner Informatica mapping that builds a patient demographics table.
          [drops XML file]

Kiro:     Reading... Found 2 source tables (PATIENT, CLARITY_SER).
          Verified both exist in Epic Clarity.
          Found 4 transformations: filter, expression, lookup, load.

          Generated:
          ✓ PySpark job (148 lines)
          ✓ Target table DDL
          ✓ 26 automated tests
          ✓ All tests passing

          Done in 3 minutes.

How It Works — The Detailed Version

Step 1: Understanding the source. The agent reads the legacy pipeline file. If it’s an Informatica XML, it parses the source tables, target table, transformations (filters, expressions, lookups, joins, aggregations), and the data flow between them. If it’s SQL, it extracts the table references, joins, WHERE clauses, and business logic.

Step 2: Finding the Epic equivalents. For each table referenced in the old pipeline, the agent searches an index of Epic’s 6,630 tables to find the equivalent. If the old pipeline reads from Cerner’s CV3_ENCOUNTER table, the agent finds that the Epic equivalent is PAT_ENC. It looks up the exact column names, data types, and relationships.

When there’s no perfect match (for example, Cerner’s CV3_CLINICAL_EVENT maps loosely to Epic’s ORDER_PROC with only 87% confidence), the agent flags it for human review and explains why.

Step 3: Applying Epic’s rules. This is where the agent earns its keep. It reads a set of rules about how Epic stores data — the patterns that trip up every migration team — and applies them to the generated code.

If the old pipeline sorts by a date column, the agent knows to use Epic’s decimal _REAL column instead. If the old pipeline looks up a diagnosis code, the agent knows that ICD-10 codes are in the CLM_DX table, not CLARITY_EDG. If the old pipeline filters on a status code, the agent knows to use the text value (‘Completed’), not a number (‘2’).

These aren’t guesses. These are rules derived from Epic’s official documentation and validated against real Epic data.

Step 4: Generating the code. The agent writes a complete PySpark job that reads from Epic Clarity (via JDBC), applies all the transformation logic from the original pipeline, and writes the results to the target data warehouse (Snowflake or Postgres). The code uses environment variables for all database credentials — never hardcoded.

It also writes a CREATE TABLE statement for the target table, with proper data types, primary keys, and indexes.

Step 5: Writing and running tests. The agent writes automated tests that verify the generated code is correct:

• Does the code compile?
• Does it reference the right source and target tables?
• Are database credentials coming from environment variables (not hardcoded)?
• Are the key transformation keywords present (filter, join, age calculation, gender mapping)?
• Are Epic patterns applied correctly?

Then it runs the tests. If any fail, it reads the error, fixes the code, and re-runs. It keeps trying until all tests pass (up to 3 attempts).

Step 6: Proving it works. Once tests pass, the agent can run the actual PySpark job against test databases — a MySQL instance with sample Epic data (source) and a Postgres instance (target). It verifies that data actually landed in the target table, checks row counts, validates the schema, and runs the job twice to confirm it’s idempotent (produces the same results on re-run).

Step 7: Committing the code. Only after the proof passes does the agent commit the code to git. It creates a branch with a timestamp, writes a commit message summarizing what was converted and the proof results, and pushes. If the proof didn’t pass, nothing is pushed. Broken code never makes it to the repository.

The Four Modes

Read Mode — “What do I have?”

You drop legacy pipeline files into Read mode and get back an analysis report. No code is generated. The agent tells you:

• What source tables the pipeline references
• What the Epic equivalent is for each one (with confidence scores)
• What transformations are applied (filters, joins, aggregations)
• What flags to watch out for (ambiguous mappings, missing equivalents)
• How complex the conversion will be

When you use this: Day 1 of a migration engagement. Drop all 500 pipelines at once and get a complete inventory — what can be auto-converted, what needs manual review, and how long the project will take. This report alone is worth $50-100K to a health system because it replaces days of manual discovery.

Write Mode — “Build me something new.”

You describe what you need in plain English, and the agent builds it from scratch. You don’t need a source pipeline — just a requirement.

“Build a pipeline that creates a 30-day readmission fact table from Epic Clarity, including patient demographics, admission diagnosis, length of stay, and the department of the index visit.”

The agent figures out which Epic tables to use (PAT_ENC, PAT_ENC_HSP, PROBLEM_LIST, CLARITY_DEP), how to join them, how to calculate length of stay, and how to identify a readmission. It writes the PySpark, the DDL, the tests, and runs everything.

When you use this: Post-migration, when the health system needs new analytics capabilities that didn’t exist in the old system. Instead of scoping a multi-day project, you get working code in minutes.

Bidi Mode — “Convert this end-to-end.”

The full conversion pipeline. Give it a legacy pipeline file, and it does everything: reads, maps, generates code, tests, proves, and pushes to git.

This is the main work mode during a migration sprint. A data engineer feeds 20 pipelines per day through Bidi mode, reviews the output, and merges the pull requests. What used to take the team months now takes days.

When you use this: The daily conversion workflow during a migration project. This is the mode that turns a 14-month project into a days-long project.

Ask Mode — “Answer a question.”

You ask a question about Epic data in plain English, and the agent generates the SQL, runs it, and gives you the answer along with an explanation of which tables it used and why.

“How many diabetic patients had an ER visit in the last 90 days and were readmitted within 30 days?”

The agent knows that “diabetic” means searching PROBLEM_LIST for active diabetes diagnoses. It knows “ER visit” means filtering PAT_ENC by department name (not a dedicated encounter type column). It knows “readmitted” means checking PAT_ENC_HSP for hospital admissions within 30 days. It knows to sort by the decimal _REAL date, not the text date column. It writes a 30-line SQL query that a human analyst would take an hour to construct.

When you use this: Ongoing, forever. Every analyst, every CMIO, every VP of Revenue Cycle can query Epic data without knowing SQL or Epic’s schema. This is the mode that creates recurring SaaS revenue.

What makes Ask mode different from ChatGPT or any generic text-to-SQL tool: A generic LLM would write SELECT * FROM patients WHERE diagnosis = 'diabetes'. That query doesn’t work in Epic. There is no patients table with a diagnosis column.

Our agent knows Epic. It knows the patient table is called PATIENT. Diagnoses are in PROBLEM_LIST (for ongoing conditions) or PAT_ENC_DX (for visit-specific ones). The diagnosis name is in CLARITY_EDG, joined by DX_ID. Active problems have PROBLEM_STATUS_C_NAME = ‘Active’ (text, not a number). And to get the ER department, you join PAT_ENC to CLARITY_DEP on DEPARTMENT_ID and filter by DEPARTMENT_NAME.

This level of Epic-specific knowledge is what separates a toy demo from a real product.

Who This Is For

The Consulting Firm (Cardamom Health)

Cardamom Health is an Epic consulting firm based in Madison, Wisconsin, founded by former Epic employees. They serve 150+ health systems doing Epic optimization, data services, and AI/ML. Their CTO has publicly advocated for agentic AI approaches to healthcare data problems.

Their current model: Charge by the hour. Revenue is linear with headcount. To do more work, they need more consultants. Finding consultants who know both legacy EHRs and Epic is their biggest hiring constraint.

With Clarity Migrate:

• Read mode becomes a product they can sell: a migration assessment for $50-100K, delivered in hours instead of weeks
• Bidi mode makes their existing consultants 10x more productive: they review agent output instead of writing code from scratch
• Ask mode becomes a SaaS product: self-service Epic analytics sold as a monthly subscription to every health system they serve
• Junior consultants become productive in days instead of months — they learn Epic patterns by reviewing agent output

The revenue model shifts from selling hours to selling outcomes.

The Health System CIO

The person who has to deliver the Epic migration on time and on budget.

Their nightmare: Pipeline conversions fall behind schedule. The data team is the bottleneck. Go-live happens with broken dashboards, missing reports, and incorrect quality measures. The board asks why they spent $100M on an EHR that can’t produce a readmission report.

With Clarity Migrate:

• Day 1: Complete pipeline inventory with complexity scores and timeline estimates
• Days 2-5: Automated conversion of 500 pipelines with proof reports
• Go-live: Every pipeline tested, proven, and committed. No surprises.
• Post go-live: Self-service analytics for everyone who needs data

The Clinical Informaticist (CMIO)

The doctor or nurse who bridges clinical practice and IT.

Their frustration: They need data answers but can’t write SQL. Every question is a 3-5 day IT ticket. By the time the answer comes back, the meeting is over, the decision is made, and the data would have changed the outcome.

With Clarity Migrate Ask mode:

• “What’s our 30-day readmission rate for heart failure patients?” → Answer in 10 seconds
• “Which departments have the highest no-show rate?” → Answer in 10 seconds
• “Compare medication count per patient between 2024 and 2025” → Answer in 10 seconds
• Export the SQL, share it with IT for the official dashboard

The VP of Revenue Cycle

The person responsible for making sure the health system gets paid.

Their fear: A broken billing pipeline delays $2M per week in claims. The billing data model is the most complex part of Epic — 35+ tables with no direct link between clinical encounters and billing transactions. The previous migration team missed the ICD-10 code location and the CSN linkage path. It took 3 months to find and fix those bugs.

With Clarity Migrate:

• The billing-expert knowledge file encodes every critical join path and gotcha
• The agent knows ICD-10 codes are in CLM_DX (not CLARITY_EDG)
• The agent knows to bridge through ARPB_VISITS (not try a direct CSN join)
• Proof reports verify billing data before go-live
• Zero revenue leakage on Day 1

The Data Engineer

The person who actually writes the code.

Their reality: They spend 70% of their time on research — looking up Epic table documentation, figuring out which table to use, understanding join patterns — and 30% on actual coding. Epic has 18,000+ tables. The documentation is one table at a time with no cross-referencing. They keep forgetting the rules (is LINE 1 the primary diagnosis? which date column do I sort by?).

With Clarity Migrate:

• Read mode: Drop the XML, immediately see which Epic tables to use
• Write mode: Describe the pipeline, get working code with tests
• The agent applies all the patterns correctly every time — no more forgetting
• Tests are generated automatically — no more skipping them under deadline pressure
• They review and refine instead of writing from scratch
• They learn Epic patterns by reading the agent’s output

The Epic Knowledge Engine

The reason this works is the knowledge layer. It’s not a generic AI writing code. It’s an AI that has been systematically taught the complete Epic data model and the rules that experienced consultants learn over years of practice.

How the knowledge is organized

The schema index. All 6,630 Epic table schemas from Epic’s official documentation site (open.epic.com/EHITables) are loaded into a SQLite database with full-text search. When the agent needs to find a table related to “billing transactions,” it runs one SQL query and gets results in milliseconds. This is critical — without the index, the agent would have to scan 6,630 individual files and would time out before finding anything useful.

The pattern rules. Six rules that govern how Epic stores data differently from every other database. These rules are encoded in a markdown file that the agent reads before generating any code. Every rule includes examples of what’s wrong (the way a generic LLM would do it) and what’s correct (the way an Epic expert does it).

The domain knowledge. Separate files for billing and clinical data that contain the join paths, gotchas, and domain-specific rules that can’t be inferred from the schema alone. For example, the billing file documents that there’s no direct link between clinical encounters and billing transactions — you have to go through a bridge table — and explains why this matters and how to handle it.

The cross-EHR mappings. A file that maps table names from Cerner, Meditech, and Allscripts to their Epic equivalents, with confidence scores. This is what enables the agent to understand a Cerner pipeline and know which Epic tables to use.

Why this can’t be replicated by prompting ChatGPT

You could paste Epic documentation into ChatGPT and ask it to convert a pipeline. Here’s why that doesn’t work:

1. Context window limits. Epic’s documentation is millions of tokens. You can’t fit it all in one prompt. You need a searchable index.

2. Hallucination. Without verified schema data, the LLM will confidently generate table and column names that don’t exist. Our agent searches the actual schema database and only uses verified tables.

3. Pattern application. Knowing that LINE ≠ priority is different from consistently applying that rule across every query in a 150-line PySpark job. Our pattern rules are injected into the agent’s system prompt so they’re applied to every line of generated code.

4. Validation loop. ChatGPT generates code and hopes it works. Our agent generates code, writes tests, runs them, reads the failures, fixes the code, and re-runs until everything passes. This self-correction loop catches the mistakes that slip through on the first attempt.

5. Domain-specific join paths. The CSN-to-billing linkage, the ICD-10 code location, the INPATIENT_DATA_ID misnomer — these are things you only learn from years of Epic experience. We’ve encoded them so the agent knows them from day one.

The Dashboard

The platform includes a web dashboard built on Next.js with a Cloudflare-inspired dark design. It provides a visual interface for all four modes.

Overview. Stats at a glance: 6,630 schemas loaded, 414 tables with data, 5 subagents active. Quick-action cards for each mode. Recent run history with status badges.

Read page. Drag-drop area for pipeline files. Source EHR selector (Cerner, Meditech, Allscripts, Athena). Analyze button. Results show mapping table with confidence scores, flags for ambiguous mappings, and the full agent trace.

Write page. Text input for natural language requirements. Example prompts to get started. Generated file list with line counts. View code button.

Bidi page. File upload plus a stage progress bar (READ → WRITE → TEST → PROVE). Live streaming terminal showing agent activity — which schemas it’s searching, which patterns it’s applying, which files it’s writing. Proof report with row counts and verification status.

Ask page. Text input for plain English questions. Example queries. Big answer display with the SQL that generated it, the tables used, and explanatory notes. Query history.

Runs page. Table of all runs with mode, pipeline name, status, duration, and table count. Filter and sort.

Settings page. Integration cards for Epic Clarity (source), Snowflake (target), PostgreSQL (dev target), GitHub (code push), and AWS Bedrock (LLM). Each card shows connection status, configuration details, and test/edit buttons. Security section showing PHI redaction, audit trail, encryption, and telemetry status.

Security

The platform is designed for HIPAA-covered environments.

What the agent processes: Table names, column names, data types, SQL structures, ETL logic. This is metadata — descriptions of the data structure, not patient data itself.

What the agent never sees: Individual patient records, names, dates of birth, social security numbers, or any other protected health information.

Even so, every precaution is taken:

All text that passes through the system is scrubbed for 18 categories of protected health information before being logged, stored, or sent to the LLM. Social security numbers, medical record numbers, phone numbers, email addresses, dates of birth, IP addresses, patient names, ZIP codes, and account numbers are all redacted automatically.

Every action the agent takes is recorded in an immutable audit log. Each entry includes a timestamp, the action performed, the source and target, and an HMAC signature that makes tampering detectable.

Database credentials are encrypted at rest using industry-standard encryption. In generated code, credentials always come from environment variables — never hardcoded.

The agent binary has been stripped of all telemetry. There are zero outbound network calls except to the AWS Bedrock API (which runs in the customer’s own AWS account under their own HIPAA Business Associate Agreement). No data phones home. No analytics. No tracking.

The container runs as a non-root user with read-only access to source files and write access only to the output workspace.

What We’ve Proven

The test suite

We ran 10 automated tests covering every capability of the platform:

• Schema search: Can the agent find Epic tables related to encounters? To billing? (Passed in 16-44 seconds)
• Pattern knowledge: Does the agent correctly explain LINE joins? _REAL date sorting? (Passed in 23-26 seconds)
• Clinical domain: Can the agent design a readmission query with the right tables and gotchas? (Passed in 52 seconds)
• Billing domain: Does the agent know the CSN-to-billing linkage path? Where ICD-10 codes live? (Passed in 22 seconds)
• Cross-EHR mapping: Can the agent map 5 Cerner tables to Epic with confidence scores? (Passed in 64 seconds)
• Full Read mode: Can the agent analyze a complete Cerner SQL pipeline and produce a mapping report? (Passed in 91 seconds)
• Ask mode (clinical): Can the agent write a 30-line diabetic readmission SQL query using correct Epic patterns? (Passed in 92 seconds)
• Ask mode (billing): Can the agent write an AR aging query? (Timed out at 2 minutes — query was too complex for the time limit, but partial output was correct)

9 out of 10 passed. The one timeout was a limit issue, not a quality issue.

The live conversion

We ran a full Bidi conversion on a real Informatica PowerCenter mapping (m_patient_demographics.xml). The agent:

1. Parsed the XML and identified 2 source tables, 1 target table, and 4 transformations
2. Verified both source tables exist in Epic’s schema index
3. Applied Epic conventions (text category values for gender, date arithmetic for age)
4. Generated a 148-line PySpark job with JDBC connectivity, filtering, expressions, and a provider lookup join
5. Generated a CREATE TABLE with primary key and indexes
6. Generated 26 automated tests covering compilation, table names, credential safety, and transformation logic
7. Ran all 26 tests — all passed
8. Produced a conversion report with full traceability, including a flag that one column (SPECIALTY) doesn’t appear in Epic’s schema index

Total time: approximately 3 minutes.

This is a pipeline that would take a consultant 2-3 days.

The Business Opportunity

The market

• 40% of hospital IT leaders are planning EHR migration projects in 2026
• Epic is the dominant destination — they hold 38% of the US hospital market and growing
• Each migration involves 200-1,000+ data pipelines that must be converted
• The data migration component typically costs $10-20M in professional services

The math

Even if we’re conservative and assume the agent handles 60% of pipelines fully automatically and 40% need human review, the project drops from 18 months to days and the cost drops by 80%.

The revenue model

Read and Bidi are project revenue. Ask is recurring revenue. The platform serves both models.

The competitive advantage

Nobody else has this combination:

1. A headless, HIPAA-hardened autonomous agent
2. An indexed knowledge base of Epic’s complete schema catalog
3. Domain-specific rules for billing and clinical data
4. Cross-EHR mapping tables with confidence scoring
5. A prove-then-push validation loop
6. All four modes (Read, Write, Bidi, Ask) on the same knowledge layer

Generic text-to-SQL tools don’t know Epic. Epic consultants don’t have agents. We have both.

There are three approaches to data migration when modernizing healthcare systems. The choice depends on how the system is used and the organization’s priorities. In healthcare, these map to risk tiers — not just technical approaches.

Why Healthcare is Different

Healthcare isn’t “move data from A to B.” It’s a regulated, high-stakes environment where:

• A broken report can delay a CMS submission — financial penalties
• A bad data write can surface wrong info in a clinical workflow — patient safety risk
• Any data movement touching PHI needs audit trails — HIPAA compliance
• Epic changes the Clarity schema with every upgrade — moving target

Strategy 1: Reader-First Migration

What it means

Migrate everything that reads from Epic Clarity/Caboodle — reports, dashboards, quality measures, analytics queries. These are read-only operations that present data to analysts, clinicians, and executives.

Why hospitals start here

• No risk to patient data integrity (read-only, nothing writes back)
• Immediate, visible ROI (reports run 10x faster on Snowflake)
• Regulatory reports (HEDIS, CMS Stars, meaningful use) modernize without touching clinical workflows
• Analysts can self-serve instead of waiting in the Crystal Reports queue

How it works in Clarity

Sarah (Data Architect) logs into Clarity.

She goes to Migrate, creates a new migration, and connects the GitHub repo where Informatica XMLs are stored. She picks “Reader-First” strategy.

The agent runs. 10 minutes later she has:

• 41 PySpark jobs generated
• 41 DDL files for Snowflake tables
• 738 tests, all green
• A conversion report showing every Informatica expression mapped to PySpark

She clicks into the completed job and sees the lineage map — every source table flowing through transformations into target tables. She screenshots this for the steering committee deck.

She shares the lineage map link with James (the consultant). He opens it, sees the full picture, and flags that 3 mappings reference a deprecated table (PAT_ENC_HSP) that was merged into PAT_ENC in Clarity 23.1. The agent already flagged this in the conversion report.

What the agent generates

For each Informatica XML mapping, the agent produces:

• A PySpark job that reads from MySQL (Epic Clarity), applies the same transformations, and writes to Snowflake
• A Snowflake DDL file (CREATE TABLE with correct types)
• Automated tests validating the conversion
• A conversion report with lineage, patterns used, and test results

Supported source formats

• Informatica PowerCenter XML (available today)
• Crystal Reports .rpt (planned)
• SSRS .rdl (planned)
• Business Objects .rep/.biar (planned)

Strategy 2: Bi-Directional Migration

What it means

During the transition period (which can be 6-18 months for a hospital), both old and new systems run in parallel. Data must stay consistent across both.

Why this matters in healthcare

• Hospitals do phased rollouts — department by department, not big-bang
• During transition, some reports read from Clarity, some from Snowflake
• Financial data reconciliation is legally required (SOX-equivalent for hospital finance)
• If a regulatory report runs in both systems and produces different numbers — that’s an audit finding

How it works in Clarity

Month 3-6: Phased Rollout

The team decides to roll out department by department. Cardiology goes first.

Sarah goes to the Go-Live Readiness dashboard. It shows:

• Cardiology: 12 reports migrated, all validated, 3 signed off by Dr. Chen, 9 pending sign-off
• Emergency Dept: 8 reports migrated, 6 validated, 2 have data drift warnings
• Internal Medicine: not started

She sets Cardiology to dual-write mode. Now every night, the PySpark jobs write to BOTH the old MySQL staging tables (so legacy Crystal Reports still work) AND the new Snowflake tables (so the new dashboards work).

The Data Drift Monitor runs every 6 hours. On day 3, it flags that FACT_ENCOUNTER in Snowflake has 12 more rows than MySQL. She investigates — a late-arriving encounter got picked up by the Snowflake incremental load but the Informatica job hasn’t run yet. Not a real issue. She marks it “expected” and the drift monitor learns to ignore timing gaps under 24 hours.

After 2 weeks of dual-write with zero drift, the Cardiology director signs off. Sarah flips Cardiology to Snowflake-only mode. The old Crystal Reports for that department get decommissioned.

She repeats for each department. The go-live dashboard shows progress ticking up from 15% to 40% to 78% to 100% over 4 months.

Key capabilities

• Dual-write mode: Generated PySpark jobs write to both MySQL staging and Snowflake simultaneously
• Data drift monitor: Scheduled checks that compare row counts, checksums, and aggregates between source and target. Alerts when systems diverge beyond a configurable threshold.
• Go-live readiness dashboard: Visual status of which departments/reports are migrated, validated, and signed off
• Rollback: If Snowflake target diverges, auto-generated recovery scripts restore from source of truth

Strategy 3: Writer-First Migration

What it means

Migrate ETL pipelines that write data — data entry feeds, lab result ingestion, claims submissions, clinical registry updates. These are write operations that push data into clinical and financial systems.

Why this is the highest risk

• Writing to Epic requires Epic-approved integration methods (Bridges, Open.Epic, Interconnect, FHIR APIs)
• Every write path needs HL7/FHIR compliance for interoperability
• PHI writes need audit trails (HIPAA §164.312)
• Wrong data written to a patient chart is a patient safety event
• Wrong data written to billing is a fraud risk (False Claims Act)

How it works in Clarity

Month 6-9: Write Path Migration

Once the read path is fully migrated, the team tackles the write path.

They have an Informatica workflow that ingests lab results from an external lab vendor, transforms them, and writes to Epic via HL7 Bridge. This is a clinical write path — if it breaks, lab results don’t show up in Epic and clinicians don’t see them.

Sarah goes to Migrate and selects “Writer-First” strategy.

The agent flags this as high risk because:

• It writes to a clinical system (patient-facing)
• It contains PHI (PAT_ID, RESULT_VALUE)
• The target is an Epic API, not a database table

The generated PySpark job includes:

• FHIR resource mapping (lab result to FHIR R4 Observation)
• An audit trail for every record written
• A sandbox validation step that runs against Epic’s test environment first
• A rollback script that can reverse the last batch if something goes wrong

Before this goes to production, it goes through an approval workflow:

1. The data architect reviews the generated code
2. The Epic analyst validates the FHIR mapping
3. The compliance officer confirms the PHI handling
4. The clinical informatics director signs off

Each approval is tracked in the migration timeline.

Key capabilities

• FHIR pipeline generation: Convert legacy HL7v2 feeds to FHIR R4 bundles
• CDC pattern detection: Identify incremental load patterns in Informatica and convert to streaming/micro-batch PySpark with MERGE statements
• Write-back validation sandbox: Run converted write pipelines against Epic’s test environment before production
• Audit trail generation: Every record written is logged with timestamp, user, target system, and PHI columns touched

Cross-Cutting: Reconciliation

The #1 question from every CFO and CMO

“How do we know the numbers match?”

Every migration — regardless of strategy — needs validation. After each migration job completes, Clarity auto-generates reconciliation checks.

How it works

Sarah runs a migration against staging Snowflake. The jobs complete. She goes to the Validation tab in the job detail view.

The reconciliation report shows every table side by side:

• DIM_PATIENT: 48,231 rows in source, 48,231 in target. Checksums match. Green.
• FACT_ENCOUNTER: 312,445 rows in source, 312,402 in target. 43 rows missing. Yellow warning.

She clicks “View Diff” on FACT_ENCOUNTER. Clarity shows her the 43 rows that exist in source but not target. They’re all encounters with APPT_STATUS_C = 6 (canceled but with a specific sub-status). The Informatica filter was APPT_STATUS_C IN (2,6) but the agent converted it as APPT_STATUS_C = 2. She edits the PySpark job, re-runs, and now it’s green across the board.

Without reconciliation, this would have gone to production with 43 missing encounters. In revenue cycle, that’s potentially $43K+ in unbilled charges.

What gets compared

Cross-Cutting: PHI Detection

HIPAA compliance, built in

Every migration job gets a PHI scan before it runs. The agent detects columns that contain Protected Health Information based on the HIPAA Safe Harbor standard (18 identifier types).

How it works

When Sarah creates a new migration, the first thing she sees is:

“This migration involves 8 high-risk PHI columns including PAT_FIRST_NAME, PAT_MRN_ID, and BIRTH_DATE. Snowflake column-level masking policies are recommended before granting analyst access.”

The lineage map shows PHI columns with a red shield icon. The reconciliation report includes a PHI section confirming that PHI columns in the target have encryption-at-rest and masking policies applied.

When she shares the migration report with the compliance team, they can see exactly which PHI flows where — without needing to read any code.

PHI classification

Application Features Summary

The Thread Connecting Everything

Trust.

Hospitals won’t migrate to Snowflake unless they trust the data is correct, the PHI is protected, and they can roll back if something goes wrong. Every feature above is a trust signal.

• Reconciliation says: “The numbers match. Here’s proof.”
• PHI detection says: “We know where patient data flows. It’s protected.”
• Dual-write says: “You can run both systems until you’re confident.”
• Go-live readiness says: “Here’s exactly where you are in the program.”
• Rollback says: “If something goes wrong, we can undo it.”

The technology is table stakes. The trust is the product.

Quick Orientation

 The insight: Clarity’s complexity — 30,000 tables, ZC_ join dependencies, continuation tables — is the moat. Whoever builds schema intelligence on top of it first wins. The difficulty is the feature.

Critical Constraints — Read Before Building

 These are not edge cases. Every one surfaces in the first month.

• T-1 freshness — All data is one day old. Agents must surface data-as-of timestamps on every output. Never use Clarity for real-time operational decisions.
• Date format — Dates stored as days since 12/31/1840 in _REAL columns (MUMPS heritage). All time-series logic requires conversion before use.
• ZC_ dependency — Every categorical field (gender, race, order status, encounter type) is a numeric code requiring a JOIN ZC_* for human-readable output. LLM-generated SQL that skips this produces unreadable garbage.
• Continuation tables — PATIENT, PATIENT_2, PATIENT_3 are one logical record. Same for CLARITY_SER, ORDER_MED, others. Querying only the base table silently loses data.
• LINE column pattern — One-to-many relationships use a LINE column (MUMPS inheritance). Appears in medications, flowsheets, diagnoses, charge lines. Agents that ignore this produce row-multiplied aggregations.
• 30K table surface — RAG over the data dictionary is the only viable architecture. No LLM can navigate this at context scale. Build schema retrieval before writing any agent logic.
• Multi-tenant schema variation — Health systems customize their Clarity schemas. An agent built against one instance will silently fail against another. Tenant-aware schema isolation is the core technical moat.

Domain Map — 12 Subject Areas

01 · Patient Identity & Demographics

Key Tables: PATIENT · PATIENT_2 · PATIENT_3

Fields & Subtypes

Agent Use Cases

• Identity resolution and deduplication across source systems
• SDOH risk stratification using zip-level poverty index and language barriers
• Patient cohort builder for population health programs
• Outreach eligibility filtering by demographics and payer

02 · Encounters & Visits

Key Tables: PAT_ENC · PAT_ENC_2 · PAT_ENC_DX · HSP_ACCOUNT

Fields & Subtypes

Agent Use Cases

• Readmission prediction via encounter sequence modeling
• Care pathway anomaly detection across patient timelines
• No-show and cancellation propensity scoring
• ED-to-inpatient conversion analysis
• LOS benchmarking against cohort and DRG norms

03 · Clinical Documentation

Key Tables: PROBLEM_LIST · ALLERGY · IP_FLWSHT_REC · HNO_NOTE_TEXT · PAT_ENC_DX

Fields & Subtypes

 HNO_NOTE_TEXT is the highest-value unstructured table in Clarity. This is where the clinical story lives. Every NLP use case runs through here.

Agent Use Cases

• NLP / LLM extraction from note text — chief complaint, HPI, assessment, plan
• Diagnosis coding accuracy audit — ICD vs. free-text alignment
• Clinical decision support triggers from flowsheet deviations
• Automated prior auth documentation generation
• Allergy-drug interaction alerting

04 · Orders & Medications

Key Tables: ORDER_PROC · ORDER_MED · MAR_ADMIN_DOSES · RX_PHR_ORDER

Fields & Subtypes

Agent Use Cases

• Polypharmacy risk detection across multi-drug regimens
• Medication adherence inference from refill gap analysis
• Order set optimization — co-ordered items correlated against outcomes
• High-cost drug utilization monitoring
• Formulary compliance enforcement and alerting

05 · Labs & Results

Key Tables: ORDER_RESULTS · LNS_RESULT · LNS_SPECIMEN · CLARITY_COMPONENT

Fields & Subtypes

Agent Use Cases

• Trend-based early warning from deteriorating lab trajectories over time
• Sepsis, AKI, and deterioration alerting from multi-lab sequences
• Critical value notification gap detection
• Lab utilization and redundancy reduction by ordering pattern
• Research cohort identification by lab phenotype

06 · Imaging & Radiology

Key Tables: ORDER_PROC (rad) · RAD_EXAM · CLARITY_PROC · Cupid (cardiology)

Fields & Subtypes

Agent Use Cases

• LLM extraction from radiology report text — incidental finding triage
• Imaging appropriateness scoring against clinical guidelines
• Repeat imaging detection and cost flagging
• Order-to-read turnaround time SLA monitoring

07 · Scheduling & Access

Key Tables: PAT_ENC (appt view) · CLARITY_DEP · CLARITY_SER_DEPT

Fields & Subtypes

Agent Use Cases

• Intelligent slot fill and open access optimization
• No-show prediction driving proactive outreach
• Referral leakage detection — did the patient follow through?
• Access equity analysis by zip code, race, and payer
• Demand forecasting for capacity planning by service line

08 · Billing & Revenue Cycle

Key Tables: HSP_ACCOUNT · ARPB_TRANSACTIONS · CLARITY_EDI · COVERAGE · ACCOUNT

Fields & Subtypes

Agent Use Cases

• Denial prediction before claim submission — intercept at charge entry
• Undercoding / upcoding audit — ICD vs. charges alignment
• Prior authorization automation from clinical documentation
• Revenue leakage detection — charges not dropped post-procedure
• Payer contract performance analysis and renegotiation intelligence

09 · Operational & Capacity

Key Tables: ADT_ARRIVAL · ADT_DAYS · OT_CASE_RECORD · BED_CENSUS

Fields & Subtypes

Agent Use Cases

• Real-time bed demand prediction and proactive discharge planning
• OR block utilization optimization — recover unused time
• LOS outlier detection triggering case management workflow
• Patient flow bottleneck analysis — ED through inpatient
• Staffing demand-supply mismatch alerting by unit and shift

10 · Providers & Workforce

Key Tables: CLARITY_SER · CLARITY_SER_2 · CLARITY_EMP · SER_DEPT_ATTND

Fields & Subtypes

Agent Use Cases

• Provider performance benchmarking across outcomes, utilization, and coding
• Referral pattern analysis and out-of-network leakage detection
• Care team attribution for value-based contract performance
• Clinical variation analysis by provider and service line
• Burnout proxy signals from documentation burden and after-hours login patterns

11 · Population Health & Quality

Key Tables: REGISTRY_PATIENT · QM_RESULT · CARE_PLAN · HEALTHY_PLANET_*

Fields & Subtypes

Agent Use Cases

• Automated care gap closure via outreach agent
• Risk stratification driving proactive intervention prioritization
• Quality measure trajectory forecasting for month-end performance
• SDOH-adjusted outcome benchmarking for equity reporting
• Value-based contract P&L attribution by attributed population

12 · System & Configuration (Foundation Layer)

Key Tables: ZC_* (all category master files) · CLARITY_DEP · CLARITY_POS

Fields & Subtypes

 Every domain query depends on this layer. ZC_ joins are a precondition for human-readable output across all 11 other domains. Build the ZC_ resolver before writing any agent logic.

Agent Use Cases

• Schema-aware SQL generation — LLM grounding on ZC_ maps is mandatory
• Data dictionary embedding for RAG-based analytics assistant
• Role-based query scoping in the agent access control layer
• Cross-domain lineage mapping for compliance audit trails

Agent Architecture — How the Layer Stacks

USER / WORKFLOW TRIGGER
Natural language query  ·  scheduled job  ·  API event  ·  alert threshold

        ↓

[ 01 ]  ORCHESTRATION LAYER
        Intent classification
        Domain router  →  selects one of 12 Clarity domains
        ReAct planning loop  →  multi-step decomposition
        Memory / state management across turns

        ↓                              ↓

[ 02a ]  NLP / LLM MODULE         [ 02b ]  SQL GENERATION MODULE
         Free-text extraction               Schema RAG over data dictionary
         HNO_NOTE_TEXT parsing             ZC_ map grounding (mandatory)
         Summarisation                      Domain-scoped query builder
         Structured field population        Query validation + explain plan

                    ↓                    ↓

        [ 03 ]  CLARITY DATABASE LAYER
                ~30,000 SQL tables  ·  12 domains
                Nightly ETL  ·  T-1 freshness
                Domain-scoped views recommended over raw tables

                            ↓

                [ 04 ]  OUTPUT LAYER
                        Insight cards  ·  alerts  ·  triggers
                        Draft documents (prior auth, appeal letters)
                        Downstream API calls (RCM system, payer portal, care management)
                        Data-as-of timestamp on every output  ←  non-negotiable

 The domain router is the most consequential design decision. Intent misclassification routes a billing query to clinical tables and produces numerically plausible wrong answers — which is worse than an obvious error. The router must be purpose-built, not a general-purpose prompt.

High-Value Wedges — VC / PE Lens

Ranked by combined score: willingness to pay + time-to-ROI + structural moat.

Architecture Decisions to Lock Early

These five decisions have the highest cost if deferred. Each becomes exponentially harder to change once agent logic is built on top of it.

01 · Schema Retrieval Strategy

Vector store over the Clarity data dictionary is the only viable architecture at 30,000 tables. The embedding corpus must include table names, column names, descriptions, ZC_ join dependencies, and sample values. Build this before writing a single agent. Everything else depends on it.

02 · Domain Router Design

Fine-tune a small classifier on domain-labeled Clarity queries. Do not rely on a general LLM’s prompt-following for routing. Routing errors produce plausible wrong answers with no visible error signal — the worst failure mode in an analytics agent.

03 · ZC_ Grounding Layer

Build a static ZC_ resolver that maps every categorical field to its human-readable lookup at query construction time. Bake it into the SQL generation layer as a mandatory post-processing step. Without it, every categorical output is a numeric code that users cannot interpret.

04 · Data Freshness Contract

Every agent output must carry a data_as_of timestamp. Build this into the output schema from day one — not as a UI afterthought. Clinical users who do not understand T-1 lag will use agent outputs in operational contexts where stale data causes patient harm.

05 · Multi-Tenant Schema Isolation

Design the vector store and SQL generation module to be tenant-aware from the start. Health systems customize their Clarity schemas. An agent built against one instance silently fails against another. This is your core technical moat if you scale across health systems — and your deepest risk if you ignore it.

Epic Clarity — Agentic AI Layer · Internal Brainstorm · Confidential

frameworks · templates · 20 starter experiments

Growth Experimentation AARRR Metrics ICE Framework MBA Intern Playbook

Growth isn’t magic. It isn’t “going viral.” It isn’t hiring a growth hacker who sprinkles fairy dust on your funnel. Growth is a systematic process: form a hypothesis, design an experiment, run it, measure the result, learn something, and repeat. The teams that grow fastest are the ones that run the most experiments — because each experiment, win or lose, compounds into knowledge about your customers that competitors don’t have.

This playbook gives you the system: how to prioritize experiments, how to design them properly, a tracker to log everything, and 20 starter ideas organized by funnel stage so you can begin running experiments this week.

Who this is for: MBA interns running growth experiments, product managers building experiment culture, founders who want a structured approach to growth, and anyone tired of guessing what will move the needle.

Part I

The Experiment Mindset

Before you run a single experiment, you need to understand why experimentation matters and how to decide which experiments to run first. Most teams have more ideas than capacity — the framework for prioritization matters more than the ideas themselves.

01 Why Experiments

Every successful growth team operates on a simple belief: opinions are cheap, data is expensive, and only experiments produce data.

The math is compelling:

Most experiments fail. That’s the point. A 20% win rate is excellent. If you’re winning more than 30% of your experiments, you’re not being ambitious enough — you’re testing things you already know will work.

The compound effect is what matters. Each winning experiment makes every future visitor, user, or customer slightly more valuable. Over a year, a team running 5 experiments per week with a 20% win rate and 5% average lift per win will more than double their core metric. That’s not theory — that’s math.

The Alternative: Guessing

Without experiments, growth decisions look like this:

• The CEO says “our homepage needs a redesign” because they’re tired of looking at it.
• The PM says “let’s add a free tier” because a competitor did.
• The marketing lead says “let’s try TikTok” because they read a blog post.

These might all be good ideas. They might all be terrible. Without experiments, you’ll never know which. And you’ll spend 3 months on a homepage redesign that turns out to decrease conversion by 8%, but nobody will know because nobody measured it.

The cost of not experimenting: A homepage redesign takes 3 months and costs $50K in design + engineering time. An experiment to test the new headline takes 3 days and costs nothing. If the headline test shows a 15% lift, you know the redesign direction is right. If it shows no lift, you just saved $50K and 3 months.

02 The ICE Framework

You’ll always have more experiment ideas than capacity to run them. The ICE framework helps you prioritize ruthlessly.

ICE Score = Impact × Confidence × Ease

Higher score = do it first. Simple as that.

Worked Examples

The scoring trap: Everyone inflates Impact and deflates Ease. Be honest. If you’ve never tested headlines before, your Confidence should be 4, not 8. If the change requires backend work, Ease is a 4, not a 7. Dishonest scoring defeats the purpose of the framework.

Common mistake: Scoring by committee. ICE works best when one person scores and the group challenges. Group scoring regresses to the mean — everything becomes a 5, and you’ve learned nothing about priorities.

Part II

The Experiment Framework

A good experiment has a clear hypothesis, a defined category, and a proper design. Most failed experiments fail because they were poorly designed, not because the idea was bad.

03 Hypothesis Format

Every experiment starts with a hypothesis. Not “let’s try changing the button color” — that’s a task, not a hypothesis. A hypothesis is a falsifiable prediction about cause and effect.

The Template

We believe that [change] will cause [effect] for [segment], which we’ll measure by [metric] over [timeframe]. We’ll consider this successful if [threshold].

Good vs Bad Hypotheses

BAD

“Let’s test a new onboarding flow.”

No prediction. No metric. No success criteria. You’ll learn nothing.

GOOD

“We believe that replacing the 7-step onboarding wizard with a 3-step quick-start will cause higher activation rates for new free trial users, measured by % of users who complete core action within 24 hours over 3 weeks. Success = activation rate increases from 34% to 42%+.”

Specific change. Named segment. Defined metric. Clear timeframe. Quantified threshold.

More Examples

04 Experiment Categories — The AARRR Framework

Dave McClure’s pirate metrics framework gives you five categories to organize experiments. Every experiment should map to exactly one stage.

Where to start: Most teams over-invest in Acquisition and under-invest in Activation and Retention. A 10% improvement in Activation has the same revenue impact as a 10% increase in traffic — but it’s usually 5x cheaper to achieve. Fix your leaky bucket before pouring more water in.

The Funnel Math

Here’s why Activation and Retention experiments often have the highest ROI:

Scenario A: Improve Acquisition by 20%
10,000 visitors → 12,000 visitors → 1,200 signups → 408 activated → 204 paying → $204K MRR

Scenario B: Improve Activation by 20% (same traffic)
10,000 visitors → 10,000 visitors → 1,000 signups → 408 activated → 204 paying → $204K MRR

Same result. But Scenario B cost $0 in ad spend.

05 Experiment Design

A poorly designed experiment is worse than no experiment. It gives you false confidence in a wrong conclusion. Here’s how to design experiments that produce real learnings.

Control vs Variant

Sample Size — When Is n Big Enough?

You don’t need to be a statistician. But you do need to know the basics:

Based on 95% confidence level and 80% statistical power. Use an online calculator (Evan Miller’s is the best free one) for your specific numbers.

Duration Rules

• Minimum 2 weeks for B2B. B2B traffic has weekly cycles (Mon–Fri vs weekends). Running for less than 2 weeks means you’re comparing weekdays to weekends.
• Minimum 1 full business cycle. If your customers have a monthly billing cycle, run for at least one full cycle.
• Don’t peek. Checking results daily and stopping when it “looks good” is the fastest way to get a false positive. Set the duration upfront and don’t stop early.
• Never stop on a Friday. Weekend traffic behaves differently. End experiments on the same day of the week you started.

The “peeking” problem: If you check your experiment every day and plan to stop when it reaches significance, there’s a 26% chance of a false positive (instead of 5%). This is called the “multiple comparisons” problem. Decide your sample size upfront, run until you hit it, then analyze. One look. One decision.

What to Measure

Guardrail metrics matter: You could increase signup rate by 50% by removing all form fields — but activation would plummet because you’re now getting unqualified signups. Guardrail metrics prevent you from optimizing one metric at the expense of another.

Part III

The Tracker

A growth program without a tracker is just a collection of random acts. The tracker is the institutional memory of your growth team — it prevents you from re-running failed experiments, helps you build on past wins, and creates a playbook that survives team turnover.

06 Experiment Log Template

Copy this table into a spreadsheet. Every experiment gets a row. No exceptions. Even failed experiments. Especially failed experiments.

Example: A Completed Experiment Log Entry

GE-042 · Acquisition · ICE: 378 · WINNER

Hypothesis: Switching homepage headline from “The Modern Data Platform” to “Build Data Pipelines 80% Faster” will increase demo requests from 2.1% to 2.8%+ among direct traffic over 2 weeks.

Duration: Apr 14 – Apr 28 (14 days)
Sample: 4,218 visitors per variant (8,436 total)
Baseline (control): 2.1% demo request rate
Result (variant): 2.9% demo request rate
Lift: +38% (p=0.02, statistically significant)
Guardrails: Bounce rate unchanged. Avg time on page +4 seconds. No negative impact on trial signups.

Learning: Outcome-focused headlines significantly outperform feature-focused ones for direct traffic. The effect was stronger on mobile (44% lift) vs desktop (31% lift). Visitors who saw the outcome headline also explored 1.3 more pages on average.

Next action: Ship variant to 100%. Run follow-up experiment testing different outcome claims (“80% faster” vs “save 20 hours/week” vs “ship in days, not months”).

07 20 Starter Experiment Ideas

These are proven experiments that work across B2B SaaS companies. Adapt them to your product. Each one includes the hypothesis framing so you can drop it straight into your tracker.

Acquisition (Top of Funnel)

1. Homepage Headline Test

Ease: 9 · Typical lift: 10–40% · Duration: 2 weeks

Test your current headline against an outcome-focused alternative. “The all-in-one platform for X” vs “Reduce X time by 60%.” Almost always, specific outcomes beat vague feature descriptions.

1. Pricing Page Layout

Ease: 7 · Typical lift: 5–20% · Duration: 3 weeks

Test 3 tiers vs 2 tiers. Test highlighting the middle tier as “most popular.” Test showing annual pricing by default vs monthly. The pricing page is usually the second-highest-leverage page after the homepage.

1. SEO Content Cluster

Ease: 5 · Typical lift: 50–200% organic traffic · Duration: 8–12 weeks

Publish 8–12 articles around one keyword cluster (e.g., “data pipeline” + long-tail variations). Interlink them. Measure organic traffic growth to the cluster after 8 weeks. This is a slower experiment but often has the highest long-term ROI.

1. LinkedIn Ad Creative Test

Ease: 8 · Typical lift: 15–50% CTR · Duration: 2 weeks

Test 4 ad creatives simultaneously: (A) customer quote, (B) data/stat, (C) pain-point question, (D) product screenshot. Almost always, customer quotes and pain-point questions outperform product screenshots.

1. Referral Landing Page

Ease: 6 · Typical lift: 20–40% referral conversion · Duration: 3 weeks

Create a dedicated landing page for referred visitors (different from homepage). Include the referrer’s name, a tailored value prop, and a simplified signup flow. Referred visitors convert at 3–5x the rate of cold traffic when the landing page matches the referral context.

Activation (Onboarding & Aha Moment)

1. Onboarding Flow Simplification

Ease: 5 · Typical lift: 15–30% completion · Duration: 3 weeks

Cut your onboarding from N steps to N/2 steps. Move non-essential setup to post-activation. The fastest path to the “aha moment” wins. Every additional step loses 10–20% of users.

1. Time-to-Value Reduction

Ease: 4 · Typical lift: 20–50% activation · Duration: 4 weeks

Pre-populate the product with sample data so users see value before doing any work. Figma does this with starter templates. Notion does this with pre-built pages. The first moment of “oh, this is useful” needs to happen in minutes, not days.

1. Checklist vs Guided Tour

Ease: 6 · Typical lift: 10–25% completion · Duration: 2 weeks

Test a static checklist (“Set up your first project, Invite a teammate, Create a dashboard”) vs an interactive guided tour that walks them through each step. Some users prefer autonomy (checklist). Some prefer hand-holding (tour). Test which wins for your audience.

1. In-App Tooltip Sequence

Ease: 7 · Typical lift: 10–20% feature discovery · Duration: 2 weeks

After the user completes onboarding, show 3–5 contextual tooltips highlighting features they haven’t discovered yet. Trigger them based on behavior, not time. “You created a project — did you know you can automate reports?” beats a random tooltip on day 3.

Revenue (Pricing & Upsell)

1. Price Increase Test

Ease: 8 · Typical lift: 10–30% ARPU · Duration: 4 weeks

Show new visitors a price that’s 20% higher than current pricing. If conversion drops by less than 20%, you’ve increased revenue. Most B2B SaaS is underpriced. A 20% price increase with a 5% conversion drop = 14% more revenue.

1. Annual Billing Default

Ease: 9 · Typical lift: 15–40% annual plan selection · Duration: 2 weeks

Default the pricing toggle to annual instead of monthly. Show the monthly price crossed out with the annual price highlighted. Annual billing improves cash flow, reduces churn (customers commit for a year), and increases LTV.

1. Upsell Trigger Email

Ease: 7 · Typical lift: 5–15% upsell rate · Duration: 4 weeks

Send an automated email when a user hits 80% of their plan limit (seats, API calls, storage). “You’re at 80% of your limit. Upgrade now and get 20% off your first month of Pro.” Timing is everything — send it when the pain is real.

1. Feature Gating Experiment

Ease: 5 · Typical lift: 10–25% upgrade rate · Duration: 4 weeks

Take a popular feature currently available on the free tier and gate it behind the paid plan. Measure: does upgrade rate increase more than free-tier churn increases? If yes, the feature was undervalued and should be gated permanently.

Retention (Churn Reduction)

1. Health Score Alerts

Ease: 5 · Typical lift: 10–20% churn reduction · Duration: 6 weeks

Build a simple health score based on login frequency, feature usage, and support tickets. When a customer’s score drops below threshold, auto-assign them to a CSM for proactive outreach. Most churn is predictable 30–60 days in advance.

1. Re-engagement Campaign

Ease: 7 · Typical lift: 5–15% reactivation · Duration: 3 weeks

For users who haven’t logged in for 14+ days, send a 3-email sequence: (1) “Here’s what you missed” with new feature highlights, (2) “Your teammates are active” with social proof, (3) “Can we help?” with an offer for a 1:1 walkthrough.

1. QBR Cadence Change

Ease: 6 · Typical lift: 10–20% renewal rate · Duration: 8 weeks

Switch from quarterly business reviews to monthly 15-minute check-ins. Shorter, more frequent touchpoints catch problems earlier and keep the relationship warm. Test on half your accounts and measure renewal rate vs control.

1. NPS Follow-Up Automation

Ease: 7 · Typical lift: variable · Duration: 4 weeks

When someone gives an NPS score of 0–6 (detractor), auto-trigger a personal email from the CEO within 1 hour asking what’s wrong. When someone gives 9–10 (promoter), auto-ask for a G2 review or referral. Most companies collect NPS and do nothing with it.

Referral (Viral Loops)

1. Invite Incentive Test

Ease: 6 · Typical lift: 30–80% referral rate · Duration: 4 weeks

Test three referral incentives: (A) $25 credit for both parties, (B) 1 month free for both, (C) exclusive feature unlock. Double-sided incentives (both giver and receiver benefit) consistently outperform one-sided. Test the format, not just the amount.

1. Sharing Mechanics

Ease: 7 · Typical lift: 15–40% share rate · Duration: 3 weeks

Add share prompts at moments of success: after completing a project, after hitting a milestone, after generating a report. The prompt should pre-fill a message like “I just used [product] to [outcome] — worth checking out.” Make sharing effortless.

1. Partner Referral Program

Ease: 4 · Typical lift: new channel entirely · Duration: 8 weeks

Recruit 10 partners (consultants, agencies, complementary tools) and give them a custom referral link with a 15–20% revenue share for the first year. Track which partners send qualified leads vs noise. Double down on the top 3.

How to use this list: Score each experiment using ICE for your specific situation. A price increase test might be high-impact for an underpriced product but irrelevant for one with price-sensitive customers. Context matters more than the idea itself.

Part IV

Running the Program

Ideas and frameworks are worthless without execution. This part covers the weekly cadence, how to build a culture of experimentation, and the hardest decision in growth: when to scale a winner vs kill a loser.

08 The Weekly Growth Meeting

30 minutes. Every week. Same time. Non-negotiable. This meeting is the heartbeat of your growth program.

The Agenda (30 Minutes)

The rules of the growth meeting: (1) Everyone comes prepared — read the results before the meeting. (2) Decisions are final — don’t relitigate last week’s decisions. (3) No experiment launches without a written hypothesis. (4) The meeting ends at 30 minutes, period. If you need more time, something is broken.

Who Attends

• Required: Growth lead (runs the meeting), PM, 1 engineer, 1 designer, 1 marketer.
• Optional: Data analyst (for statistical questions), sales rep (for qualitative input).
• Never: More than 8 people. Growth meetings die when they become status updates for leadership.

09 Building a Growth Culture

The difference between a team that runs 2 experiments/week and one that runs 10 isn’t headcount or budget. It’s culture. Here’s how to build it.

The Five Principles

1. Document Everything

Every experiment goes in the tracker. Every result gets a written analysis. Every learning gets tagged and searchable. In 12 months, you’ll have 200+ experiments worth of institutional knowledge. New team members can read the log and understand what works in days, not months.

2. Celebrate Learnings, Not Just Wins

A failed experiment that teaches you something is more valuable than a successful experiment you can’t explain. When an experiment fails:

• Don’t hide it. Share it in Slack. “GE-047 failed: outcome-focused CTAs don’t work for enterprise prospects. They prefer specificity (‘see how Acme saved $1.2M’) over generality (‘save 40%’).”
• Ask “what did we learn?” not “why did it fail?”
• Update your mental model. Failure + learning = progress. Failure + silence = waste.

The most dangerous outcome of an experiment is not failure. It’s success you can’t explain. If you don’t know WHY something worked, you can’t replicate it, scale it, or build on it. Always understand the “why.”

3. Lower the Bar for Launching

If an experiment requires a design review, a product spec, a legal review, and a VP sign-off, you’ll run 2 experiments per month instead of 10 per week. Most experiments are low-risk (copy changes, email sequences, landing page variants). Create a fast lane:

4. Build a Growth Playbook

After 6 months of experiments, you’ll notice patterns. Document them:

• “Outcome-focused headlines beat feature-focused headlines 80% of the time (n=12 experiments).”
• “Re-engagement emails work best when sent at Day 14, not Day 7 (n=4 experiments).”
• “Annual billing defaults increase annual plan selection by 20–35% with no measurable drop in total signups (n=3 experiments).”

This playbook is your competitive advantage. It’s knowledge that took months and thousands of dollars of experiment time to build. Competitors don’t have it.

5. Make Data Accessible

If only the data analyst can check experiment results, you’ve created a bottleneck. Set up dashboards that anyone on the growth team can check. The tools don’t matter (Amplitude, Mixpanel, even a Google Sheet that auto-updates). What matters is that any team member can answer “how is GE-042 performing?” in 30 seconds.

10 When to Scale vs Kill

Every completed experiment leads to one of three decisions: scale it, kill it, or iterate on it. This is where most teams get stuck — they don’t have clear criteria, so winning experiments sit in limbo for weeks and losing experiments zombie on because nobody wants to admit they failed.

The Decision Framework

The sunk cost trap: “But we spent 2 weeks building this feature for the experiment.” Doesn’t matter. If the data says it doesn’t work, kill it. The 2 weeks are gone whether you ship it or not. Shipping a losing variant because you feel bad about the effort is the most expensive mistake in growth.

Scaling Checklist

Before scaling a winning experiment to 100%:

• Confirm statistical significance with your data team. Don’t trust the A/B tool’s dashboard blindly.
• Check segment-level results. Did it work for all segments, or just one? If it only worked for enterprise but hurt SMB, you need a segmented rollout.
• Verify guardrail metrics. A 20% lift in signups means nothing if 30-day retention dropped 15%.
• Document the learning in the experiment log and the growth playbook.
• Plan the follow-up. If the headline test won, what headline variants should you test next? Compounding wins is the game.

The Velocity Target

Track your team’s experiment velocity as a meta-metric:

Don’t compare yourself to Netflix on day one. Start at 1–2 experiments per week. Get the process right. Build the habit. In 3 months, you’ll naturally be at 5/week because you’ve eliminated the friction. Trying to force 10/week before you have the infrastructure leads to sloppy experiments and bad data.

The Growth Experiment Checklist

Write the hypothesis first      no hypothesis = no experiment
ICE score everything         prioritize ruthlessly, don’t go by gut
One change per experiment    if you change two things, you learn nothing
Set duration upfront         don’t peek, don’t stop early
Define guardrail metrics     don’t optimize one metric by destroying another
Log every experiment        wins, losses, and inconclusives
Ship winners in 48 hours    velocity of scaling matters as much as velocity of testing
Kill losers immediately     sunk costs are sunk

Growth is not a hack. It’s a system. Build the system. Run the system. Trust the math.

metrics · formulas · benchmarks · cadence

Sales Ops Dashboard Forecasting MBA Intern Weekly Review

Most sales dashboards are decoration. They look impressive in board decks but nobody actually uses them to make decisions. The numbers are stale by the time anyone reads them, the metrics are vanity (total pipeline! total activities!), and there’s no connection between what the dashboard shows and what the team should do differently.

This playbook builds a dashboard that a sales leader actually opens every Monday morning, spends 15 minutes on, and walks away with 3 specific actions. It tracks leading indicators (what’s about to happen) not just lagging indicators (what already happened). And it’s opinionated — every metric has a target, and every missed target has a prescribed action.

Who this is for: MBA interns building their first sales dashboard, RevOps analysts designing weekly reporting, and sales leaders who want a template they can ship in a day.

Part I

The Dashboard Philosophy

Before building a single chart, you need to understand what makes a dashboard useful versus what makes it a vanity project. The difference is whether it changes behaviour.

01 Why Weekly, Not Monthly

Monthly reporting is an autopsy. By the time you see that pipeline coverage dropped or win rate tanked, you’ve already lost 4 weeks of potential correction. You can’t un-lose the deals. You can’t un-skip the prospecting.

Weekly reporting is a diagnostic. You catch problems while they’re still fixable:

• Pipeline coverage dropped below 3x this week? You have 3 weeks before it shows up in a missed forecast. Time to run a prospecting blitz.
• Rep X had zero meetings booked last week? That means zero new pipeline in 30 days. Intervene now, not after the quarter ends.
• Average deal size trending down? Catch it in week 3, not month 3. Are reps discounting? Selling to smaller accounts? Wrong product mix?

A weekly dashboard that takes 15 minutes to review is worth more than a monthly dashboard that takes 3 hours to build and nobody reads.

The 15-Minute Monday Review

Your dashboard should answer exactly three questions in 15 minutes or less:

1. Are we on track to hit the number this quarter? (Forecast vs quota)
2. Do we have enough pipeline to hit next quarter’s number? (Pipeline coverage)
3. Is anyone falling behind? (Rep-level attainment and activity)

If your dashboard requires more than 15 minutes, it has too many metrics. Cut ruthlessly.

02 Leading vs Lagging Indicators

This is the single most important concept in sales dashboarding. Most dashboards are 90% lagging indicators. Yours should be 60% leading.

The trap: Revenue closed is the metric the board cares about. But by the time you see a revenue miss, the deals were already lost 60–90 days ago. The leading indicators — meetings booked, pipeline created, proposals sent — told the story months earlier. Your dashboard should scream “warning” at the leading indicator stage, not at the revenue stage.

Rule of thumb: For every lagging metric on your dashboard, you should have at least two leading metrics that predict it. Revenue is predicted by pipeline coverage + win rate. Pipeline is predicted by meetings booked + outbound activity. Work backwards from the number you need to hit.

Part II

The Metrics

Every metric below includes the formula, the benchmark target, and what to do if you’re below target. If a metric doesn’t have a “what to do” action, it doesn’t belong on your dashboard.

03 Pipeline Metrics

Pipeline is the lifeblood of a sales team. These metrics tell you whether you have enough opportunities, whether they’re moving, and whether they’re healthy.

Stage Conversion Benchmarks (B2B SaaS, Mid-Market)

The pipeline coverage lie: 4x coverage means nothing if 40% of the pipeline is zombie deals that will never close. Calculate real coverage: remove all deals that haven’t had activity in 21+ days. If your “real” coverage is below 2.5x, you have a problem — regardless of what the headline number says.

04 Activity Metrics

Activity metrics are the purest leading indicators. They tell you right now whether next month’s pipeline will exist.

Activity metrics are not about micromanagement. They’re about early warning systems. If an AE’s meetings booked drops to zero for two consecutive weeks, that AE will miss quota in 60 days. Guaranteed. The dashboard should make this visible before it’s a crisis.

05 Revenue Metrics

These are the lagging indicators — the scoreboard. They tell you what happened, not what’s going to happen. Track them weekly to spot trends, but don’t use them as the primary management tool.

Sales Cycle Benchmarks by Segment

06 Forecast Metrics

Forecasting is where art meets science. The dashboard should track both the forecast itself and how accurate the forecast has been — because most sales teams are terrible at forecasting, and they need to see that fact in writing.

The sandbagging tax: When reps sandbag (hide good deals from the forecast to look like heroes), leadership can’t allocate resources, can’t plan hiring, and can’t set accurate expectations with the board. Sandbagging is just as bad as over-committing. Track forecast accuracy both ways.

07 Rep-Level Metrics

The team dashboard hides individual performance problems. A team hitting quota can have 2 reps at 150% and 3 reps at 60%. The rep-level view surfaces this.

Ramp Schedule Benchmarks (Mid-Market AE)

Part III

Building It

You don’t need a BI tool. Google Sheets or Excel with data pulled from your CRM is enough to build a dashboard that’s more useful than 90% of what Tableau produces. Here’s how.

08 Google Sheets / Excel Setup

Your dashboard workbook should have exactly 4 tabs:

The simplicity principle: Resist the urge to build 12 tabs with pivot tables and conditional formatting. The dashboard you actually use every Monday is better than the beautiful one you stop updating in week 3. Start with 4 tabs. Add complexity only when you’ve used it for a full quarter.

Summary Tab Layout

Structure the Summary tab in 5 horizontal sections, top to bottom:

1. Header: Quarter, weeks remaining, team quota, closed-won QTD, gap to quota
2. Forecast: Commit, Upside, Best Case, Weighted Pipeline
3. Pipeline: Coverage, Created this week, Aging deals, Velocity
4. Activity: Team totals for meetings, calls, emails, proposals (with WoW change)
5. Rep Scorecard: One row per AE with pipeline, attainment %, activity grade

09 CRM Reports to Pull

Whether you’re on Salesforce, HubSpot, Pipedrive, or Close, you need these 5 CRM reports exported weekly:

Pro tip: In Salesforce, save these as scheduled reports that email you a CSV every Monday at 7am. In HubSpot, create saved views with these exact filters. The goal is to make the Monday data pull take less than 5 minutes so you never skip it.

10 Formulas Reference

Every formula you need for the dashboard, written for Google Sheets. Adapt cell references to your layout.

Conditional formatting rules: Apply these to your Summary tab for instant visual scanning. Green = at or above target. Yellow = within 10% of target. Red = more than 10% below target. The Monday review should take 15 seconds of scanning colours before you read any numbers.

Part IV

The Weekly Cadence

A dashboard without a meeting cadence is just a spreadsheet. These three weekly touchpoints turn data into action.

11 Monday Pipeline Review (15 min)

When: Monday 9:00–9:15 AM. Who: Sales leader + all AEs. Format: Standing meeting, screen-sharing the dashboard.

Agenda

The 15-minute rule: This meeting must end at 15 minutes. If a deal needs deeper discussion, take it to the Wednesday review. The Monday meeting is a pulse check, not a strategy session. If it consistently runs over, you have too many metrics or too many people talking.

12 Wednesday Deal Review (30 min)

When: Wednesday 2:00–2:30 PM. Who: Sales leader + 1–2 AEs (rotate). Format: Deep dive on 3–4 specific deals.

Deal Selection Criteria

Don’t review all deals. Review the ones that matter most right now:

• Commit deals closing this month: What’s the close plan? What could go wrong?
• Largest deals in pipeline: Are they progressing? Multi-threaded? Executive sponsor identified?
• Stuck deals: No stage movement in 14+ days. What’s the blocker?
• Deals with competitors: What’s our positioning? Do we know the competitor’s pricing?

Questions to Ask for Each Deal

The best deal reviews don’t just ask “what’s the status?” — they ask “what’s the close plan?” A close plan has a specific next step, a specific date, and a specific person. “I’ll follow up next week” is not a close plan. “I’m sending the proposal to the CFO on Thursday, and we have a review call booked for Monday” is a close plan.

13 Friday Forecast (15 min)

When: Friday 4:00–4:15 PM. Who: Sales leader (solo or with RevOps). Format: Update the forecast categories and submit to leadership.

The Forecast Update Process

1. Review each AE’s Commit deals: Did anything slip this week? Is the close plan still intact? Move slipped deals from Commit to Upside.
2. Review Upside deals: Did any Upside deals advance enough to become Commit? (Must have: verbal yes, defined close plan, confirmed timeline.)
3. Calculate the gap: Remaining Quota minus Commit = Gap. Is the Upside pool large enough to fill the gap at a realistic conversion rate?
4. Submit the call: Your forecast to leadership should be: “We will close [Commit number]. Upside of [Upside number]. Risk: [biggest risk to the Commit number].”

Forecast accuracy goal: Over time, your Commit number should land within +/- 10% of actual closes each week. If you’re consistently off by more than 20%, the team’s commit criteria are too loose. Tighten them: verbal yes isn’t enough — require a signed order form or PO in progress to count as Commit.

Part V

Complete Example Dashboard

A fully worked dashboard for a hypothetical 5-AE mid-market SaaS team. Q2 2026, Week 7 of 13. Quota: $2.5M team ($500K per AE). ACV: $45K average. All numbers are realistic.

14 Full Dashboard — NovaCRM (5 AEs, Q2 2026)

NovaCRM — Q2 2026 Sales Dashboard · Week 7 of 13

Forecast

Pipeline Health

Action needed: 7 aging deals totaling $510K are inflating pipeline coverage. Without them, real coverage drops to 3.1x. Review all 7 on Wednesday: close, advance, or kill. The 2 new aging deals this week (Meridian Corp $85K and TechFlow $65K) haven’t had activity in 28 days.

Activity (Team Totals — This Week)

Rep Scorecard

This week’s focus:

1. Tom Nguyen: 1:1 pipeline building session. Coverage at 2.0x is critical. Block 3 hours for prospecting blitz. Review his target account list.
2. Aisha Patel: Deal coaching. High pipeline (4.6x) but low win rate (15% vs team avg 24%). Review her discovery calls — likely not qualifying hard enough.
3. Aging deals: Review all 7 on Wednesday. Kill at least 3. That $510K is inflating everyone’s numbers.

Revenue — This Week

The Dashboard Checklist

Update every Monday        5 min data pull, 15 min review
Leading > Lagging          60% leading indicators, 40% lagging
Every metric has an action   if below target, what do you DO?
Rep-level visibility        team averages hide individual problems
Kill zombie deals           pipeline coverage means nothing if 30% is dead
Track forecast accuracy     hold yourself accountable to what you commit
3 actions per week max      focus beats coverage every time

The dashboard doesn’t close deals. It tells you where to focus so your team can.

interviews · tracking · analysis · action loop

Sales Strategy Competitive Intel Win/Loss Deal Analysis Product Feedback

Every sales team has a graveyard of lost deals and a trophy case of wins. Almost none of them systematically study either. They move on to the next deal, repeating the same mistakes and accidentally replicating the same successes without understanding why.

Win/loss analysis is the most underused intelligence source in B2B sales. It tells you why buyers actually chose you (or didn’t), what your competitors are doing, where your product falls short, and which sales motions work. Learning from losses is 3x more valuable than learning from wins — because losses reveal the gaps you can’t see from the inside.

Who this is for: Sales leaders building a win/loss program, product marketers who own competitive intelligence, and founders who want to understand why deals are being lost.

Part I

Why Win/Loss

Before building the system, you need to understand why this matters and why most companies don’t do it despite the obvious value.

01 The Most Underused Intelligence Source

Your CRM has a “Closed Lost — Reason” field. It probably says things like “Price” or “Timing” or “Went with Competitor.” These reasons are almost always wrong.

They’re wrong because:

• The AE filled them in. Reps have an incentive to blame external factors (price, timing, budget) rather than admit they lost on value, missed signals, or got outsold.
• The buyer gave a polite reason. “We went a different direction” or “Budget got cut” is the B2B equivalent of “It’s not you, it’s me.” The real reason is usually more specific and more fixable.
• Nobody digs deeper. The deal is lost. The rep moves on. The real intelligence dies in a Salesforce picklist.

Win/loss analysis fixes this by going straight to the source: the buyer. Not your AE. Not your champion. The person who made the decision. In a structured, non-sales conversation, conducted within 2 weeks of the decision while the experience is still fresh.

Companies that run formal win/loss programs see a 15–30% improvement in win rate within 2–3 quarters. Not because of any single insight, but because of the cumulative effect of dozens of small improvements that only surface when you ask buyers directly.

02 Why Losses Are 3x More Valuable Than Wins

Win interviews tell you what you already know (or suspect). Loss interviews tell you what you don’t know and can’t see from the inside. That’s why they’re 3x more valuable.

The uncomfortable math: If you have a 25% win rate, 75% of your market interactions are losses. Those 75% of buyers chose someone else (or chose nothing). They have information you desperately need. Every loss you don’t interview is intelligence you’re throwing away.

What Win/Loss Reveals That Nothing Else Can

• Your real competitive positioning: Not what your marketing says. What buyers actually think when they compare you side-by-side.
• Your sales process gaps: “Your demo was great but we never talked to a technical person. The competitor brought an SE to every call.” You won’t find this in CRM data.
• Pricing perception: Not whether your price is too high (it usually isn’t). Whether the buyer understood the value enough to justify the price.
• The decision timeline: When did they actually make the decision? (Usually 2–3 weeks before they told you.) What happened in that window?
• Stakeholder dynamics: Who had influence you didn’t know about? “Our VP of Security had veto power and your competitor addressed his concerns directly. You never met him.”

Part II

The Interview

The interview is the core of win/loss analysis. Get this right and everything else follows. Get it wrong and you’re collecting bad data that leads to bad decisions.

03 When to Conduct & Who to Interview

Timing

Who to Interview

Who should conduct the interview: NOT the AE who worked the deal. Ideally, someone from product marketing, sales enablement, or a dedicated win/loss analyst. The buyer will be more honest with someone they don’t have a sales relationship with. If you’re small and the AE is the only option, have a manager or founder conduct the interview instead.

How to Get Buyers to Agree

The participation rate for win/loss interviews is typically 40–60% when done right. Here’s how to ask:

To: The Buyer · 1–3 days after decision

Quick favor — 15 min to help us improve

Hi ,

Congratulations on making your decision — I hope it goes well regardless of outcome.

We’re always trying to improve our process. Would you be open to a 15-minute conversation about your evaluation experience? This isn’t a sales call — we won’t try to change your mind. We genuinely want to learn what we did well and where we fell short.

Your feedback would be incredibly valuable. Happy to work around your schedule.

(Note: this should come from someone other than the AE)

Why this works: “This isn’t a sales call” removes the fear that you’ll try to re-open the deal. “Regardless of outcome” is gracious. “15 minutes” is a small ask. Most buyers are willing to help if you make it easy and genuine.

04 Interview Guide — Won Deals

For deals you won, the goal is to understand why you won from the buyer’s perspective (not your AE’s) and what almost went wrong.

Opening Questions (2 min)

1. “What prompted you to start evaluating solutions in the first place?”
2. “What was the business problem or trigger that made this a priority?”

Evaluation Process (5 min)

1. “Walk me through your evaluation process. How did you structure the decision?”
2. “Who was involved in the decision? What role did each person play?”
3. “What were your top 3 criteria when comparing solutions?”
4. “Who else did you consider? How far did each get in the process?”

Decision (5 min)

1. “What ultimately tipped the decision in our favour?”
2. “Was there a specific moment or interaction where you thought ‘this is the one’?”
3. “What almost stopped you from choosing us? What was your biggest hesitation?”
4. “How would you rate our sales process? What could we have done better?”

Forward-Looking (3 min)

1. “What does success look like for you in 6 months?”
2. “Is there anything you wish we’d told you during the process that you had to figure out on your own?”

The gold question for wins: “What almost stopped you from choosing us?” This reveals your vulnerabilities. The things that almost killed the deal this time will actually kill it next time against a stronger competitor. Fix them now.

05 Interview Guide — Lost Deals

For deals you lost, the goal is to understand the real reason (not the polite reason), what the competitor did better, and where your sales process broke down.

Opening Questions (2 min)

1. “What originally prompted you to look at solutions like ours?”
2. “How did you first hear about us?”

Evaluation Process (5 min)

1. “Walk me through your decision process from start to finish.”
2. “What were your top 3 evaluation criteria?”
3. “Who was involved in the final decision? Was there anyone who had particularly strong opinions?”
4. “How many vendors did you evaluate? How did we compare?”

The Decision (5 min)

1. “What ultimately tipped the decision away from us?”
2. “Was there a specific moment where you thought ‘this isn’t going to work’?”
3. “If you could change one thing about our product, what would have made the difference?”
4. “How did pricing factor into your decision? Was it about the price itself or the value you saw for the price?”
5. “What did do particularly well in their sales process?”

Our Sales Process (3 min)

1. “How would you rate our sales process overall? What worked? What didn’t?”
2. “Was there anything missing from our process that you expected or that the competitor provided?”
3. “Did you feel like our team understood your requirements?”
4. “If you were coaching our sales team, what would you tell them to do differently?”

Closing (1 min)

1. “Is there anything else that influenced the decision that I haven’t asked about?”
2. “Would you be open to reconsidering us in the future if things change?”

Question 15 — “If you were coaching our sales team, what would you tell them to do differently?” — is the single most valuable question in win/loss analysis. Buyers give incredibly specific, actionable feedback when asked this way. You’ll hear things like: “Your rep should have asked about our compliance requirements in the first call, not the third” or “The competitor brought a customer reference who was in our exact industry. You didn’t.”

06 Interview Technique

The quality of your interview depends entirely on technique. Bad technique = polite surface-level answers. Good technique = specific, honest, actionable intelligence.

Part III

The Tracking System

Individual interviews are useful. A systematic database of 50+ interviews over time is transformational. Here’s how to build the tracking system that turns anecdotes into data.

07 Building the Tracking System

Your win/loss tracking lives in two places:

1. CRM (structured data): Standardised fields on every closed deal. Picklists, not free text. This is what you’ll analyse at scale.
2. Spreadsheet or Notion (qualitative data): Interview notes, quotes, themes. This is where the rich insights live.

CRM Fields to Add

08 Standardised Win/Loss Reasons

The picklist is critical. Free-text loss reasons are useless for analysis (“it was complicated” doesn’t help anyone). Use these standardised categories:

Win Reasons

Loss Reasons

The “price” trap: When an AE says they lost on price, it’s almost never actually about price. In win/loss interviews, “price” usually translates to: (a) they didn’t see enough value, (b) we didn’t help them build the internal business case, or (c) the competitor positioned value better at a similar price. If more than 25% of your losses show “Price” as the reason, your real problem is value communication, not pricing.

Part IV

Analysis

Interviews are the raw material. Analysis is where you turn raw material into decisions. Run this quarterly with at least 15–20 data points.

09 Quarterly Analysis Framework

Every quarter, slice the data across 5 dimensions:

Example: Quarterly Win Rate Analysis (Hypothetical)

The insight that pays for the program: In this hypothetical data, the single biggest lever is meeting the economic buyer (40% vs 18% win rate). If you could increase the “met decision maker” rate from 58% to 80% of deals, overall win rate would jump approximately 5 points. That’s worth millions in pipeline conversion.

10 Pattern Identification

Beyond the numbers, look for qualitative patterns across interviews. Group interview notes into themes:

Common Patterns to Look For

Pattern identification rule: One interview is an anecdote. Three interviews with the same theme is a pattern. Five interviews is a systemic problem that needs to be fixed. Don’t over-react to individual interviews. Wait for patterns to emerge across 15–20+ data points.

11 Executive Report Format

Your quarterly win/loss report to leadership should be exactly 4 sections on a single page (plus appendix):

Section 1: Summary Metrics

Q2 2026 Win/Loss Summary

• Deals closed: 52 (28 won, 24 lost)
• Win rate: 24% (target: 28%)
• Interviews conducted: 22 of 52 (42%)
• Average deal size (won): $48K
• Average deal size (lost): $62K — losing larger deals

Section 2: Top 3 Loss Reasons (with frequency)

1. Competitor Strength (35% of losses) — Primarily CompetitorA in enterprise segment
2. Product Gap (25% of losses) — SSO and advanced permissions most cited
3. Sales Process (20% of losses) — Not meeting decision maker, slow response times

Section 3: Top 3 Recommendations

1. Build CompetitorA battle card — Win rate vs CompetitorA is 17%. Need competitive training and SE pairing for every CompetitorA deal.
2. Accelerate SSO roadmap — SSO was cited in 6 of 24 losses. Enterprise buyers treat this as non-negotiable.
3. Require decision-maker meeting — Win rate jumps from 18% to 40% when we meet the economic buyer. Make it a required stage gate.

Section 4: Key Buyer Quotes

Include 3–5 direct quotes from interviews. Quotes are more persuasive than data because they put leadership in the buyer’s shoes.

The one-page rule: Executives don’t read long reports. One page of findings + one page appendix with supporting data. If you can’t fit it in one page, you haven’t synthesised enough. The appendix is for people who want to go deeper.

Part V

Templates

Copy-paste templates for the interview script, the tracking spreadsheet, and the quarterly report.

12 Interview Script Template

Win/Loss Interview Script · 15–20 minutes

Opening (1 min):
“Thank you for taking the time. This is purely a learning conversation — I’m not going to try to sell you anything or change your mind. I’m [Name] from [Company]. We want to understand your experience so we can improve. Everything you share is confidential and used only internally. May I record this for accurate note-taking?”

Context (2 min):

1. “What prompted you to start looking at solutions like ours?”
2. “What was the business problem you were trying to solve?”

Process (4 min):

1. “Walk me through your evaluation process from beginning to end.”
2. “What were your top 3 criteria?”
3. “Who was involved in the decision?”
4. “Who else did you evaluate?”

Decision (5 min):

1. “What ultimately drove the decision?”
2. “Was there a specific moment that was decisive?”
3. [For wins] “What almost stopped you from choosing us?”
4. [For losses] “What could we have done differently to change the outcome?”
5. “How did pricing factor in?”
6. “What did [competitor] do well?”

Our Process (3 min):

1. “How would you rate our sales process?”
2. “Was anything missing from our approach?”
3. “If you were coaching our team, what would you tell them?”

Close (1 min):

1. “Anything else I should know that I haven’t asked about?”
2. “Thank you — this is incredibly valuable.”

13 Tracking Sheet Template

Build this in Google Sheets or your CRM. One row per closed deal. These are the columns:

14 Quarterly Report Template

Win/Loss Quarterly Report · Q2 2026

Executive Summary
Win rate this quarter: (vs last quarter). Interviews conducted: . Three patterns emerged: , , .

Win Rate by Dimension
• By competitor: [table]
• By segment: [table]
• By ACV range: [table]
• By sales factor: [table]

Top Loss Reasons (ranked by frequency)

1. — of losses —
2. — of losses —
3. — of losses —

Top Win Reasons (ranked by frequency)

1. — of wins
2. — of wins

Key Buyer Quotes
• “” — VP Engineering, $65K deal
• “” — Director of Ops, $45K deal
• “” — CTO, $120K deal

Recommendations

1. — Owner: — Impact:
2. — Owner: — Impact:
3. — Owner: — Impact:

Progress on Last Quarter’s Recommendations
• :
• :

Part VI

The Action Loop

Win/loss analysis that doesn’t change behaviour is an expensive journaling exercise. The insights must feed back into 6 specific areas, with owners and timelines.

15 Closing the Loop

Every win/loss insight should feed back into one of these six areas. If an insight doesn’t map to one of these, it’s interesting but not actionable — deprioritise it.

The win/loss program pays for itself when one loss pattern gets fixed. If “product gap: SSO” was causing $420K in quarterly losses and you ship SSO, you’ve potentially recovered $1.6M/year in pipeline. That’s the ROI of win/loss analysis: not the interviews themselves, but the decisions they inform.

The Quarterly Action Review

At the end of each quarter, review two things:

1. What did we recommend last quarter? Track status. Hold owners accountable. If a recommendation from Q1 still hasn’t been acted on by Q3, either escalate it or accept it won’t happen and stop recommending it.
2. Did the changes work? If you implemented a CompetitorA battle card in Q2, did the win rate vs CompetitorA improve in Q3? Measure the impact. Report it. This builds credibility for the program and ensures it keeps getting funded.

The program lifecycle: Quarter 1: build the system, conduct first interviews, establish baseline. Quarter 2: first analysis, first recommendations. Quarter 3: first impact measurements. By Quarter 4, you should have clear evidence that win/loss analysis is improving win rates. If you don’t, the program design needs fixing — not the concept.

Getting Started — The First 30 Days

The Win/Loss Checklist

Interview within 2 weeks       memory fades fast
Talk to the buyer, not your AE   AEs have blind spots and biases
Ask “why?” three times          the first answer is never the real one
Standardise the reasons         picklists, not free text
Look for patterns, not anecdotes 3+ interviews = a pattern
Feed insights back             battle cards, training, product, pricing, ICP
Measure the impact            did the changes actually improve win rate?

Every lost deal has a lesson. The question is whether you’re listening.

quarterly business review · structure · deck · templates

Customer Success Account Management QBR Retention Expansion

The quarterly business review is the single most important customer meeting that most companies do badly. They turn it into a product roadmap presentation. Or a feature request session. Or a status update that could have been an email. All of those are wastes of your customer’s executive time.

A great QBR is a business conversation about value. You show the customer what they’ve achieved with your product, tie it to their business outcomes, surface risks before they become churn, and plant seeds for expansion — all in 50 minutes. It’s the meeting that prevents surprise churn and creates organic upsell.

Who this is for: CSMs running their first QBRs, AMs looking for a repeatable template, and CS leaders building a QBR program from scratch.

Part I

Why QBRs Matter

The QBR is not a nice-to-have. It is the structural mechanism that prevents churn, identifies expansion, and keeps your executive sponsor engaged. Skip it, and you’re flying blind on your most important accounts.

01 The Meeting That Prevents Churn

Most churn doesn’t happen because the product is bad. It happens because the customer forgot why they bought. The day-to-day users know the product works. But the VP who signed the contract? She hasn’t logged in since the kickoff call. She sees a line item on the budget and thinks: “What are we getting from this?”

The QBR answers that question before she asks it.

• Churn prevention: You show the executive sponsor concrete ROI. She sees the value. She approves the renewal without a second thought.
• Expansion seeds: When you show how similar customers expanded usage, you plant the idea. “If Acme’s west coast team is getting these results, why aren’t we doing this for our APAC team?”
• Risk detection: A QBR surfaces problems that support tickets don’t. “Actually, the team in London stopped using the product two months ago.” You’d never know this from usage data alone.
• Relationship depth: Quarterly face-time (or video) with the exec sponsor keeps the relationship alive. When a competitor comes knocking, they think of you as a partner, not a vendor.

Companies that run structured QBRs with their top-tier accounts see 15–20% higher net revenue retention than companies that don’t. The QBR is not overhead. It is the highest-ROI hour in customer success.

02 QBR vs Product Update — Know the Difference

The litmus test: If you could give this exact same presentation to every customer by just changing the logo, it’s a product update, not a QBR. A real QBR is so specific to this customer that it would make no sense to anyone else.

Part II

The QBR Structure

Six sections, 50 minutes, tightly timed. Every section has a purpose and a transition to the next. The structure ensures you cover value, growth, and risk without running over or going off-track.

03 The 50-Minute Structure

The 50-minute rule: Book 60 minutes but plan for 50. The extra 10 minutes is buffer for when the exec asks a follow-up question you didn’t expect (which is a good sign). Never go over 60. Respect their time and they’ll show up next quarter.

04 Section 1: Relationship Check (5 min)

Goal: Warm up the room and surface any organisational changes that affect the account.

This is not small talk. It’s strategic relationship intelligence gathering disguised as small talk.

Questions to Ask

• “How’s the team doing? Any changes since last quarter?”
• “I saw you hired a new [VP of Ops / Head of Data]. How’s the transition going?”
• “Any shifts in company priorities we should know about?”
• “How’s [specific initiative they mentioned last quarter] progressing?”

Why this matters: If your champion left and you don’t know about it, the account is already at risk. If the company pivoted strategy, your use case might not be a priority anymore. Five minutes of relationship check can reveal existential risks that no dashboard will show you.

Transition to Section 2

“Great, thanks for the context. Let me show you what the team has accomplished this quarter — the numbers are really strong.”

05 Section 2: Value Delivered (15 min)

Goal: Show the executive sponsor concrete, quantified value. This is the most important section. If you nail this, the rest of the QBR is easy.

The key word is their. Not your product metrics. Their business metrics.

What to Show

The sentence “Based on your usage, that’s approximately $57K in analyst time saved” is the sentence that gets the renewal signed. The exec sponsor doesn’t care about DAU. She cares about ROI. Always translate usage into dollars.

The ROI formula: (Hours saved per week × Average hourly cost × 13 weeks) + (Errors avoided × Average cost per error) + (Revenue influenced) = Quarterly value delivered. Work with the customer to agree on the inputs during onboarding so the QBR numbers aren’t a surprise.

Transition to Section 3

“These results are strong. Now let me show you what’s coming that’ll make this even better for your team.”

06 Section 3: Roadmap Alignment (10 min)

Goal: Show 3–5 upcoming features that directly address needs this specific customer has expressed. This is NOT a product demo. It’s a targeted preview.

How to Present Roadmap

The commitment trap: Never promise a specific feature or date that hasn’t been committed by your product team. “We’re exploring this” or “This is in design” is fine. “I guarantee this will ship in June” will come back to haunt you. Be honest about what’s confirmed vs what’s planned.

Transition to Section 4

“With these improvements coming, I want to share how some of your peers are getting even more value — and see if any of it resonates.”

07 Section 4: Growth Conversation (10 min)

Goal: Plant expansion seeds by showing how similar customers have grown their usage. This is not a sales pitch. It’s peer benchmarking that naturally leads to “we should do that too.”

The Framework

Use the “customers like you” framework:

1. Benchmark: “Companies at your stage and size typically use [X, Y, Z] features.”
2. Gap: “Your team is doing great with X, but hasn’t explored Y yet.”
3. Peer story: “Acme Corp started exactly where you are. When they rolled out Y to their APAC team, they saw a 40% improvement in [metric].”
4. Question: “Is that something your team has thought about?”

Don’t say

“We have an enterprise tier that includes API access and SSO. The pricing is $80K/year. Would you like to upgrade?”

Say this instead

“Companies your size that added the API integration saw their team’s output increase by 35%. Stripe did this last quarter and it cut their manual reporting from 10 hours/week to 1. Based on your trajectory, this could save your team a significant amount of time. Worth exploring?”

Why this works: You’re not selling. You’re showing them what’s possible based on what their peers have done. The customer arrives at the expansion idea themselves. That’s a much stronger buying signal than responding to a pitch.

08 Section 5: Risk & Feedback (5 min)

Goal: Get honest feedback. Surface problems before they become churn risks. This section only works if you ask the right questions and then actually listen.

Questions to Ask

• “What could we be doing better?”
• “Is there anything that’s been frustrating your team?”
• “On a scale of 1–10, how likely are you to recommend us to a peer? Why that number?”
• “If you could change one thing about working with us, what would it be?”
• “Are there any blockers to your team getting full value?”

The uncomfortable truth: If the customer says “everything’s great” and has no feedback, that’s a red flag, not a green flag. It means they’re not engaged enough to have opinions. Probe deeper: “I appreciate that. Most customers have at least one thing they’d change. Even small things — what comes to mind?” Silence after this question is the real danger signal.

Transition to Section 6

“Thank you for that feedback — it’s genuinely helpful. Let me capture our next steps so nothing falls through the cracks.”

09 Section 6: Next Steps (5 min)

Goal: Lock in specific actions with specific owners and specific dates. “We’ll follow up” is not a next step.

Next Steps Format

The follow-through test: The #1 thing that kills QBR credibility is not following through on next steps. If you say “I’ll get back to you on the API question by Friday” and you don’t, the customer’s trust erodes. Track every action item. Close every loop. No exceptions.

Part III

Preparation

A QBR is only as good as the preparation behind it. The meeting itself is 50 minutes. The preparation should be 2–3 hours. Here’s exactly what to pull and who to invite.

10 Data to Pull (1–2 Hours Before)

The preparation signal: When a customer sees you’ve pulled their specific data, referenced their specific requests, and connected everything to their specific goals — they know you take the relationship seriously. That’s worth more than any feature you could demo.

11 Who to Invite

From the Customer Side

From Your Side

The exec sponsor problem: If you can’t get the exec sponsor to attend, something is already wrong. Either: (a) they don’t see value in the relationship, (b) your champion can’t influence them, or (c) you’re not positioned at the right level. All three are churn risks. If the exec won’t attend, your pre-QBR work should focus on figuring out why and fixing it before you try again.

Part IV

The QBR Deck

8 slides. No more. Each slide has a specific purpose and specific content. The deck is a conversation guide, not a script to read from.

12 Slide-by-Slide Guide

SLIDE 1

Cover Slide

Their logo (not yours) + “Quarterly Business Review” + Q2 2026 + Date
Subtle: “Prepared by [Your Company]” in small text at the bottom. Their brand is the hero.

SLIDE 2

Agenda

The 6-section agenda with timings. Simple bullet list. Sets expectations. Shows you’re organised and won’t waste their time.

1. Relationship Check (5 min)
2. Value Delivered (15 min)
3. Roadmap Alignment (10 min)
4. Growth Opportunities (10 min)
5. Risk & Feedback (5 min)
6. Next Steps (5 min)

SLIDE 3

Partnership Summary

One-page snapshot of the relationship:

• Customer since: [date]
• Current plan: [tier / seats / modules]
• Key contacts: [names and roles]
• Goals established at kickoff: [1–3 goals]
• Renewal date: [date]

This slide is your memory check. If anything is wrong, the customer will correct you — which is useful intelligence.

SLIDE 4

Value Delivered — The Metrics

The centrepiece of the deck. Show 3–5 metrics with QoQ trends:

• Usage: 2,340 analyses (+28% QoQ)
• Time saved: ~380 hours ($57K in analyst time)
• Adoption: 34/40 seats active (85%)
• ROI: 1.2x on contract value (time savings alone)
• Benchmark: Top quartile adoption vs peers

Use their colours if possible. Make it feel like their internal report, not a vendor slide.

SLIDE 5

Value Delivered — The Story

A visual: adoption curve over time, showing key milestones.

“In January, your London team came online. Adoption jumped from 60% to 85%. The team now runs 3x more analyses than they did in Q1.”

Tell the story behind the numbers. Executives remember stories, not data points.

SLIDE 6

Roadmap Alignment

3–5 upcoming features, each tied to a need this customer expressed:

• Advanced API (Q3): Addresses your request for automated data pulls
• Custom dashboards (Q3): Lets your APAC team build their own views
• SSO improvements (Q4): Simplifies onboarding for new team members

Only show features relevant to them. Not your entire roadmap.

SLIDE 7

Growth Opportunities

Peer comparison + expansion suggestion:

“Companies at your stage typically expand to [X]. Based on your trajectory, here’s what that could look like:”

• Scenario A: Add APAC team (20 seats) → estimated $24K/yr additional value in time saved
• Scenario B: Upgrade to API tier → automate 10 hrs/week of manual reporting

Frame as “here’s what similar companies did” not “here’s what you should buy.” Let them draw the conclusion.

SLIDE 8

Next Steps

Action items table: Action / Owner / Date

• Send QBR summary — CSM — Tomorrow
• Schedule APAC team training — CSM — By Apr 30
• Share API integration proposal — AE — By May 5
• Connect us with APAC lead — Customer — By May 2
• Next QBR — Both — Week of Jul 14

Book the next QBR before ending this one. It’s 10x easier to schedule when everyone’s in the room.

Part V

Templates

Copy-paste templates for the pre-QBR invite, the post-QBR follow-up, and the internal debrief. Adapt them to your voice.

13 QBR Emails

Pre-QBR Invite (Send 2 Weeks Before)

To: Executive Sponsor + Champion · 2 weeks before QBR

Q2 Business Review —

Hi ,

I’d like to schedule our Q2 business review. This is a 50-minute session where we’ll:

• Share your team’s results and ROI from this quarter
• Preview upcoming product improvements relevant to your goals
• Discuss opportunities to get even more value
• Get your feedback on how we can improve

I’d love to include — we’ve prepared some data I think she’d find valuable, especially around the time savings the team is seeing.

Could you suggest 2–3 times that work in the next two weeks?

Best,

Why this template works: It leads with what they’ll get (results, ROI), not what you need (renewal discussion). It specifically requests the exec sponsor and gives a reason (“data she’d find valuable”). It’s short and asks for a simple action (suggest times).

Post-QBR Follow-Up (Send Within 24 Hours)

To: All QBR Attendees + Exec Sponsor (CC) · Within 24 hours

Q2 Business Review Summary —

Hi team,

Thank you for a great conversation today. Here’s a summary of what we covered and next steps:

Key Results This Quarter:
• 2,340 analyses run (+28% QoQ)
• ~380 hours saved ($57K in analyst time)
• 85% seat adoption (34/40 active)
• ROI: 1.2x on contract value

Next Steps:
• — by
• — by
• — by

Deck attached for reference. Our next QBR is scheduled for .

Let me know if I missed anything or if any of the action items need adjusting.

Best,

CC the exec sponsor on the follow-up even if she wasn’t in the meeting. This email is your value proof to the person who controls the budget. If the exec sponsor only sees one email from you all quarter, make it this one.

14 Internal Debrief Template

After every QBR, fill out this internal debrief and share with your team. It takes 5 minutes and creates a record that’s invaluable at renewal time.

Internal QBR Debrief · Share with CS + Sales + Product

Account:
Date:
Attendees:
Health Score (before / after):

Key Takeaways:

Risks Identified:
•

Expansion Signals:
•
•

Product Feedback:
•

Renewal Outlook:
Renewal Date:
Expansion Potential:

Action Items:
• — by

Part VI

Common Mistakes

These are the mistakes that turn a high-value business conversation into a forgettable vendor meeting. Avoid all of them.

15 The 10 QBR Mistakes

The QBR Checklist

Exec sponsor in the room       no exec = reschedule
Their metrics, not yours        lead with ROI and business outcomes
Custom deck                   every slide is account-specific
40/60 talk ratio              they talk more than you
Plant expansion seeds         “customers like you” framework
Surface risk                  “everything’s great” is a red flag
Follow up within 24 hours     summary email + action items
Book the next QBR            before ending this one

The QBR is not a presentation. It’s a business conversation that proves value and builds trust.

frameworks · models · teardowns · implementation

SaaS Pricing MBA Workshop Revenue Growth Monetisation

Pricing is the most underleveraged growth lever in SaaS. Most companies spend hundreds of hours on acquisition, dozens on retention, and approximately zero on pricing. This is a mistake. A 10% improvement in pricing yields a 12.7% improvement in profit — more than a 10% improvement in volume (3.3%) or a 10% reduction in variable costs (7.8%).

This workshop is designed to give you the frameworks, models, and practical tools to audit, design, and implement pricing for any SaaS product. Every section includes worked examples, real company teardowns, and templates you can apply immediately.

Who this is for: MBA interns working on growth strategy, product managers owning monetisation, founders setting pricing for the first time, and anyone who has ever said “we should probably raise our prices” but didn’t know where to start.

Part I

Pricing Foundations

Before you touch a pricing page, you need to understand why pricing matters more than you think, what a value metric is, and how to measure what customers are actually willing to pay.

01 Why Pricing Is the #1 Lever

Here is a simple truth that most SaaS operators ignore: a 10% price increase is a 10% ARR increase at zero incremental CAC. No new leads. No new pipeline. No new reps. Just more revenue from the same customers.

Compare the three growth levers side by side:

Source: McKinsey & Company pricing study across 2,400+ companies. The profit impact numbers assume typical SaaS cost structures.

Despite this, most SaaS companies underprice by 20–40%. Why?

• Fear of churn. Founders are terrified that raising prices will cause customers to leave. In practice, a 10% price increase rarely causes more than 1–2% incremental churn — the math overwhelmingly favours the increase.
• Anchoring to competitors. “Our competitor charges $49/mo, so we charge $39/mo.” This ignores that your product may deliver different (or more) value. Competing on price is a race to the bottom.
• Set and forget. The founding team set pricing in 2019 based on vibes. It’s 2026. The product has 10x more features. The price hasn’t changed.
• No ownership. Nobody owns pricing. It falls between Product, Sales, Marketing, and Finance. Everyone assumes someone else is handling it.

Insight: Pricing is the highest-leverage, lowest-effort growth lever in SaaS. If you haven’t touched your pricing in the last 12 months, you are almost certainly leaving money on the table.

The Pricing Impact Calculator

Here’s a worked example. Assume a SaaS company with these metrics:

The math: A 10% price increase on a $5M ARR business nets ~$425K after accounting for 1.5% incremental churn. To get that same $425K through new customer acquisition, you’d need to spend ~$340K in sales and marketing. Pricing is free. Acquisition is not.

02 The Value Metric

The value metric is what customers pay for that scales with the value they receive. It is the single most important decision in your pricing architecture. Get it right and revenue grows naturally as customers succeed. Get it wrong and you either leave money on the table or create perverse incentives.

What Makes a Good Value Metric

Common SaaS Value Metrics

How to Find Your Value Metric

Interview 20 customers. Ask these three questions:

Value Metric Discovery Interview · 3 core questions

Q1: “If you had to measure whether our product is worth what you pay, what number would you look at?”

Q2: “What does success look like for you when using our product? How would you measure it?”

Q3: “If our price doubled tomorrow, what would you need to see more of to justify it?”

Listen for patterns. If 12 of 20 customers say “the number of reports generated” or “the number of team members using it” — that’s your value metric.

The test: A good value metric passes this sentence: “The more _____ the customer uses, the more value they get, and the more they should pay.” If you can fill in the blank and it feels fair to both sides, you’ve found it.

03 Willingness to Pay Research

You cannot set prices by guessing. You need data on what customers will actually pay. Two proven methods:

Method 1: Van Westendorp Price Sensitivity Meter

The Van Westendorp method uses four questions to map the boundaries of acceptable pricing. Survey at least 100 prospects or customers.

The Four Van Westendorp Questions

Q1 — Too Cheap: “At what price would you consider this product to be so cheap that you’d question its quality?”

Q2 — Cheap / Good Deal: “At what price would you consider this product a bargain — a great deal for the money?”

Q3 — Expensive / Getting Pricey: “At what price would you consider this product to be getting expensive — not out of reach, but you’d have to think about it?”

Q4 — Too Expensive: “At what price would you consider this product too expensive to consider purchasing?”

How to Interpret the Results

Plot cumulative distributions of all four answers. The intersections give you:

Example result: You survey 150 mid-market SaaS buyers about a project management tool. PMC = $12/seat/mo, OPP = $18/seat/mo, IDP = $22/seat/mo, PME = $35/seat/mo. Your acceptable range is $18–$35/seat/mo. Most companies would have guessed $10–$15 and left 40%+ on the table.

Method 2: Gabor-Granger (Simpler)

When you don’t have 100+ survey respondents, Gabor-Granger works with smaller samples. It’s simpler but less nuanced.

Gabor-Granger Method

Step 1: Show a price. Ask: “Would you buy this product at $X/month?”

Step 2: If YES → increase price by 20%. Ask again.

Step 3: If NO → decrease price by 20%. Ask again.

Step 4: Continue until you find the threshold. Repeat across 30+ respondents.

Output: A demand curve showing % of people who would buy at each price point. Multiply price × demand to find the revenue-maximising price.

When to use which: Use Van Westendorp when you have access to 100+ respondents and want the full picture (acceptable range, optimal point). Use Gabor-Granger when you have fewer respondents (30–50) and just need a revenue-maximising price quickly.

Part II

The Six Pricing Models

Every SaaS product uses one (or a combination) of these six models. Understanding the tradeoffs of each is essential before you design or redesign your pricing.

04 Flat Rate Pricing

One product, one price, every customer pays the same thing. The simplest possible model.

Case Study: Basecamp

Basecamp Pricing Teardown

Model: Flat rate — $349/month for unlimited users, unlimited projects

Why they chose it: Basecamp’s philosophy is simplicity. They don’t want customers thinking about per-seat costs when adding team members. They believe “pricing shouldn’t be a spreadsheet exercise.”

The tradeoff: A 5-person startup pays $349/mo ($69.80/user). A 500-person company pays $349/mo ($0.70/user). Basecamp is effectively giving away 99% of the value to large customers.

Why it works for them: Their brand is built on being the anti-enterprise tool. Their TAM is SMBs who value simplicity. The flat rate is the product positioning.

Why it wouldn’t work for you: If you have customers ranging from 5 to 5,000 users, flat rate means your largest customers get an incredible deal and your smallest customers subsidise them. You also have zero expansion revenue — no net revenue retention above 100%.

The flat rate trap: Flat rate pricing caps your NRR (Net Revenue Retention) at 100%. You can never earn more from an existing customer. In SaaS, the best companies have NRR of 120–140%+. Flat rate makes that mathematically impossible.

05 Per Seat Pricing

The most common B2B SaaS model. Each user (seat) costs a fixed amount per month.

Mechanics

Per Seat Pricing: Pros and Cons

Real Company Teardowns

How to Set Your Per-Seat Price

1. Calculate value delivered per user. If your tool saves each user 5 hours/week and their loaded cost is $75/hr, you deliver ~$1,500/mo in value per user.
2. Apply the 10:1 value ratio. Customers should get 10x the value they pay. $1,500 value / 10 = $150/user/mo maximum. This is the ceiling.
3. Run willingness-to-pay research. Van Westendorp or Gabor-Granger to find the acceptable range.
4. Set price at 70–80% of the WTP ceiling. Leave room for annual discounts and enterprise negotiation.

Insight: Slack’s genius move: they only charge for active users. If someone on your team hasn’t used Slack in 14 days, they’re automatically deactivated and you don’t pay. This removes the biggest objection to per-seat pricing (“I’m paying for people who don’t use it”) and dramatically increases willingness to roll out company-wide.

06 Usage-Based Pricing

The customer pays per unit consumed. No fixed fee, no seats — you pay for what you use. This is the fastest-growing pricing model in SaaS.

How It Works

Usage-Based Pricing: Pros and Cons

Real Company Teardowns

Why usage-based NRR is insane: Snowflake’s NRR of 158% means the average customer spends 58% more each year without any upselling effort. That’s because as their data grows, compute usage grows. Revenue is a function of customer success. This is the holy grail of SaaS monetisation.

How to Set Usage-Based Rates

1. Calculate your cost per unit. Infrastructure cost (compute, bandwidth, storage) per unit of consumption. Add a healthy margin (70–85% gross margin target).
2. Benchmark against competitors. If Twilio charges $0.0079/SMS and you charge $0.05/SMS, you need to justify 6x with differentiated value.
3. Design volume tiers. Reward growth: higher volume = lower per-unit price. This encourages consolidation onto your platform.
4. Consider committed-use discounts. “Commit to $10K/mo and get 30% off per-unit rates.” This gives you revenue predictability while giving them savings.

07 Tiered Packages

The Starter / Pro / Enterprise model. The most common pricing page design in SaaS. Three (sometimes four) packages at escalating price points with increasing features, limits, and support levels.

How to Design Tiers

The Decoy Effect (Asymmetric Dominance)

The middle tier should be designed to look like the obvious best deal compared to the other two. This is called the decoy effect — the lower and upper tiers make the middle tier look like incredible value.

Worked Example: Project Management SaaS

Starter — $12/user/mo
5 projects, 10GB storage, email support

Pro — $24/user/mo MOST POPULAR
Unlimited projects, 100GB storage, priority support, integrations, reporting

Enterprise — $45/user/mo
Everything in Pro + SSO/SAML, audit logs, 99.9% SLA, dedicated CSM, custom integrations

The jump from Starter ($12) to Pro ($24) doubles the price but adds 10x the value (unlimited projects, 10x storage, integrations). The jump from Pro ($24) to Enterprise ($45) nearly doubles the price but mainly adds compliance features most mid-market companies don’t need. Result: 60–70% of customers choose Pro.

The psychology: Good/Better/Best works because humans avoid extremes. Given three options, most people pick the middle one. If you design your tiers so the middle option has the best value-to-price ratio, you can predict that 60–70% of customers will land there — and you can set that tier’s price accordingly.

Real Company Teardown: HubSpot

Notice the massive price jump from Starter ($20) to Professional ($890). HubSpot’s value metric is contacts, but the real gate is features. The Professional tier is where the product becomes genuinely useful for a real marketing team. This is intentional — the free and Starter tiers exist to get you hooked.

Tier Design: What Goes Where

08 Hybrid Pricing

Most modern SaaS companies don’t use a single model — they combine two or more. This is hybrid pricing, and it’s increasingly the default for companies at scale.

Common Hybrid Structures

How to Structure a Hybrid Model

Hybrid Pricing Design Framework

Step 1: Identify your base value.
What does every customer need? This becomes the platform fee or base tier. It should cover your cost to serve + margin.

Step 2: Identify your expansion vector.
What grows as the customer gets more value? Seats? Usage? Contacts? This becomes the variable component.

Step 3: Set the ratio.
Aim for 60–70% of revenue from the predictable component (platform fee + seats) and 30–40% from the variable component (usage). This balances predictability with expansion.

Step 4: Include a buffer.
Give each tier a usage allowance so customers don’t get surprised by overage charges. The allowance should cover the 50th percentile of usage. Only the top 25–30% of customers should trigger overage billing.

The hybrid advantage: Platform fee gives you revenue predictability (CFO loves it). Usage component gives you natural expansion (CRO loves it). Tiered features give you an upgrade path (Product loves it). Hybrid is harder to design but dramatically better for the business.

09 Freemium

Freemium is not a pricing model — it’s a customer acquisition strategy. You give away a limited version of your product for free, and convert a small percentage to paid. It works spectacularly well for some companies and is a slow death sentence for others.

When Freemium Works

When Freemium Does NOT Work

Freemium Benchmarks

Designing the Free Tier

The free tier should be valuable enough to be useful, limited enough to create upgrade pressure. Two approaches:

FEATURE-LIMITED

Give full access to core features but limit advanced functionality.

Example (Notion):
Free: Unlimited pages, basic blocks, 5MB file uploads, 7-day page history
Paid: Unlimited file uploads, 30-day history, databases, API access, bulk export

USAGE-LIMITED

Give full features but cap usage volume.

Example (Mailchimp):
Free: All email features, up to 500 contacts, 1,000 sends/mo
Paid: Unlimited contacts, unlimited sends, automation, A/B testing

The free tier mistake: If your free tier is too generous, nobody upgrades. If it’s too restrictive, nobody gets enough value to care. The sweet spot: 80% of free users should hit a limit within 30 days that makes them want to upgrade, not need to. The trigger should feel like growth, not frustration.

Part III

The Pricing Audit

You’ve learned the models. Now apply them. This section gives you an 8-step framework to audit any SaaS company’s pricing and a guide to designing the pricing page.

10 How to Audit Your Current Pricing

Use this 8-step framework to evaluate any SaaS product’s pricing — whether it’s your own company or a case study target.

Step 1: Map Current Pricing Structure

Document exactly what you charge, how you charge it, and what’s included at each level.

Pricing Structure Map Template

Model type: [Flat / Per Seat / Usage / Tiered / Hybrid / Freemium]
Value metric: [What do customers pay per unit of?]
Tiers: [List each tier, price, and key inclusions]
Add-ons: [Any optional modules or overages]
Discounts: [Annual, volume, enterprise negotiated]
Free tier: [Yes/No, what’s included]
Last price change: [Date and nature of change]

Step 2: Revenue Per Customer Distribution

Pull a histogram of revenue per customer. You’re looking for the shape of the distribution.

Step 3: Value Metric Alignment

Ask: Are customers paying in proportion to the value they receive?

• Identify your top 10 happiest customers (highest NPS or CSAT). What do they pay? What value do they get?
• Identify your top 10 churned customers. What did they pay? Did they feel they were paying too much for too little?
• If happy customers are paying very little (value » price), you’re underpricing.
• If churned customers felt the price was too high relative to value, your value metric is misaligned.

Step 4: Churn Analysis by Price Tier

Step 5: Competitive Comparison

Map your pricing against the top 3–5 competitors on these dimensions:

• Price per unit (seat, API call, etc.) at equivalent tiers
• What’s included at each tier vs what’s gated
• Value metric used (are they charging for the same thing?)
• Free tier / trial structure
• Enterprise pricing model (per-seat, custom, consumption)

Important: Competitive analysis informs — it doesn’t dictate. If you deliver 2x the value of a competitor, you should charge more, not match their price. The goal is to understand the market context, not to race to the bottom.

Step 6: Willingness to Pay Survey

Run a Van Westendorp or Gabor-Granger study (see Section 03). Segment by company size, use case, and buyer persona. Different segments will have very different WTP.

Step 7: Identify Expansion Gaps

Look for moments where customers hit a limit but have no way to upgrade incrementally.

Common Expansion Gaps

Gap 1: Cliff between tiers. Pro is $49/mo and Enterprise is $499/mo. Customers at $49 who need one enterprise feature (like SSO) can’t justify 10x the price. Fix: add SSO as a $50/mo add-on to Pro.

Gap 2: No usage overage. Pro includes 10,000 API calls. Customer hits 12,000. They either upgrade to Enterprise (overkill) or stay on Pro and lose data. Fix: add per-unit overage at $0.01/call above the limit.

Gap 3: Seat bundles too large. You sell in packs of 10 seats. A team of 12 has to buy 20 seats and pay for 8 empty ones. Fix: allow individual seat purchases or smaller bundles.

Gap 4: Annual-only Enterprise. A growing startup wants Enterprise features but can’t commit to annual. Fix: offer monthly Enterprise at a premium (20–30% more than monthly equivalent of annual price).

Step 8: Model Three Pricing Scenarios

Build a financial model with three scenarios and project the impact over 12 months:

Insight: The most underrated step is #7 (expansion gaps). Most SaaS companies lose 15–25% of potential expansion revenue because customers hit ceilings with no incremental way to pay more. Finding and fixing these gaps is often the single highest-ROI pricing change you can make.

11 Pricing Page Design

Your pricing page is the most visited page on your site after the homepage. It’s where buyers decide if they can afford you, if you’re serious, and which plan to choose. Here’s what the best pricing pages get right.

The Anatomy of a Great Pricing Page

Pricing Page Teardown: Notion

What Notion Gets Right

1. Four clear tiers: Free, Plus ($10/user/mo), Business ($18/user/mo), Enterprise (Contact Sales)

2. Annual default: Toggle defaults to annual pricing. Monthly shows a higher price, making annual feel like a deal.

3. “Most Popular” on Business: The Business tier is highlighted. This is their target tier for growing teams.

4. Feature comparison below: A detailed table with every feature and which tier includes it. This is the page enterprise buyers screenshot and send to their manager.

5. Free tier is generous: Unlimited pages for individuals. This is the PLG hook — get individuals addicted, then the team plan sells itself.

6. Simple value metric: “Per member per month.” Everyone understands it. No compute units, credits, or confusing metrics.

The pricing page test: Show your pricing page to someone who has never seen your product for 10 seconds, then take it away. Ask: (1) How many plans are there? (2) Which one would you pick? (3) What does the product do? If they can answer all three, your pricing page works. If they can’t, simplify.

Part IV

Experiments & Implementation

You’ve audited your pricing. You know the models. Now it’s time to make changes — and that means raising prices, running experiments, managing discounts, and building a process for ongoing review.

12 How to Raise Prices

Raising prices is the scariest thing most SaaS teams do. It doesn’t have to be. Here’s the playbook that minimises risk and maximises revenue impact.

The Price Increase Playbook

Price Increase Communication Template

To: All Customers · Email

Updates to [Product] plans

Hi [Name],

Over the past 12 months, we’ve shipped [specific improvements — 3–4 bullet points]. These investments have made [Product] significantly more powerful, and our customers are seeing real results: [1–2 customer proof points].

To continue investing at this pace, we’re updating our pricing effective [date — 60+ days out]. Your current plan of [current plan] at [current price] will move to [new price].

What this means for you:
• Your price stays the same through [grandfather date].
• If you’d like to lock in your current rate for the next 2 years, switch to annual billing before [date].
• All features you currently have will remain — nothing is being removed.

If you have any questions, reply to this email or book time with your account manager: [link].

[CEO Name]
Founder & CEO, [Company]

Why this template works: (1) Leads with value delivered, not cost increase. (2) Gives 60+ days notice. (3) Offers a lock-in option that converts monthly-to-annual. (4) Comes from the CEO (signals importance and respect). (5) Grandfather period reduces churn shock.

Expected impact of a well-executed 15–20% price increase: Incremental churn of 1–3%. Net ARR increase of 12–17%. 20–30% of monthly customers convert to annual (lock-in offer). Support ticket volume spikes for 2 weeks, then normalises. NPS dips 2–5 points for 1 quarter, then recovers.

13 Pricing Experiments

How to test pricing changes without betting the company on a guess.

A/B Testing Pricing: The Rules

What to Measure in a Pricing Experiment

Experiment Design: Worked Example

Experiment: Testing a 20% price increase on Pro tier

Hypothesis: Increasing Pro tier from $49/mo to $59/mo will reduce conversion by <10% but increase ACV by 20%, resulting in net positive revenue impact.

Control (Cohort A): All signups in March — see $49/mo Pro pricing.
Test (Cohort B): All signups in April — see $59/mo Pro pricing.

Sample size: Need 200+ signups per cohort for statistical significance on conversion.

Measurement window: 90 days from start of each cohort.

Success criteria:
• Conversion drop < 10% (from 5.0% to no less than 4.5%)
• 90-day churn no more than 1.5% higher
• Revenue per cohort (ACV × conversions × retention) is higher for Cohort B

Decision: If all criteria met, roll $59 pricing to all new customers. If conversion drops >10% but retention is identical, try $54 as a middle ground.

14 Discount Strategy

Discounts are the most abused tool in SaaS sales. Used well, they accelerate deals and lock in long-term revenue. Used poorly, they destroy pricing integrity and train buyers to always ask for less.

When to Discount

When to NEVER Discount

Discount Authority Matrix

The Trade-for-Trade Framework

Never give a discount without getting something in return. Every concession should be a trade.

Trade-for-Trade Examples

“I can do 15% off if you sign a 2-year term instead of 1-year.”

“I can do 10% off if you commit to 100 seats instead of 50.”

“I can do 20% off if you agree to a published case study within 6 months.”

“I can waive the onboarding fee if you pay annually upfront.”

“I can match that price if you sign by Friday and remove the legal redlines.”

The psychology: when you give something, ask for something. It signals that your pricing has integrity. The buyer respects you more, not less.

Insight: The best sales teams have a discount rate under 8% of list price on average. The worst have 25%+. The difference is not generosity — it’s discipline, value selling, and a clear discount policy that everyone follows.

15 The Pricing Committee

Pricing is too important to be owned by one person and too cross-functional to be owned by one team. You need a Pricing Committee.

Who Sits on the Pricing Committee

How Often to Review Pricing

The Quarterly Pricing Review: What to Bring

Pricing Committee Quarterly Agenda

1. Revenue Dashboard (Finance)
• ARR, ARPU, NRR by tier
• Revenue per customer histogram
• Expansion and contraction revenue trends

2. Win/Loss Analysis (Sales)
• Win rate by tier
• Average discount given (by tier, by AE, by deal size)
• Top 5 losses where price was the stated reason
• Competitive pricing intelligence updates

3. Product Usage Data (Product)
• Feature usage by tier (are Pro features being used? Are Enterprise features worth the price?)
• Usage patterns near tier limits (are customers hitting ceilings?)
• Upcoming features that could justify price changes

4. Churn & Retention (Finance / CS)
• Churn by tier and by price point
• Downgrade patterns (who’s moving to lower tiers and why)
• NPS by price tier

5. Recommendations (All)
• Proposed changes with financial models
• Experiment designs for testing changes
• Timeline for implementation

The discipline: Companies that review pricing quarterly grow revenue 30% faster than companies that set-and-forget. The review doesn’t have to result in changes every quarter — often the data confirms your current pricing is right. But when it’s wrong, you catch it 3 months earlier than everyone else.

The Pricing Strategy Checklist

Know your value metric       what scales with value received
Measure willingness to pay    Van Westendorp or Gabor-Granger, not guessing
Pick the right model         flat, seat, usage, tiered, hybrid, or freemium
Design tiers for upgrade     middle tier = best value, clear path up
Audit quarterly            revenue distribution, churn by tier, expansion gaps
Test before you ship        cohort-based experiments, 90-day measurement window
Raise prices annually       grandfather existing, test on new, communicate value
Never discount without a trade   every concession earns something back

Pricing is not a launch decision. It is a continuous process. Revisit it every quarter.

the playbook · framework · templates · worked examples

Competitive Intel Sales Enablement Account Executives Product Marketing Deal Strategy

Every deal you lose to a competitor is a deal where the AE didn’t have the right information at the right moment. The buyer asked “why not go with [Competitor X]?” and your rep fumbled. Or worse — the buyer never mentioned the competitor, and your rep never asked, and the deal died silently to an alternative you didn’t even know was in play.

Battle cards fix this. They’re one-page tactical cheat sheets that give AEs exactly what they need during a live deal: what the competitor does well, where they’re weak, what questions to plant with the buyer, and how to respond when the buyer pushes back with competitor claims. Not a strategy deck. Not a market analysis. A weapon.

Who this is for: MBA interns building competitive intelligence for the first time, product marketing teams creating enablement materials, AEs who want to win more competitive deals, and founders who need to arm their sales team against specific competitors.

Part I

Why Battle Cards

Before building anything, you need to understand what battle cards are, what they’re not, and where the intelligence comes from. Most competitive analysis is useless because it’s written for the wrong audience. Battle cards are written for one person: the AE in the middle of a deal.

01 What Battle Cards Are

A battle card is a one-page competitive intelligence sheet designed to be used during live sales conversations. It answers a single question: “How do I win against this specific competitor?”

Battle cards are not:

• Market landscape documents. Those are for executives and board decks. AEs don’t need a 2x2 matrix — they need a comeback for “but Competitor X has a free tier.”
• Feature comparison spreadsheets. A 200-row feature checklist helps nobody in a live conversation. The buyer doesn’t care about 190 of those features.
• Strategy memos. Your competitive strategy might be “move upmarket and ignore them.” The battle card is what the AE says when the buyer brings them up anyway.

When to Use Battle Cards

Insight: The best battle cards are brutally honest. If your competitor is better at something, say so. AEs who get caught lying about competitor capabilities lose all credibility. The card should say: “They’re better at X. Here’s why it doesn’t matter for this buyer.”

02 How to Build One — Research Sources

Great battle cards are built on intelligence, not opinion. The best competitive researchers use a systematic set of sources. Here’s where to look, in order of value:

The 80/20 rule for research: G2 reviews + your own lost deals + their website = 80% of what you need. Don’t spend two weeks building the perfect dossier. Spend 4-6 hours per competitor, then iterate based on what AEs actually ask about in live deals.

Research Process: Step by Step

1. Start with your CRM. Pull every closed-lost deal where this competitor was mentioned. Read the notes. Talk to the AEs who lost. This is the highest-signal data you have.
2. Read 30-50 G2 reviews. Categorize complaints into themes. “Slow support” mentioned 12 times is a real weakness. “Ugly UI” mentioned twice is an outlier.
3. Screenshot their pricing page. Most competitors change pricing quarterly. You want a timestamped record.
4. Sign up for their product. Use a personal email. Go through their onboarding. Note what’s good and what’s painful. Take screenshots.
5. Read their case studies. Who are their best customers? What outcomes do they highlight? These are their strongest talking points — you need to be prepared for them.
6. Check job postings. What are they hiring for? 10 new enterprise AE roles = they’re going upmarket. 5 data scientist roles = AI product incoming.
7. Draft the card. Use the template in Section 3. Get feedback from 2-3 AEs who’ve competed against them.

Part II

The Framework

The exact template every battle card should follow, plus three complete worked examples you can adapt to your competitors. The template is opinionated by design — every section exists because AEs asked for it in live deals.

03 The Battle Card Template

Every battle card follows this exact structure. Ten sections. One page (front and back if printed, single scroll if digital). Nothing extra, nothing missing.

The honesty rule: Section 5 (Where They Win) is the most important section on the card. If your AEs don’t trust the card, they won’t use it. Being honest about competitor strengths builds credibility for everything else on the page. A card that says “they have no strengths” is a card that gets ignored.

Section-by-Section Guidance

Section 1: Competitor Overview

One sentence maximum. The AE needs context, not a Wikipedia article.

GOOD “DataCorp is a legacy on-prem data warehouse vendor (founded 2003, ~2,400 employees, $180M ARR) that’s been bolting on a cloud offering since 2021.”

BAD “DataCorp is a leading provider of enterprise data management solutions headquartered in Dallas, TX. They serve over 500 enterprise customers across industries including financial services, healthcare, and manufacturing…”

Section 5: Where They Win

This section must be honest. If you lie here, AEs will find out in live deals and stop trusting the card.

GOOD
• Deep regulatory compliance. They have FedRAMP High, SOC 2 Type II, and HIPAA BAA out of the box. We only have SOC 2 Type II today.
• Established enterprise relationships. Their sales team has existing MSAs with most F500 procurement departments. Buying from them is easier politically.
• On-prem deployment option. For air-gapped environments (defense, some financial), they’re the only option. We’re cloud-only.

BAD
• “They have good marketing but not a great product” (vague, dismissive)
• “Some customers like their UI” (damning with faint praise — AEs see through this)

Section 7: Landmine Questions

Landmine questions are questions you coach the buyer to ask every vendor in the evaluation — questions that your product answers well and the competitor answers poorly. The buyer doesn’t know they’re landmines. They just think they’re doing thorough due diligence.

The psychology: Buyers trust their own conclusions more than anything a sales rep tells them. If YOU say “Competitor X has bad support,” the buyer is skeptical. If the buyer asks Competitor X about support response times and gets a vague answer, the buyer concludes on their own that support is weak. Same conclusion, 10x more persuasive.

Section 10: Trap Avoidance

Your competitor has their own battle card about you. They’re planting their own landmines. This section prepares AEs for the attacks that are coming.

04 Three Worked Examples

Below are three complete, realistic battle cards. They’re fictional companies, but the patterns are real. Every B2B SaaS company faces these three archetypes: the legacy incumbent, the direct competitor, and the “build it ourselves” option.

Battle Card A: Us vs Legacy Incumbent

Scenario: You sell a modern cloud-native data platform. The incumbent is a 20-year-old on-prem vendor trying to add a cloud layer.

Battle Card B: Us vs Direct Competitor

Scenario: You both sell cloud-native analytics platforms. Similar product, similar stage, different positioning. They emphasize self-serve BI; you emphasize the data platform layer.

Battle Card C: Us vs DIY / Internal Build

Scenario: The most common “competitor” isn’t a company — it’s the prospect’s own engineering team saying “we can build this ourselves.” Or worse: doing nothing at all.

Part III

Using Battle Cards in Deals

Having a battle card and using it well are different skills. This part covers how to deploy competitive intelligence at each stage of the sales cycle — from discovery to negotiation to post-mortem.

05 In Discovery — Surfacing the Competitive Landscape

The first rule of competitive selling: never ask “who else are you evaluating?” directly. It puts the buyer on the defensive. They’ll either lie (“just looking around”) or use it as leverage (“oh, we’re talking to everyone”). Instead, surface the competitive landscape indirectly.

Indirect Probing Techniques

Example Discovery Dialogue

AE (You):

“Walk me through what’s driven this evaluation. What’s happening internally that made this a priority now?”

Buyer:

“Our data team is drowning. We have 40+ dashboards and nobody trusts the numbers. The CFO asked for a revenue report last week and got three different answers from three different tools.”

AE:

“That’s painful. What are those three tools, out of curiosity?”

Buyer:

“We’ve got a mix of Metabase, some Google Sheets, and a couple of analysts writing raw SQL against the warehouse.”

AE:

“Got it. So you’re looking to consolidate onto one platform. What does the evaluation process look like on your side? Are you looking at a couple of options, or is this wider than that?”

Buyer:

“We’re looking at a few things. Our VP Product really likes CloudMetrics — she used it at her last company. And our VP Eng thinks we should just build something on top of dbt and Superset.”

What just happened: Without asking “who are your competitors?” directly, you now know: (1) CloudMetrics is in play, championed by the VP Product, (2) DIY is in play, championed by the VP Eng, (3) the buying committee has at least 3 voices (CFO triggered the eval, VP Product has a preference, VP Eng has a different preference). You can now pull the CloudMetrics and DIY battle cards.

Reading the Tea Leaves

Sometimes the buyer won’t name competitors directly. Watch for these signals:

06 In Demo — Positioning Without Naming Competitors

During the demo, you have 30-45 minutes to differentiate. The goal is to position your strengths in ways that expose competitor weaknesses — without ever naming the competitor. Here’s why: if you trash-talk a competitor by name, the buyer mentally defends them. If you describe a capability gap without naming anyone, the buyer connects the dots themselves.

The Two Approaches

BAD: Naming Competitors

“Unlike CloudMetrics, we have a full semantic layer that ensures metric consistency across all your dashboards. CloudMetrics doesn’t have this, which is why their customers end up with conflicting numbers.”

GOOD: Positioning by Capability

“One of the things that makes us different is our semantic layer. Every metric is defined once, centrally, and every dashboard pulls from that definition. Teams that don’t have this — regardless of which tool they use — typically end up with 50+ dashboards showing conflicting numbers. Our customers don’t have that problem.”

Why the second approach wins: (1) You never look petty or threatened. (2) The buyer who’s evaluating CloudMetrics immediately thinks “wait, CloudMetrics doesn’t have a semantic layer…” (3) You’ve planted a buying criterion (semantic layer) that favors you without making it feel like an attack.

Differentiation Talking Points by Competitor Type

When the Legacy Incumbent is in Play

Emphasize during the demo:

• “Let me show you how fast this is.” Run a live query on a large dataset. Let the speed speak for itself. The buyer will compare it mentally to the 45-second query on the legacy platform.
• “We’ll be live in 2 weeks.” Mention time-to-value early and often. The legacy vendor is quoting 4-6 months. You don’t need to say that — the buyer knows.
• “Your team already knows the tools.” Show dbt integration, SQL editor, Python notebooks. The message: your team can start productive on Day 1 with no training. The legacy tool requires proprietary training.
• “Here’s the total cost: one line item.” Show transparent pricing. No hidden infra fees, no professional services surcharge, no Year 2 surprises.

When the Direct Competitor is in Play

Emphasize during the demo:

• Start with the self-serve dashboard builder. Don’t lead with the data engineering features. Prove that PMs can use it first. Then go deeper. This defuses the “your tool is for engineers” attack.
• “Let me show you the semantic layer.” Build a metric definition live. Then show how that definition flows to every dashboard. Plant the “metric consistency” criterion.
• “Now let me show you what happens at scale.” Run a query on 100M+ rows. Fast. The direct competitor chokes at this scale, and the buyer will test them on it next.
• “Your data team and your product team use the same platform.” Show SQL alongside no-code. The message: you don’t need two tools.

When DIY is in Play

Emphasize during the demo:

• “This took us 4 years and 80 engineers to build.” Casually mention the engineering investment. Let the buyer do the math on what it would cost them internally.
• “Monitoring, alerting, access controls, audit logs — all built in.” Show the things that custom builds always skip in V1 and regret in V2.
• “Live in 2 weeks.” The internal build timeline is 6-12 months. You don’t need to say that. Just show the speed.
• “And your engineers can go back to building [their product].” Name what the company actually does. “Your engineers can go back to building the recommendation engine instead of maintaining Airflow DAGs.”

07 In Negotiation — When Buyers Use Competitors as Leverage

This is where deals are won and lost. The buyer has chosen you (probably) but is using competitor pricing to extract a discount. This is normal, expected, and manageable — if you don’t panic.

The Most Common Scenario

Buyer:

“Look, we like your platform, but CloudMetrics quoted us 40% less. I need you to come down on price or I can’t get this through procurement.”

What NOT to Do

• Don’t immediately offer a discount. The moment you drop price without resistance, the buyer knows there’s more room. They’ll ask again.
• Don’t trash the competitor’s pricing. “Well, you get what you pay for” is condescending and unhelpful.
• Don’t bluff. “Our pricing is firm” when it isn’t. The buyer will call your bluff and you’ll fold, losing credibility.

The Response Framework: Acknowledge, Reframe, Offer

AE:

“I appreciate you sharing that, and I want to be transparent about our pricing. CloudMetrics is a great product for self-serve dashboards. Our platform includes the data warehouse, pipelines, modeling layer, and BI — so it’s not an apples-to-apples comparison.”

[Acknowledge the competitor. Don’t dismiss them. Reframe the comparison.]

AE:

“If you go with CloudMetrics, you’ll still need a separate warehouse ($X), an ETL tool ($Y), and dbt ($Z). When you add those up, the total stack cost is actually comparable or higher than us — and you’re managing four vendors instead of one.”

[Show the math. Make it about total cost, not unit price.]

AE:

“That said, I want to make this work. If annual commitment is on the table, I can offer [specific concession — e.g., 15% discount on a 2-year deal, or free onboarding]. Does that help get this through procurement?”

[Offer value, not just discount. Tie the concession to a commitment.]

Price Negotiation Tactics

The golden rule of negotiation: Never give a concession without getting something back. Discount for a longer commitment. Free onboarding for a case study. Extra seats for a reference call. Every “give” should have a “get.”

08 Win/Loss Analysis

The best battle cards are built on win/loss data, not opinions. After every competitive deal — win or lose — you should run a structured debrief. Wins tell you what’s working. Losses tell you where to improve. Both feed back into the battle card.

The Interview Template (Lost Deals)

This should be conducted by someone other than the AE who lost the deal (product marketing or sales enablement). The AE is too close to the deal to get honest answers from the buyer.

Win/Loss Tracking System

The pattern to watch for: If you lose 3+ deals to the same competitor for the same reason, that’s not a sales problem — it’s a product or positioning problem. Escalate to product leadership with the data. “We lost 4 deals to CloudMetrics in Q3. In all 4, the buyer said our self-serve UX wasn’t good enough for non-technical users. Here are the quotes.”

Part IV

Operations

A battle card that’s 6 months old is worse than no battle card at all. This section covers how to keep cards accurate, where to store them, and how to train AEs to actually use them in live deals.

09 Keeping Cards Updated

Ownership

Update Cadence

What to Monitor

Set up alerts for these competitive signals:

• Their blog and changelog. RSS feed or Google Alert. New features and product updates.
• Their pricing page. Screenshot monthly. Use Visualping or similar to detect changes.
• Their job postings. New roles reveal strategic direction. A “Head of Enterprise” hire means they’re moving upmarket. 20 new SDR postings means they’re scaling outbound.
• G2 reviews. Set up a monthly review of new reviews. Track sentiment changes over time.
• Crunchbase / PitchBook. Funding rounds, acquisitions, key hires.
• Social media. Follow their executives on LinkedIn and Twitter. They’ll announce things before the press release.
• Their customers. Track when their logos change. If a big customer leaves, find out why.

Insight: A battle card that was accurate 6 months ago and hasn’t been updated is actively harmful. Your AE quotes a competitor’s old pricing, the buyer corrects them, and now your AE has lost credibility. Outdated cards are worse than no cards. If you can’t commit to keeping them updated, don’t build them.

10 Distribution & Training

The most common failure mode for battle cards: product marketing spends 40 hours building beautiful cards, uploads them to a shared drive, sends a Slack message saying “new battle cards are live!”, and nobody uses them. Distribution and training are just as important as the content.

Where to Store Battle Cards

Training AEs to Actually Use Them

Uploading cards to a wiki is not enablement. Here’s how to make AEs actually use battle cards in live deals:

1. Launch with a Live Session (Not a Slack Message)

For each new or updated card, run a 30-minute session with the sales team:

• 10 min: Walk through the card. Highlight what’s new.
• 10 min: Role-play the 2-3 most common objections from that competitor.
• 10 min: Q&A. “What are you hearing in deals that’s not on this card?”

2. Role-Play Exercises

The most effective way to train competitive selling. Run these monthly.

Role-Play Scenario 1: Legacy Incumbent in Play

Setup: You’re demoing to a VP Data at a 2,000-person company. They’ve been using DataCorp for 5 years. The CIO is comfortable with DataCorp but the VP Data is frustrated with performance and cost. Halfway through the demo, the VP Data says:

“This is impressive, but honestly, our CIO is going to push back hard. DataCorp has been here forever and the switching costs scare him. How do I make the case internally?”

What you practice: Arming the champion. Giving the VP Data the talking points to sell internally. The parallel deployment story. The ROI model. The risk mitigation plan.

Role-Play Scenario 2: Price Pressure from Direct Competitor

Setup: You’re in negotiation with a Head of Analytics at a Series C startup. They love your product but the CFO is pushing back on price. The buyer says:

“CloudMetrics is offering us 50 seats at $45/user/month. You’re asking $120/user/month. I personally prefer your platform, but I need to justify that 3x price difference to my CFO. Help me out.”

What you practice: The total cost of ownership argument. Building the ROI model together. Offering creative deal structures (fewer seats to start, annual commitment for a discount, free onboarding).

Role-Play Scenario 3: The DIY Objection

Setup: You’re in discovery with a CTO. The conversation is going well, but then:

“Look, I’ve been thinking about this. We have 8 data engineers. Airflow, dbt, and Superset are free. My VP Eng thinks we can build what we need in 3 months. Why would I pay you $200K a year?”

What you practice: The cost math (engineers are not free). The timeline reality (it’s always 3x). The opportunity cost (what those engineers could build instead). The risk (what happens when the builder leaves).

3. Integrate Into Deal Reviews

In every deal review or pipeline meeting, ask:

• “Which competitors are in this deal?”
• “Have you reviewed the battle card?”
• “Which landmine questions have you planted?”
• “What’s the competitor’s likely attack against us in this deal?”

When battle cards are part of the deal review process, AEs use them because they’ll be asked about them.

4. Celebrate Competitive Wins

When an AE wins a deal against a named competitor, share the story in Slack with specifics:

#wins channel:

Closed HealthTech Co ($140K ACV) against DataCorp.

What worked: Planted the “run a live query on 1TB” landmine question. DataCorp’s demo took 90 seconds per query. Ours took 3 seconds. The VP Data said that was the moment the decision was made.

Battle card in action. Update: added this as a win story on the DataCorp card.

The metric that matters: Track “battle card influenced win rate.” Compare win rates in competitive deals where the AE used the battle card vs. deals where they didn’t. In our experience, battle card usage improves competitive win rates by 15-25 percentage points. That’s the number that justifies the investment in building and maintaining them.

The Battle Card Checklist

Be honest about competitor strengths     AEs who get caught lying lose all credibility
Back weaknesses with evidence          G2 quotes, customer complaints, specific data
Landmine questions, not feature lists    let the buyer discover weaknesses themselves
Never name competitors in demos        position by capability, not by attack
Never discount without getting something   longer commitment, case study, reference
Update quarterly or don’t bother         outdated cards are worse than no cards
Role-play monthly                     reading a card is not the same as using it
Track competitive win rate              the metric that justifies everything

The goal is not to trash competitors. The goal is to help the buyer make the best decision — and make sure they have the information to see why that decision is you.

the 5-act framework · scripts · objection handling · templates

Enterprise Sales Product Demos AE Playbook SaaS MBA Interns

Most demos fail. Not because the product is bad, but because the demo is a feature tour disguised as a conversation. The rep opens the product, starts clicking through screens, and narrates what they see: “And here you can see the dashboard… and over here is the reporting module… and this is where you’d configure your integrations.” The prospect nods politely, says “this looks great, let me loop in my team,” and then goes silent forever.

This playbook teaches a different approach. A demo is not a product tour. It is a performance — a carefully structured 25-minute act where every click, every sentence, and every pause is designed to make the prospect say: “Yes, this solves my problem. What do we do next?”

Who this is for: AEs running enterprise demos, MBA interns learning SaaS sales, SEs who want to understand what happens before they take over, and sales leaders designing demo playbooks for their team.

Part I

Foundations

Before you open the product, you need to understand why most demos lose deals, the 5-act structure that wins them, and how to prepare so thoroughly that the demo feels effortless.

01 Why Most Demos Fail

The data is brutal: 60% of enterprise deals are lost because of bad demos, not bad products. Gartner’s 2024 B2B Buying survey found that the single largest predictor of a stalled deal is the prospect’s experience during the demo — not price, not features, not competitors. A bad demo kills deals that were otherwise winnable.

Why? Because most demos commit the same sin: they show the product instead of solving the problem.

The “Show Up and Throw Up” Anti-Pattern

This is what 80% of demos look like:

The typical demo · What the prospect actually hears

“Let me start by giving you a quick overview of our platform…”
[Prospect thinks: I didn’t ask for an overview.]

“So here’s the main dashboard. You can see all your data in real-time…”
[Prospect thinks: I don’t care about your dashboard. I care about my problem.]

“And over here is our AI-powered analytics engine, which is really exciting…”
[Prospect thinks: Exciting to whom? What does this do for me?]

“Let me show you the integrations page — we integrate with over 200 tools…”
[Prospect thinks: Do you integrate with the ONE tool I care about?]

“Any questions?”
[Prospect thinks: I have no idea what I just watched. “Looks great, let me get back to you.”]

What went wrong: The rep showed every feature without connecting any of them to the prospect’s actual problems. The prospect sat through 25 minutes of someone else’s agenda. They were polite. They said “looks great.” And then they ghosted — because nothing in that demo gave them a reason to change how they work today.

Feature Tour vs Pain-Based Demo

Insight: A demo is not a product tour. It is a conversation where the product appears as evidence. The prospect’s problems are the agenda. The product is the proof.

The Three Reasons Demos Fail

1. No discovery recap. The AE jumps straight into the product without confirming they understand the problem. The prospect sits there wondering: “Did they even listen to me last time?”
2. Feature-first structure. The demo follows the product’s navigation instead of the prospect’s priorities. The thing they care about most might be screen #7 in the product, but it should be minute #3 in the demo.
3. No trial close. The demo ends with “any questions?” instead of “does this solve the problem we discussed?” Without a trial close, you leave with no information about where you stand — and the prospect has no psychological commitment to move forward.

02 The Demo Framework — 5 Acts in 25 Minutes

Every winning demo follows the same structure. It doesn’t matter what you’re selling — dev tools, HR software, financial platforms, security products. The structure is universal because it mirrors how human decision-making works: confirm the problem, set expectations, show the solution, differentiate, and ask for a commitment.

Total time: 25 minutes. Not 45. Not 60. Enterprise buyers have short attention spans and packed calendars. If you can’t make your case in 25 minutes, you don’t understand it well enough. Book a 30-minute slot. Use 25. Give them 5 minutes back. They’ll remember that.

The Emotional Arc

A great demo has an emotional arc, not just an information arc:

03 Pre-Demo Prep

The demo is won or lost before you open Zoom. The best AEs spend 2–3x more time preparing than they spend presenting. A 25-minute demo should have 45–75 minutes of prep behind it.

The Pre-Demo Checklist

The customization test: If you could give this exact same demo to a different prospect without changing anything, you haven’t prepared enough. A great demo feels like it was built specifically for the person watching it — because it was.

Know Who’s in the Room

Part II

The Demo Script

Word-for-word scripts for each act. Adapt the specific content to your product, but keep the structure and psychology intact. These scripts are battle-tested across thousands of enterprise demos.

04 Act 1: Recap Discovery (2 Minutes)

Goal: Reconnect the prospect to the pain they told you about. Prove you listened. Get them nodding before you show a single screen.

This is the most important two minutes of the demo. If you nail the recap, the prospect trusts you for the next 23 minutes. If you skip it, they spend the whole demo wondering whether you actually understand their problem.

The Script

Act 1 Script · 2 minutes · No product on screen yet

“Before I show you anything, I want to make sure I’ve got the right context from our last conversation. You mentioned three things that were keeping you up at night:

First — . You said this was costing you roughly.

Second — . And the downstream effect was.

Third — ``.

Did I capture that right? Is there anything that’s changed since we last spoke, or anything I’m missing?”

Why this works: (1) “Before I show you anything” signals that this demo is about them, not your product. (2) Using their exact words from discovery proves you listened — the most powerful sales move there is. (3) Quantifying the pain ($X/month) keeps the cost of the problem front and center. (4) “Did I capture that right?” invites them to correct you, which gives you even better information for the demo. (5) “Anything changed?” catches new context that could shift your entire demo.

What If They Correct You?

If they add a new pain or re-prioritize

“That’s really helpful — I’m glad you mentioned that. Let me adjust what I was going to show you. I’ll start with `` since that sounds like the most urgent piece, and then we’ll cover the other two. Sound good?”

This is a gift, not a problem. When the prospect corrects your recap, they’re giving you a real-time update on what will close the deal. Adapt on the fly. This is where prepared AEs crush unprepared ones.

What If Multiple People Are on the Call?

Multi-stakeholder opener

“I know some of you are joining for the first time, so let me quickly set the context. and I spoke last week and identified three areas where is losing time and money. I’ll recap those in 30 seconds, and then I want to hear from everyone — especially if I’m missing something your team cares about.

The three problems we identified were…”

05 Act 2: Set the Agenda (1 Minute)

Goal: Tell them exactly what they’re about to see, how long it’ll take, and what happens at the end. This reduces anxiety, builds trust, and creates the “fairness contract” that makes the trial close feel natural.

The Script

Act 2 Script · 1 minute · Still no product on screen

“Great. Here’s how I’d like to use the next 20 minutes. I want to show you three things, each one tied directly to the problems we just discussed:

One — how we solve . **Two** — how we handle.
Three — how we address ``.

At the end, I’m going to ask you a straight question: does this solve the problem we discussed? If the answer is yes, we’ll talk about next steps. If the answer is no, or if we’re not the right fit, I’ll tell you that — and I’ll point you to whoever might be a better fit. Fair?”

Why the “fairness contract” is the most important sentence in the entire demo:

(1) “I’ll ask you a straight question” — This pre-commits the prospect to giving you a real answer at the end. Without this setup, the trial close at the end feels abrupt. With it, it feels expected.

(2) “If we’re not the right fit, I’ll tell you that” — This is disarming. Most salespeople would never say this. By saying it, you position yourself as an advisor, not a closer. The prospect’s guard goes down.

(3) “Fair?” — One word that creates a micro-agreement. When they say “fair” or “sounds good,” they’ve psychologically committed to the framework. This makes the trial close at the end feel like following through on a mutual agreement, not a surprise sales tactic.

Why You Don’t Show the Product Yet

Notice that Acts 1 and 2 are three minutes long and the product hasn’t appeared on screen. This is deliberate. The first three minutes are a framing exercise. You’re setting the lens through which they’ll see everything else. Without this framing, the prospect watches the demo through their own random lens — “is this easy to use?” / “does this look modern?” / “I wonder if this integrates with Salesforce.” With the framing, they watch through the lens you set: “does this solve my three problems?”

Insight: The best demo you’ll ever give has 3 minutes of no product and 22 minutes of targeted product. The worst demo you’ll ever give has 25 minutes of product and 0 minutes of context.

06 Act 3: Pain → Solution Mapping (15 Minutes)

Goal: Show exactly how your product solves their top 3 problems. Organized by their problems, not by your product’s navigation. Every click on screen should connect back to something they told you in discovery.

The Structure for Each Pain

For each of the three pains, follow this micro-structure (5 minutes per pain):

The check-in is non-negotiable. After each pain block, pause and ask. This does three things: (1) confirms you’re on the right track, (2) surfaces hidden objections early, and (3) keeps the prospect engaged instead of passively watching. If they say “actually, we’d need it to also do X” — that’s gold. That’s a requirement you can solve for in the next round.

Worked Example 1: Selling a Spend Management Platform to a CFO

Pain #1 · “We have no visibility into department-level spending”

Restate: “You mentioned that right now, if the CEO asks you ‘how much did engineering spend on cloud last quarter,’ it takes your team 2-3 days to pull that number from spreadsheets and expense reports.”

Show: [Opens the platform, which is pre-configured with the prospect’s department structure and realistic spend data]

“This is what your spend looks like in our platform. I’ve set up your department structure — engineering, product, sales, marketing. Watch what happens when I click into engineering…”

[Clicks. Shows real-time spend broken down by vendor, team, and month.]

“That 2-3 day question? It’s now a 10-second answer. And it updates in real-time as transactions come in.”

Quantify: “For a finance team your size, our customers typically reclaim 15-20 hours per month that were going into manual spend reconciliation.”

Check-in: “Does that match the problem you’re seeing? Is there a specific cut of the data you’d want that I’m not showing?”

Worked Example 2: Selling an Observability Tool to a VP of Engineering

Pain #2 · “When something breaks in production, it takes 45 minutes to find the root cause”

Restate: “You told me that your MTTR is around 45 minutes, and most of that time is engineers jumping between Datadog, CloudWatch, and Slack trying to correlate events.”

Show: [Opens a pre-configured incident scenario using their actual service names]

“I’ve set up a simulated incident for your checkout-service. Watch what happens when the error rate spikes…”

[Shows the platform automatically correlating logs, traces, and metrics. Root cause highlighted in red.]

“The platform identified the root cause in 90 seconds — it was a config change in the payment gateway that increased latency by 400%. No tab-switching, no manual correlation.”

Quantify: “Going from 45-minute MTTR to under 5 minutes — for a team shipping to 2M users, that’s the difference between a P1 incident and a blip nobody notices.”

Check-in: “Is that the kind of incident you’d typically see? Or are your root causes usually somewhere else?”

Worked Example 3: Selling an HR Platform to a VP of People

Pain #3 · “Our onboarding process is a mess — new hires don’t feel productive for 3-4 weeks”

Restate: “You said new hires are getting a Google Doc with 47 links on day one and basically left to figure it out. The result is 3-4 weeks before they’re productive, and about 15% of new hires cite onboarding as a reason for leaving within 6 months.”

Show: [Opens a pre-built onboarding workflow with the prospect’s company branding]

“This is what Day 1 looks like for a new hire at `` in our platform. Instead of a Google Doc, they get a guided experience — tasks show up in sequence, each one has a responsible person, and their manager gets a dashboard showing exactly where they are.”

[Clicks through the new hire’s view, then switches to the manager’s dashboard.]

“No more ‘did you set up your Okta yet?’ Slack messages. The manager can see it all in one place.”

Quantify: “Our customers at your stage typically see time-to-productivity drop from 3-4 weeks to 8-10 days. For a company hiring 15 people per quarter, that’s roughly 60 productive days per year you’re getting back.”

Check-in: “Does that workflow match how you’d want onboarding to look? Anything you’d change?”

The pattern across all three examples: (1) Restate the pain in their words with their numbers. (2) Show the product solving that exact pain with their data. (3) Quantify the impact in terms that matter to them. (4) Check in to keep them engaged and surface objections. This is not a feature tour. It’s a problem-solving conversation with live evidence.

Transition Between Pains

Don’t just jump to the next feature. Use a transition that reinforces the emotional arc:

“Great — so that’s how we handle . The second thing you mentioned was, and you said it was actually the one causing the most friction with your team. Let me show you how that changes…”

07 Act 4: Differentiation (5 Minutes)

Goal: Position against competitors and alternatives without trashing anyone. The prospect is almost certainly evaluating 2–3 other solutions. They’re thinking “why this over X?” even if they don’t say it. Address it head-on.

The Golden Rule of Competitive Positioning

Insight: Never trash a competitor. The moment you say “Competitor X is terrible because…” you look insecure, you insult the prospect’s intelligence (they might have liked that product), and you turn the conversation into a debate instead of a decision. Instead: acknowledge the competitor, name the specific difference, and let the prospect decide.

The Script Framework

Competitive positioning script · Adapt to your specific competitors

“You might be wondering how this compares to ``, since I know you’re [evaluating them / using them today]. Totally fair question.

is a good product — they do well. The key difference is ``.

Specifically:

They optimize for . **We optimize for**.

For a team like yours, where the priority is , that difference matters because.”

Example: Positioning Against an Incumbent

Example · Selling a modern data platform against a legacy tool

“I know you’re currently using Informatica for your ETL pipelines. Informatica is a proven tool — they’ve been in the market for 20+ years and they handle complex enterprise transformations well.

The key difference is speed of iteration. Informatica was built for a world where data pipelines change quarterly. Our platform was built for a world where they change daily. When your data team needs to add a new source or modify a transformation, it takes minutes in our tool versus the weeks you described in discovery.

For a team that’s trying to become more data-driven and move faster, that iteration speed is the difference between the data team being a bottleneck and the data team being an accelerator.”

What this does: (1) Acknowledges Informatica is good — this builds credibility. (2) Doesn’t list 10 differences — picks the ONE that matters most to this prospect. (3) Connects the differentiation back to their stated priority from discovery. (4) Positions it as a trade-off, not a “we’re better” claim.

Handling “Why Not Just Build It Ourselves?”

“That’s a fair question, and a lot of engineering-led companies consider it. Here’s what we’ve seen: teams that build in-house spend 3–6 months getting to a V1 that covers maybe 60% of what you’d need. Then the engineer who built it leaves, or priorities shift, and the internal tool becomes legacy code that nobody wants to maintain.

The math usually comes down to this: your engineers cost you $150–$200K/year fully loaded. Two engineers for 6 months is $150–$200K in opportunity cost — and that’s just the build, not the ongoing maintenance. Our platform costs ``/year, it’s maintained by a team of 50 engineers, and it’s production-ready today.

The question isn’t whether you can build it — you absolutely can. The question is whether you should build it, given everything else your engineering team could be working on.”

Handling “We’re Also Looking at [Competitor]”

“Good — you should be. We’d want you to make an informed decision. Can I share what we hear from customers who’ve evaluated both?

The typical feedback is: is easier to set up for simple use cases, and our platform is stronger when you need. Given what you told me about ``, I think you’ll find that’s where the decision hinges.

Happy to do a side-by-side if that would be helpful.”

08 Act 5: Close the Demo (2 Minutes)

Goal: Get a clear signal. Don’t leave the demo without knowing where you stand. The trial close is the moment of truth — and it only feels natural because you set it up with the fairness contract in Act 2.

The Trial Close Script

The trial close · This is where the deal moves forward or stalls

“So we covered the three things we discussed: ,, and ``.

I promised I’d ask you straight: based on what you’ve seen today, does this solve the problems we discussed?”

Then stop talking. Do not fill the silence. Let them answer. The silence is uncomfortable for you, not for them. They’re processing. Give them space.

Handling the Three Responses

Response 1: “Yes, this looks great.”

“That’s great to hear. Let’s talk about next steps. Typically, after a demo like this, the next move is ``. Does that make sense for your process?

Who else would need to be involved in the decision? And what does your timeline look like — is this something you’re looking to solve this quarter, or is it more of a next-quarter initiative?”

Why you ask about timeline and decision-makers: A “yes” without a next step is a polite brush-off. The questions above convert a vague “yes” into a concrete action with a timeline. If they can’t answer these questions, the “yes” might not be as strong as it sounded.

Response 2: “Mostly, but I have some concerns about X.”

“Tell me more about that. What specifically about `` is giving you pause?”

[Listen. Don’t defend. Understand the concern fully before responding.]

“That makes sense. Here’s how we’ve addressed that for other customers in your situation: ``. Does that address the concern, or is there something deeper I’m missing?”

Response 3: “I’m not sure. I need to think about it.”

“Totally fair. Can I ask — what specifically would you need to see or know to feel confident one way or the other? Is it a technical question, a business case question, or something else?

I ask because I’d rather address it now than have it linger. And if the answer is ‘this isn’t the right solution,’ I’d genuinely rather hear that so we don’t waste each other’s time.”

Why this works: “I’m not sure” usually means one of three things: (a) they liked it but can’t make the decision alone, (b) they have a specific concern they haven’t voiced, or (c) they’re politely saying no. The script above surfaces which one it is. The line “I’d genuinely rather hear that” gives them psychological permission to be honest.

Locking in the Next Step

Before you hang up, you must have one of these confirmed:

Never leave a demo with “we’ll be in touch.” If you don’t book the next step on the call, the probability of the deal moving forward drops by 80%. The next meeting should be scheduled before you hang up. Pull up your calendar. Pull up theirs. Book it live.

Part III

Advanced Techniques

When demos get complicated — multiple stakeholders, hostile objections, technical deep-dives, and live bugs. These situations separate good AEs from great ones.

09 Multi-Stakeholder Demos

The hardest demo is the one with 5+ people in the room. Each person has different concerns, different knowledge levels, and different decision-making authority. If you treat it as a single-audience presentation, you’ll satisfy nobody.

The Room Map

Before the demo, create a map of who’s in the room and what each person needs to hear:

The Multi-Stakeholder Script

Opening with multiple people

“Thanks everyone for making time. I know this is a big group, so I want to use your time well.

Sarah and I have been talking for a few weeks, and we identified three areas where the team is losing time and money. I’ll walk through how we solve each one — and I’ll make sure to cover the technical details for Priya, the business case for Mike, and the daily workflow for Jason.

If at any point I’m not covering what you care about, please interrupt me. I’d rather answer your real question than present something that’s not relevant to you.”

Why name-check each person: (1) It shows you know who they are and what they care about. (2) It gives each person a reason to pay attention — they know their moment is coming. (3) “Please interrupt me” is disarming and establishes that this is a conversation, not a presentation.

Managing the Skeptic

Every multi-stakeholder demo has a skeptic. They sit with their arms crossed. They ask pointed questions. They’re trying to protect the status quo. Do not ignore them. The skeptic is often the most influential person in the room because their objection becomes everyone else’s excuse not to move forward.

When the skeptic challenges you

Skeptic: “We tried something like this two years ago and it was a disaster.”

You: “That’s important context — thanks for raising it. Can you tell me what specifically went wrong? I want to make sure we’re not walking into the same problem.”

[Listen carefully. Take notes visibly.]

“So it sounds like the main issue was . That's actually one of the reasons we built the way we did. Let me show you specifically how it’s different…”

[Show the feature. Then address the room:]

“Karen, does that address the concern, or is there more I should dig into?”

The skeptic play: If you convert the skeptic into a supporter during the demo, the deal is essentially closed. Nobody else in the room will have a stronger objection than the skeptic. Win them, win the room.

10 Live Objection Handling

Objections during a demo are not problems — they’re buying signals. A prospect who doesn’t object isn’t engaged. A prospect who objects is processing how this would work in their world. That’s exactly where you want them.

The 6 Most Common Demo Objections

Objection 1: “It looks complicated.”

“I appreciate you saying that — I’d rather you tell me now than think it silently.

Let me ask: which part specifically felt complicated? Was it the setup/configuration, or the daily workflow?

[If setup:] The setup is something our implementation team handles. Your team doesn’t touch it. What they interact with is the daily workflow, which is this screen right here — [show the simplified daily view]. For ``, their entire workflow is these 3 clicks.

[If daily workflow:] That’s fair — I probably showed too much in one pass. Let me zoom in on the only screen your team would use daily — [show simplified view]. Everything else is admin configuration that gets set up once.”

Objection 2: “We tried something similar before.”

“What did you try, and what went wrong?

[Listen. Don’t interrupt. Take notes.]

So the issue was . That's a legitimate concern. Here's what's different about our approach:.

I can also connect you with who had the same concern — they were burned by before switching to us. They can give you an unfiltered take on whether this is actually different.”

Objection 3: “How does this integrate with X?”

“Great question. We have a native integration with ``.

[If you do:] Let me show you — [live demo of the integration]. Data flows in real-time, and the setup takes about 15 minutes.

[If you don’t, but have an API:] We don’t have a pre-built integration with ``, but our API covers 100% of the platform functionality. Our customers typically build the integration in 1–2 days using our API docs and sample code. I can connect you with our SE to walk through the technical details.

[If you don’t and it’s a real gap:] Honestly, we don’t integrate with `` today. It’s on our roadmap for Q3, but I don’t want to sell you on a promise. If that integration is a hard requirement for day one, I want to be upfront about that. Is it a dealbreaker, or is it something that can come later?”

Why honesty about gaps wins deals: When you say “we don’t have that today,” you build more trust than any feature claim ever could. The prospect thinks: “If they’re honest about what they can’t do, I can trust what they say about what they can do.” The reps who lose deals are the ones who say “yes, we can do that” to everything and get caught in the technical evaluation.

Objection 4: “What about security?”

“Important question. Let me give you the quick summary, and then I’ll share our full security documentation.

We’re SOC 2 Type II certified, data is encrypted at rest and in transit, we support SSO through ``, and we offer role-based access control. We can deploy in your VPC if that’s a requirement, and we go through a third-party penetration test every quarter.

I’ll send over our security questionnaire responses — we have a pre-filled version for the standard 300-question enterprise security review. And I can connect you with our security team directly if there are specific concerns.”

Objection 5: “This seems expensive.”

“I understand. Let me frame it differently.

You mentioned earlier that is costing you roughly. Our platform costs /year. So the question isn't whether is a lot of money — it is. The question is whether it’s less than ``.

Our average customer sees ROI within ``. I can build out a detailed business case for your specific situation if that would help the internal conversation.”

Objection 6: “We need to discuss internally.”

“Absolutely — that makes total sense. Can I ask: what specifically do you need to discuss? Is it the budget, the technical fit, or the timing?

I ask because I might be able to provide materials that make that conversation easier. If it’s budget, I can send a one-page business case. If it’s technical, I can have our SE join a call with your team. If it’s timing, I can share how other customers have phased the implementation.

When are you planning to have that discussion? I’d like to follow up right after so we don’t lose momentum.”

The meta-pattern: Every objection response follows the same structure: (1) Validate the concern. (2) Ask a clarifying question to understand what’s really behind it. (3) Respond to the real concern, not the surface-level one. (4) Offer a concrete next step to resolve it. Never be defensive. Never dismiss. Never argue.

11 The Technical Deep-Dive

At some point in an enterprise sale, the technical evaluator needs to go deep. This is where the Solutions Engineer (SE) takes over. The AE’s job during the technical deep-dive is not to sit silently and check email. It is to manage the room.

The Handoff Script

AE to SE handoff

“We’ve covered the business side — now I know has some deeper questions about how this works under the hood. I'm going to hand it over to, who’s been building integrations for customers in your space for the last 3 years. , take it away — and, please don’t hold back.”

Why “don’t hold back” matters: Technical evaluators are often hesitant to ask hard questions in front of their boss. Giving them explicit permission to go deep makes them feel respected — and it shows confidence in your product. If your SE can handle the toughest technical questions, the evaluator becomes an internal advocate instead of a blocker.

What the AE Should Do While the SE Is Driving

Taking Back Control

SE to AE handback

“Thanks — and, great questions. We’ll send over the API documentation and the architecture diagram you asked about after this call.

I want to zoom back out for a second and ask the bigger question: based on what you’ve seen today — both the business workflow and the technical deep-dive — does this solve the problems we discussed at the start?”

12 Demo Environment Best Practices

Your demo environment is your stage. A messy stage kills the performance even if the actor is brilliant.

Custom vs Generic Data

The rule: If you can see the prospect’s company name and logo in your demo environment, you’ve done enough customization. If you can see their actual team names, department structure, or realistic data, you’ve done exceptional customization. If they see “Acme Corp” or “John Doe” sample data, you haven’t prepared enough.

What to Pre-Configure

• Company name and logo in the platform header and any reports.
• Department/team structure that mirrors their org chart.
• Realistic data volumes — if they have 500 employees, don’t demo with data for 10. If they process 10K transactions/month, load that volume.
• Integration connections that show their actual tools (Salesforce, Slack, Jira, whatever they use) connected and working.
• A “hero workflow” pre-built and ready to demonstrate. Don’t configure things live unless the configuration itself is the selling point.
• Pre-load the exact screens you need in browser tabs. No searching for things during the demo.

Handling Live Bugs and Errors

Things will break. The question is not if but when. How you handle it determines whether it kills the deal or builds trust.

The principle: Never panic. Never apologize excessively. Acknowledge, switch to backup, and move on. Prospects expect software to have hiccups. What they’re evaluating is how your team handles problems — because that’s how you’ll handle their problems as a customer.

The “That’s a Great Question” Save

When a prospect asks to see something you didn’t prepare:

“That’s a great question, and I actually want to show you that properly rather than fumble through it live. Can I set up a dedicated walkthrough of `` and send you a recording by end of day tomorrow? That way you get to see it with your actual use case configured, not a rushed version.”

This works because it (1) validates their request, (2) sets up a follow-up touchpoint, and (3) avoids a fumbled live demo that could undermine everything you’ve shown so far. It’s always better to say “let me show you that properly” than to wing it and fail.

Part IV

Templates

Printable checklists, follow-up email templates, and the top demo mistakes ranked by deal impact. Steal these and make them your own.

13 Demo Prep Checklist

Print this. Use it before every demo. If you can’t check every box, you’re not ready.

DEMO PREP CHECKLIST
Complete before every enterprise demo

RESEARCH
☐ Reviewed all discovery notes (their exact words highlighted)
☐ Identified and ranked their top 3 pains
☐ Quantified each pain in dollars or hours
☐ LinkedIn-reviewed every attendee (role, tenure, concerns)
☐ Identified the champion, economic buyer, technical evaluator, and skeptic
☐ Researched what competitors they’re evaluating

CUSTOMIZATION
☐ Demo environment loaded with their company name and logo
☐ Realistic data matching their scale (employees, transactions, etc.)
☐ Department/team structure mirrors their org
☐ Integration connections show their actual tools
☐ Hero workflow pre-built and ready to demonstrate

PREPARATION
☐ Click path mapped (exact sequence of screens, zero improvisation)
☐ Written out the discovery recap (their words, their numbers)
☐ Prepared the agenda script with the fairness contract
☐ Prepared transitions between each pain block
☐ Written word-for-word responses for 3 most likely objections
☐ Prepared competitive positioning for their likely alternatives
☐ Trial close script ready

TECHNICAL
☐ Demo environment tested — all screens load correctly
☐ Screen sharing tested on the platform they use (Zoom, Teams, Meet)
☐ Audio/video tested
☐ Browser tabs pre-loaded in the right order
☐ Backup screenshots/recording ready in case of live issues
☐ SE briefed and aligned on their role (if technical deep-dive expected)

LOGISTICS
☐ Calendar invite sent with agenda
☐ Joined the call 5 minutes early
☐ Notifications silenced (Slack, email, phone)
☐ Clean desktop (no embarrassing browser tabs or Slack messages visible)

14 Post-Demo Follow-Up

The follow-up email goes out within 2 hours of the demo ending. Not tomorrow. Not end of week. Within 2 hours. Speed signals professionalism and keeps the momentum alive while the demo is still fresh in the prospect’s mind.

The Follow-Up Template

To: **** (CC:) · Sent within 2 hours

Re: `` Demo — Recap & Next Steps

Hi ``,

Thanks for the time today — and thanks to everyone who joined. Great conversation.

Quick recap of what we covered:

**Problem 1: ** We showed how handles this by . For a team your size, customers typically see.

**Problem 2: ** We demonstrated. The key metric: ``.

**Problem 3: ** We walked through, which typically results in ``.