Restaurant Operations Pilot

A global beverage brand wanted its drinks to taste their best in every location of one of the world’s largest restaurant chains. That depends on routine work, like cleaning beverage equipment and restocking, that’s easy to skip on a busy shift, and managers can’t watch every task.

I framed it as a behavior-change problem with a clear hypothesis: crews will complete tasks reliably without constant oversight if they have the right time, tools, triggers, and motivation. The pilot set out to prove it against three goals: more tasks done, done at the right time, by the right person.

The key call was where to put competition.

Competition between crewmates would have driven task completion fast, but it could have damaged the culture inside each restaurant, where people depend on each other every shift. So competition happened only between restaurants, through team leaderboards and weekly winners, and everything inside a restaurant was built on collaboration: boosts to nudge a teammate, shout-outs to celebrate one.

Using Applied Game Theory™, I designed the system around crew members first and managers second, and kept the four-week pilot focused on crew behavior by moving supervisor tasks to a future phase.

• Motivation: heavy on accomplishment and social influence, to build habits and make it a team effort, with light touches of urgency and surprise.
• Triggers: notifications timed to each task’s window, and reminders from teammates.
• Rewards: a deliberate blend of gift cards, public recognition, shout-outs from teammates, and small moments of delight.
• A points economy: I built it so tasks that happen once a day and tasks that happen every hour both felt worth doing.

I designed the wireframes for a mobile web experience, and Dragon Army’s design team created the visual design.

• Tasks with time windows: each task is available for a limited time, with points for finishing it before the window closes.
• Boosts and shout-outs: crew members can nudge a teammate to finish a task, or praise them for a job well done.
• Team leaderboards: restaurants competed for the most points, with a winner each week before the leaderboard reset.
• Manager reports: daily and per-employee reports showed where support was needed.

Testing the app was a hard problem with no playbook. Its logic played out over hours, shifts, and weeks, so a standard test plan couldn’t cover it. I stepped in and designed a QA day that ran the whole challenge in compressed form, with every action the team took scripted to the minute, so we could confirm that each task, point, and time window behaved exactly as designed.

Launch was hands-on. Two teammates and I split the eight restaurants and trained each crew in person, with a manual I created with our project manager, plus pins and stickers to build excitement. During the pilot, our team was the crews’ support line, working from a support plan and schedule I built and a response matrix written by our account manager and copywriter.

The pilot proved the concept in some places and taught us a lot in others. Across eight restaurants, crews completed more than 4,100 tasks. The mechanics that relied on teamwork worked especially well: 88% of boosted tasks were completed after a teammate’s nudge.

The lead restaurant showed what the system could do: 70% of its tasks were completed in the right time window, 81% by the person assigned, and every surveyed manager there said it made their job easier.

Engagement wasn’t even, though. Some restaurants dropped off by the final week, and the data showed why:

• Roles didn’t match reality: a quarter of completed tasks were claimed by someone outside the assigned role, because each restaurant divides the work differently.
• Managers avoided penalties: only one task was ever rejected, because rejecting work cost the team points.
• Access and awareness: sign-in friction and low awareness of the prizes held some crews back.

I turned these into recommendations, from quick wins like account setup, Spanish language support, and a penalty-free review process, to longer-term moves like integrating with scheduling systems and letting each restaurant customize its challenge.

This was a fast and furious project: four months from start to finish, with a small team. There wasn’t a specialist for every problem, so I stepped outside my role more than once, from testing to support to training.

That’s what I carried forward. On a small team, leadership often means taking on the complicated problem no one has solved yet, and figuring it out fast enough to keep everyone else moving.