Implementation Guides

Realistic timelines

Be sceptical of any vendor timeline that does not ask about your CRM, your list hygiene and your training throughput first. Those three answers determine the date; the platform is the easy part.

The first 30 days

A sequence that holds up because each step's output is the next step's input.

1. Days 1–3 — Decide what success looks like. Pick the core six KPIs and record your current baseline for each. If you cannot state today's numbers you will not be able to prove the project worked.
2. Days 2–5 — Data readiness. Dedupe, validate, timezone-tag and scrub the list. Do this before configuration, because list structure drives campaign structure.
3. Days 3–7 — Numbers and carrier. Provision or port, confirm attestation, set caller ID strategy.
4. Days 5–10 — Core configuration. Campaigns, queues, skills, dispositions, calling windows, abandonment ceilings.
5. Days 8–15 — Integration. Field mapping, screen pop, disposition write-back, then user acceptance testing with real records.
6. Days 12–18 — Scripts and IVR. Build, then walk every path aloud with someone who has never seen it.
7. Days 15–22 — Agent training. Run in training mode against realistic scenarios, not a slide deck.
8. Days 20–24 — Pilot. One team, one campaign, real traffic, conservative settings.
9. Days 24–30 — Scale and tune. Raise pacing incrementally, calibrate QA, compare against the day-one baseline.

Data readiness

The most common cause of a disappointing go-live is a list that was never cleaned. The platform dials what you give it, faithfully, including the duplicates.

• Deduplicate across sources — the same person on three lists gets called three times and complains once.
• Validate number format and type — landline vs mobile matters for both consent and connect rate.
• Timezone-tag every record — required for lawful calling windows, and area code is not a reliable proxy for where someone lives.
• Scrub before load, and again before each dial — see DNC scrubbing.
• Carry consent provenance as a field — source, timestamp, disclosure text. If it lives only in the origin system you cannot prove it at dial time.

Numbers and carrier setup

Porting existing numbers takes carrier time you do not control, so start it first and provision temporary numbers to unblock configuration. Decide caller ID strategy deliberately rather than defaulting: how many numbers, matched to what geography, rotated how often. Aggressive rotation reads as spoofing to carrier analytics and will cost you reputation.

Confirm your STIR/SHAKEN attestation level during setup, not after connect rates disappoint. And register for branded calling where your volume justifies it.

Campaign design

A campaign is a list plus a dialing mode plus pacing plus a script plus a disposition set plus caller ID plus calling-hour rules. Getting the disposition set right matters more than anything else on that list, because dispositions drive redial logic, suppression and every report you will later argue about.

• Keep the disposition list short. Twelve well-chosen codes beat forty. Agents pick accurately from a list they can see without scrolling.
• Make every code drive an action. If a disposition does not change what happens to the record, delete it.
• Separate outcome from reason. "No sale" and "wrong number" are not the same kind of fact.
• Map suppression codes explicitly. Which codes write to your internal DNC list should be a decision, not an assumption.
• One campaign per segment. See list segmentation.

Queues and routing

Queue design determines abandonment as much as staffing does. The main trade-off is skill granularity: narrow skill groups raise resolution rates and lengthen queues, because a narrow group is harder to keep staffed.

• Define skill groups broad enough to remain staffable at your smallest shift.
• Set overflow before you need it, with an explicit second and third choice.
• Offer a virtual hold callback at a wait threshold — usually the cheapest abandonment reduction available.
• Cap maximum wait and decide deliberately what happens at the cap.
• Separate incident traffic from routine service so an outage does not corrupt your baseline reporting.

IVR design

Badly designed IVR is one of the most common causes of high abandonment, and it is usually caused by designing the menu around the org chart rather than around what callers ask for.

• Four options per menu, three levels deep, maximum. Beyond that callers stop listening and start pressing zero.
• Order options by actual call reason volume, measured, not assumed.
• Put the most common reason first and never make callers hear promotional messaging before the menu.
• Always provide an escape to a human. Hiding it does not reduce demand, it produces angrier callers.
• Test by reading it aloud to someone unfamiliar with the business. Menus that look clear written down are frequently unusable spoken.

Agent onboarding

Training throughput is a real constraint on go-live and it is routinely ignored in project plans. Fifty agents do not get trained in the time twelve do.

Use training mode against realistic scenarios, including the difficult ones — the angry caller, the revocation request mid-call, the record that turns out to be the wrong person. Agents who have rehearsed a revocation request handle it correctly; agents who have only read about it do not, and that is a compliance failure rather than a training gap.

Workforce forecasting

Forecasting converts expected contact volume and handle time into the headcount needed to hit a service level. Erlang C is the standard formula. It assumes callers wait rather than abandon, so it overstaffs slightly for centers with high abandonment — a conservative error, and the right direction to err.

QA programme setup

Build the scorecard before go-live, not after the first bad month. A workable one is short: six to ten items, each observable from the recording alone, each with a written definition of what "meets" looks like.

• Calibrate before scoring anyone. Have three evaluators score the same five calls; if they disagree, the rubric is ambiguous, not the evaluators.
• Score for coaching, not for ranking. A QA programme used primarily to justify terminations stops producing honest scores within a quarter.
• Include compliance items as pass/fail rather than weighted points.
• Decide sample size honestly. Two calls per agent per month is a sample too small to conclude anything from — see automated QA for the alternative.

Integration scope

Integration is where timelines actually go. The scope question that matters is not "does it integrate with our CRM" but "which direction does each field flow, and what wins on conflict". Answer that in writing before configuration starts. Details in the CRM integration guides.

Week-one troubleshooting

Deep-dive guides in progress

Each of these becomes a working document — a checklist or worksheet you can take into a project meeting rather than an article you read once.

• The 30-day go-live plan as a printable checklistIn progress
• Data readiness: a pre-load audit worksheetIn progress
• Disposition scheme design, with a worked exampleIn progress
• IVR design: menu structures that reduce abandonmentIn progress
• Erlang C staffing: a populated worked exampleIn progress
• Shrinkage: measuring your own rather than borrowing 32%In progress
• QA scorecard and calibration packIn progress
• Migration: reconciling old and new reportingIn progress

These are listed without links on purpose — we would rather show you what is coming than send you to a page that does not exist yet. Tell us which to prioritise.

Frequently asked questions