Delivery & Fulfillment
At ezCater, a catering marketplace, customers wanted to know where their food was, and restaurant partners (the restaurants that sell on ezCater) were about to pay a fee for every delivery they didn't track. I designed the tools that answered the first question and made the new rule fair.
You've watched the little car on DoorDash or Uber Eats inch toward your door. Now imagine you've ordered lunch for 50 and there's no map at all. Many restaurants delivering their own ezCater orders didn't share tracking, so customers called support to ask: Is it on time? Running late? Showing up before we're set up? Every call cost money.
Many restaurants delivering their own ezCater orders shared no tracking, so customers ordering lunch for 50 called support to ask where it was. Every call cost money.
ezCater's answer was a rule: starting in 2026, orders restaurants delivered themselves had to be fully tracked, meaning the customer could follow the driver live from pickup to drop-off, with a fee for each one that wasn't. Partner satisfaction was already falling, so we set an order of operations: insight and tools first, accountability second.
ezCater added a fee for orders that weren't fully tracked, starting in 2026. We set the order: insight and tools first, accountability second.
Ready: Mark Food Ready. Third-party drivers sometimes claimed food wasn't ready, which triggered wait fees ezCater paid. Staff could mark an order ready from their phone, with photos and a package count, creating a timestamp both sides could trust. Staff mark an order ready from their phone, with photos and a package count, so wait-fee disputes have a timestamp both sides trust.
The business wanted Mark Food Ready required on every order with an ezCater-sourced driver. My researcher and I pushed back with the math below. It showed we'd be asking too much of partners: the time it cost them outweighed what requiring it would gain, so it stayed optional.
Handoff: one sticker label, three audiences. Restaurants print a sticker for every package of food, and that small label has to work for three people at three moments. I mapped the journey first: the restaurant packing the order (is anything missing?), the driver at pickup and drop-off (which order is mine, and is it all here?), and the guest at the table (what is this, and can I eat it?). Two rounds of testing with 18 partners and 14 drivers refined the hierarchy and simplified printing to one flow that defaults to one label per item. One label has to work for the restaurant, the driver and the guest. Testing with 18 partners and 14 drivers refined it to one print flow.
On the way: designed for an anxious host. Someone with 50 people waiting needs to know their event will be okay, so the page answers their questions in order: a plain-language status (is it on time?), a prominent "Updated 30 seconds ago" bar (how current is this ETA?), every vehicle on big orders (is it all coming?) and a one-tap Call driver button (what if something's wrong?). Partners see the same view from their order details. The page answers a nervous host's questions in order: is it on time, how fresh is this ETA, is it all coming, and who do I call.
Improve: Operational Metrics. The performance page sent mixed signals, with alarming red buttons and poor hierarchy. I put the metrics that can pause a store first and partnered with our content designer to rewrite the content in plain language. A concept test with 13 partners confirmed the paused state read clearly. Metrics that can pause a store come first, in plain language. A concept test with 13 partners confirmed it read clearly.
Partners needed to see which orders weren't tracked, and why, before the fees kicked in.
{{ dCur.lead }} {{ dCur.body }} {{ dCur.short }}