Vendor Out
- Service Designer & Researcher
- 15 weeks · Jan to Apr 2021
- Solo course project
Vendor Out is a proposed hot food vending service for offices, hospitals and campuses. Customers order through an app, restaurants manage meals from a tablet, and the business pays a flat subscription instead of a commission on each order.
2
2
5
A failed delivery could cost the restaurant more than the sale.
I began with a convenience problem. People in busy places often had little time and few healthy options nearby. Restaurants faced a different pressure: delivery platforms brought new customers, but charged for every order at a time when many businesses had few alternatives.
“What shocked me was that if anything goes wrong the restaurants are the ones that take the blame and have to pay, while the company operating the app doesn’t have to do anything but provide the ‘service’ as the middle man.”
One restaurant owner described what happened in their experience when delivery failed: they refunded the customer while still paying the driver and platform fee. It was one account, not an industry-wide finding, but it changed what I chose to design.
So the question stopped being only how to sell food from a machine. It became how to give restaurants more predictable costs without making the meal harder to buy.
How might a hot food vending service give people a reliable meal while giving local restaurants a more predictable way to sell it?
Who I was designing for
I designed around two perspectives: a local restaurant owner looking for a more predictable alternative to delivery fees, and a student or shift worker with little time and few healthy options nearby. The service had to work for both.
A vending machine has two users, so I built for both.
Pick up
Enter your address and the app shows the nearest machine and what’s sitting in it right now. Nothing to order ahead, nothing to wait for.
Checkout gives you a box number and a code. That’s the entire transaction. No staff, no queue, and no handoff between an app and a driver that can go wrong.
Pre-order
If you want something specific, you order ahead and the restaurant cooks it into the machine for a pickup window you choose.
A time estimate and a loading state tell you when the meal has actually reached the machine, so you’re not walking over to an empty box.
This is the part delivery apps struggle with. The food is waiting somewhere you’re already going, at a time you picked.
The confirmation also tells you where the recycling slot is, because the container goes back into the machine.
The restaurant’s tablet
Restaurants get a tablet when they sign up. Orders land on it and they accept or cancel, the same control they’d have over a walk-in.
Two kinds of order arrive. Pre-orders from customers, and restock suggestions from an algorithm that learns what sells and when.
The menu
Restaurants add and edit their own items. Nobody has to call a support line to change a price.
Every item has a visibility toggle. Run out of an ingredient and you hide the dish, and it disappears from the customer app straight away.
That toggle exists because a kitchen runs out of something at 12:40 and has no time to phone anyone about it.
I planned to interview customers. I got two people from the food industry.
I wanted to speak with vending machine manufacturers. Nobody replied, so I recruited through my own network and spoke with a restaurant owner who used Uber Eats and someone working in food distribution.
Two interviews are not enough to generalize from. I treated them as directional, then compared what I heard with five services already operating vending or prepared-food models.
How I ran it
Two participants, two weeks apart
What actually happened:
Reached out to vending machine manufacturers and got no response
Recruited through my own network instead
Interviewed a local restaurant owner on 24 March 2021
Interviewed someone from food distribution on 30 March 2021
What the two interviews told me
The liability problem, and a use case I hadn’t considered
The restaurant owner explained where the money actually goes when a delivery fails. That became the centre of the project.
What came out of it:
When an order goes wrong the restaurant refunds the customer, pays the driver, and still pays the platform
Anyone delivering to a machine should be trained, not a stranger absorbing someone else’s liability
Hospitals and late shifts already rely on vending machines and get badly served by them
Sanitation and vandalism were their first two questions, before anything else
Five machines already doing this
Operators who had solved the parts I was worried about
Most of my secondary research was watching operators explain their own systems. Each had solved something I needed.
What the comparison contributed:
A curry machine in Japan holding food at 140°F, with the sauce packaged separately
Layered packaging that keeps wet and dry ingredients apart until collection
Existing hot-food operators using timed stock and expiry controls
UV treatment used by JC Meal Box during COVID
Shared cabinets placed where people already spend long hours
A sales scenario, not an outcome
What twenty meals a day would mean
A 2021 article reported that an independent vending-machine operator in Japan could earn up to ¥500,000 a month. I treated it as a benchmark, not evidence for Vendor Out.
For a local scenario, I modeled twenty meals a day at an average of $12: about $7,440 in monthly food sales before restaurant share, delivery, machine costs, spoilage, rent, or taxes. The exercise made placement and operating costs the next things to test.
Two interviews and five comparable services. That was the evidence base behind the concept, not proof that the business would work.
Every step, and who is responsible for it.
I mapped the customer and restaurant journeys separately, then joined them in one service blueprint before designing the screens. It connects what each person does with the work behind the machine: order handoff, courier runs, restocking, expiry checks, and maintenance.
Mapping both sides exposed the questions the interface alone could not answer: who refills the machine, who notices aging food, and who is called when it breaks.
Customer + restaurant service blueprint · tap to view full size
I asked four people what could go wrong. They found things I hadn’t.
I ran a workshop on a Miro board with four people. I asked what could go wrong, what would make the service easier to use, how restaurants should pay for it, and what else was on their mind.
The middle two produced useful suggestions. The first produced the list I ended up designing against.
What could go wrong
I’d been designing the happy path
The group went straight for the ways it breaks, and most of it hadn’t occurred to me.
What they raised:
Somebody orders a meal and never collects it, holding a box all day
A restaurant puts a meal in the wrong box
Someone breaks into the machine
The power goes out and everything inside spoils
A competitor removes another restaurant’s food to sell more of their own
What changed because of it
Five problems became five rules
Each of these went into the design directly, and none of them were in it beforehand.
What I added:
Timed collection windows so an abandoned order cannot hold a box indefinitely
Cameras on every machine, and placement chosen near buildings that already have their own
An impact sensor that locks the machine and calls maintenance
The same lock on power loss, so nothing can be sold out of a cabinet that has been warm
Expiry tracking that pulls food before it becomes unsellable and routes it to compost
Cooked to order, or to restock
Layered, so it survives the wait
Trained and employed, not a gig
Hot/cold storage; UV concept to validate
A code opens the box. Mix and eat.
↺ THE CONTAINER GOES BACK INTO THE MACHINE IT CAME FROM
Locked before it expires, collected, composted
The cabinet locks itself and calls maintenance
The app was the easy part. Every meal has a life around it.
The container concept was layered: broth on the base, noodles and toppings above, mixed after collection. I adapted that idea from prepared-food vending examples already in use.
I also explored hot and cold compartments and UV treatment because JC Meal Box used UV during COVID. I did not validate either choice with a manufacturer or food-safety expert.
The service used a trained courier instead of an open gig model. That came from interview feedback about restaurants absorbing delivery mistakes. Containers returned through a slot in the machine; unsold food would be locked before expiry, collected, and composted. These were service requirements to test, not finalized operations.
What happens to the food nobody buys
Two things leave without being sold, and both needed a route
A machine full of hot food has two failure states that have nothing to do with the app.
Where things go:
Food approaching expiry gets locked so it can’t be sold, then collected and composted
Returned containers are collected for cleaning and reuse
A damaged or unpowered cabinet locks itself and calls maintenance
Containers return through the recycling slot in the machine they came from
People don’t believe food from a vending machine is any good.
Demand was the first risk. My secondary research suggested that people could be hesitant to buy a meal from a vending machine, but I never tested whether they would try it.
Placement decides the economics, and I never asked a building owner whether they would give up lobby, hospital, or campus floor space.
I also never spoke with a manufacturer or food-safety expert. The cabinet, UV treatment, storage temperatures, and maintenance flow were informed by existing operators, not confirmed as buildable or compliant.
What I’d have measured
The numbers that would tell me whether the model held
Each one tests a specific bet, and a bad result would tell me which decision was wrong.
What I’d watch:
Meals sold per machine per day, against the twenty-meal scenario
Spoilage rate by location and time of day
Pre-order share against grab-and-go, which decides how much a kitchen can plan
Container return rate through the recycling slot
Restaurant retention after three months, because the subscription only works if they stay
Three things I’d pick up first.
- Talk to a manufacturer. I should have done this in week one.
- Test whether a building owner would actually give up floor space for one of these.
- Finish the WCAG work across both apps.
I set out to design a vending machine and ended up redesigning who carries the risk.
The screens were only one part of it. The more useful idea was a flat subscription as an alternative to commission-based delivery. That came from one restaurant owner’s account, and it remained a hypothesis.
With more time, I would define who absorbs refunds and failed orders, then test the model with restaurant owners, building operators, a manufacturer, and a food-safety expert before refining the interface.
I nearly designed the wrong thing
The machine was the obvious project
For weeks I was solving heat retention and theft. Those are real problems, but they’re the ones you can see. The one that mattered was invisible and financial, and it only surfaced because somebody who runs a restaurant told me where the money goes.
I left the manufacturer call too late
I designed a physical product without speaking to anyone who builds one
I reached out and got no reply, then moved on instead of pushing. Everything about the cabinet is inferred from operators talking about their own machines on camera. It might all be buildable. I can’t say that it is.
Two interviews shaped everything
A small research base carrying a lot of weight
One of those conversations produced the insight the whole project turns on. That’s luck as much as method, and a second restaurant owner might have sent me somewhere else entirely.
Thank you.