Sales capacity planning for SDR teams

What this gets you

• A per-rep, per-project bookings-per-hour rate that improves as evidence accumulates
• Manager overrides layered on top for cases the data has not caught up with
• Working-day counts net of public holidays for the relevant country
• An arithmetic answer to "can we take this client on in six weeks"
• Absences and per-user work-hour overrides already in the model

The question that is hard to answer

“If we sign this client, can we staff them?” Most operations answer it by instinct, because answering it properly needs three numbers nobody has: how many bookings each rep produces per hour, on each specific client, and how many hours they will actually be available in the relevant weeks.

All three are harder than they look.

Rates that account for uncertainty

A naive rate is bookings divided by hours. That falls apart on small samples: a rep who booked two meetings in their first three hours on a new project does not have a rate of 0.67/hour, and planning against that number will embarrass you.

Dialbrew maintains allocation rates per (SDR, project) pair using a Bayesian estimate, so a rate starts near a sensible prior and moves toward the observed value as evidence accumulates. A rep with twenty hours of history on a project has a rate you can plan against; a rep with two hours has one that is appropriately conservative.

On top of that sit manager overrides — a separate stored layer, not an edit to the computed rate. When a lead knows something the data does not yet (a rep is ramping, a client’s list quality just changed), they set an override and it is visible as an override rather than silently corrupting the underlying estimate.

Hours that are real

Capacity is a rate multiplied by available hours, and available hours is where most forecasts quietly go wrong.

Working days are weekdays minus public holidays. This is enforced across the platform rather than left to each calculation: any count of working days, billable days, expected hours or capacity subtracts public holidays for the account’s country, read from a cached holiday table. The country defaults to the account’s configured country code, Finland if unset.

It sounds pedantic until you forecast a Finnish December against a Finnish March and wonder why the team “underperformed”.

Absences are first-class — vacation, sick leave and personal time are recorded objects that reduce available hours, not annotations in a calendar.

Work hours are per-account with per-user overrides, so a part-time rep is modelled as part-time rather than as a full-timer who keeps missing targets.

Seeing where the hours actually went

Forecasting is only half of it. Work-time variance compares expected hours against what was logged, so a drift between the plan and reality surfaces while you can still act on it rather than at the end of the quarter.

Alongside it, EUR-efficiency reporting relates money produced to hours spent, per rep and per project — which is usually the number that actually decides whether a client relationship is worth keeping.

The honest caveat

A forecast is a forecast. The platform’s stated design target is a six-week horizon within ±15%, and that is an objective the system was built around rather than a measured guarantee. What it does remove is the three specific sources of error above: small-sample rates, invisible overrides and holiday-blind day counts.