Delivery Operations Platform
The client wanted faster delivery. The real problem was everything that happened before the courier reached the door.
One restaurant became fifteen
What began as an ordering website grew into connected tools for customers, restaurants, coordinators and couriers.
The original request sounded straightforward: build a website where customers could order food from the client’s restaurant.
Once we looked behind the order button, the project became much larger.
Once we looked behind the order button, the project became much larger.
- Where would phone orders go?
- Who would assign a courier?
- How would the restaurant communicate that food was ready?
- What happened when a courier was late?
- How would the customer know where their dinner was?
And that was still only one restaurant.
During the pandemic, the client decided to extend the service to other businesses. The system now had to receive orders from different restaurants, coordinate a shared courier operation and keep every participant working with the same order state.
We spent a month mapping the existing process with the owner: where orders came from, how coordinators distributed them, what couriers complained about and where customers experienced delays.
After launch, feedback collected from restaurant employees, coordinators and couriers guided more focused improvements.
During the pandemic, the client decided to extend the service to other businesses. The system now had to receive orders from different restaurants, coordinate a shared courier operation and keep every participant working with the same order state.
We spent a month mapping the existing process with the owner: where orders came from, how coordinators distributed them, what couriers complained about and where customers experienced delays.
After launch, feedback collected from restaurant employees, coordinators and couriers guided more focused improvements.
Ninety minutes had no single cause
Customers were promised delivery in 30 minutes. Some waited an hour and a half.
At first, it was tempting to treat this as a courier problem. The solution is an app for couriers with automatic order distribution and navigation.
At first, it was tempting to treat this as a courier problem. The solution is an app for couriers with automatic order distribution and navigation.
But a late delivery could begin long before a courier received it.
A restaurant might accept the order late. Preparation could take longer than expected. One courier could be carrying several orders while another waited without work. A coordinator could miss a delay while manually distributing orders across multiple restaurants.
A restaurant might accept the order late. Preparation could take longer than expected. One courier could be carrying several orders while another waited without work. A coordinator could miss a delay while manually distributing orders across multiple restaurants.
By the time a customer complained, the problem had often been moving through the system for an hour.
It was the same order everywhere:
It was the same order everywhere:
The interfaces could be different.
The order logic could not.
The order logic could not.
The nearest courier was not always the right courier
The system did not simply search for the closest courier. It looked for the courier who could complete the order most efficiently within the current operation.
The nearest courier looked like the obvious choice.
Until that courier already had two orders, the food was still being prepared and their shift was about to end.
The nearest courier looked like the obvious choice.
Until that courier already had two orders, the food was still being prepared and their shift was about to end.
Choosing well required more context:
The system evaluated these conditions and automatically assigned the most suitable courier.
This removed a routine decision from the coordinator’s workload and distributed orders more evenly across the team.
This removed a routine decision from the coordinator’s workload and distributed orders more evenly across the team.
The goal was not to help coordinators assign every order faster. It was to stop making them assign every order.
Automation handled the flow. People handled exceptions.
When everything looks urgent, people eventually stop seeing urgency. Routine orders stayed in context; exceptions received a layer of their own.
I turned those states into three visible starting points:
Only after selecting the relevant path did customers move into production settings.
Automatic did not mean irreversible
The system made the default decision. The interface kept that decision understandable and reversible.
- The timeline reveals where the delay began.
- All three locations remain visible together.
- Nearby couriers can be compared.
- Automatic assignment can be overridden without leaving the order queue.
Selecting an order expanded it inside the table.
The coordinator could see the order, comments, payment, complete stage timeline and a map connecting the restaurant, courier and customer.
Nearby couriers were visible on the same map. If the automatic assignment no longer made sense, the coordinator could cancel it and choose someone else.
The coordinator could see the order, comments, payment, complete stage timeline and a map connecting the restaurant, courier and customer.
Nearby couriers were visible on the same map. If the automatic assignment no longer made sense, the coordinator could cancel it and choose someone else.
Four roles did not need four complex products
The coordinator needed the complete operational picture. Everyone else needed a much narrower part of it.
The restaurant needed a production queue
Orders were organised by preparation state: created, viewed, preparing, ready and archived.
The restaurant could see deadlines, update order status, manage menu availability and temporarily stop accepting orders when the kitchen was overloaded.
- Order timing is visible beside its preparation state.
- Delays are highlighted before the courier arrives.
- Unavailable dishes can be disabled immediately.
- The restaurant can pause new orders when overloaded.
The courier needed one next action
The Android application changed with the delivery stage.
Start the shift. Accept an order. Reach the restaurant. Check the items. Pick up the order. Navigate to the customer. Complete delivery. Return the cash.
Addresses, phone numbers, comments and payment details appeared when they became useful.
Location tracking worked only during the courier’s shift.
Start the shift. Accept an order. Reach the restaurant. Check the items. Pick up the order. Navigate to the customer. Complete delivery. Return the cash.
Addresses, phone numbers, comments and payment details appeared when they became useful.
Location tracking worked only during the courier’s shift.
- A countdown keeps the current deadline visible.
- One primary action changes with the order state.
- Navigation and calling appear in context.
- The courier checks every item before leaving.
- Cash settlement closes the shift.
The courier never had to understand the whole delivery system. The application translated it into the next necessary action.
The customer needed reassurance
Customers usually ordered through the restaurant’s own website. After placing the order, they could follow its status and see the courier on a map. Tracking removed the uncertainty of waiting without knowing whether the food had left the restaurant at all.
The same operational data that helped coordinators manage delivery helped customers feel in control of the wait.
We built an aggregator. The value was underneath it.
We started by building a place where customers could find restaurants. The business found more value in the machinery underneath.
The project initially expanded towards a public restaurant marketplace.
Customers could discover restaurants, browse menus, order food and track delivery in one place.
Technically, the model worked.
Commercially, it required something the business did not have: enough budget to attract restaurants and consumers at the same time.
Competing for the consumer market meant sustained advertising. A more viable direction was to work directly with restaurants that already had customers and ordering channels.
Their websites remained the main customer entry points. The platform underneath connected those orders to restaurants, coordinators and couriers.
Customers could discover restaurants, browse menus, order food and track delivery in one place.
Technically, the model worked.
Commercially, it required something the business did not have: enough budget to attract restaurants and consumers at the same time.
Competing for the consumer market meant sustained advertising. A more viable direction was to work directly with restaurants that already had customers and ordering channels.
Their websites remained the main customer entry points. The platform underneath connected those orders to restaurants, coordinators and couriers.
The public aggregator became less central.
The delivery infrastructure continued to grow.
The delivery infrastructure continued to grow.
60–90 minutes became 30–40
The first version launched for one restaurant in 2020.
In 2021, the system expanded across the client’s other restaurants and began connecting independent businesses.
In 2021, the system expanded across the client’s other restaurants and began connecting independent businesses.
After six months of use, the client reported that the typical delivery range had decreased:
Before: 60–90 minutes
After: 30–40 minutes
Before: 60–90 minutes
After: 30–40 minutes
Today, more than fifteen restaurants use the platform. No single interface created that result.
Delivery became faster because the operation became connected:
Faster delivery was not the result of a faster-looking interface. It came from removing delays between people, decisions and systems.
The difficult part was deciding when not to automate
The platform is still actively used and developed.
Its environment keeps changing. Navigation can become unreliable. Courier transport and delivery zones change. Restaurant operations introduce requirements nobody could have predicted at the beginning.
The system has had to change with them.
I used to think the difficult part would be designing several interfaces at once.
It was not.
The difficult part was deciding which actions the system could take alone, which information each person needed — and exactly when a human should step back in.
Its environment keeps changing. Navigation can become unreliable. Courier transport and delivery zones change. Restaurant operations introduce requirements nobody could have predicted at the beginning.
The system has had to change with them.
I used to think the difficult part would be designing several interfaces at once.
It was not.
The difficult part was deciding which actions the system could take alone, which information each person needed — and exactly when a human should step back in.
Automation should remove routine decisions. It should not remove people’s ability to understand or correct them.
@ann_fatalieva