Lead management software for SDR agencies

What this gets you

• Prospect lists scoped to the client project they belong to
• Expiring lead reservation — two reps can never work the same company
• Phone numbers normalised to E.164 at import, so deduplication actually works
• Per-client DNC filtered at import, before any rep sees the row
• Phone quality tracked as data, so bad numbers are measurable per supplier
• Depletion alerts before a rep spends a week working an empty list

Lead management for an agency is a different problem

Most lead management software assumes one company working one pool of leads. An SDR agency works several clients’ lists at once, with a shared roster, different suppression rules per client, and a hard requirement that work never gets attributed to the wrong account.

That changes what the software has to do. Scoping is not a filter you apply — it is the structure.

Lists belong to a client project

Prospect lists are scoped to a client project, not a global pool. So are the products and pricing, the DNC list, the reporting, and the SDR roster. Per-client reporting and per-client suppression are properties of the data model rather than queries you remember to add.

A list carries its own lifecycle: imported, worked, depleted. Which brings us to the two problems that actually cost money.

Problem one: collision

On a shared list, two reps contacting the same company is a certainty, not a risk. To the prospect it reads as disorganisation, and it is entirely avoidable.

Opening a lead reserves it — a soft lock pinning it to that rep with an expiry. A background job releases stale holds.

The expiry is the design detail people get wrong. A permanent assignment turns a shared list into a graveyard of leads one rep touched once and will never revisit. An expiring hold keeps the list circulating. Reservations also extend automatically as the rep keeps working the lead, and release on a terminal outcome.

Problem two: silent depletion

This is the expensive one, because nothing errors. A rep working a depleted list produces nothing, activity numbers just drift down, and it can be a week before anyone asks why.

Each list carries a depletion threshold and alerts on it. Remaining workable list is also a far better leading indicator of next week’s output than this week’s dial count.

Import hygiene, enforced at import

Every control that depends on a rep remembering is not a control. These run at import time:

Phone normalisation to E.164. The same Finnish mobile can arrive as 040 123 4567, 0401234567, +358 40 123 4567 or 358401234567 — four strings, one number, and no deduplication will catch them because none of them match. Everything normalises to +358401234567 on the way in. The default country comes from the account’s configured country rather than being guessed per row.

Deduplication on a stable key. Company name is unreliable (Oy vs Oy Ab vs abbreviations). Domain is better. A normalised number is good — which is why normalisation has to happen first.

Per-client DNC filtering. Every client has companies you must not contact: their existing customers, live negotiations, competitors, and anyone who has objected. That last group is a GDPR obligation, not a courtesy. Suppression is applied before the row reaches a rep, and it survives re-importing the original source — a suppression a fresh CSV can overwrite is not a suppression.

Per-row error reporting. A summary count (“1,240 imported, 83 failed”) is not actionable, and a truncated error list is worse because it implies you have seen everything. The usual cause of a failed batch is one systematic formatting issue affecting hundreds of rows, fixable in seconds once visible.

Phone quality as data, not a feeling

Some proportion of any list is dead — disconnected, wrong, switchboards that go nowhere. The mistake is treating that as a vague sense that “the data is rough”.

Phone quality is a tracked status, recomputed as call outcomes accumulate, and the origin of each number is recorded on the lead. Two payoffs: you can stop reps burning hours on a list that is 40% dead, and you can tell which supplier’s data is actually worth paying for. The second one usually saves more money than the first.

Call outcomes also distinguish BAD_NUMBER (not in service — set automatically from the telephony response) from WRONG_NUMBER (number works, wrong person answered — set by the rep). Those are different data-quality facts and collapsing them loses the signal.

What a lead carries

Beyond the obvious contact fields: status, a two-dimension manual rating (was the company a fit, was the contact the right person), a structured lost reason, enrichment signals such as a recent hire or funding event, an append-only activity timeline across call/SMS/email/note, and an immutable history of every state transition with the actor who made it.

That last one matters for disputes. “Who disqualified this lead and why” has a stored answer.

What this is not

Dialbrew does not source leads. It has no contact database and will not find you new numbers. Bring your own data — from a provider, a scrape, or the client — and Dialbrew cleans, scopes, protects and tracks it.

It is also not a nurturing tool. There are no drip campaigns or lead-scoring automations designed to warm a lead over months; the model is an SDR working a list, not a marketing sequence.