Standard evaluation criteria were written for operations where one customer holds one account and calls about their own business. Logistics does not work that way, and vendors demonstrating against generic requirements will pass an assessment that never tested the things most likely to fail.
What follows is the set of questions I’d want answered before signing anything.
Why Standard Evaluation Criteria Miss Logistics
Most contact center selection frameworks assume a stable relationship between a caller and a record. Freight, parcel and fleet operations break that assumption in two specific ways, and nearly every practical difficulty traces back to one of them.
The Three-Party Problem
A shipment involves at least three parties with different relationships to you.
- The shipper pays the invoice and holds the commercial relationship
- The consignee receives the goods and generates most of the inbound contact
- The carrier or driver executes the movement and calls about exceptions
Only the first is your customer in the accounting sense. The second produces the majority of your call volume and frequently has no account, no credentials and no record in your CRM. The third calls from a mobile number that changes between subcontractors.
Ask any vendor how their platform handles a caller who is not the account holder but is legitimately entitled to information about a specific consignment. The quality of that answer separates platforms built for this sector from platforms adapted to it.
There’s a reporting consequence too, which surfaces later and irritates everybody. Contact volume attributed to accounts will understate what a shipper actually generates, because their consignees called you rather than them. A customer whose freight produces four hundred consignee inquiries a month appears in your reporting as a light user, and any cost-to-serve analysis built on that reporting is wrong in a direction that flatters the account. Ask whether the platform can attribute contacts to a shipment and therefore to the shipper behind it, rather than only to the calling party.
Volume Is Event-Driven Rather Than Seasonal
Retail contact centers forecast against predictable daily and weekly curves. Logistics volume responds to exceptions: a port delay, a customs hold, a weather event, a failed delivery attempt, a system outage at a partner.
That difference matters for staffing because historical averages describe what usually happens rather than what is about to. A vessel arriving two days late generates a contact spike no seasonal model anticipated, and the spike arrives with roughly twelve hours of warning if somebody is watching the right operational feed.
Twelve hours is enough time to act, which is the interesting part. Most operations do not act, not because the warning is unavailable but because the person reading the vessel schedule and the person building the roster have no mechanism connecting them. Whether a platform can accept an external demand signal is therefore only half the question; the other half is whether your own organization has anybody responsible for sending one.
ACXPA describes handling time as the primary input to workforce planning, where small movements carry significant staffing and cost implications (ACXPA). In logistics the same sensitivity applies to arrival forecasting, and the useful question becomes whether your platform can accept a demand signal from operational systems rather than only from its own history.
Identification, Routing and What the Agent Sees
This section produces the sharpest differences between vendors, and it’s where I’d spend most of an evaluation.
Can the System Identify a Shipment Before an Agent Answers?
The dominant contact reason in most logistics operations is some version of “where is it?” Handling that efficiently depends on capturing a tracking or consignment reference during the automated portion of the call and resolving it against your systems before anybody speaks.
Questions worth asking:
- Can the IVR accept alphanumeric references by keypad and by speech, including the mixed formats carriers actually use?
- What happens when recognition fails, and how many attempts before escalation?
- Can the system look up status in real time, or does it hand a raw reference to the agent?
- Can a caller be identified by phone number matched against consignee contact details rather than by account?
- What happens when one number relates to several active shipments?
Question five catches vendors out regularly. A regular consignee may have four consignments in transit, and a system designed around one-caller-one-record will either pick the wrong one or dump the disambiguation on the agent.
What Appears on the Agent’s Screen at Answer
Screen pop in most demonstrations shows a customer record. Useful in retail, considerably less so here, where the agent needs the shipment: current status, last scan, expected delivery window, exception codes, the responsible depot, and any open case.
Ask to see it with your own data. A vendor who can display a consignment record pulled live from a test environment during evaluation is telling you something real; one showing a mocked-up screen is telling you something else.
Consider what the agent needs to avoid asking as well. Every question an agent puts to a caller that the system already knows the answer to costs handling time and, more importantly, signals to the customer that the organization is not tracking their shipment attentively. Reading the last scan location back before the caller has finished explaining themselves changes the tone of the entire conversation, and it requires nothing more sophisticated than the lookup happening before answer rather than after.
Routing a Caller You Cannot Authenticate
Consignees usually cannot be authenticated the way an account holder can. They may have a tracking number and nothing else, which creates a genuine question about what they should be told.
Disclosing delivery status to whoever holds a reference number seems harmless until you consider what it reveals: that a specific business is receiving a shipment from a specific supplier, on a specific date, of a specific weight. For commercially sensitive freight that is information a competitor would value.
TabaTalk recommends defining disclosure tiers explicitly before configuring anything: what a reference number alone unlocks, what requires additional verification, and what stays restricted to the account holder. Then test that the platform can enforce those tiers at routing and at agent-desktop level, since a policy the system cannot support becomes a policy agents apply inconsistently.
Reasonable people land in different places on where the line sits. Consumer parcel operations lean toward openness, because friction on a delivery inquiry costs more than the disclosure risk. Freight forwarders handling commercially sensitive cargo lean the other way, sometimes considerably. What matters less is which position you take than whether it was decided deliberately, since the default in most platform configurations is whatever the implementation consultant assumed.
Integration Questions That Decide the Outcome
It’s the TMS and WMS That Matter, Not the CRM
Generic evaluations weight CRM integration heavily. For logistics the binding integrations are your transport management system, your warehouse management system, and whatever tracking layer sits above them.
Ask specifically:
- Which of our operational systems can you connect to, and have you done it before?
- Is the connection real-time query or scheduled synchronization?
- What is the latency on a status lookup during a live call?
- What happens to call handling when the operational system is unavailable?
- Can routing rules use operational data, such as sending exception-flagged consignments to a specialist queue?
That last one is where value concentrates. Routing a caller whose shipment already carries an exception code to a team equipped to resolve it, rather than to whoever answers next, removes a transfer and a re-explanation from every one of those interactions.
Latency deserves a specific number rather than a reassurance. A lookup taking four seconds is invisible inside an IVR prompt; one taking fifteen means either dead air or the agent answering before data arrives, which defeats the purpose. Ask what the measured response time is against a system of comparable size to yours, under load rather than in a demonstration environment with three test records in it.
What “Integration” Means in a Demonstration
Here’s a caution I’d apply to any vendor in this category, and I’d include scrutiny of claims that appear on solution pages generally.
Vendors describe integrations at several different levels, and the word covers all of them: a prebuilt connector maintained by the vendor, an API your team builds against, a middleware platform in between, or a single previous project delivered by professional services for one customer.
Ask which of those applies, per named system. Ask whether the connector is documented publicly. Ask to speak to a customer using that specific integration. Enterprise platforms including Genesys and its peers publish connector directories you can check independently, and any vendor claiming a named integration should be able to point at documentation rather than at a logo on a slide.
TabaTalk recommends treating an unverifiable integration claim as an absent capability during evaluation, then reintroducing it if evidence appears. That framing keeps the assessment honest without requiring anybody to accuse a vendor of anything.
Deflection: The Dominant Contact Reason
Status inquiries are the highest-volume, lowest-value contact type in most logistics operations, and they are unusually well suited to automation because the answer is a lookup rather than a judgment.
Practical value depends entirely on whether the platform can query your systems in real time. Automated handling reading back a status field twelve hours old produces a second contact rather than removing the first, which is worse than not deflecting at all.
Worth being clear-eyed about the ceiling as well. Status inquiries are automatable; the contacts that follow a genuine failure are not, because somebody whose shipment missed a production deadline wants a commitment rather than a status field. Deflection removes the easy half of your volume and leaves a residual mix that is harder, longer and more emotionally demanding, which changes what your remaining agents need to be capable of. Plan the capability shift alongside the technology, because the reduced headcount you modeled will not deliver the outcomes you expect if the people remaining were selected for handling simple lookups quickly.
Worth asking:
- Can automated handling read live status, or cached?
- Can it send a link or message rather than reading a long address aloud?
- What proportion of status inquiries does it contain, measured on our data rather than in general?
- What happens on handover, and does the agent see what the automated system already said?
That final question matters more than the containment rate. CEB’s research published in Harvard Business Review found customers wanted simple, quick solutions rather than exceptional service gestures (Harvard Business Review), and a handover that discards context forces the customer to start again, which is the clearest available way to deliver the opposite.
The Proactive Question Nobody Asks
Reactive deflection removes contacts one at a time. Proactive notification prevents them in batches, and the platform question is whether it can trigger outbound messaging from operational events rather than only from campaign lists.
A delay notification sent to two hundred consignees before they call is worth considerably more than a well-handled queue afterward. Ask how event-triggered messaging is configured, whether operations staff can build a trigger without developer involvement, and what channels it supports. TabaTalk’s Call Flow Builder covers the routing side of this, and the wider set sits in our guide to contact centre automation.
Peak Elasticity and Commercial Terms
Logistics demand is lumpy in ways that make standard licensing awkward. Fourth-quarter e-commerce peaks, regional shopping events, and disruption episodes all require capacity that sits idle the rest of the year.
Questions to put in writing:
- How quickly can we add agent licenses, and is there a minimum term on the addition?
- Can licenses be reduced after a peak, and with what notice?
- Is there a concurrency model rather than a named-user model?
- What happens to pricing if our volume doubles for six weeks?
- Are there usage-based charges that scale with contact volume rather than headcount?
- What is the provisioning time for a temporary team, including telephony?
Number six is the one that bites. Adding thirty seasonal agents is straightforward on the licensing side and considerably less so if each needs a configured extension, a recorded greeting, queue permissions and a tested desktop. Ask how long that actually takes, and ask somebody who has done it rather than somebody selling it.
Ask about removal as well, since the reverse direction is where costs quietly persist. Licenses that continue billing after a peak, because deactivation requires a support ticket nobody raised in January, are a recurring and entirely avoidable expense. Establish whether you can deactivate yourself and whether billing stops on deactivation or at the next renewal date.
The Contract Question About Disruption
Worth asking directly: what happens if we need double our contracted capacity for three weeks because a port closed?
Vendors answer this in one of two ways. Some describe a commercial process involving account managers and amended orders. Others describe a technical capability you can invoke. The second is what you want, and the difference only becomes apparent during an event when nobody is available to sign anything.
Build the answer into the contract as a defined burst allowance rather than relying on goodwill. Goodwill is genuine and also unevenly distributed across a vendor’s organization at two in the morning during a regional disruption, which is roughly when you will need it.
Language, Drivers and Gulf Realities
Regional operations carry requirements that generic evaluation frameworks omit entirely, and this is the section I would least expect a vendor arriving from another market to have thought about.
Language coverage is wider here than most vendors assume. Consignees and shippers commonly operate in Arabic and English; drivers and warehouse staff frequently speak Urdu, Hindi, Malayalam or Tagalog. That is not a single additional language requirement but several, each with its own queue, its own coverage cost and its own recruitment difficulty.
Test speech recognition and any automated handling separately per language using your own recordings. Performance varies substantially, and Arabic in particular presents difficulty because spoken dialects differ considerably from Modern Standard Arabic, while code-switching between Arabic and English mid-sentence is routine in this market.
Set acceptance thresholds per language rather than one global figure, and be prepared to deploy automated handling in the languages where it performs while leaving the others to agents. That is an unsatisfying answer to give a steering committee expecting uniform rollout, and I would rather give it than watch a deployment fail publicly in the language half the callers use.
Driver and field lines behave differently from customer lines. Calls are short, frequently from moving vehicles with variable connectivity, often about a single operational question, and sometimes urgent in a way customer contact rarely is. Treating them as one more queue on the customer platform usually disappoints everybody. Ask how the platform handles poor-quality mobile audio, whether drivers can reach a dispatcher without traversing a customer-facing menu, and whether messaging is a viable primary channel for that population.
Cross-border movement complicates the picture. GCC road freight crossing borders generates customs and documentation queries needing routing to people who handle them, which is a skills-based requirement rather than a general queue.
Operating hours stretch alongside it. Freight moves overnight and clears borders at hours no customer service roster was designed around, and a driver stuck at a crossing at three in the morning needs somebody reachable. Decide whether that is a staffed function, an on-call arrangement, or an automated path to a duty manager, then check the platform supports whichever you chose rather than assuming after-hours means a voicemail greeting.
The Question About Where Your Data Sits
Freight data reveals commercial relationships, volumes and pricing patterns, which some shippers treat as confidential in contract. Ask where recordings, transcripts and analytics are stored, whether residency can be specified, and whether backups follow the same commitment as the primary store.
Our vendor security questionnaire covers the full set of questions if your customers impose data handling requirements on you contractually.
Frequently Asked Questions
Should logistics operations use a general contact center platform or an industry-specific one?
Industry-specific platforms are rare in this category, so the practical choice is usually a general platform plus integration work. What matters is whether the vendor can connect to operational systems in real time and route on operational data, rather than whether their marketing names your sector. Evaluate the integration capability and the flexibility of routing configuration; a general platform that connects well outperforms a sector-labeled one that connects through nightly synchronization.
How should tracking number recognition be tested during evaluation?
Use your own reference formats and your own recordings, not vendor samples. Test alphanumeric strings by keypad and by speech, in each language your customers use, including accented and code-switched speech. Measure the failure rate and, more importantly, what happens on failure, since a system that loops rather than escalating creates worse experiences than one that transfers quickly. Test with background noise comparable to a warehouse or a vehicle.
What integration approach works when the TMS cannot be modified?
Middleware or an API layer sitting between the platform and the operational system is the usual answer, and it works provided latency stays acceptable for live lookups. Where the transport system offers no API at all, screen-level integration or scheduled data extracts are fallbacks, though both degrade the experience. Establish during evaluation which approach applies to your specific systems and who builds it, since integration effort is frequently the largest hidden cost in these projects.
How do you handle contact from consignees who are not your customers?
Define disclosure tiers before configuring the platform: what a reference number alone reveals, what requires further verification, and what stays restricted to the account holder. Route unauthenticated callers to queues configured for limited disclosure, and ensure agent screens reflect the same restriction rather than relying on training. Shippers with commercially sensitive freight sometimes specify these rules contractually, so check whether your agreements already impose requirements you are not currently enforcing.
Can proactive notification reduce inbound volume meaningfully?
It typically outperforms reactive deflection, since a message sent before somebody calls prevents the contact entirely rather than handling it more cheaply. Effectiveness depends on triggering from operational events rather than from scheduled campaigns, and on the message answering the question the customer would have asked. Measure the effect on inbound volume for the affected consignments specifically, rather than across total volume, since the signal disappears in aggregate reporting.
What should be tested before signing rather than after?
Live lookup against your own operational systems, tracking recognition in each language you serve, the agent screen populated with real consignment data, an event-triggered outbound message end to end, and the provisioning time for a small temporary team. Vendors resist proof-of-concept work on this scale, understandably. Insisting on it anyway is the single most useful thing a logistics buyer can do, because every one of those items is expensive to discover after implementation.
Working through a platform decision?
The most revealing exercise in any evaluation costs an afternoon: hand the vendor twenty of your own tracking references and ask them to demonstrate lookup, routing and screen population using your data rather than theirs.
TabaTalk provides cloud contact center software built for Gulf operations, covering omnichannel routing across voice and messaging, no-code flow design, event-triggered outbound, and configurable queues for customer, driver and exception traffic. Contact our sales team to review your transportation setup, or ask us to run a lookup test against your own consignment references before you shortlist anybody.
