Annual GTM Capacity Planning: Build Your Own Model or Buy One

A capacity plan needs three real numbers, not three guesses: average deals a rep can actively manage at once without pipeline quality dropping, average sales cycle length by segment, and ramp time for a new hire to reach full productivity. Pull these from your CRM's own history rather than industry rules of thumb, because your sales cycle and your ramp time are shaped by your product and your buyer, not by a generic benchmark someone else's team published.

If you don't have twelve months of clean stage-history data to pull these from, that's the actual first project, before the capacity model itself. A plan built on guessed inputs will look precise and be wrong in exactly the way that erodes trust in RevOps the next time you present a number to the executive team.

Pull these three inputs from your own CRM history:

• The average number of deals a rep can actively manage at once before pipeline quality drops.
• The average sales cycle length, calculated separately for each segment.
• The ramp time a new hire needs to reach full productivity.
• At least twelve months of clean stage-history data to base them on; if it doesn't exist, building it comes before the capacity model.

For a team under roughly 15 reps, a spreadsheet that pulls these three inputs and lets you flex headcount, segment mix, and ramp assumptions is usually enough. It's fast to build, easy for a CRO to sanity-check line by line, and doesn't require anyone to learn a new system mid-planning-cycle. The failure mode isn't the spreadsheet itself, it's letting the same file survive three planning cycles without anyone re-pulling the underlying CRM numbers, so the ramp assumption from two hiring cycles ago quietly outlives its accuracy.

Build the spreadsheet so each input cell links back to a saved CRM report or export, not a number someone typed in from memory during a planning meeting. That one habit is what keeps the model honest a year later.

Once you're planning across multiple segments, multiple motions (outbound, inbound, partner), or more than roughly 20 to 25 reps, a static spreadsheet stops reflecting reality quickly, because it can't easily model what happens when one segment's ramp slips or one motion's win rate moves. At that scale, a RevOps platform built for scenario planning, or a CRM like Pipedrive or Close paired with a proper forecasting layer, earns its cost by letting you re-run the model when an assumption changes instead of rebuilding formulas under deadline pressure the week before a board meeting.

Average win rates on new-logo deals sit around 19%¹, and that single number should anchor your pipeline coverage math. Say your target requires closing 40 new-logo deals next year: you need pipeline sized against a win rate close to that average, not against an aspirational number nobody on the current team has actually hit.

Two plans with identical headcount can produce very different revenue if the segment mix shifts. A plan that quietly assumes more enterprise deals than last year, without adjusting cycle length and ramp time for that segment, will look achievable on paper and fall short by the second quarter. Model each segment's inputs separately rather than blending them into one average rep profile, especially if your motion is splitting between a faster-cycle self-serve tier and a longer enterprise cycle.

Once the model says the target requires 14 reps at full productivity and finance has budgeted for 9, someone has to decide: cut the target, extend the timeline, change the segment mix toward faster-cycle deals, or accept a lower average win rate as a tradeoff for volume. Skipping this conversation is what produces a plan that looks fine in the boardroom in January and is quietly abandoned by every rep by June, once the gap between plan and reality becomes too obvious to keep ignoring in the weekly forecast call.