Incentive compensation management for SDR teams

What this gets you

• Commission computed from the booking itself, not from an exported spreadsheet
• Exactly one commission row per booking, enforced by a unique database constraint
• A retried job or redelivered message cannot double-pay — the database refuses it
• Approve → pay lifecycle, so "has this been paid" is a stored fact
• Cancellations and no-shows resolved by a stored policy, applied identically every month
• The same billable set produces both the payout and the client invoice

The problem with most incentive compensation management

ICM platforms are good at modelling compensation. They share one assumption that quietly causes most of the pain: the data arrives from somewhere else.

Someone exports activity from a CRM, maps it to plan rules, loads it, reconciles the result against what actually happened, and fixes the gaps by hand. The modelling is sophisticated; the input is a monthly data-wrangling project. And for an agency there is a second problem the ICM category does not address at all — the money moves in two directions. You pay a rep and you invoice a client for the same meeting, and nothing checks that those two numbers agree.

Commission as a by-product, not a project

Dialbrew computes compensation from the work as it happens, because it is the system the work happens in.

A lead is reserved to a rep. Calls, SMS and notes land on that lead’s timeline. A booking is created and pushed to the client’s CRM. An outcome is recorded — held, no-show, or no-show-with-reschedule. That outcome generates the commission row. No export, no mapping, no reconciliation step.

Products carry both prices

Each client has products, and every product carries a customer price and an SDR commission, each with its own currency. One is the default. Products are archive-only and never deleted, so a historical booking always resolves to the product that priced it.

A completed booking therefore prices twice from one row — once for the invoice, once for the payout. That is the structural reason the two figures cannot drift apart. There is no second system to reconcile against.

One row per booking, enforced by the database

This is the detail that matters most and gets implemented least often.

A completed booking generates exactly one commission row, enforced by a UNIQUE (booking_id) constraint. The guarantee lives in the database, not in application logic that can be bypassed and not in a human reading a spreadsheet. Background jobs retry. Message queues redeliver. Both can attempt the same insert twice. A constraint makes the duplicate impossible rather than unlikely.

An explicit lifecycle

Commission rows move pending → approved → paid, with reversion available. “Has this been paid” is a stored state with a timestamp and an actor — not a recollection, and not inferred from a bank statement.

Critically, the sync that maintains commission rows from booking outcomes will never touch a row a manager has already approved or paid. It reads the current state first and skips those. Re-computing an approved payout is exactly the kind of silent error that destroys trust in a compensation system.

The compensation matrix: deciding edge cases once

Every SDR operation has a policy for cancellations and no-shows. Most keep it in somebody’s head, which means it gets applied differently depending on who closes the books that month.

Dialbrew encodes it as a matrix over the real scenarios — who cancelled, how much notice, whether a reschedule was requested, whether the booking had already been invoiced — producing two answers per case:

1. What the client is credited
2. What the rep keeps

Those are separate decisions. It is entirely coherent to credit the client and pay the rep when the failure was not the rep’s doing — and that is usually the right call, because a rep who loses income to a prospect’s absence stops trusting the whole system.

Because the policy is stored, the same situation resolves the same way in March and in November.

Frozen prices, reproducible history

When a commission row or a billing record is created, the price is copied onto it. Raise a client’s price next quarter and last quarter’s payouts and invoices still reproduce exactly, because nothing looks the price up live.

This sounds like a footnote until you need to reproduce a payslip from eight months ago, or a client disputes an invoice you already sent.

What this is not

Dialbrew is not an enterprise ICM platform. It does not do multi-tier channel compensation, territory planning, complex accelerator structures, or quota modelling across a large sales organisation. Dedicated platforms — Everstage, CaptivateIQ, Xactly and others — are genuinely better at those, and if that is your problem you should buy one.

What Dialbrew does that they do not: produce the data in the first place, and close the loop by deriving the client invoice from the same billable set.

It also does not run payroll. The payout itself happens in your own payroll or invoicing process. What the platform guarantees is that the number handed to that process is correct, singular, and reconciles with what the client was charged.

When this fits

You have several clients, several reps, and a commission model that differs by client. Someone currently spends real time each month turning booked meetings into both a payout and an invoice, and making sure the two agree.

If you have one client and one comp scheme, a spreadsheet is genuinely fine and we would rather say so.