Miss Delivery

Delivery should fit a life—not interrupt it

You choose a delivery window. Then a meeting runs late, or your plans change. With groceries, a missed handover is more than an inconvenience: the food still needs appropriate storage, while the logistics operator faces another handling and delivery cycle.

Miss Delivery proposes a different response: help people plan for a delivery, but also give them an alternative when being at home becomes impossible. A nearby helper could receive and temporarily store the order, with the option of bringing it to the customer later.

The project was developed in 2019 for a Leadership & Innovation course brief concerning STEF, a temperature-controlled logistics operator exploring B2C home delivery. It connects an app experience to a neighbourhood service network and the operational changes needed behind it.

From logistics efficiency to customer flexibility

The team’s preliminary analysis combined market trends, customer needs, competitor strategies and a SWOT assessment of the proposed B2C transition. The important tension was between an established logistics system and the uncertainty of individual customers’ routines.

Competitor approaches were grouped into prevention, cure and supporting information. Time windows and tracking help people prepare, but do not resolve what happens after their availability changes. That gap became the opportunity for the proposal.

Prevention, with a way back when plans change

Original strategy diagram linking a specific time window to community, notifications, tracking and mutual ratings — The original direction: prevention and cure as parts of one service.

Prevent the missed handover

Let customers choose a delivery window, access tracking information, and receive confirmation and reminders through email, SMS and the app.

Offer a nearby alternative

If the customer cannot be home, connect them to an available helper who can receive and store the groceries. Customers choose storage alone or storage with onward delivery.

Keep the experience connected

The alternative should stay linked to the original order: its status, destination and contact details must remain understandable to the customer, helper and operator.

The concept does not ask everyone to join a community before they need it. The original scenario starts with an ordinary order and introduces the alternative at the moment a reminder makes the delivery relevant again.

Original storyboard showing a customer choosing a delivery time at a computer — 1 · Plan ahead: choose a window when placing the order.

Original storyboard showing a delivery reminder asking whether the customer can be home and offering a helper alternative — 2 · Reconsider: a reminder creates an opportunity to act before a missed delivery.

Three routines, one connected journey

The team constructed three personas to explore both sides of the service. They are design scenarios, not participants from a reported field study. Their differences matter more than a single generic “busy customer.”

Different circumstances lead to different service choices
Perspective	Giovanna · customer	Matteo · customer	Antonio · helper
Routine	A project manager balancing work and personal commitments.	A student whose plans can change spontaneously.	A part-time worker with spare time and storage space.
Tension	An urgent deadline prevents her from being home.	An unexpected invitation clashes with the delivery.	He wants useful, paid activity without a large time commitment.
Service choice	Ask a helper to store the order and deliver it later.	Arrange storage, then collect the order himself.	Declare availability and capacity, then accept suitable requests.
Design implication	Make status and later handover clear.	Keep access quick, even for a late arrival to the app.	Make the work and storage commitment explicit before acceptance.

Original three-lane journey map following Giovanna and Matteo's requests alongside Antonio's receiving, storage and handover actions — The original journey connects two customer paths through one helper. Each request creates commitments on another person's timeline.

The map follows the service beyond finding a match: an order must be received, its arrival communicated, and the final handover completed. A successful match is only the beginning of the service.

A small entry point into a larger community

The interface proposal moves from immediate utility to a more involved service relationship. Tracking is available before registration; an account becomes relevant when a customer requests help or offers storage.

1 · Track without committing

Original phone mockups showing tracking-number or QR entry and a parcel-status screen before login — A useful first interaction before asking people to join.

Enter a tracking number or scan a QR code to see the order’s progress. The app first answers an immediate question: where is my delivery?

2 · Find appropriate help

Original customer order screen and helper list with distance, ratings and storage or delivery options — The order becomes the starting point for choosing an alternative.

Compare nearby helpers by distance and rating, then choose storage alone or storage plus delivery. Suitability also depends on availability and the order’s storage requirements.

3 · Define what you can offer

Original helper setup mockups showing time windows, optional delivery and chilled and frozen parcel capacities — Availability includes time, service choice and physical capacity.

Helpers specify receiving and collection windows, whether they can deliver, and the chilled or frozen storage they can offer in standard parcel sizes.

4 · Accept a specific commitment

Original notification and request mockups showing the customer, time window, parcel quantities and accept or deny controls — A request explains the work before the helper agrees.

The helper reviews the request and accepts or declines. The final report proposes a fifteen-minute response limit so that customers are not left waiting indefinitely.

These are original concept mockups, not captures of a functioning service. Prices and timings visible in them are illustrative values from the proposal’s development, not a live offer.

The service behind the screens

Changing an address is easy to draw and difficult to operate. The proposal therefore connects the visible interactions to three backstage requirements.

Match capacity, not just proximity. Standardised parcel sizes would allow an order’s chilled and frozen storage needs to be compared with the capacity declared by a helper. This would require coordination with the grocery partners’ packaging process.

Update one shared order. Once a helper accepts, the destination and delivery status would need to update across the app and the logistics operator’s systems. Customer and helper would retain a direct contact route.

Paired original customer and helper mockups after acceptance, with the revised destination, tracking and call controls — One arrangement, two perspectives: both sides need to know where the parcel is going and how to contact each other.

Reconsider the route. The team proposed “double routing” within each delivery area: first serve customers retaining their original address, then use a second part of the hour for redirected helper deliveries. Keeping helpers within the same area was intended to contain the disruption.

This is an operational hypothesis, not a demonstrated routing improvement. Its feasibility depends on request timing, local helper density, route capacity and the reliability of the information exchanged.

Trust belongs in the service, not just the profile

The final report refines the early rating idea into feedback about communication, punctuality and, for helpers, parcel condition. Both parties would see each other’s feedback only after both had submitted it, with the aim of reducing retaliatory ratings.

Final report's two rating mockups showing communication and punctuality for both parties and parcel condition for the helper — A later refinement: evaluate the service interaction rather than rely only on an undifferentiated star score.

Ratings alone cannot establish food safety or resolve a failed handover. The original proposal identifies opportunistic behaviour, limited data and organisational inertia as risks. Before a pilot, the service would also need explicit arrangements for storage verification, accountability, disputes and an unavailable helper. These remain open requirements, not solved features.

Making the business logic visible

The commercial proposition connects three kinds of value: customers gain flexibility; helpers earn for receiving and storing orders; the operator could avoid some repeat-delivery costs. The business model depends on making all three work together.

Original business model canvas covering partners, activities, resources, value proposition, relationships, channels, customer segments, costs and revenue — The original business model canvas. Named companies are part of the proposal's partner context, not evidence of new partnerships secured by the team.

Build and sustain the network

The 2019 model estimates €100,350 in initial investment across app development, systems integration, training and launch marketing. Ongoing costs cover maintenance and community growth.

Recruiting users is not enough: helper availability must grow in the same places and at useful times.

Separate revenue from savings

The proposal combines partner advertising and a proposed 10% transaction commission from year three with potential savings in transport, handling, fuel and refrigeration.

Those savings depend on actually preventing repeat attempts—not merely recording more app activity.

The original five-year financial model is an exploratory 2019 estimate, not realised revenue or verified return on investment. A pilot would need to test demand, willingness to pay, helper participation and operational costs before its projections could support an investment decision.

A shared proposal, brought into focus

I worked as team leader and design synthesiser, helping connect different perspectives and make the team’s proposal visible. The work brought together architecture, interior design, civil engineering and management engineering; the service concept and business case were developed collaboratively.

The most useful shift in this project was from treating missed delivery as a scheduling failure to treating it as a service that needs to accommodate changing plans. That reframing also made the limits clearer: a convincing interface is only one part of a viable service. The neighbourhood relationships, cold-chain responsibilities and logistics system have to support the same promise.

Project context and credits

2019 · Academic business and service design proposal. Leadership & Innovation, Politecnico di Milano. Professor Roberto Verganti; tutor Federico Zasa.

Team #14 — The Odd Fellows: Darashik Abbas, Leo Acciarri, Giulia Bazzani, Lorenzo Berardocco, Andrea Califano and Peng Lu.

Adapted from the team’s review presentation and final report. The page retains original illustrations, journeys, interface mockups and business-model artwork, with a rewritten web narrative. It does not claim that STEF implemented the service or that the concept’s commercial or user outcomes were validated.