SDR outsourcing — the operating system for the provider
If you sell SDR capacity as a service, this is the platform that runs it: shared rosters across client projects, per-client pricing and commission, honest booking outcomes, and a client portal that proves delivery.
What this gets you
- One shared rep roster spread across many client projects, with unambiguous attribution
- Per-client products carrying a customer price and an SDR commission
- Booking outcomes that decide billability and payout from the same record
- A client portal that proves delivery without a monthly export
- Capacity answers before you sign the next client
Two audiences, one page
If you provide outsourced SDR capacity, this is the operating system for it.
If you are buying it, the second half of this page is about what to demand from a provider — and the honest answer is that most of it is about record-keeping, not headcount.
What makes outsourcing operationally hard
An outsourced SDR provider is not one sales team. It is N client relationships served by a shared pool of reps, each client on different commercial terms, each wanting proof of what they got. That shape breaks most sales tooling, which assumes one company selling one product.
Three specific failures:
Attribution. Reps are not dedicated one-to-one to clients. When a meeting lands it has to be unambiguous which client it belongs to and which rep gets paid for it. Dialbrew models this as a named roster per client project, held separately from the account manager who owns the relationship. So “who is working Client A this week” has a stored answer, and “who booked this” has exactly one.
Two prices for one event. The same booking is revenue at one number and cost at another. If those live in separate spreadsheets they will eventually disagree, usually in a month you have already invoiced. Here each client has products carrying both a customer price and an SDR commission, so one completed booking prices twice from one row.
Proof. The client is buying meetings they cannot see being made. Without a credible record, every renewal conversation starts from suspicion. A client portal shows them their meetings with outcomes, their reports and their billing — the same rows your team sees, not an export.
Pricing the service, and who carries the risk
Within a per-meeting model the billing trigger is the negotiation:
| Trigger | You carry | Client carries |
|---|---|---|
| Meeting booked | Nothing | Attendance + qualification risk |
| Meeting held | Attendance risk | Qualification-fit risk |
| Accepted as qualified | Attendance + their judgement | Little |
| Opportunity created | All of it + their sales process | Almost nothing |
Each step down should raise your per-unit price, because you are absorbing more variance. Teams get into trouble agreeing a qualified-meeting trigger at a booked-meeting price.
Meeting held is usually the right place to land: it aligns incentives without making the provider carry risks they cannot see. Dialbrew records held / no-show / no-show-with-reschedule as distinct states precisely so that trigger is enforceable rather than argued.
The clause most contracts leave vague
No-shows. Decide, in writing, before you sign:
- Prospect no-show — replaced, or billed? Capped?
- Prospect reschedules — same unit, or a new one? (It should be the same unit, or you are double-billing.)
- Client no-show — if their AE misses a delivered meeting, that is billable. Say so.
- Disqualified after the fact — within what window, on what criteria, with what evidence?
Then the symmetric internal question: what does the rep get paid in each case? Dialbrew encodes both answers in a stored compensation matrix, so the same scenario resolves identically every month and the client sees the credit appear by itself.
Capacity before you sign
Bookings-per-hour rates are maintained per rep per client project, with manager overrides, against hours that subtract public holidays and absences. That turns “can we take on this client in six weeks” from instinct into arithmetic.
If you are the buyer
Ask the provider four things:
- Can I log in and see my own meetings and outcomes, live? If the answer is a monthly PDF, their record is a copy and copies drift.
- Are no-shows visible to me, with credits applied automatically? Netting them off a total quietly is the most common way providers lose accounts.
- What exactly triggers an invoice? Booked, held, or accepted — and what is the rejection window?
- Who specifically worked my account this month? A stored roster answers it; a shared mailbox does not.
A provider running on Dialbrew can answer all four from the system. One running on a spreadsheet will answer them from memory.