Spend limits and the checkout argument

The dispute is predictable, so design for it

At checkout a guest will say they did not buy four drinks on Tuesday. Without a plan this becomes a manager writing the charge off, which is fine once and becomes policy by the end of the season. The plan is two things: a per-transaction record showing time, outlet and band, and a threshold above which a server also asks for a room number. Neither is complicated and both have to exist before the programme launches rather than after the first argument.

A threshold is better than a signature on everything

Requiring confirmation on every transaction destroys the reason for going cashless — the swim-up bar queue reappears immediately. Requiring it above a value catches the transactions large enough to be worth disputing while leaving the ordinary ones frictionless. Where the threshold sits is a judgement about the property, but the existence of one is close to universal among programmes that run without incident.

Children need a visible answer, not a system rule

A twelve-year-old with a band that opens a tab is the fastest route to a difficult conversation at checkout. Whatever the system enforces has to be visible on the wrist as well, because a bartender at a busy pool bar is not looking anything up. A distinct child band colour that a server reads instantly, with the system enforcing what the colour promises, closes this. A rule that exists only in software will be worked around by staff under pressure.

The band is not the control

None of this is a wristband specification. It is a set of operating decisions that the wristband makes possible, and the reason to write them down before ordering is that they change what you order — whether children need a separate colour, whether the band must show a number a supervisor can read, how many tiers exist. Properties that specify the band first and the policy afterwards usually reorder.