Sales performance management for SDR teams

What this gets you

• Performance rollups pre-aggregated per rep and per rep-per-client-project
• Bookings-per-hour rates that stay conservative on small samples
• Money produced per hour spent, per rep and per client
• Work-time variance: expected hours against hours actually logged
• Show rate measured at the grain where the cause lives

Measuring SDR performance badly is easy

Most SDR dashboards are not using the wrong metrics. They are using the right metrics with wrong denominators, and the errors are systematic rather than random.

Three that recur:

Weekdays instead of working days. Counting weekdays makes December look like March, so per-day productivity appears to collapse in holiday-heavy months and a team gets a performance conversation it did not earn. Dialbrew counts working days as weekdays minus public holidays for the account’s country, then reduces further by absences and part-time schedules. This is enforced platform-wide rather than left to each calculation.

Booked meetings instead of held meetings. A booking is a promise, not a delivered unit. Counting bookings overstates performance, and not uniformly — show rates differ meaningfully between reps and between clients. Held, no-show and no-show-with-reschedule are three distinct recorded states here.

Rates from small samples. A rep with three hours of history on a new client does not have a meaningful bookings-per-hour rate. Treating two bookings in three hours as 0.67/hour and planning against it is how forecasts embarrass people.

What gets measured

Performance rollups are pre-aggregated per rep, and per rep per client project, across daily, weekly and monthly periods. Pre-aggregation is what makes a live client portal viable rather than slow.

Each rollup carries calls made and connected, bookings, meetings completed / no-showed / disqualified / rejected, connect rate, conversion rate, no-show rate, scheduled hours, observed active hours and absence hours.

Allocation rates estimate bookings-per-hour for each (rep, client project) pair using a Bayesian estimate: the 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 has one that is appropriately conservative.

Manager overrides sit as a separate stored layer on top — visible as an override rather than silently corrupting the computed estimate, with the original model value preserved so you can revert.

Work time is accrued from the application itself, pausing on idle and when the tab is hidden, so observed active hours are a real signal rather than a self-reported timesheet. Work-time variance compares expected hours against logged hours, so drift surfaces while you can still act on it.

Money per hour relates revenue produced to hours spent, per rep and per client project. This is usually the number that actually decides whether a client relationship is worth keeping — and it is the one most operations never compute. A client with a hard-to-reach target market and a 40% show rate can be comfortably loss-making while headline revenue looks healthy.

Gaming, and how the design resists it

Any metric that drives pay gets optimised, including in ways you did not intend. Bookings invite low-quality meetings; dials invite short pointless calls; self-reported hours invite under-logging.

Two structural guards: pay on held rather than booked, which removes the main volume incentive; and take hours and outcomes from the system rather than from self-report. Logged activity and recorded outcomes are much harder to shade than a timesheet.

On benchmarks

Teams constantly ask what a good show rate or bookings-per-hour figure is. The honest answer is that your own trailing numbers, segmented by client, are a far better benchmark than any industry figure — because they already control for your market, your list quality, your pricing and your qualification bar.

The platform’s stated design target is a six-week capacity forecast within ±15%. That is an objective the system was built around, not a measured guarantee.