Improving restaurant order tracking

Just Eat's partner base depended on small kitchens tolerating chaos. Orderpad could accept orders, but it often failed to show where each ticket sat in the flow, when food needed to be ready for handoff, or what tapping 'On Its Way' committed to downstream. Teams worked around those gaps; the cost showed up as late deliveries, support calls, and poor reviews.

My JTBD research identified three frustrations: unclear order status (prep versus ready versus collected), no direct access to Partner Centre tasks (hours, radius, pricing) during service, and weak driver visibility compared to rivals. I led discovery that included in-restaurant observations during live shifts (Friday and Saturday nights, lunch rushes), partner surveys via Qualaroo in-product pop-ups, and a Nielsen heuristic framework NN/G heuristics applied across five brands.

Constraints: audit only, no implementation commitment. Recommendations had to separate quick wins from structural changes requiring policy or contract shifts. Out of scope for this engagement: Orderpad pixel changes, A/B tests, or production UI. The deliverable was research, prioritisation, and a design spec for backlog funding.

Success metric upfront: one scoring sheet all stakeholders could point to, with partner survey percentages finance could fund against.

I structured the audit around six Nielsen-based review areas: system status visibility, fit for kitchen work, control and speed, recognition over recall, layout clarity, and error recovery. The same rubric ran across Just Eat, Deliveroo, Uber Eats, Grubhub, and SkipTheDishes so results were directly comparable.

Three audit scopes were considered. Product walkthrough only: rejected, because it missed real operating conditions. Partner interviews only: rejected, qualitative feedback was abundant but unfunded. Combined product analysis, surveys with percentages, and live observation: what I shipped.

I paired product walkthroughs at realistic order volumes with competitor benchmarking on the same six heuristics. Deliveroo and Uber Eats showed live driver maps and explicit prep→ready→collected timelines; Grubhub and SkipTheDishes surfaced Partner Centre shortcuts from the order screen. Those were the patterns Orderpad lacked on status visibility and in-flow partner tasks.

Qualaroo in-product surveys captured importance ratings for specific features. In-restaurant observation during live service covered noise, rush periods, and multilingual teams. The output was one scoring sheet showing Just Eat ranked last across the five brands, theme briefs with screenshots on status visibility, Partner Centre access, and driver tracking, and a prioritised readout separating quick fixes (clearer button labels) from business-level decisions (opening Partner Centre API to Orderpad required cross-functional alignment).

I specified a recommended status rail — prep, ready, collected, driver en route — as the design target when Orderpad could not show where a ticket sat during live service. That spec became the bridge from audit to backlog: finance could size 82% Partner Centre demand and 56% driver-visibility demand against a concrete UI pattern, not a theme label alone.

Field validation was the point. Kitchen visits during real service caught what desk walkthroughs missed: which status gaps cost seconds when the rider was already at the door.

Across Deliveroo, Grubhub, Uber Eats, SkipTheDishes, and Just Eat, the combined heuristic roll-up put Orderpad last. That was uncomfortable in the room, but it replaced opinion with one curve everyone could point to: the gap ran across status, fit to kitchen reality, control, and recovery, not a single bad icon.

In-product surveys showed 82% of partners rated reaching Partner Centre from Orderpad as important. 56% wanted a clearer view of drivers on busy nights, while optional driver tooling sat at almost no adoption next to rivals who ship live tracking by default. Those numbers turned 'they keep asking' into backlog pressure with a size on it.

Nothing in an audit ships pixels by itself. What shipped was clarity: ranked themes, a cut between work that could ride normal release cadence and work that needed brand or policy concessions, and constraints spelled out so roadmap bets matched what ops could open and what contracts allowed.

Impact for this engagement is measured in research outcomes, not conversion: a funded backlog sequenced by partner survey weight, a single five-brand curve stakeholders could point to in prioritisation, and a status-rail design spec ready for implementation when policy allowed Partner Centre access from Orderpad.

Because the recommended status rail named prep→ready→collected→driver en route explicitly, stakeholders could size backlog against expected kitchen behaviour (fewer 'where is this order?' moments during rush) rather than a vague 'status' theme. That clarity is why 82% Partner Centre demand and 56% driver-visibility demand converted to sequenced roadmap bets. Because I scoped the engagement to research and design spec only (no Orderpad pixels or A/B), the deliverable stayed honest: funded backlog and a concrete UI target, not implied conversion lift.