Many new businesses now have delivery written into the product. A subscription arrives on a set morning. A marketplace promises same-day handover. A clinic or pharmacy launches a home-delivery service. A platform connects customers with a physical item that has to cross London.
The natural instinct is to start with the technology: a booking flow, a driver app, a map, automatic notifications and a dashboard for the team. Those tools are useful. But they describe how an operation will be managed, and they assume the operation already works.
When it does not, the software simply shows the problem more clearly. The customer can now watch a delivery that should never have been promised for that time.
This article looks at what technology does well, what it cannot fix and which operational decisions founders should make before they build.
Part 2 of 4 in our series on building a delivery operation: test the delivery model, design the operation (this article), turn it into a repeatable process and automate the process.
Key Takeaways
- Technology automates an operation. It does not design one.
- Most delivery problems start with an unrealistic promise, a missing instruction or an exception nobody owns.
- Visibility is not accountability: someone still has to own the outcome.
- Decide the promise, the windows, the handover evidence and the exception owner before writing the specification.
- A delivery partner can run the physical operation while the platform is still learning.
What technology does well in a delivery operation
Good software removes repetitive work and makes information easier to share. In a delivery operation it can:
- take bookings in a consistent format;
- hold route information, addresses and instructions;
- send notifications to customers and recipients;
- show where a job has reached;
- report on volumes, timings and exceptions.
All of this is valuable. None of it decides whether the operation behind it is sound.
What software cannot fix
Technology works with the information and decisions it is given. It cannot compensate for:
- an unrealistic collection window, where goods are rarely ready when the courier arrives;
- the wrong vehicle, where the load, the access or the handling needs something different;
- poor courier briefing, where the courier knows the address but not the requirement;
- unclear recipient instructions, such as a general reception desk for an item that needs a named person;
- weak escalation, where nobody is clearly responsible when a job goes wrong;
- insufficient capacity, where the plan depends on every courier being available every day;
- a poor handover, where the item arrives but the experience falls short of what the brand has promised;
- a process that does not work, however well it is recorded.
Each of these appears in the software as a late, failed or disputed delivery. The cause sits upstream, in decisions made before any code was written. For brands where the handover is part of the product, we describe what that standard involves in what a premium courier service actually means.
A dot on a map is not accountability
Tracking has become the symbol of a modern delivery service, and there is value in knowing where a vehicle is.
But a customer watching a vehicle move is not the same as a coordinator understanding what is happening. The map shows that the courier is ten minutes from the door. It does not know that the building’s loading bay closes in five, that the recipient has left for a meeting or that the next drop on the route is more urgent than this one.
Someone has to notice, decide and tell the client before the client needs to ask. That is accountability, and it is a human responsibility.
Technology supports accountability. It does not replace it. The strongest delivery operations use systems to give a coordinator better information, then rely on that person to act on it. We explain how this works day to day in our article on proactive courier communication.
Inside Selena
Our model is led by people and supported by technology. Clients have one accountable point of contact who knows the job, the courier is briefed on the requirement rather than only the address, and the client hears about a problem while there is still time to act on it.
Our systems help the team see what needs attention. The decisions, and the conversation with the client, stay with people.
Design the operation before the platform
Before writing a specification, a founder should be able to answer five questions in plain language.
What exactly are we promising the customer?
A delivery day, a two-hour window, same-day delivery within a zone? The promise shapes everything else, and it should be one the operation can keep on its worst normal day, not its best.
What are the real collection and delivery windows?
When is the item ready, and when can the recipient receive it? Build the windows from what happens, not from what would be convenient.
What closes a delivery?
A name, a signature, a photograph, a handover to a specific person? Decide what evidence your customers and your own team will need when a query comes in.
Who owns an exception?
When a recipient is absent, an address is wrong or an item is not ready, who decides what happens next, and how quickly is the customer told?
How does capacity flex?
What happens on the busiest day of the month, during holidays or when a courier is unavailable? A model that only works at full availability is not yet a model.
Once these answers are clear, the specification becomes much simpler, because it describes an operation that already exists.
Where a delivery partner fits while the platform is young
In the early stage of a business, volumes are uncertain, the geography is still forming and customer expectations are still being learned. Building an in-house delivery team for that stage is expensive. Relying on anonymous on-demand capacity leaves the founder managing every exception personally.
A third option is to run the physical operation with a delivery partner while the platform learns. The partner handles collection, routing, courier briefing, exceptions and handover. The founder gets real data about timings, volumes and customer needs, and can decide later what to build, what to automate and what to keep with a partner.
Through our Embedded Delivery Solutions, Selena supports London businesses in this way: learning the operation, testing it in a small pilot and turning it into a planned route that is reviewed as the business grows. Urgent and one-off work can still be handled through our same-day courier service. If your first question is how to test the model, start with our guide to running a delivery pilot.
Elena's Perspective
I have seen very good technology struggle with a problem that a five-minute conversation would have prevented. A courier following a map to the front door of a building where deliveries go to the side entrance does not have a software problem. They have a briefing problem.
Technology is useful, but relationships solve problems. Build the operation first, then choose the technology that makes it easier to run.
Build the service, then the software
A delivery platform is only as good as the operation it represents. Founders who design the promise, the windows, the handover and the exception process first tend to build simpler software, launch with fewer surprises and keep their customers’ trust when something changes.
If you are building a business with delivery at its centre, talk to us about the operation before the platform. We will help you design and test the delivery model it needs.
