Why hospitality tech dies on a Friday night

It’s 9:40 on a Friday. The room’s full. One of your two closers called in sick at four and you couldn’t backfill, so you’re a body down all night. The kitchen’s forty minutes behind and the printer’s chewing dockets. Someone’s eighteenth in the function room has picked up about thirty guests nobody accounted for. A rep you’ve been dodging for a fortnight is standing at the end of the bar with a folder, waiting for “just five minutes”.

That’s not a bad night. That’s a Friday.

Now picture the software demo you sat through on a Tuesday morning. Clean dashboard. Tidy numbers. A salesperson clicking through screens in a quiet room with good wifi and nothing on fire. It looked great. It probably was great, in that room.

The gap between those two rooms is where most hospitality tech goes to die.

It’s not that the software is bad

This is the bit people get wrong when they hear an operator complain about tech. They assume we mean the product is rubbish. Usually it isn’t. Most of it is competently built by people who work hard and genuinely want it to help.

The problem is that it’s built for operating conditions that don’t exist in a venue after about 9pm. Almost every venue tool I ever got sold made at least one of four assumptions, and every one of them is wrong on a Friday.

It assumes somebody has a spare hand. A lot of software needs to be fed. Enter the wastage, tick off the checklist, tag the incident, update the count. On a Tuesday, fine. On a Friday, the person who’s supposed to feed it is carrying six glasses and settling a disagreement about whose round it is. Any tool that needs a spare hand at peak will only ever get data from off-peak, which means it ends up describing a version of your venue that doesn’t include your hardest hours.

It assumes somebody has a spare brain. This one’s worse, and less obvious. Attention is the scarcest thing in a busy venue — much scarcer than time. A tool can be quick to use and still be unusable, because it asks you to hold something in your head while you’re already tracking the door, the bar, the pokies room and the group that’s gone quiet in the wrong way. Cognitive load isn’t a design term in hospitality. It’s the whole job.

It assumes low staff turnover. Software designed around a well-trained regular user is designed around a person a lot of venues don’t have. The realistic user is a nineteen-year-old on their fourth shift who’s covering because someone quit by text. If the tool needs training to be safe, it will be used unsafely. Not out of laziness — out of arithmetic.

It assumes clean data. Venues are messy in ways that break systems. Tabs get merged. Names get misspelled. The function booking is under someone’s partner’s name. Two staff have the same first name and one of them is “Big” something. Any tool that gets confused by mess will get confused constantly, and a tool that’s wrong often enough gets ignored entirely — usually within a fortnight.

The rep at the end of the bar

Here’s the other half of the problem, and it’s the half the industry never talks about.

Almost every venue technology decision gets made at the worst possible moment. A rep catches you mid-shift, or at the end of one, when you’re flat and you want the conversation to be over. He’s personable. He knows the industry. He says the right things about how busy you must be. And you’re standing there doing sums you’re not equipped to do, about a pricing model you’ve never seen before, while someone waves an empty glass at you.

I made buying decisions like that. More than one. Nobody makes good decisions like that.

The tell I learned to watch for was the demo that never showed me a hard moment. If a salesperson walks you through their product and every screen is calm, they’ve either never seen a real venue or they’re hoping you won’t ask. Ask them what it looks like at capacity. Ask what happens when the internet drops for ninety seconds, because it will. Ask who’s holding the phone at 11pm — you or a casual. Watch what happens to their face.

And ask this one, which is the most useful question I never asked often enough: who has to do something new for this to work, and when in their shift do they have to do it? If the answer is “the person on the floor, during peak”, it will not work. Not because they’re not good enough. Because peak is already full.

The Friday night test

I’m on the other side now. I build software for venues instead of buying it, which means I get to make the same mistakes from a new angle — with the added bonus that software hides its problems much longer than a pub does.

That’s the thing nobody warns you about in the switch. In hospitality, feedback is instant and brutal. Beer’s flat, you know in thirty seconds. Roster’s wrong, Saturday tells you. The cool room picks 6pm on a Saturday to choose violence and you find out immediately. You are never confused about whether something worked.

Software will let you polish a thing for a fortnight, feeling productive as hell, and never tell you it’s useless. It’s the digital equivalent of deep-cleaning the cool room while nobody’s ordering — technically work, but the room doesn’t care.

So I stole a test from the old job and pointed it at my own work:

Would this survive a Friday night?

Not a Tuesday lunch. Not a demo. A proper Friday. Short-staffed, loud, everything running twenty minutes late.

It’s a harsher filter than it sounds, and it kills a lot of clever ideas. Some things it has taught me, in no particular order:

• If it needs perfect attention, it fails.
• If it needs perfect data, it fails.
• If it only works when the venue is calm, it isn’t a tool. It’s homework.
• If it needs a keen person to champion it, it dies the week that person goes on leave.
• If it can’t be ignored for a night without breaking, it will break, because it will be ignored for a night.

The corollary is the useful bit: the tools that actually survive in venues tend to ask for almost nothing. They work with what’s already there. They’re useful even when nobody’s tending them. They fail quietly instead of loudly. They don’t need a hero.

That’s less exciting than a dashboard. It’s also the difference between a tool that’s still in use in six months and one that’s an unused login and a line item somebody forgets to cancel.

Build for pressure, not for demos

If you build for hospitality, spend a Friday night in a busy venue before you write another feature spec. Not a polite Tuesday lunch where the owner has time to chat and explain their pain points. A proper Friday, standing out of the way, watching how many things the duty manager is holding at once. You’ll redesign half your product in your head before last drinks, and you’ll be right to.

And if you run a venue: the next time someone’s selling you something, you don’t need to know anything about technology to ask the only question that matters. When exactly, in a shift that’s already full, does somebody have to do this?

If they can’t answer that in one sentence, it won’t survive your Friday either.