Revenue surprises rarely start in the revenue report.
They usually start somewhere quieter: a customer hits a limit twice, a healthy account stops using the product, a trial finishes activation but never pays, a top-up buyer keeps buying credits instead of moving plans, or an admin keeps visiting the pricing page while support tickets are still open.
The MRR dashboard catches the outcome. The work is catching the churn risk, expansion readiness, or conversion risk before that.
That's the job of a revenue signal audit.
You're not trying to build a giant predictive model on day one. You're trying to find the handful of customer moments that should already be routed to a human, campaign, support play, or sales task.
For Prevenue's ideal buyer - B2B SaaS teams around $900k to $6M ARR, often using Stripe plus product analytics and a lifecycle or CRM tool - the problem usually isn't no data.
It's that the decision is scattered.
Billing sees one piece. Product sees another. Support sees the part that should change the message. CRM knows who owns the account. Nobody assembles it in time.
What A Revenue Signal Actually Is
A revenue signal is an observable customer change that should alter a revenue decision.
It's not just an event. It's not just a score. It has five parts:
| Part | Question it answers | Example |
|---|---|---|
| Event | What happened? | Account used 91% of credits by day 18. |
| Context | Why does it matter? | They are on a low plan and did this two cycles in a row. |
| Category | What kind of movement is this? | Grow. |
| Action | What should happen next? | Send upgrade prompt or create a sales-assist task. |
| Owner | Who owns the response? | Lifecycle, CS, sales, founder, or support. |
That fifth column is where a lot of teams lose money.
They can see the behavior. They just don't know whether it belongs in Customer.io, Slack, HubSpot, Intercom, a founder's inbox, or nowhere yet.
The Prevenue framing is simple: connect billing and product behavior, interpret what it means for revenue, and route the next action.
The Four Buckets To Audit
Don't start with every possible metric. Start with four categories a revenue team can understand.
Grow
These are customers showing expansion, upgrade, seat, annual, or top-up potential.
Look for:
- Early-cycle high usage.
- Repeat top-ups or credit purchases.
- Limit hits on a lower plan.
- Multiple teammate invites.
- Pricing or upgrade page views.
- Stable monthly customers who may be annual-ready.
The mistake is treating all high usage as good news.
High usage with clean adoption can be an upgrade moment. High usage with support friction can be a save moment.
The audit should separate those cases before any campaign fires.
Save
These are customers showing contraction, churn, downgrade, disengagement, or friction risk.
Look for:
- Usage dropping after a healthy baseline.
- Failed payments paired with low recent engagement.
- Admin silence after activation.
- Repeated support issues or workflow errors.
- Downgrade or cancellation intent.
- Renewal silence from an account that used to engage.
Many churn guides talk about prediction, and the strongest ones emphasize usage decline, billing patterns, support friction, and fast-moving engagement signals. Kinde's churn prediction guide focuses on billing and usage patterns, while CustomerScore frames churn prediction as valuable only when it turns into retention action. That is the right bar: a risk flag that does not route to a save play is just a scarier dashboard.
Convert
These are free, trial, or self-serve accounts that have reached value but have not become paid revenue.
Look for:
- Activation completed but no payment.
- Trial user invited teammates.
- Checkout started but no subscription.
- High usage during the trial window.
- Pricing intent from a high-fit account.
The important distinction is between "not ready" and "ready but stuck."
A trial that has not activated needs value help. A trial that activated, invited teammates, and started checkout needs conversion help.
Watch
These are early or low-confidence signals that need more data before action.
Watch exists because not every behavior deserves a revenue motion.
A single downgrade page view with stable usage might be nothing. A single limit hit might be curiosity. A noisy account with broken identity mapping might be a data quality issue.
The Watch bucket prevents teams from turning every event into an email.
The Audit: Where To Look
Don't start by inventing a new dashboard.
Start by walking through the systems you already have. Ask what each system knows, what it does not know, and which revenue action should happen when its data changes.
| System | What to audit | Signal examples | Where action should go |
|---|---|---|---|
| Stripe | Plans, subscriptions, invoices, trials, failed payments, top-ups, cancellations | Repeat top-up, annual-ready, failed payment with risk, trial not paid | Slack, Customer.io, CRM, founder inbox |
| Product analytics | Usage, activation, feature adoption, limits, upgrade intent, team invites | Upgrade-ready, usage drop risk, team expansion, limit friction | Customer.io, Slack, HubSpot, Intercom |
| CRM | Owner, stage, account tier, open opportunity, lifecycle status | Sales-assist, expansion deal, owner alert | HubSpot, Salesforce, Slack |
| Lifecycle | Campaign engagement, suppression, prior offers, trial nudges | Convert readiness, failed sequence, annual offer timing | Customer.io, Segment, webhook |
| Support | Tickets, errors, complaints, unresolved friction | Support friction risk, suppress upgrade prompt | Intercom, Zendesk, Slack |
| Data quality | Missing account IDs, unmatched Stripe customers, stopped events | Billing-no-usage, usage-no-billing, event stopped | Admin dashboard, engineering Slack |
You don't need deep native integrations for every destination on day one.
Prevenue's integration architecture starts with Stripe, direct events, PostHog or Segment-compatible event payloads, Slack, and generic webhooks because that is enough to prove whether signal-to-action routing creates value before the team buys or builds the heavier version.
The Most Useful First Signals
If you're doing this for the first time, don't create 30 rules. Start with six to eight.
| Signal | Rule of thumb | Category | Action |
|---|---|---|---|
| Upgrade-ready | 80%+ usage allowance before day 20, especially across cycles | Grow | Prompt upgrade or create sales-assist task. |
| Repeat top-up | 2+ top-ups in 60 days | Grow | Recommend higher plan or annual credit bundle. |
| Limit friction | 2+ limit hits in a billing cycle | Grow or Save | Offer upgrade, top-up, or support depending on friction. |
| Usage drop risk | 50%+ usage drop after activation or a healthy baseline | Save | Trigger success intervention, not an upgrade prompt. |
| Trial activated, not paid | Activation completed but no payment before trial end | Convert | Send value recap, concierge offer, or founder email. |
| Team expansion | 3+ invites or multiple active users on low-tier plan | Grow | Offer team plan or sales-assist route. |
| Upgrade intent | Pricing page or upgrade flow viewed repeatedly | Grow | Route sales assist or lifecycle prompt. |
| Checkout abandoned | Checkout started, no plan change within 24 hours | Convert or Grow | Send help, FAQ, support prompt, or owner task. |
Notice the wording: "rule of thumb." These are starting points, not universal laws. The best version of the audit tunes thresholds to the pricing model, value metric, customer count, and sales motion.
What To Suppress
Suppression is where this gets more useful than a generic customer health score.
Don't send an upgrade prompt when:
- The account has unresolved support friction.
- Usage is high because a workflow is failing and being retried.
- Identity mapping is broken.
- A cancellation or downgrade conversation is active.
- The customer just got a failed-payment notice.
- The signal is low confidence and has not repeated.
In those cases, the recommended action might be support, save, observe, or fix data quality.
That's still a revenue action. It's just not a sales action.
A 30-Minute Revenue Surprise Audit
Use this when you want a first pass before buying anything, building anything, or handing the problem to engineering.
- Pick the revenue movements that hurt most: churn, missed expansion, stalled trials, downgrades, or top-up leakage.
- List the systems that see those movements before the dashboard does.
- Choose two Grow signals, two Save signals, one Convert signal, and one Watch or data quality signal.
- For each signal, define the event, threshold, account context, owner, destination, and success metric.
- Add suppression rules before launching campaigns.
- Review the last 30 to 90 days manually and ask: which accounts would this have caught earlier?
- Route the first version into Slack or a webhook before building a complex dashboard.
- Measure whether the action happened and whether revenue moved.
If the audit cannot name the action, the signal is not ready.
What Good Looks Like
A good revenue signal is specific enough that someone can act without opening six tools.
Bad:
"Customer health score dropped."
Better:
"Apex Data is a Save signal. Usage dropped 62% after activation, the admin has not logged in for 11 days, and they are still paying $499 MRR. Recommended action: trigger success intervention and suppress upgrade prompts."
That version tells the team what happened, why it matters, how to respond, and what not to do.
That's the difference between "interesting" and "someone can run with this today."
Who Gets The Signal
The audit is not done until each signal has a destination.
For lean SaaS teams, this is where the audit starts to matter.
The same account pattern can mean different work depending on value, relationship, timing, and risk.
Use a simple routing rule before building anything fancy:
| Signal pattern | Default owner | Why |
|---|---|---|
| Low-touch Grow signal | Lifecycle | The account needs a relevant prompt, not a sales meeting |
| High-value Grow signal | Sales or founder | The account may need packaging, plan-fit, or annual conversation |
| Save signal with support friction | Support or CS | The first move is repair, not revenue pressure |
| Save signal with commercial context | CS, sales, or founder | The customer may need a retention path or commercial option |
| Convert signal | Lifecycle or sales | The account needs trial-to-paid help while intent is fresh |
| Watch signal | Ops or engineering owner | The issue may be identity, event quality, or missing context |
The rule can be rough at first. What matters is that the signal does not land in a generic "someone should look" pile.
If two owners could receive the same signal, write the tie-breaker down. MRR, segment, account owner, active opportunity, support state, and lifecycle stage are usually enough to decide.
Routing does not need to be perfect on day one. It needs to be explicit enough that the next action happens.
Common Failure Modes
Most teams don't fail because the signal is impossible.
They fail in one of five much more ordinary ways.
The Signal Exists, But The Owner Does Not
This is the classic founder-led or early RevOps problem.
Everyone agrees the account looks important. Nobody owns the next step.
Fix it by adding one owner field to every signal. If the account is under a certain MRR threshold, the owner may be lifecycle. If it is above the threshold, it may be CS, sales, or the founder.
The rule does not need to be perfect. It needs to remove ambiguity.
The Event Exists, But It Has No Revenue Context
Product analytics may show limit_reached, but the team still does not know the plan, MRR, account size, billing status, support state, or owner.
Fix it by joining the event to billing and account context before it becomes a signal. A raw limit event is activity. A low-plan account hitting its API limit twice by day 17 is a revenue moment.
The Dashboard Exists, But No Action Routes
Many teams already have a dashboard showing usage, churn, or expansion movement.
The issue is that the dashboard depends on someone remembering to look.
Fix it by choosing a destination for each signal: Slack for visibility, Customer.io for lifecycle, CRM for owner tasks, Intercom for support context, or webhook for flexible routing.
The Campaign Exists, But Suppression Is Missing
This is how revenue automation becomes annoying.
The customer receives an upgrade prompt while support is still debugging their issue.
Fix it by defining suppression rules before the campaign launches. Support friction, data quality issues, active cancellation flow, and failed payment state should all change the action.
The Team Measures Signals, But Not Outcomes
A signal system that never learns becomes noisy.
Fix it by attaching the outcome to the signal: upgraded, retained, renewed, converted, annualized, checkout completed, support resolved, or suppressed correctly.
The point is not more alerts. The point is knowing which revenue actions worked.
What To Write Down
For every first-pass signal, document the same seven fields:
| Field | Example |
|---|---|
| Signal name | Repeat top-up to plan |
| Trigger | Customer buys 2+ top-ups in 60 days |
| Inputs | Stripe invoice, top-up SKU, current plan |
| Category | Grow |
| Recommended action | Recommend higher plan or annual credit bundle |
| Destination | Customer.io for self-serve, HubSpot for sales-assist |
| Outcome | Top-up buyer moved to higher plan |
This is the minimum viable signal spec.
It's small enough for a founder to write and specific enough for RevOps, lifecycle, or engineering to implement.
Where Prevenue Fits
Stripe shows billing. PostHog shows behavior. Customer.io sends messages. HubSpot manages sales work. Support tools show friction.
The missing piece is not another place to stare at numbers.
It's the layer that decides what the combined pattern means for revenue.
That's what Prevenue is built for.
It connects the systems, stitches account identity, applies revenue semantics, recommends the next action, routes the signal, and helps track whether the action created or saved MRR.
That's the difference between "we have events" and "we know who is ready to grow, who is at risk, who is ready to convert, and what should happen next."