Revenue Intelligence

The problem I kept seeing

Pipeline reviews read the current stage, so win rate and sales cycle describe the snapshot instead of the history.

The current stage column is a convenience. Historical win rate and cycle have to come from the stage transition that closed the deal.

Without a repeatable answer: A lost deal whose current stage was edited still counts as open, and the pipeline requirement moves with it.

What I was working from

Synthetic book for the same fictional company: accounts, contacts, reps, territories, opportunities, stage history, activities, targets, and forecast submissions. One seeded loss still shows Negotiation on the opportunity row, so a win rate taken from the current stage would be wrong.

Workflow

Choose the window and the cut → Resolve each opportunity's stage as of that date → Read coverage, win rate, cycle, aging, slippage, and attainment → Compare the plan with bookings and the forecast commit

In plain language

Filters → Stage as of a date → Metric queries → Plan versus execution

Described stack — not what this repository runs

Names below are a sketch. They are not completed integrations unless the technology section says Built with.

Next.js · PostgreSQL · SQL in lib/intelligence/sql.ts · Stage history as the source of truth

Territory · Rep · Account · Contact · Opportunity · Stage history · Activity · Revenue target · Forecast submission

Separate app in gtm-revenue-os. Not embedded on this site. Account potential is excluded from the plan-versus-execution comparison.

Goals

• Report pipeline by stage, territory, and rep from Postgres.
• Calculate win rate and sales cycle from the history row that closed the deal.
• Compare planned new ARR, actual bookings, the latest forecast commit, and pipeline still required.

Out of scope

• Treating account potential as pipeline or bookings.
• Calculating history from opportunities.stage.
• Presenting the seeded attainment as a measured result.

Smallest version

Dashboard with date, territory, rep, segment, and stage filters. The stage filter does not rewrite historical win rate. Moving an open stage leaves the historical win rate unchanged.

Question that version tests: Does the required-pipeline number change when win rate is taken from closes instead of the current stage?

Metrics I would watch

These are not results unless the section above says they are on record.

• Win rate and cycle cite the close event
• Queries are explained on the SQL lesson in the app
• Filters used in a review
• Hypothesis: the gap that matters is planned versus booked versus still required

A win rate taken from the close event changes the pipeline a team thinks it still needs. The seeded book is a fixture.

Tradeoffs

• A stage-history table costs writes on every move. Reporting off the current stage would be shorter and wrong.

What I would build next

• When a CRM sync arrives, keep stage history as the source of truth. Do not backfill win rate from the latest stage.