An error should say what to do next

The highest-stakes moment on a QR menu is the second after somebody taps Place order. If it fails, what they see next decides whether they try again, give up, or come and find a member of staff.

Ours used to show the browser's own alert box: a grey rectangle with one line of raw text in it and an OK button. On an iPhone it prints the website's address above the message, which is a detail nobody has ever found reassuring.

The text was whatever the server had said. Sometimes that was clear. Sometimes it was a sentence written for a developer. Either way it answered the wrong question.

The three things a guest actually needs

Watch someone hit that error and you can see them working through it:

• Has money moved? Overwhelmingly the first thought.
• Is my basket gone? Fifteen minutes of choosing.
• What do I do now? Try again, or give up and queue?

The reason is useful, but it is fourth. So the failure now says what went wrong and then: "Nothing has been charged and your basket is still here. Tap Place order to try again, or order at the counter."

That sentence is true because the code makes it true in the same breath — it re-enables the button and leaves the basket alone. A reassurance that the software does not actually honour is worse than silence.

Why the browser's box has to go

Beyond the look, it cannot carry this. One string, no heading, no second paragraph, no room for the sentence that matters. The moment you want to say two things, you need your own.

Eleven of those boxes were still reachable across our guest pages, the food-hall page and the staff app. They are gone. Each one now has a title, the reason, and a line telling you what to do about it.

The cheap audit

Go to your own ordering page, turn off your wifi, and try to place an order. Read what appears as if you were hungry and slightly annoyed. If it does not tell you whether you have paid, it needs rewriting — and that is true whoever built it.