BPO call center VoIP setup checklist: 12 steps from contract to live

This checklist is written for the implementation lead coordinating a BPO VoIP go-live. Follow the sequence in order and complete each confirmation gate before progressing.

The 12 steps below are grouped into three phases and move a deployment from contract acceptance to production traffic with a documented handoff at each stage. Each step ends with a Confirm before moving on gate: don't advance until you can tick it.

Phase A

Commercial & compliance

Step 1. Contract / Public Offer acceptance

Decide which commercial path applies: a public offer (standardised terms; the default path) or an individual contract (negotiated terms, available on request; timing is agreed with you). Sign or countersign. Confirm you hold a copy of the executed document and that both sides have acknowledged acceptance in writing.

Step 2. KYC submission (customer side)

Decision point — what to prepare.

Prepare the standard B2B VoIP KYC package before submitting it:

• Certificate of company registration
• Government-issued ID for the authorised director or signatory
• Business email address on your company domain
• Use-case description (call center type, destination countries, approximate daily call volume)

Submit the package complete and in one pass where possible, as missing items can delay review and activation.

Step 3. KYC review (provider side)

This step is on the provider's side. On the public-offer path, the request is reviewed within about 24 hours of submission; the account is activated once the review is complete.

While review is in progress, finalise your routing plan (Step 4), gather SIP configuration parameters from your PBX vendor, and confirm codec support with your infrastructure team.

Step 4. Number allocation request + routing plan agreed

Decision point — concurrent capacity sizing.

Request your DID numbers and submit a routing plan: which DIDs route to which queues or extensions, where a call goes if your team doesn't answer (a backup number you choose, set in your PBX), and whether inbound-only, outbound-only, or bidirectional trunking is required.

At the same time, finalise concurrent-call capacity:

Step 4 involves a capacity decision: how many concurrent calls the SIP trunk needs to support. Calculation framework: peak hour traffic × average call duration × seat utilization × 1.5 headroom. The financial impact of capacity sizing depends on the provider's pricing model — under per-channel models, overestimating means paying for unused channels; under per-minute traffic pricing (which VoipTower currently uses), channel limits per direction are confirmed at order. Under-sizing still matters either way: at peak, excess calls either queue or drop. Measure if you can, estimate conservatively if you can't.

For large deployments, plan for a staged capacity rollout: start at a comfortable ceiling and expand in phases rather than provisioning full peak capacity on day one.

Phase B

Technical configuration

Step 5. SIP trunk credentials issued

The provider issues SIP trunking credentials: server hostname or IP, port, authentication username, password or IP-whitelist entry (depending on whether the trunk is registration-based or IP-based). Store these securely in a password manager or secrets vault, not a shared chat window.

Confirm transport protocol (UDP/TCP/TLS; see RFC 3261) and whether SRTP is required. Mismatches here cause silent failures during testing.

Step 6. PBX-side trunk configuration

Decision point — setup scope and codec alignment.

VoipTower configures the SIP trunk (credentials or IP authentication), codecs and inbound routing of your numbers to your PBX, and helps your engineer on the PBX side, free of charge. VoipTower also helps connect calls to your CRM through your PBX or dialer — free, in the same chat. CRM-side development stays with your team or your CRM vendor.

Codec alignment between PBX and trunk is a configuration check you own. Supported codecs are G.711 a-law/μ-law and G.729. Set the PBX codec priority list to match what the trunk supports. Codec mismatch can show up later as one-way audio or dropped calls, so confirm alignment before testing.

For PBX setup and CRM connection guidance, including supported PBX platforms, see the provider's service page.

Step 7. CRM / dialer connection (your team or your platform vendor; VoipTower helps)

Your team or your platform vendor configures the connection between your SIP trunk/PBX and your CRM or dialer now; VoipTower helps connect the calls through your PBX or dialer.

Key checks: outbound caller ID passes through correctly; inbound calls trigger a screen pop or record lookup; call disposition codes write back to the CRM record. Test with a small user group before assigning the full agent population.

Step 8. DID-to-extension mapping

Map each allocated DID number to its destination: queue, ring group, IVR, or direct extension. Document the full mapping table: DID, destination name, destination ID, business-hours rule, after-hours fallback.

Use this table as the reference for go-live verification in Phase C. Keep it in a shared, version-controlled location.

Phase C

Testing & go-live

Step 9. Test call (inbound) — one-direction verification

Decision point — NAT/firewall handling.

Place an inbound test call to each DID (or a representative sample for large deployments). Verify: call connects, routes to the correct destination, audio is clear and bidirectional, call completes cleanly.

The first inbound test call often reveals NAT/firewall handling — a standard SIP setup consideration covered in RFC 3581. If the call does not behave as expected, resolve the handling before advancing.

Step 10. Test call (outbound) — CLI verification

Decision point — outbound CLI ownership verification.

Place an outbound test call and verify that the correct CLI appears on the receiving end. Outbound CLI must be verified-owned at the provider — an industry-standard anti-spoofing practice (see RFC 8226, part of the STIR caller-identity standards). Verifying ownership means the provider confirms you have the right to display that CLI: the number must be allocated to your account by the provider, or ported in and verified.

If the CLI displayed does not match expectation, check: (a) the PBX outbound route is sending the correct From header, (b) the CLI is registered to your account, (c) the trunk isn't overriding it at the provider level.

Step 11. Load test — concurrent-call capacity validation

Run a concurrent-call test up to (or close to) your agreed capacity figure from Step 4. Measure: call setup time, audio quality under load, call drop rate, and queue behaviour at or near the concurrent ceiling.

For large deployments on a staged rollout, run the load test at the first-phase capacity level, not the full eventual ceiling. Document results. If the drop rate or PDD under load falls outside acceptable bounds, investigate trunk capacity, PBX thread limits, and network QoS before cut-over.

Step 12. Cut-over and monitor — production traffic + support handover

Cut over production traffic. For phased rollouts, move one campaign or agent group at a time. During the first days of live traffic:

• Monitor ASR and PDD in real time
• Keep rollback path available (previous routing or PSTN backup)
• Confirm support handover: who to contact, escalation path, group-chat channel (Telegram / Teams / WhatsApp)

Pre-go-live readiness checklist

Before go-live, confirm:

• Concurrent capacity sized per Step 4 framework?
• KYC documents prepared per Step 2 list?
• PBX-codec aligned per Step 6?
• CLI ownership verified per Step 10?
• NAT/firewall handling tested per Step 9?

If any item is unresolved, hold the cut-over.

Support models differ by provider. VoipTower, for example, works in one group chat in your messenger regardless of seat count: questions get resolved in the same chat where your engineer, account manager and billing already are — no ticket queue, no department transfers (see its call-centre voice page). Regardless of provider, the 12-step sequence above remains the same at any deployment size.