Logistics and Warehouse Phone Systems: Handling Peak Voice Load

A warehouse phone system is judged on the worst ten minutes of the year, not on the average. When the morning inbound surge hits and every driver, carrier and supplier wants to know where their load is, the phone system becomes the constraint on the entire floor.

Definition: A warehouse or logistics phone system is a business voice platform sized and configured for high inbound and outbound call volume, with queue handling, IVR routing, on-site survivability and call recording for dispatch and dispute resolution.

Why warehouse voice breaks under peak load

Most warehouse telephony problems are not caused by insufficient capacity. They are caused by capacity being sized for the average and tested never.

A distribution centre's call pattern is spiky and predictable. In the first part of the shift the inbound queue fills with drivers confirming pick locations. Later in the afternoon outbound calls to carriers and suppliers stack up. Near the end of the shift there is a wave of delivery-confirmation calls. Average traffic over a full day might sit at a level that a modest system handles easily — but the same system's behaviour in the worst ten minutes of the busiest week is a completely different question.

Three failure modes show up repeatedly:

• Call abandonment. Callers hear a busy signal or an endless hold music and give up, then phone the load again. The operational cost is duplicated handling, not just an angry driver.
• Routing collapse. When the queue is full, calls need to go somewhere sensible — a supervisor, a callback queue, a shared line. Systems that cannot overflow gracefully turn a queue into a wall.
• The WAN failure that happens during a shift. In a warehouse, a network outage is not an inconvenience. It is a shift that stops working, and the clock keeps running.

The design principle that follows from this is uncomfortable but simple: size for the concurrent peak, not the daily average, and make sure the failure behaviour is designed rather than discovered.

Modelling peak inbound and outbound traffic

The planning sequence that works is arithmetic, but it needs the right inputs.

1. Count the concurrent work, not the headcount. In a warehouse, a large share of the "workforce" is not on phones at all. Forklift operators, pickers and packers rarely need an extension. Your extension count and your user count are very different numbers, and the difference matters for licensing.
2. Identify the simultaneous-call drivers. At peak, what fraction of the floor is on a call at once? If every supervisor on shift is holding two conversations at the top of the wave, peak concurrency is twice the number of supervisors on shift, not the number of supervisors.
3. Separate inbound from outbound concurrency. Outbound campaign or carrier-confirmation traffic consumes the same concurrent call capacity as inbound. A dispatch team working through a carrier list within a single hour is a load that looks trivial in a monthly call report and heavy in a busy-hour chart.
4. Add margin on the peak, not on the average. If your peak concurrency estimate already sits close to a published limit, plan for a platform whose concurrent call figure comfortably exceeds it rather than one that exactly meets it.

Newrock publishes the concurrent call figures directly, which makes the arithmetic concrete rather than something to request from a vendor:

For a mid-size distribution centre, the OM80E is the interesting row: 216 max users, 216 trunks, 48 built-in FXS/FXO ports and 90 concurrent calls. For a large regional hub, the OM200G family gives 120 concurrent calls with 96 built-in analogue ports. For a multi-site network where each site runs independently, the OM1000-UC at 200 concurrent calls per platform becomes relevant. Note the shape of the table: concurrent calls never scale linearly with user count, so a platform chosen on headcount alone will disappoint at the peak.

Surviving a WAN or PSTN failure mid-shift

A warehouse cannot pause, so the failover design is part of the capacity design.

WAN failure. If the site's phones depend on a head office PBX over the wide area link, a cut means silence on the floor. The MA50-LS local survivability branch exchange exists for this: 2 to 8 FXO ports, 50 to 200 SIP user registrations, local call service maintained when the head office or cloud server becomes unreachable, and automatic switch-back to the central server once the connection is restored. The MX60E-G adds a complementary layer at gateway level, with SIP registration failover, load balancing and PSTN failover, plus optional 1+1 redundancy on the network port and power supply — so a gateway in a remote building keeps serving when its uplink or its power fails.

PSTN failure. Carrier diversity is the only real answer here, and it is a trunk-provisioning question rather than a platform question. What the platform does have to do is fail over cleanly rather than dropping calls, which is where the MX60E-G's PSTN failover and the SX100's trunk redundancy and load balancing come in.

Power failure. The MX60E-G's optional 1+1 power redundancy matters more in a warehouse than in an office, because a rack that loses power takes down every port on it at once.

The question to ask at design review is not "does it have redundancy" but "if this one component fails, who can still make a call, and how many of them".

Call handling for suppliers, carriers and customers

A warehouse has three distinct caller populations, and treating them the same is the most common design mistake.

Carriers and suppliers are repeat callers who need specific information — dock number, booking reference, load status. They should not be queued behind general enquiries. An IVR that identifies the caller type and routes accordingly is worth more here than anywhere else.

Drivers are one-off callers, often calling from a mobile, often in a noisy cab. They need a short path to a human and a way to call back if they are put on hold. A callback option pays for itself in abandoned-call reduction alone.

Customers want a reference number and a promise. That means call recording on the inbound queue and a CDR trail that can be retrieved later.

Newrock's OM20G provides the call handling primitives for a small site: 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, reaching 48 FXS/FXO ports with registration failover, load balancing and PSTN failover. The SX100 session border controller adds trunk-side control with 1000 user registrations, 120 concurrent sessions, 70 media transcoding channels, call recording and voice quality monitoring, which is what a network operator or a multi-site warehouse group would use between the sites and the carriers.

Choosing between an OM series PBX and a gateway approach

Two architectures, and the deciding factor is where the analogue devices are.

PBX-only works when everything is SIP. The OM series covers 54 to 10000 users with published concurrency figures, and the built-in FXS/FXO ports on the OM80E (48) and OM200G (96) cover a meaningful legacy population without an extra box. This is the simpler estate to run: one platform, one management console through UMS.

Gateway-based makes sense when the analogue population is large and concentrated — a warehouse with a large population of legacy radio-telephony handsets, or a yard full of weatherproof extensions. The MX120G reaches up to 96 FXS and FXO ports; the MX60E-G reaches 48 with the failover features that matter at a remote site.

A hybrid is common in mixed estates: PBX at the main building, gateway at the yard, with the MA50-LS at sites where the WAN is not dependable.

Newrock perspective

Newrock's position on warehouse voice is that the platform has to be sized for the peak and configured so that the peak degrades gracefully. The OM series publishes concurrent call capacity so the sizing exercise can be done with real numbers rather than vendor adjectives — and the relationship between concurrent calls and user count is the number that catches people out, because 10000 users on the OM8000 still means 800 concurrent calls.

For the failover story, the MX60E-G's SIP registration failover, load balancing and PSTN failover with optional 1+1 network and power redundancy is the relevant specification, and the MA50-LS's local survivability with 2 to 8 FXO ports and 50 to 200 SIP registrations is what keeps a branch working when the link drops. UMS manages and remotely maintains the OM and MX fleet together, which matters when the platforms are distributed across sites that nobody visits often.

For reporting, CDR Software collects call detail records as .txt files to an external server and manages and retrieves them — the raw material for the queue and outbound campaign analysis that a distribution centre actually acts on. RMS does the same for recordings.

The OM80E IP-PBX, MX60E-G VoIP gateway and MA50-LS local survivability branch exchange pages are the ones to read for a warehouse or logistics deployment.

FAQ

How many concurrent calls does a warehouse actually need?

Work it out from peak behaviour, not headcount. Count how many people are genuinely on the phone simultaneously at the busiest moment, multiply by the calls each of them holds, and add the outbound load running at the same time. Then add margin. A useful sanity check is the concurrent call figure against the user figure in the capacity table — they are not proportional.

Do we need a dedicated call centre system?

Not for a warehouse. The OM20G includes call center features, 24/7 IVR, DID, direct access for VIP callers that bypasses the voice menu and auto-answer, which covers the queue and routing needs of a site without a separate platform. A dedicated contact centre product becomes worth it when you need skills-based routing, agent desktops and campaign management.

What happens if the internet goes down at the warehouse?

It depends on the design. With no local component, the site stops. The MA50-LS local survivability branch exchange keeps calls working locally when the head office or cloud server is unreachable, with 2 to 8 FXO ports and 50 to 200 SIP registrations, and switches back automatically once the connection is restored. The MX60E-G adds SIP registration failover, load balancing and PSTN failover with optional 1+1 network and power redundancy for the gateway layer.

How do we handle carrier diversity?

Order trunks from more than one carrier and configure failover at the trunk layer. The SX100 supports trunk redundancy and load balancing, and the MX60E-G supports PSTN failover, so a primary trunk failure routes to the secondary rather than dropping the call.

Can we use our existing radio or warehouse handsets?

If they are analogue, yes — through the built-in FXS/FXO ports on the OM80E (up to 48) and OM200G (up to 96), or through an MX-series gateway if the count is higher. If they are SIP, they will register directly. Verify the analogue devices early, because warehouse handsets and radio adapters vary more than office phones do.

Do we need call recording?

For dispute resolution and customer service quality, yes. RMS collects, stores, plays back and manages recordings from OM-series IP-PBX systems and MX-series gateways, and Recording Agent runs on Windows to collect OM recordings and store them as MP3. What you must confirm is your own retention and consent obligations under local rules, which are not something a product specification can settle for you.

How do we monitor several warehouses centrally?

UMS is built for that: it provides unified management and remote maintenance across OM-series IP-PBX systems and MX-series VoIP gateways. Combined with CDR Software collecting call detail records to an external server, you get both the operational telemetry and the reporting in one place.

Is there a per-user licence?

No — OM-series platforms license by device rather than by person. In a warehouse where most of the workforce never touches a phone, that difference between device count and person count is a real number on the quote.

Conclusion

A warehouse phone system has one job: keep the floor working through the morning surge and through the failure nobody planned for. Size on concurrent peak calls rather than headcount, and use the published concurrency figures to do it — 90 concurrent calls on an OM80E, 120 on an OM200G, 200 on an OM1000-UC, 800 on an OM8000, none of which scale the way the user figures do. Design the failover before you order: the MA50-LS for a site that must keep calling when the WAN drops, the MX60E-G's registration failover, load balancing and PSTN failover with 1+1 network and power redundancy for the gateway layer, carrier diversity for the PSTN. Route drivers, carriers and suppliers differently instead of funnelling them into one queue, and put CDR Software and RMS in place so the queue behaviour can be analysed rather than argued about. Then license by device, because most of a warehouse floor does not need a phone and should not be billed as if it does.