Problem
Dojo's RMS had no way for venues to protect themselves against no-shows, in an industry losing £16bn a year to them.
Solution
Dojo RMS's first payment feature — deposits and card-on-file policies that protect venues without feeling punitive to guests.
Impact & Results
*captured within the initial rollout period.
Stack
Figma · FigJam · usertesting.com · Looker · Miro · Notion
A meaningful gap
Dojo's Restaurant Management System (RMS) helps independent restaurants, pubs, and cafés managing bookings, walk-ins, and queues. When I joined, it had one meaningful gap: no way for venues to protect themselves against no-shows.
What is a No-Show?
A restaurant no-show occurs when a guest makes a booking but fails to arrive, without cancelling or notifying the restaurant. A table blocked for a party of six that never shows up might not be filled at 8pm on a Saturday night and that revenue is gone.
For Dojo's venues, this wasn't a theoretical concern. It was a weekly frustration. And it was costing the industry at scale: the UK hospitality sector loses an estimated £16 billion a year to no-shows and late cancellations. For Dojo, addressing this represented a potential 30% TAM expansion and approximately £3.5MM/year in additional revenue.
No-shows sit at the intersection of guest trust, venue operations, and payment technology.
I ran a structured research process which included 25 participants across discovery, concept validation, and usability testing.
How Venues manage no-shows
Venues were managing no-shows through a mix of manual follow-up (calling guests to confirm), overbooking (accepting more reservations than capacity to account for expected no-shows), and absorbing the cost. None of these worked cleanly.
Biases
Guests, meanwhile, had mixed feelings about deposits. In hospitality, a deposit still felt unusual to most UK diners. The framing mattered enormously: "card on file" felt lighter than "deposit." "Cancellation policy" felt fairer than "penalty."
A Booking policy must haves
1-Name/Title 2-Date ranget 3-Party size 4. Consumer Memo
More about each research steps below:
Some Numbers
Target Customers
Competitive Analysis
The guest experience
Early alignment
I ran early alignment sessions to surface technical constraints and operational requirements before committing to a direction. This kept the design grounded in what was actually buildable, reduced back-and-forth in later stages, and meant fewer surprises at handoff.
Payments
Leverage the existing company products to take Deposits as an upfront payment.
Underwriting
Manual process that will need to evolve into scalable and sustainable.
More about the process below:
Workshop
User Flow
The challenge
Dojo's RMS didn't have payment infrastructure at the venue-setup level. This project was introducing a new concept to the product: that booking settings could include financial obligations.
That created two distinct user groups to design for in parallel, constantly checking how the venue configuration choices would surface to guests. A policy that was easy to set up but alienating to read on a booking confirmation wasn't a solution.
Venue Operators
Setting up policies, deciding between deposits and card-on-file, choosing amounts, defining cancellation windows. These are busy people, they don't have time to read documentation. The setup flow needed to be fast, clear about what each option meant in practice, and confident enough to use without CS support.
Operators
Guests
Design: four key decisions
IA Dilemma
A key early decision was determining where Booking Policies should sit within the product architecture, as a standalone feature, or nested within existing settings. The placement had real downstream consequences: how policies would integrate with existing flows, and whether the structure would constrain future development.
Early conversations were gravitating toward making Booking Policy the parent of Schedules and Experiences. I pushed back. Elevating Booking Policy to that level would have created unnecessary coupling and made the architecture harder to extend over time.
To pressure-test the decision, I mapped Booking Policies, Schedules, and Experiences against their shared and distinct attributes. The answer became clear: both Booking Policies and Experiences belonged within Schedule settings and was then also validated by my TL. This consolidation meant users input relevant information once, within a single coherent flow, reducing friction during schedule creation and editing, and establishing a more scalable foundation for what would come next.
Schedules Home
Schedules Setup
Policies Home
Policies Setup
Deposits vs. card-on-file: two products, not one
A deposit takes money now and refunds it (or keeps it).
Card on file doesn't take money at the time the booking is made, but saves the Credit Card details to charges a cancellation fee later.
The trust dynamics, the guest communication requirements, the venue operations implications and the legal-payments implications are different enough to warrant distinct setup flows and product effort.
Deposits were easier to achieve from a technical pov, with no dependencies with other part of the business (Payments squad). As per customers preference both deposits and cards on file were seen as an important step to prevent no-shows. For diners, both policy types were seen as painful depending on context.
We launched the MVP with deposits and limited the Restaurant to do full or no refund. From diners side (on web and mobile app) we didn't immediately implement the option to save the Credit Card details for future payments (the consumers app had no payments feature at the time).
Before
Deletion
After
Deposits vs. card-on-file: two products, not one
After MVP we implemented Cards on file as another Booking Policy option and we also connected Dojo Restaurants with Dojo Payments so that users could apply partial refunds or take partial charges from the payment platform.
Before
Deletion
After
Once the Dojo payments-restaurants blockers were removed, further iterations included allowing operators to charge full or partial fee and issue full or partial refund from Dojo RMS; on top of it we also started tracking operators reasons to issue refunds/fees by adding a choice-select. This helped with tracking and categorised transaction data on both platforms giving us insights and keeping multiple operators belonging to the same restaurant on top of each others actions.
Card on file
Deposit
Ethical and transparent
I led the conversation around ethical design within the team, working directly with Legal to align on compliance, and championing a transparent, user-first experience throughout.
Example 1
Example 2
Edge cases as primary cases
What happens when a guest disputes a charge? What if a venue misconfigures their cancellation window? What if a booking is modified after a deposit is taken? I mapped these scenarios early and built them into the spec, rather than deferring them to "v2." Payment features with unresolved edge cases generate chargebacks and support tickets and both were metrics the business cared about.
Any booking management actions presented a considerable number of variables to be considered: cancellation window (set up by the restaurants), party size (increase/decrease), date/time (belonging to different schedules)
One or more changes to the above variables could lead to either a change within the same policy or to a new policy, meaning any of these journey could happen: total deposit refund, partial deposit refund, new deposit payment, policy fee payment, policy fee increase, policy fee decrease.
Example 1
Example 2
Example 3
Planner
List
Diner's side
The diners experience runs on both Dojo's customer-web and the Dojo native app.
This part of the project involved cross-squad alignment and collaboration with the Consumer Experience squad; with Payments tribe, at tech level for SDK integration.
I injected booking policies in the booking creation and management (delete a booking and edit a booking) journeys and comms (emails).
As per Operators journey, any booking management actions presented a considerable number of variables to be considered: cancellation window (set up by the restaurants), party size (increase/decrease) , date/time (belonging to different schedules)
One or more changes to the above variables could lead to either a change within the same policy or to a new policy, meaning any of these journey could happen: total deposit refund, partial deposit refund, new deposit payment, policy fee payment, policy fee increase, policy fee decrease.
Impact within the initial rollout period
31,932 transactions
processed through the booking policies feature
Less No-Shows
Venues reported meaningful reduction in no-show rates (specific percentage data not captured in rollout instrumentation — an identified gap)
What I learned
Payment UX is trust UX
The technical plumbing of charging a card is less than half the design problem. The other half is making the transaction feel fair, expected, and easy to reverse if something goes wrong for both the venue and the guest.
Research depth pays for itself in edge case coverage.
The scenarios we found in sessions: the guest who disputes a charge, the venue that sets a deposit and forgets, the diner who books on behalf of a group and doesn't know a deposit applies. They would have become chargebacks and tickets without design coverage.
Language alignment with the rest of the product areas
Dojo RMS in part of Dojo payments. The two systems are not belongin one product and the user has to go through two different logins and products to manage their restaurants and their pyaments provider. Aligning with the Payments squads was however vital to create a coherent language across the two platforms.