The Demo‑to‑Sales Wiring Diagram: tie UI events, billing units, and telemetry that prove MRR lift in 30 days

The first step is a crisp contract that ties every demo interaction (what the salesperson shows or the prospect uses in a trial) to one and only one billing unit. Examples of billing units: seats, projects, API calls, documents processed, or feature-tier flags. If a demo uses a composite experience, split it into atomic billing units and pick the one metric you’ll measure for revenue lift.

Write that contract as a single sentence per demo play: “When the prospect completes X in the demo, they consume Y billing unit (property: billing_unit_id) and this should create an entitlement record in the billing system with idempotency key Z.” This makes the downstream mapping unambiguous for engineers, analytics, and contractors.

Minimalism wins: instrument only the events needed to answer whether the demo-to-trial path increased paying conversions or MRR. That usually means three event categories: demos played (UI events), trial starts (backend events), and billing/entitlement events (backend, durable). Instrument event-level properties that lock identity across systems: user_id, account_id, billing_unit_id, product_id, and stable event_id for deduplication.

Use a tracking plan document (CSV or small JSON) that lists each event, the required properties, producer (web, backend), expected frequency, sampling rules, and acceptance criteria for data quality. Tools like Amplitude’s tracking-plan workflow and common taxonomy guidance are a practical template — but keep your plan intentionally narrow for the thirty‑day validation window.

Ship the instrumentation as code with test cases. Acceptance criteria should be binary and easy to validate: events arrive in staging Amplitude (or your analytics) within X minutes; each event contains all required properties; billing_event rows reconcile to the billing database within a tolerance; and duplicate billing events are rejected by idempotency keys.

Provide a short checklist for reviewers: unit tests for event construction, integration tests hitting a staging analytics endpoint, a reconciliation query that matches trial_started to billing_event for 7 days, and a runbook for telemetry loss detection. These objective checkboxes speed contractor handoffs and reduce rework.

To prove MRR lift in 30 days you don’t need exhaustive telemetry — you need reliable, attributable signals. Track cohorted conversion rates (demo_played → trial_started → paid_conversion) and normalized MRR (billing_event revenue aggregated per account). Run the measurement on rolling cohorts and ensure your analytics joins events to billing by account_id so you can compute incremental MRR per cohort.

If you plan an experiment, confirm power and expected effect sizes before you start. For campaigns with small sample sizes or low conversion volume, expect longer windows; for immediate validation focus on high-quality leads and tighter cohorts so changes can reach statistical or practical significance fast. Keep a short dashboard of: demo plays, trials started, paid conversions, and new MRR set to renew.

Anti-pattern: relying on client-only events for billing attribution. Billing and entitlements must be captured server-side with durable records — client events can be noisy and lost. Capture revenue and entitlement changes as backend events and include stable identifiers for deterministic join paths.

Anti-pattern: instrument everything at once. Over-instrumentation creates noise and slows analytics. Start with the minimal plan, validate the wiring, then iterate. Also, build simple validation queries and monitor telemetry loss; papers and industry notes show telemetry loss can bias experiment results if unaccounted for, so include sanity checks that compare analytics counts to source-of-truth systems.