What SDR operations actually is (and why it is not sales engagement)

Most tooling in sales development is built for engagement — designing a sequence, sending the touches, measuring which message performs. SDR operations is a different discipline. It is the work of running the function: supplying it, staffing it, measuring it honestly, paying for it, and proving it to whoever is funding it.

The distinction is not academic. A team can have excellent engagement and broken operations, and the symptom is always the same: a reconciliation at the end of every month that somebody does by hand.

A working definition

SDR operations is responsible for five things.

1. Supply. Someone has to make sure reps have lists to work, that those lists are clean, that they do not collide, and that nobody is sitting on an empty list for a week without anyone noticing.

2. Staffing. Who works which account, how much capacity that represents, and whether you can take on more work six weeks from now.

3. Record. What was actually done to each prospect, by whom, and what came of it — in a form that survives staff turnover and can be produced in a dispute.

4. Money. What each rep earned, what each client owes, and the guarantee that those two numbers were derived from the same facts.

5. Proof. Giving the person paying for the meetings a credible, current view of what they got.

Engagement platforms address none of these directly. That is not a criticism — it is a scope boundary.

Failure mode one: supply runs on vibes

The two specific problems are collision and depletion.

Collision is two reps contacting the same company on the same client. Without a locking mechanism it is a certainty on any shared list, and to the prospect it reads as disorganisation. The fix is a reservation: an expiring claim that pins a lead to the rep working it. The expiry is the part people get wrong — a permanent assignment turns a shared list into a graveyard of leads nobody will revisit.

Depletion is quieter and more expensive. A rep working a list that has run dry produces nothing, and because the activity numbers simply drop rather than erroring, it can go a week before anyone asks. Depletion alerting per list is unglamorous and pays for itself immediately.

Failure mode two: the record is a copy

If your client report is an export, it is a copy, and copies drift from their source. The client has no way to check, so when the report and the invoice disagree a reporting task becomes a trust problem.

The structural fix is that the client reads the same rows you do, scoped by tenancy, rather than a monthly extract. This also eliminates the whole category of conversation that begins by reconciling two documents.

Failure mode three: outcomes collapse into “booked”

This is the most common and most damaging. A booking is a promise, not a delivered unit. Until you know whether it held, counting bookings overstates performance — and the overstatement is not uniform, because show rates differ meaningfully between reps and between clients.

Track three distinct states, not one:

• Held — delivered.
• No-show — the prospect did not attend.
• No-show with reschedule — distinct, because the meeting may still be delivered and the commercial consequence differs.

Two reps with identical booking counts and different show rates are not performing equally. A forecast built on bookings alone is wrong by exactly the size of that gap.

Failure mode four: two sources of truth for one event

A booked meeting is revenue at one number and cost at another. If commission lives in one sheet and client billing in another, they will eventually disagree — usually in a month you have already invoiced.

The only robust fix is derivation from a shared record. The same billable set that produces the client invoice should produce the commission rows, and “has this been billed” should be defined exactly once and read by everything. Two definitions of billed, in two places, will diverge.

Two further details matter more than they look:

• Idempotency. Background jobs retry and message queues redeliver. Without a unique constraint tying one commission row to one booking, a retry can double-pay. This belongs in the database, not in application logic that can be bypassed.
• Frozen prices. A sent invoice must stay reproducible. If the billing record looks the price up live, changing a price next quarter silently rewrites history.

Failure mode five: capacity maths that ignores the calendar

Capacity is a rate times available hours, and both halves are usually wrong.

The rate gets computed as bookings divided by hours, which collapses on small samples. A rep with three hours of history on a new client does not have a meaningful rate, and planning against one will embarrass you. An estimate that starts from a prior and moves toward the observed value as evidence accumulates keeps early forecasts appropriately conservative. Manager overrides should sit as a visible separate layer rather than silently editing the estimate.

Available hours gets computed as weekdays. This is the error that makes a December forecast identical to a March one. Working days are weekdays minus public holidays for the country the account operates in, then reduced further by absences and part-time schedules. It sounds pedantic right up until you review a quarter and conclude the team underperformed when in fact your denominator was wrong.

The threshold question

None of this argues that every team needs a platform. A spreadsheet is genuinely better for exploration, costs nothing, and handles bespoke arrangements a product would refuse.

The honest threshold is two signals:

1. Someone spends a day a month reconciling.
2. A rep or a client has disputed a number and you could not immediately prove it.

Below that, keep the spreadsheet. Above it, the cost has stopped being the tool and started being the reconciliation — and at that point operations deserves a system rather than a discipline.