The conversation gets the attention. The dialler decides whether it ever happens.
A perfect agent that calls at the wrong hour is worth nothing. Most of the gap between a programme that works and one that does not sits before the customer says hello: who you called, when, how many times, on what number, and whether the rules let you. That is what this layer does, and it is the least glamorous thing we build.
Six jobs, none of them optional.
Your book arrives and it has to be turned into an order of attempts. Not everyone is worth calling first, and some are not worth calling at all today. Segment by the thing that actually predicts a result: days past due, ticket size, promise history, whether the last attempt reached a person.
- Priority set per campaign, not one queue for everything
- Suppression for accounts already resolved, disputed or paid
- Reordering as the day's outcomes come in, so effort follows what is working
Reachability is a function of hour and day, and it differs by segment. A salaried customer and a shopkeeper are reachable at different times, and calling both at 11am wastes half your attempts.
- Attempt windows set per segment rather than per campaign
- The right-time signal learned from your own connect history, not a generic table
- Respects time zones and regional holidays, so calls land at a legitimate local hour.
This is where the risk team decides whether you go live. Calling-hour restrictions, do-not-disturb registers, consent state and the contact-centre regime all constrain who may be called and when. A rule written in a training deck holds on some calls; a rule enforced in the platform holds on all of them.
- Permitted calling windows applied before an attempt is queued, not checked afterwards
- Do-not-disturb and consent state respected at attempt level
- Attempt caps per account per period, so nobody is harassed into a complaint
- Enforcement behaviour is configured to the applicable regulatory regime.
Most diallers retry on a timer. That is the wrong variable. A ringing-no-answer, a busy tone, a switched-off phone and a wrong number are four different problems and deserve four different next moves. Retrying a disconnected number eleven times is how a programme burns its capacity and its credibility at once.
- Next attempt driven by the last disposition, not a fixed interval
- Escalation to a different channel or a person when the pattern says the number is dead
- Attempts stopped the moment the outcome is achieved, including outside the call
Reaching the customer is only half of it. The line has to be good enough that the conversation does not fall apart, and the number you show has to be one they will answer.
- Number presentation and rotation are handled in line with carrier rules.
- Silence and voicemail detected so the agent does not open to an answering machine
- Line quality tracked as a first-class metric, because bad audio ruins a good model
The team that runs the book has to be able to change the book. If a pacing change needs an engineering ticket, the programme moves at the speed of a release cycle instead of the speed of the day.
- Campaigns started, paused, reprioritised and re-paced by your operations team
- Concurrency raised for a month-end push and dropped afterwards, without a deployment
- Every change logged, so the audit answer includes who changed what and when
Most failed programmes failed here.
In our experience the usual causes are duller than that: the list was stale, the attempts landed when nobody was home, the retries were spent on unreachable numbers, or a compliance constraint quietly capped the volume nobody had planned for. When a pilot underperforms, this is the first layer we look at, and it is usually where the answer is.
It is easy to make a dialler look busy. Concurrency is the vanity metric of this layer, and a platform can burn through a book at impressive speed while achieving very little. What we optimise is the ratio between attempts made and outcomes reached, which is the same number your operations head is judged on.
The same layer answers when they call you back.
A customer who received a call at 3pm often rings back at 7pm, and if that call lands in a queue behind everything else, the work you did in the afternoon is wasted. Inbound is answered immediately, the AI already knows what the earlier conversation was about, and the customer does not start again from the beginning. That continuity is the point of running both directions through one system rather than bolting an outbound tool onto an existing switchboard.
Bring us a bad list and the result will be bad.
No amount of pacing intelligence fixes a book where a third of the numbers are wrong and the balances are out of date. If the data is stale, the first fix is the data, and we would rather say that in the first meeting than discover it in week six of a pilot. Ask us what we need from your side and we will give you a short, specific list.