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, faster activation) or a custom contract (negotiated terms, adds 2–3 business days of legal review on top of KYC). 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 opening the submission portal:

• 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 — ~24 hours / 1 business day)

This step is on the provider's side. On the public-offer path, KYC review typically completes in ~24 hours / 1 business day. A custom contract adds 2–3 business days of legal review before this stage begins.

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, what the failover destination is, 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 usage-based traffic pricing (which VoipTower currently uses), capacity is a technical sizing decision rather than a billing one. 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 — service tier and codec alignment.

Who configures the PBX trunk depends on your service tier:

• Tier 1 — Self-service: Provider supplies SIP credentials and configuration templates; your engineer configures the PBX (Asterisk, FreePBX, 3CX, or FreeSWITCH) and CRM/dialer. Suited to teams with in-house telecom engineers.
• Tier 2 — Assisted: Provider configures the trunk and inbound routing; your team handles CRM/dialer integration. The right fit for most BPO clients.
• Tier 3 — Full white-glove: Provider configures everything end-to-end, including CRM integration. For teams without internal telecom expertise.
• Custom platforms: Provider handles what it can; your platform vendor's support team handles the rest, with coordinated handoff.

VoipTower structures delivery across these tiers; confirm yours at contract stage if it wasn't already specified.

Whichever tier applies, 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 and CRM integration guidance, including supported PBX platforms, see the provider's integration page.

Step 7. CRM / dialer integration setup (if your tier includes it)

If your service tier includes CRM/dialer integration (or if you're on Tier 1 and handling it yourself), configure the connection between your SIP trunk/PBX and your CRM or dialer now.

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 or you must demonstrate administrative control of it.

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 24–48 hours 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 per your support agreement), response SLA

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, assigns a dedicated engineer per customer regardless of seat count, with group-chat support in your messenger (see its call-centre voice page). Regardless of provider, the 12-step sequence above remains the same at any deployment size.