Author: Domagoj Markovina
Delivery operators handle millions of customer interactions every year. Most of them aren’t complaints. They’re not disputes. They’re people asking one simple question: “Where is my parcel?”
That question, repeated thousands of times a day, is quietly overwhelming customer service teams across the industry. Queues are long, agents are stretched, and customers arrive frustrated before anyone even picks up. Leadership wants costs down. Service quality can’t slip. And somewhere in the middle of all that sits a transformation project that nobody quite knows how to scope.
The instinct is usually to buy something. A new CRM. A better contact centre platform. A chatbot. But large-scale customer service transformation at a delivery operator is rarely a technology problem at its core. It’s an operational problem with a technology component. Getting that distinction wrong is why so many of these projects run late, cost more than planned, and quietly disappoint.
First, find out why people are actually calling
Before you touch any system, you need a clear picture of your call drivers – in real detail, not rough categories.
Most delivery operators can tell you the top five reasons customers call. Tracking queries, failed deliveries, address changes, complaints, returns. But “roughly knowing” isn’t enough when you’re trying to redesign a large operation. You need to understand the proportions, the peaks, the patterns, and the root cause behind each one.
Take tracking calls. They’re almost always the highest volume category. But why? Often it’s because the tracking information available online is delayed, vague, or just hard to read. Customers can’t tell if their parcel is late or simply not updated yet, so they call to ask a human. Fix the quality of the tracking data and how it’s presented, and a meaningful share of those calls goes away – without any agent involved at all.
The same question applies to failed deliveries. Is it a last-mile capacity problem? A notification problem? Are customers simply not home, or are they not being warned that a delivery is coming? The answer changes what you build.
Run a proper call reason analysis before you write a single requirement. Tag a sample of calls. Categorise them properly. Build a picture of what’s actually driving volume. It takes a few weeks. It changes everything that comes after.
Map what actually happens, not what’s supposed to happen
Every large organisation has a gap between its documented processes and what agents do day to day.
In a high-volume environment, agents develop workarounds. They keep a spreadsheet alongside the main system because the CRM doesn’t surface the information they need quickly enough. They take paper notes mid-call because updating the screen takes too long. They’ve memorised fixes for scenarios the system handles badly. Some of this is good practice. Most of it is a symptom – the official process doesn’t fit the actual work.
If you design a transformation around the documented process without understanding the real one, you’ll replicate the same problems in a newer system. That’s an expensive mistake.
Spend time on the floor and shadow agents during busy periods. Ask them where they lose time. What information do they spend time looking for? Which calls take most time to resolve and why? What would make the most difference to their day? This isn’t glamorous discovery work, but it’s where the real scope of your project comes from.
Don’t try to fix everything at once
The most common mistake in large transformation programmes is defining an enormous scope upfront and committing to deliver it all together.
The logic is understandable. Everything is connected. You can’t improve case management without redesigning the agent desktop. You can’t build self-service without integrating tracking data. You can’t improve first-contact resolution without a proper knowledge base. So the scope expands until it covers the whole operation.
Projects built this way rarely finish on time, and they rarely deliver what was promised. By go-live, the business has moved on, priorities have shifted, and the system no longer quite fits.
A better approach is to identify the changes with the highest impact and lowest delivery risk, and start there.
For most delivery operators, those early wins sit in three areas:
Proactive outbound notifications
Tell customers where their parcel is before they feel the need to call. A simple, timely SMS or email update – especially when something changes – removes a substantial share of inbound volume without any process redesign at all.
Better self-service
Clear, accurate tracking status. Simple digital forms for common requests like redelivery booking or address updates. The bar here isn’t high. Customers don’t need an impressive portal. They need information that’s correct and easy to act on.
A single view for agents
Give agents the customer history, parcel status, and case information they need on one screen. Not switching between four systems to answer a basic query. This alone reduces average handling time and makes agents less exhausted by the end of a shift.
None of these require a full, complex CRM implementation. Each one delivers measurable value – and together they create the breathing space to tackle the larger structural changes.
Phase the bigger programme properly
Once early wins are delivered and confidence is built, you’re in a better position to take on the structural work.
A sensible approach for a large delivery operator runs in three phases:
Phase one: reduce avoidable contact
Proactive notifications, improved tracking, self-service for common requests. The goal is to bring inbound volume down without reducing the quality of service for customers who genuinely need help. This phase is mostly about integration and data – connecting existing systems and making information accessible.
Phase two: improve the agent experience
A unified desktop that brings together tracking, customer history, case management, and guided workflows in one place. This is where CRM sits at the centre. Cases are logged consistently. Agents follow clear processes. First-contact resolution improves because the information is there when it’s needed.
Phase three: use the data
With cases logged properly and consistently, you can start seeing what’s actually happening. Which case types take longest to resolve? Where are escalations happening that shouldn’t be? What’s driving complaint volume this week? You shift from managing by intuition to managing by evidence.
Each phase builds on the last. Each delivers real value before the next one starts.
Stakeholder alignment matters more than most people plan for
Customer service transformation at a large delivery operator touches at least four different parts of the organisation, and they don’t always want the same thing.
Operations wants cost per contact down and less headcount pressure. Customer service leadership wants quality up and agents less burnt out. IT wants a clean architecture and nothing unsupported. The business wants it all delivered without disrupting live service.
These priorities are mostly compatible. But they’re not identical. If you don’t get clear agreement on what the programme is actually for and what success looks like, you’ll hit trade-offs mid-project with no agreed way to resolve them. Those trade-offs will be resolved by whoever shouts loudest. That’s not a good way to run a large programme.
Do the alignment work early. Not just a steering committee and a mandate document – real conversations about priorities, acceptable trade-offs, and who has the authority to make decisions when things get difficult.
Change management is where these projects succeed or fail
Technology is rarely the hardest part. People are.
Agents who have worked a certain way for years will resist new processes, even genuinely better ones. Supervisors who manage by instinct won’t automatically trust a dashboard. Middle managers will protect their team’s existing ways of working. Senior leaders will expect results faster than the programme can deliver them.
None of this is unusual. It happens in every large operational change programme. The question is whether you plan for it or let it catch you off guard.
Build change management in from day one. Involve agents in the design work – they’ll spot problems that no analyst will find. Run pilots with real teams before wide rollout. Communicate clearly and honestly, especially when things aren’t going to plan. Give people time to adapt before measuring success.
The operations that handle this well tend to have one thing in common: senior leadership that is visibly committed and genuinely involved. When agents and managers see that this isn’t just an IT project, the resistance diminishes.
What a well-run delivery operation’s customer service actually looks like
A well-run operation tends to look the same wherever you find it.
Most customers who want to know where their parcel is can find out without calling. When something goes wrong – a missed delivery, a delay, a damaged item – they’re told proactively. When they do call, the agent already knows who they are and what’s happened. They don’t ask for information the customer already gave. They resolve it in one call.
Case data is clean and consistent, so managers can see what’s happening and respond quickly. If a particular issue is generating a sudden spike in contacts, they know within hours rather than weeks.
And the system supports the work. Agents aren’t fighting slow load times or navigating multiple cluttered screens to answer a simple question.
Getting there takes time. It takes honest discovery work, a realistic phased plan, proper stakeholder alignment, and more change management investment than most programmes budget for at the start. But it’s achievable.
If you’re trying to work out where to start on a programme like this, the most useful first step is usually a clear, honest view of your current call drivers and agent experience – not a business case or a requirements document, just a factual picture of what’s happening today.
From there, the high-impact changes and a realistic roadmap tend to become obvious.
If you’d like to talk through how to approach the scoping and phasing for your operation, we work with large service organisations on exactly this kind of programme.
Talk to Our Team
