Call Centre Software on IP-PBX: IVR, Queues and Reporting Without the Guesswork

A contact centre is not a phone system with a queue attached. It is a routing problem, and the routing problem is where most implementations go wrong — because the people who write the IVR menu are usually not the people who have to answer the calls it produces.

Definition: Call centre software on an IP-PBX is the layer that routes inbound and outbound calls to the right person or place, handles queues and overflow, applies business hours and IVR logic, and produces the reporting that tells you whether any of it worked.

What an IP-PBX can and cannot do for contact centres

It is worth being clear about this, because buyers routinely expect a phone system to be a contact centre and then discover the gap in month two.

What an IP-PBX handles well: call processing at volume, IVR menus, queue and hunt group management, overflow and ring group behaviour, business hours, holiday routing, caller ID and DID handling, call recording, direct access for priority callers, auto-answer, and call detail record production. These are telephony-native capabilities and they are where an IP-PBX is genuinely strong, because it already owns the call.

What it does not do: agent desktop integration, workforce management and adherence, skills-based routing with real-time agent state, predictive dialling, screen recording with agent activity, out-of-band supervisor coaching, CRM and helpdesk context on the agent's screen, or campaign management. These are contact centre application capabilities. They are bought separately and integrated.

Newrock's OM20G carries the telephony side explicitly: call center features, 24/7 IVR, DID, direct access for VIP callers that bypasses the voice menu, and auto-answer. The MX60E-G is built for higher-volume environments and reaches 48 FXS/FXO ports with SIP registration failover, load balancing and PSTN failover, and the SX100 session border controller adds the trunk-side layer with 1000 user registrations, 120 concurrent sessions, 70 media transcoding channels, call recording and voice quality monitoring.

So the practical answer: an IP-PBX can be the call routing engine of a contact centre, and for a site with a modest number of agents and a well-defined caller mix, it can be the whole thing. The moment you need agent state, you need an application layer on top.

IVR design for repeat callers

The most common design mistake in an IVR is treating every caller as new. In practice most callers have called before and have a specific reason.

A routing structure that tends to work:

1. Identify the caller type before asking for an account number. If the caller ID is recognised, route on that. This is where the OM20G's DID and direct access for VIP callers that bypass the voice menu pay for themselves — a known customer with an active issue should not be made to listen to a menu.
2. Offer a small number of top-level choices, each of which resolves quickly. A menu that asks a caller to classify their own issue reliably is rarer than people assume. Where the classification is genuinely hard, route to a human rather than to a deeper menu.
3. Support a callback path. Callers who abandon or are placed on hold can request a callback. This is one of the highest-value features per line of configuration in any contact centre, and it directly reduces abandonment.
4. Keep the escape hatch wide and obvious. A caller who needs a person should reach a person in two actions, at any depth, at any time. Deep menus are a cost centre in caller patience.

Two operational details that matter more than the menu design itself: the IVR must be available when the platform is, which means the call handling has to survive the failure cases described later in this article; and the menu must be changed on the basis of the reporting, which means the reporting has to be retrievable and attributable.

Queues, skills and VIP routing

Queue behaviour is where a contact centre either works or produces complaint tickets.

The essentials of good queue configuration: reasonable wait time expectations announced to the caller, periodic announcements so the caller knows they are still in the queue, an overflow target when the queue reaches a threshold, and an after-hours plan. The OM20G's 24/7 IVR and business hours handling cover the framework; what the configuration needs is the thresholds and the overflow destinations set deliberately.

Priority routing matters more than most implementations assume. The OM20G's direct access for VIP callers that bypasses the voice menu is a capability, not a setting — you need a rule that identifies the caller. Whether that is by caller ID, by a DID range, by a prefix, or by a database lookup determines how well it holds up against caller ID spoofing and against callers who genuinely need help but are not on the list.

Skills-based routing needs agent state, and that is the boundary of what the platform can do. Basic group routing — sales, support, billing — is available from hunt groups. True skills-based routing with real-time agent availability, wrap-up time and skills tags is an application layer concern. Being clear about this boundary early prevents the classic mid-project re-planning exercise.

Reporting: from call detail records to action

Reporting is what turns a contact centre from a queue into a managed operation, and it starts with call detail records.

Newrock's CDR Software runs on Windows, collects call detail records from OM systems as .txt files to an external server, and manages and retrieves them. The recording side is RMS, which collects, stores, plays back and manages recordings produced by OM-series IP-PBX systems and MX-series gateways, with Recording Agent collecting OM recordings and storing them as MP3. The OM20G also has built-in recording storage. For outbound and campaign work, the SX100's voice quality monitoring is relevant because a campaign with poor audio quality generates complaints that look like an agent problem and are not one.

The five numbers a contact centre should be able to produce without anyone exporting a spreadsheet by hand:

• Abandonment rate by queue and by hour. Not a monthly average — by hour, because that is where the staffing problem shows.
• Average wait time and longest wait. The average hides the complaints; the maximum is what the customer remembers.
• Calls offered versus calls handled. The gap is the overflow that went somewhere you did not intend.
• Resolution by route. Which menu path produces a resolution rather than a transfer. This is the number that justifies IVR changes.
• Outbound attempt and contact rates by campaign. Without this, outbound dialling decisions are made on instinct.

One caution worth stating: retention and consent obligations for recordings and call data are set by your jurisdiction and your policy. The technical system should be configured to whatever you establish, and the recording store should be access-controlled accordingly. Anyone quoting you a specific retention period is guessing.

Choosing an entry point: small site vs high-volume site

The sizing decision comes down to concurrent calls, not agent count, and the published capacity figures make it arithmetic.

For a small contact centre — with a small agent pool, a predictable caller mix, and modest outbound work — the OM20G is the natural starting point, with 24 concurrent calls, 24/7 IVR, call center features, DID, direct access for VIP callers and auto-answer, plus built-in recording storage. It is an all-in-one platform, which matters when the person running it has other jobs.

For a mid-size site, the OM50G at 140 max users and 30 concurrent calls, or the OM80E at 216 max users and 90 concurrent calls, depending on the concurrency profile. The OM80E's 48 built-in FXS/FXO ports also make it the right choice when the contact centre has a legacy analogue element — headsets on analogue handsets, older ACD terminals.

For a high-volume site, the MX60E-G is built specifically for high-traffic call centre and enterprise applications, reaching 48 FXS/FXO ports with SIP registration failover, load balancing and PSTN failover and optional 1+1 redundancy on network port and power supply. Its failover features are the reason it suits a site that cannot afford a single gateway failure. The MX120G reaches up to 96 FXS and FXO ports for large call centre deployments.

Where calls cross carrier boundaries, the SX100 provides the trunk and media layer with 1000 user registrations, 120 concurrent sessions, 70 media transcoding channels, customisable signalling header fields, codec and protocol conversion, DTMF mode conversion, call recording and voice quality monitoring, and trunk redundancy and load balancing.

Newrock perspective

Newrock's position on call centre software is that the platform should own call routing properly — IVR, queues, overflow, business hours, priority routing, recording and CDR — because those are telephony problems, and because doing them well does not require an application layer that only makes sense for larger sites.

The OM20G is the compact case: an all-in-one IP telephony system with call center features, 24/7 IVR, DID, direct access for VIP callers bypassing the voice menu, auto-answer, built-in analogue gateway module and recording storage, FoIP and voicemail, mobile extensions, a Windows SoftConsole for click-to-dial, call records and recording, XML and HTTP RESTful API support for integration into your own systems, remote access through New Rock Cloud, TR-069 and SNMP management, and Class I lightning protection. The XML and RESTful API support is the detail that matters when a contact centre needs to pull data from, or push actions into, an internal system.

For volume, the MX60E-G's 48 FXS/FXO ports with registration failover, load balancing and PSTN failover and optional 1+1 redundancy on network and power is the high-traffic answer, and the MX120G extends that to 96 ports for large deployments. For trunk and media control, the SX100 brings trunk redundancy and load balancing, voice quality monitoring and call recording. For reporting, CDR Software collects call detail records as .txt to an external server for management and retrieval, and RMS manages recordings centrally. For multi-site contact centre operations, UMS manages and remotely maintains the OM and MX fleet together, and the MA50-LS local survivability branch exchange with 2 to 8 FXO ports and 50 to 200 SIP registrations keeps a remote site serving calls when the central server is unreachable.

The OM20G IP-PBX, MX60E-G VoIP gateway and SX100 session border controller pages cover the platform side.

FAQ

Can an IP-PBX replace a full contact centre platform?

For telephony — IVR, queues, overflow, business hours, hunt groups, priority routing, recording and CDR — yes, and that is what the OM series provides. For agent desktops, workforce management, true skills-based routing with real-time agent state, predictive dialling and screen recording, you need an application layer integrated on top. Know which of those you actually need before you start.

How many concurrent calls do we need?

Count the calls in progress at your busiest moment, not your agent count. A team on long calls at a high occupancy rate produces a concurrent call figure well below its agent count, and the gap widens as call length and occupancy rise. Then check that against the concurrent call figures: 24 on the OM20G, 30 on the OM50G, 90 on the OM80E, 120 on the OM200G, 200 on the OM1000-UC, 800 on the OM8000.

How do we handle VIP callers?

Direct access that bypasses the voice menu, which the OM20G supports natively, but it needs a rule to identify the caller. Choose the identification method deliberately — caller ID, DID range, prefix or lookup against your own records — and consider how it behaves when caller ID is unreliable or spoofed. Route the identified caller to a dedicated group with a shorter queue.

Can we get reporting without writing SQL?

Yes. CDR Software collects call detail records from OM systems as .txt files to an external server and manages and retrieves them, and RMS collects, stores, plays back and manages recordings. These are retrievable datasets — what you build on top depends on your reporting tools.

What happens if the PBX fails during a busy hour?

That is a platform reliability question and it should have a plan. The MX60E-G provides SIP registration failover, load balancing and PSTN failover with optional 1+1 redundancy on the network port and power supply for the gateway layer, the SX100 provides trunk redundancy and load balancing, and the MA50-LS local survivability branch exchange keeps a remote site serving calls when the head office or cloud server is unreachable, with 2 to 8 FXO ports, 50 to 200 SIP registrations and automatic switch-back on recovery.

Can we integrate with our CRM or ticket system?

The OM20G supports XML and HTTP RESTful API support, which is the integration path for reading and pushing information. For anything deeper — click-to-dial from a CRM screen, screen pop, or recording attached to a ticket — that is an integration project, and it is worth specifying it as such rather than assuming the phone system will handle it.

Do we need to worry about call recording consent?

Yes, and the requirements are set by your jurisdiction and your policy rather than by any product. The technical side is straightforward: RMS collects, stores, plays back and manages recordings, Recording Agent collects OM recordings as MP3, and the OM20G has built-in recording storage. Build the consent and disclosure into the flow, and configure retention to your established policy.

How does this work for a multi-site contact centre?

One platform per site with the fleet managed centrally. UMS provides unified management and remote maintenance across OM-series IP-PBX systems and MX-series gateways, the OM series supports head-office and branch SIP trunk communication for inter-site routing, and the MA50-LS gives each site local survivability so a WAN outage does not silence it. CDR Software collects records from all sites to one external server for consolidated reporting.

Conclusion

A contact centre on an IP-PBX works when the platform owns routing properly and the reporting is actually used. Start with the caller mix, not the menu: identify repeat callers and give them a short path, offer a small number of top-level choices, build in a callback option, and keep the route to a human obvious at every depth. Set the queue thresholds, overflow destinations and after-hours plan deliberately, and route priority callers using a rule you have thought about rather than one that just looks good on the config page. Then size on concurrency — 24 calls on an OM20G for a small site, 90 on an OM80E, 200 on an OM1000-UC — because agent count is not the constraint. Add the MX60E-G when you need gateway-level failover and up to 48 analogue ports, the SX100 for trunk redundancy, media transcoding and voice quality monitoring, CDR Software and RMS for the reporting loop, UMS for a multi-site fleet and the MA50-LS for local survivability. And be clear about the boundary: the platform does telephony routing, and anything needing agent state is an application layer you add deliberately.