Write one real incident, not “the system is bad.” Example: Friday night a guest wants a dish changed, the till cannot do it, people wait at the table; or the handover does not balance, and you only notice a missing payment the next morning. Put it on paper: did it stall on ordering, changing an item, taking payment, or closing the day; how many times a week; how long guests waited; whether someone had to write it by hand.
What “keep it” looks like
The people on shift can open, take money, fix mistakes and close; you already have a workaround you accept — printer down, write it by hand, still balance at night; machines, repairs and your own books are still reachable. A switch means downtime, training and spend that is larger than this trouble — then do not switch yet. Put “keep the current system” on the same sheet. Do not only write how to change.
What “look seriously” looks like
The same incident cuts into service every week; takeaway or moving tables — things the shop must do — the current system cannot do; nobody repairs the hardware, you cannot export the books; you plan delivery or a second site, and this setup cannot follow.
A sales demo, a feature list, or one new rule is not a reason to switch on its own. First write which night must run end to end, and how you will check it. If those answers are still blank, do not set a cutover date.
Back to Restaurant POS selection checklist.