The symptom is always the same: someone discovers a renewal two weeks before it expires. The commercial conversation is already lost at that point, whatever the account’s health looked like a quarter earlier. The root cause is almost always the same too: renewals living inside the sales pipeline, invisible among deals that behave nothing like them.
This is the architecture we build instead. It comes from client work, and every number in it is from a shipped engagement.
Why does mixing renewals and new business break forecasting?
A renewal and a new logo differ on every axis that makes a forecast work:
| Axis | New business deal | Renewal |
|---|---|---|
| Baseline probability | Low, earned stage by stage | High, lost by neglect |
| What moves it forward | Rep activity | The calendar |
| Cycle length | Weeks to months, variable | Fixed by contract date |
| Owner | Sales | CS or account management |
| Failure mode | Lost to competitor or no-decision | Missed, then negotiated from weakness |
Weight those two populations with one probability model and the output is wrong in a way nobody can decompose. The forecast says one number; the components mean different things. That is why the fix is structural, not a better report.
What does the dual-pipeline architecture look like?
Two pipelines, one rule connecting them:
The sales pipeline holds new business and expansion, with stages that describe selling: discovery, evaluation, proposal, close. Rep-driven, activity-based, forecast by stage probability.
The renewals pipeline holds every contract with a date. Its stages are time-based, not activity-based: a renewal moves from “Pending” to “90 days out” to “Approach” because the calendar says so, with automated notifications firing at each transition. Nothing depends on anyone remembering.
The connecting rule: an expansion deal cannot close without linking to its renewal. Expansion sells like new business, so it lives in the sales pipeline, but the renewal record stays the single source of truth for the account’s contract.
We first built this shape for a growth-stage DevOps company where new business, renewals, and expansion were tangled in one pipeline, and separated them into three clean revenue streams. A payments FinTech got the same renewals architecture after running renewal management from spreadsheets, reactive every time.
How do you implement it without breaking history?
- Standardize the value fields first. ARR and TCV on line items, multi-year contracts modeled year by year. Do this before migrating, because moving deals twice is misery.
- Create the renewals pipeline with time-based stages. Keep it to four or five: Pending, 90 days, Approach, Won or Lost. More stages than decisions is decoration.
- Wire the notifications. The 90-day alert to the owner is the single highest-value automation in the whole build. Add 60 and 30 if your motion needs them.
- Backfill open renewals only. Historical closed deals stay where they are; rewriting history breaks every report that referenced it.
- Set the ownership rule. Every renewal has an owner on creation. An unowned renewal is the spreadsheet failure with better furniture.
What does this change in reporting?
Separation is what makes previously unanswerable questions cheap. Win rate by revenue stream becomes real: our DevOps client measured 18.5% win rate from first meeting for the first time, a number that was uncomputable while renewals inflated the denominator. Renewal rate becomes a real number instead of a guess. And the weighted forecast finally means one thing, because each pipeline carries one kind of probability.
The reporting layer on top is a pipeline dashboard per stream, which is a small build once the structure underneath is honest.
If your renewals are still surprises, this is the renewals pipeline project, and it is one of the more contained builds we do: structure, alerts, and ownership, live in weeks. The wider version, with forecasting and operating cadence on top, is revenue operations.