Revenue Cockpit

Collected revenue and its evidence

The page opens with payment evidence from your own connected Stripe account. Net collected amounts remain separate by currency and subtract succeeded refunds. The receipt table keeps collection and refund dates visible. A failed read shows unavailable, and a history above 50,000 stored payment events withholds totals rather than presenting a partial sum as complete. Receipts are paginated in groups of 25.

A receipt with stored content attribution links straight to that piece in Studio, opening the exact draft rather than the whole queue.

Select a receipt to inspect its recorded content reference, date basis and attribution version. These references reuse retained attribution receipts; they do not prove content caused a sale. The view reads the latest attribution record for up to 200 owned content pieces and marks incomplete evidence when that limit is exceeded or the read fails. Payment dates missing from the source are labeled with the stored-event fallback.

Identity mapping says how the payer was matched: the payer email and Stripe customer on the invoice, matched to the first tagged conversion with the same email, plus the identity mode your PostHog connection uses. Evidence chain puts the links on one line, content then conversion then payment, each with its id and date. Attributions recorded before the conversion was stored say so in the chain.

Show rejected event lists the attribution events the revenue rollup refused on its latest run, newest first, each with its reason. A content reference that names no piece in this workspace is rejected and recorded only as that fact: the reference itself is not kept, since it may belong to someone else. A tagged event with no customer email, and a payment collected outside the attribution window, are rejected too. A rejected event changes no attribution or metrics.

Product feedback lets you select an imported PostHog project and exact event name as a milestone. The posthog-event-email/v1 contract counts unique normalized emails only when the connector records explicit event email identity. It also shows deduplicated occurrences and events without explicit email. These counts identify people, not customer accounts or revenue attribution. The selection stays in the page URL, including while you review receipts.

The window is the current UTC quarter. The reader accepts at most 5,000 stored PostHog events, deduplicates provider event IDs and excludes platform usage. A failed or capped read, missing connection, unrecorded first sync or source sync error withholds counts. No imported events does not prove zero product usage. Last sync and latest occurrence remain visible so you can assess freshness.

The existing composite score and planning inputs remain under Revenue health and planning.

Opportunity origin

View revenue origin on a Campaigns conversation opens this page with an Opportunity origin panel for that opportunity. It lists, from stored records only: the research run that wrote the draft (its skill, how many sources it cited, the brief version and run reference), the contact, the approved send and whether the provider returned a receipt, the reply, any meeting linked by the attendee's address, the opportunity, and its CRM record. The CRM line links to the record when an approved CRM write named this opportunity and the CRM confirmed it, and says the opportunity was not written to a CRM when none did. A link nobody recorded reads "Not recorded". An opportunity that is not in your workspace shows no chain.

Reuse review

The required dedup review chose to extend this cockpit. Currency and refund calculations reuse the day revenue engine, event history uses the existing paginated reader, and attribution comes from retained content metrics. No second attribution engine, connection flow or report destination was added.

Overview

Revenue Cockpit is the CRO's whole-revenue view in one place. Rather than open four surfaces separately, it composes the top-line output of each, Efficiency, Attribution, Win/Loss, and Forecast Governance, into a single revenue-health read and one worklist. It is reuse-first: it re-scores nothing, it blends numbers those surfaces already produce.

What it is for, on the page. Under the headline, this page says what it produces, what makes it run, and where the output lands. Every Work page reads that line from one registry, so the three answers cannot drift from the page.

One number, one risk

The cockpit reads each surface's headline, the efficiency band, NRR and GRR, win rate, forecast reliability, and blends the ones it has into a composite revenue-health score banded strong, watch, or at-risk. It then names the single worst area as the top risk, so the board conversation starts with the one thing to fix rather than a tour of every metric. Attribution is shown as context, the top sourcing channel, rather than scored as health.

Filled in from your own surfaces

Opening the page reads what the four surfaces already know and fills those inputs in for you, each labelled From your data. Six of the seven can come from your stored book: NRR and GRR from the ARR on your accounts, win rate and the top headwind from your closed opps, forecast reliability from the commits that have closed, and the top sourcing channel from the touches on your opps. Every prefilled value stays editable, so a number you disagree with is one you can type over before composing.

An input the product cannot know says why in place of a number. Efficiency band is always one of those: it needs your sales-and-marketing spend and net new ARR, which the product does not store, so you enter it from Efficiency. Where you have nothing stored yet, the page says so plainly rather than showing zeros, and the inputs fill themselves once you connect a CRM or import a CSV.

Honest about what it knows

A surface you have not filled in stays unknown and does not drag the composite down, so a partial cockpit is still useful and never falsely pessimistic. Nothing is invented: every prefilled figure is the underlying surface's own number or straightforward arithmetic on it, never an estimate. Forecast reliability is the one conversion, and it is an identity rather than a guess: governance measures mean absolute error, and reliability is one minus that. A surface that cannot evidence a number leaves the field blank instead of offering a plausible one.

If the prefill read itself fails, the page says the read failed. It does not fall back to empty inputs, because "you have no data" is a claim about your business and a failed request is not evidence for it.

Deterministic

The composition is deterministic: the same top-line numbers always produce the same revenue-health read and the same top risk, so the cockpit holds up as the single slide a CRO opens a board update with.