One of the things I value most about my role as Principal Product Manager at Scurri is the direct access I have to enterprise customers. I spend a significant amount of time in conversations with operations directors, heads of warehousing, supply chain leads, the people who are living inside delivery management every day. Those conversations are where most of our best product thinking comes from, because the problems they describe are rarely the ones you’d invent sitting in a product planning session. They’re messier, more specific, and usually more expensive than anyone has formally acknowledged.
Over time, I’ve noticed a pattern. When I ask enterprise customers what frustrates them most about their current delivery management setup, the answers cluster around the same themes. Not the same words, but the same underlying problems. And the most common one, by some distance, is this: they’ve become more dependent on their platform provider than they ever expected to be, and it’s slowing them down in ways that are genuinely difficult to quantify.
What follows is an honest attempt to name those patterns ,partly because I think it’s useful for any operations team to have a clear framework for evaluating where their delivery management layer is creating drag, and partly because the market pressures that make this matter are only getting more intense.
1. Every carrier or service change requires a support ticket
This is the one I hear most often, and it tends to come with a particular kind of frustration: the frustration of something that seems like it should be straightforward turning into a multi-week process. A retailer wants to activate a new service tier with an existing carrier. A carrier updates their API. A team wants to toggle a value-add like PIN services or signature requirements. In traditional platforms, the operation has to go back to the provider for every single minor adjustment, raise a request, and wait for it to be configured.
The ticket itself is the symptom. The underlying problem is that legacy platforms weren’t designed to let operations teams manage carrier relationships and services themselves. At a moment when the carrier landscape is shifting faster than it has in years, that constant dependency is a meaningful constraint. New surcharge structures, updated service definitions, changes to carrier APIs, these things need to be absorbed into an operation quickly.
At Scurri, we believe in putting control back where it belongs. While our expert internal operations team handles the heavy lifting of the initial carrier onboarding and account configuration to ensure total accuracy, everything after that is in your hands. Once a carrier is live on your account, your team has complete, self-serve control to independently activate new services, manage configurations, and enable value-adds for various delivery scenarios without waiting on a ticket. It completely changes the dynamic, giving the ops team total commercial agility rather than waiting for someone else to unlock it for them.
2. Your dispatch logic reflects how the business worked at go-live, not how it works now
Carrier selection rules get set up at implementation. They reflect the carrier mix, volume patterns, and service requirements that existed at that moment. But businesses change, new carriers are contracted, volumes shift between channels, new retail partners are onboarded with different routing requirements, fulfilment points move. The dispatch logic, however, often doesn’t keep up, not because anyone made a deliberate decision to leave it static, but because changing it requires going back through the same ticket process, and there’s always something more urgent.
The result is that a lot of operations are making dispatch decisions based on logic that’s a year or two out of date. The operation works, orders get out, but it’s not working as well as it could. Carriers are getting volume that doesn’t align with their specific network strengths or specialized service tiers. Opportunities to leverage new, tailored services from carrier partners aren’t being used.. And because the system appears to be functioning, the gap between “working” and “optimised” often goes unmeasured.
This becomes particularly visible when the external environment changes quickly. The introduction of additional charges for parcels crossing into EU markets from the UK is a good example. Carriers have had to adjust their pricing structures, and retailers have had to reconsider their routing decisions, particularly for cross-border flows where a fixed surcharge per parcel can meaningfully erode margin at scale. An operation with flexible, self-managed dispatch logic can respond to that kind of change quickly. An operation where routing changes require a ticket and a wait cannot, and in the interim, it absorbs a cost it doesn’t need to.
The same applies to customs complexity in other markets. US import requirements vary by product category, and carriers have had to adapt their services and documentation accordingly. Retailers selling into the US need to be confident that their delivery management platform is current with those requirements and that they can adjust carrier selection and service routing without a long lead time. When they can’t, margin impact follows.
3. B2B label requirements are a constant source of friction
For retailers operating across both direct-to-consumer and trade channels, B2B label management is one of the less glamorous but genuinely painful parts of running a delivery operation. Every retail partner has its own specifications: label dimensions, data fields, barcode formats, placement requirements. Some have compliance standards that, if not met, result in chargebacks. Getting those requirements right isn’t a one-time setup; they change, partners are added, and the operations team needs to be able to update label configurations without it becoming a significant exercise every time.
In practice, what I hear from enterprise customers is that label changes sit in a queue alongside everything else, and the operations team has limited visibility into when they’ll be resolved. When you’re managing a retail partner relationship and they’ve updated their specifications, the gap between “we know what needs to change” and “the change is live” is a period of operational risk. It’s also, frankly, time and attention that the team is spending on something that shouldn’t require their management or input at all.
4. Tracking means logging into multiple carrier portals
When I ask ops teams how they monitor shipments in transit, the answer is almost always some version of “it depends which carrier.” There’s one portal for one carrier, a different login for another, a third system for international services. Exception management: identifying where something has gone wrong before a customer complains about it, requires checking across all of them, and the picture you get is never quite complete because the data sits in different places and updates at different times.
The commercial cost here is twofold. First, the customer service team is working harder than they need to in order to answer basic queries, because the information isn’t consolidated anywhere. Second, proactive exception management: catching a problem before it becomes a complaint is nearly impossible when the data is fragmented. The operations team ends up reactive by default, not by choice.
A centralised tracking layer that pulls data across all carriers into a single view changes this entirely. Not just for the operations team, but for customer service, for commercial reporting, and for the post-purchase experience the customer receives. It’s one of the areas where the difference between having the right platform and not having it is most immediately felt.
5. You can't easily see which carriers are performing and what delivery is actually costing you
Reporting is the area where I see the widest gap between what operations teams need and what their current platform gives them. SLA performance by carrier, cost per shipment by service and route, on-time delivery rates broken down in a way that’s actually useful for carrier conversations, these are the numbers that should underpin how a well-run delivery operation manages its carrier relationships. Without them, the ops team is managing on instinct and anecdote rather than data, and collaborative reviews with your carrier partners become difficult to have with any rigour.
This matters more as the carrier landscape becomes more complex. When you’re managing multiple carriers across B2B and D2C flows, with different service tiers, surcharges, and cross-border requirements in play, understanding your true delivery cost and how effectively you are utilizing your carrier network requires a reporting layer that can pull it all together cleanly. Most legacy platforms weren’t built to do that, and retrofitting it tends to produce dashboards that are technically functional but not genuinely useful for operational decision-making.
What this means in practice
None of the five things above is a crisis on its own. Individually, they’re manageable, the ops team finds workarounds, and the business keeps running. But together, they describe a delivery management layer that’s absorbing a significant amount of time and attention that could be going into improving the operation rather than maintaining it.
The market environment right now amplifies all of this. Carriers and logistics providers are having to adapt quickly to regulatory and cost changes: cross-border surcharges, updated customs requirements, shifting service definitions, and retailers need to be able to adapt alongside them without waiting on a platform vendor to do it on their behalf. That’s the standard I’d set for any delivery management platform: not just whether it can accommodate change, but whether it puts the operations team in a position to manage change themselves, quickly, without creating a dependency every time the external landscape shifts.
At Scurri, keeping our retail customers current with market changes, whether that’s new carrier services, regulatory updates, or cross-border requirements, is something we treat as a core obligation, not an optional service layer. The same applies to the support experience: our view is that a customer who needs to open a ticket should receive a fast, substantive response, not a queue number. But the goal, ultimately, is to build a platform where the operations team can handle most things themselves and the support ticket is the exception rather than the routine.
If any of the five signs above sound familiar, it’s probably worth asking whether the friction has become so normalised that its cost has stopped being visible. In my experience, it usually has.