The best hospitality software is the software nobody has to learn
Training time is the real price of a venue tool, and almost nobody puts it on the invoice.
Every piece of software sold to a venue has two prices. There’s the one on the invoice, and there’s the one paid in training: the shifts where someone is learning the tool instead of doing the job, the laminated instructions taped to the counter, the casual who started last week and has never seen the dashboard.
The second price is usually larger, and it’s almost never quoted.
Turnover is the constraint
Hospitality has high staff turnover. That isn’t a problem to be fixed by better software; it’s the environment the software has to survive. A tool that takes an hour to learn doesn’t cost you an hour. It costs you an hour times every person who will ever touch it, which in a venue with normal turnover is a recurring expense forever.
This is why so much venue software quietly stops being used about six weeks in. Not because it was bad, but because the person who understood it left.
What we optimise for instead
Both of our products are built around the same constraint, from different ends of the counter.
For the guest, the interaction has to work with no instruction and no install. That’s why Waitspot joins a queue with a scan and nothing else, and why ReviewBox requires exactly one answer, a star rating, and makes everything else optional. Every additional required field is a percentage of people who don’t finish.
For staff, the test is harsher: can someone use it correctly on their first shift, mid-rush, with nobody free to help? That pushes you toward one screen instead of five, defaults that are right most of the time, and actions that are hard to get wrong rather than actions that are merely undoable.
The uncomfortable trade
Designing this way means saying no a lot. Every feature request arrives attached to a real customer with a real reason, and most of them would be individually fine. Collectively they’re how you end up with the thing that needs a training day.
The rule we use: if a feature makes the first thirty seconds harder for someone who’s never seen the product, it needs to be worth substantially more than it costs. Usually it isn’t, and it goes behind a setting or doesn’t get built.
Slower roadmap, longer-lived deployments. For this market, that’s the right side of the trade.