The multiplier that turns available hours into a forecast. Computing it naively as bookings divided by hours breaks on small samples — a rep with three hours of history does not have a meaningful rate. A Bayesian estimate starts from a sensible prior and moves toward the observed value as evidence accumulates, which keeps early forecasts conservative. Manager overrides should sit as a separate layer on top rather than editing the computed rate, so an override stays visible as a human judgement.

Two design details decide whether it holds up. First, the price must be frozen onto the record when it is created rather than looked up live, or changing a price next quarter silently rewrites invoices you already sent. Second, the meaning of “billed” has to be defined once and shared — a record sitting as a draft in your accounting system is not the same as one sent to the client — because if the client portal and the compensation logic use different definitions they will eventually disagree in public.

Treating the booking rather than the touch as the unit is what makes an operation measurable. A booking has an owner (the rostered SDR), a client project it belongs to, a calendar entry, a push into the client CRM, and — critically — an outcome. Until the outcome is known, a booking is a promise rather than a delivered unit, which is why counting bookings without tracking outcomes overstates performance.

The outcome is the fact that money depends on. Held means delivered. No-show means the prospect did not attend. No-show with reschedule is a distinct third state, because it has a different commercial consequence from a plain no-show — the meeting may still be delivered later. Collapsing these three into “booked” is the single most common way an SDR operation loses the ability to reconcile its billing.

One row per completed booking is the integrity rule that matters, and it is best enforced by a unique database constraint on the booking rather than by application logic — because background jobs retry and message queues redeliver, and either can attempt the same insert twice. The row then needs a lifecycle (pending, approved, paid, and the ability to revert) so that “has this been paid” is a stored fact rather than someone recollecting.

Every SDR operation has this policy; most keep it in somebody head. Writing it down as a matrix over the possible outcomes — who cancelled, how far in advance, whether a reschedule was requested, whether the meeting was already invoiced — makes the resolution identical every month regardless of who closes the books. It also lets the credit appear in the client view automatically, which is the difference between a non-event and a renewal conversation.

Separate from any national register, a client-level DNC list captures the organisations that specific client has asked you not to approach — existing customers, active negotiations, competitors, or anyone who has objected. The list has to be enforced at import time rather than checked manually, because a suppression that relies on a rep remembering is not a suppression. Treat an objection to contact as a GDPR obligation, not a courtesy.

For example +358401234567. It matters because it is the only format that deduplicates reliably. The same Finnish mobile can arrive in a CSV as 040 123 4567, 0401234567, or +358 40 123 4567 — three strings, one number, three rows in your list unless you normalise at import. Telephony APIs also generally require E.164, so normalising early avoids failed calls later.

On a shared prospect list, collisions are inevitable without a lock — and a prospect contacted twice in a day by the same company sounds disorganised. A reservation records which user holds the lead and when the hold expires, so an abandoned claim does not block the lead forever. A background job releases stale reservations. The expiry is the important design detail: a permanent assignment becomes a dead list over time.

Operationally a no-show is not a failure to record and forget — it is an event with two financial consequences. Whether the client is still billed, and whether the rep still earns, are separate policy questions. Deciding them case by case each month is how disputes start; encoding them in a compensation matrix is how they stop. A no-show should also be visible to the client, because a credit that appears automatically costs far less trust than one they have to ask for.

Role and visibility are different questions, and conflating them forces you to invent fake roles. Keying data scope off explicit permissions instead means a contractor SDR restricted to their rostered projects and an employee SDR with visibility across all clients can hold the same role and differ only by template. Employment type is then recorded as the HR fact it is, used to pick a sensible default at invite time rather than hardcoded into access logic.

Scoping the list to a client project rather than a global pool is what makes per-client reporting and per-client DNC enforcement possible. Lists need two pieces of lifecycle management that are easy to overlook: hygiene on the way in (phone normalisation, deduplication, suppression) and depletion alerting, because a rep working a list that has run dry is an expensive silence nobody notices for a week.

Distinct from the account manager who owns the client relationship — the two are deliberately separate, because the person who holds the commercial relationship is rarely the person dialling. A stored roster answers two questions that are otherwise guesswork: who is working this client this week, and does this rep legitimately get credit for this booking. It is also the natural basis for data scoping, so a contractor sees only the clients they are rostered on.

A sales development representative owns the top of the funnel: researching and contacting prospects, qualifying them, and booking a meeting for someone else to run. The distinction from an account executive matters operationally, because an SDR is measured on meetings produced rather than revenue closed — which is why an SDR operation needs a booking, not a deal, as its unit of output.

Distinct from sales engagement, which is about executing and optimising the touches themselves. SDR operations is the layer around that: deciding who works which account, making sure lists do not run dry or collide, recording what was done, establishing whether a booked meeting actually held, calculating what the rep earned, and proving the output to whoever is paying for it. In most organisations this layer is a spreadsheet.

The number that separates a real pipeline from an optimistic one. Two reps with identical booking counts and very different show rates are not performing equally, and a forecast built on bookings alone will be wrong by exactly the gap. Be careful about the denominator and the period: counting a reschedule as a separate booking inflates both sides, and attributing a meeting to the month it was booked rather than the month it was due makes the rate jump around for no real reason.

The definition people get wrong. Counting weekdays alone makes December and March look identical, so a capacity forecast is systematically wrong in exactly the months where it matters most. A correct count subtracts public holidays for the country the account operates in, which means holding a holiday calendar per country rather than hardcoding one. Absences and part-time schedules then reduce the figure further.