A useful founder dashboard is a decision register with numbers attached. Keep a metric only when its event, denominator, review cadence, owner, and possible decision are explicit. There is no universal activation, retention, support, or churn threshold that makes every micro-SaaS healthy.
Start with the dashboard contract
Before opening an analytics tool, write down the product’s recurring job. A reminder product may need to schedule and deliver a reminder. A reporting product may need to ingest current data and produce a report. The dashboard should show whether eligible customers reach that job, return when the job recurs, and encounter enough friction to threaten delivery or support capacity.
Each row needs six fields: metric name, event definition, denominator, exclusions, review owner, and the decision it can trigger. “Activation is down” is not yet actionable. “Accounts that completed a first live report within their defined setup window, divided by eligible new paying accounts whose window has closed” is inspectable.
A compact metric dictionary
| Metric | Exact definition | Denominator and exclusions | Decision owner |
|---|---|---|---|
| Activation rate | Eligible accounts that complete the named first useful event within the product’s setup window ÷ eligible accounts whose setup window ended in the period. | Exclude staff, test accounts, duplicate workspaces, and accounts still inside the window. Define the window from the promised time-to-value, not a generic benchmark. | Product/onboarding owner: inspect the failed step and choose one setup intervention. |
| Retained-job rate | Accounts that complete the core job again when it is expected ÷ accounts with an eligible repeat opportunity in the same cohort period. | Do not put monthly, weekly, and event-driven accounts in one denominator. Mark accounts with missing telemetry separately. | Product owner: investigate the first broken repeat cycle. |
| Support burden | Workflow-related support minutes and tickets recorded during the period, shown beside active paying accounts in that same period. | Separate bugs, setup help, billing, unclear copy, and feature requests. A ticket count without handling time or consequence can hide one severe incident. | Support owner: fix the highest-consequence repeated state, not automatically the largest tag. |
| Logo churn | Paying accounts whose service ended in the period ÷ paying accounts active at the start of the period. | Keep voluntary cancellation, failed payment, closure, and planned migration distinct. Do not mix trials with paying accounts. | Founder or customer owner: assign the cancellation to a cause only after checking evidence. |
| Recurring revenue lost | Recurring revenue removed by cancellations and downgrades in the period ÷ recurring revenue present at the start of the period. | State whether taxes, usage charges, credits, expansion, and currency conversion are included. Keep the rule stable across periods. | Pricing/finance owner: inspect which customer and package changes created the loss. |
| Cash coverage | Unrestricted cash available ÷ forecast recurring cash obligations under the documented operating assumptions. | List the obligations and forecast horizon beside the figure. Do not treat expected invoices as cash received. | Founder/finance owner: change spending, collection, or commitments when the forecast no longer supports the plan. |
Do not force every number into a weekly cadence
| Cadence | Use it for | Decision |
|---|---|---|
| Daily or incident-led | Failed imports, billing errors, undelivered reminders, data integrity, and service interruptions. | Contain harm, restore service, communicate, and record the incident. |
| Weekly operating review | Eligible activations, repeat-job opportunities, support burden, cancellations, and cash movements. | Choose one bottleneck to investigate or one intervention to run. |
| Monthly or natural product cycle | Cohort retention for products used monthly, quarterly, or when an external event occurs. | Decide whether the product is returning with the customer’s job rather than with the calendar. |
| Quarterly or after enough contract events | Package fit, segment economics, channel quality, and pricing assumptions. | Revisit positioning or commercial structure without reacting to one account. |
A weekly meeting may still review whether slower-cycle evidence exists, but it should not manufacture a weekly retention rate for a quarterly workflow.
Illustrative four-week operating dashboard
Illustrative example — fictional operating data, not a customer result. Assumptions: the product produces a weekly client report; a new paying account is eligible for activation after connecting a live data source; test accounts are excluded; repeat-job eligibility begins only after the first report; support records include founder handling time. Fractions are left visible so the denominator can be inspected.
| Review | Activation | Retained job | Support evidence | Cancellation evidence | Owner’s decision |
|---|---|---|---|---|---|
| Week A | 2 activated / 4 eligible starts | 6 repeated reports / 8 eligible accounts | Import mapping: 4 tickets, 95 minutes | 1 ended account; reason not captured | Product owner reviews failed import states before changing acquisition. |
| Week B | 3 / 5 | 7 / 9 | Import mapping: 3 tickets, 70 minutes | No ended accounts; one payment retry remains open | Support owner separates payment recovery from voluntary churn. |
| Week C | 2 / 3 | 6 / 10; telemetry missing for 2 eligible accounts | Report delivery: 1 incident, 110 minutes | 1 ended account after a delivery failure | Reliability owner pauses onboarding copy work and investigates delivery. |
| Week D | 4 / 6 | 8 / 11; telemetry missing for 1 | Billing wording: 5 tickets, 45 minutes | 1 downgrade; stated reason is package fit | Pricing owner reviews package boundaries; no price change is assumed yet. |
The table does not prescribe a “good” rate. It demonstrates how a decision can change when the denominator, missing data, incident severity, and cancellation type are visible. Week C has fewer support tickets than Week A, but the delivery incident carries a different consequence.
Run the review as a sequence of decisions
- Confirm data integrity. Name missing events, changed definitions, duplicate accounts, and delayed billing records before interpreting a trend.
- Locate the broken job. Identify whether the problem appears before first value, during repeat use, at delivery, in support, or at renewal.
- Open the underlying evidence. Read the relevant ticket, event trace, cancellation note, or invoice rather than guessing from the chart.
- Assign one decision owner. The same founder may wear every role, but the decision still needs a named owner and due state.
- Record one intervention or one research question. “Watch the metric” is not a decision. “Instrument the missing export event” or “review the failed imports” is.
Metric specification card
Set thresholds from consequences, not borrowed benchmarks
A threshold can be useful when it expresses a product-specific boundary: an error that risks incorrect billing, a support load the current team cannot sustain, or a cash forecast that conflicts with signed obligations. It should document the consequence, the affected segment, and the action that follows.
External benchmark charts cannot define whether a quarterly compliance product should look like a daily collaboration tool. Use your stable metric definitions, comparable cohorts, customer evidence, and operating constraints. If there is not enough evidence to set a threshold, record the uncertainty instead of inventing precision.