Keep, replace, or cancel: the line-by-line read of your software bill.
Five questions for every line, the case for keeping what works, the order to change things in, and a blank worksheet to decide each line in your own hand.
Daniel M. Ortiz · September 2026
The question usually arrives as one line: do we have to replace the POS? It is the wrong first question, because the POS is one line on a bill that runs to a dozen, and the problem that raised the question rarely lives inside it.
This is how we read a software bill on a walkthrough: every line, the same five questions, and a written answer of keep, replace or cancel per line. You can run it yourself with the invoices and an evening.
Should a restaurant replace its POS when operations break down?
Usually not. A POS gets replaced when it is dying, or when the vendor is forcing a migration you did not choose. Otherwise the problems that raised the question survive the replacement, because most of them live in the seams around the POS: the phone order keyed in by hand, the book that does not talk to the floor, the third-party order that never reaches the close-out. A new POS prints those tickets the way the old one did. Read the whole bill before you decide any single line on it.
The answer cannot come from the POS vendor or from whoever is selling you the replacement; each can see as far as its own login. The bill is the only place all of them sit on the same page, which is why the read starts there.
Start with the software bill, every line.
Pull the last invoice for every tool the operation pays for, including the ones on a personal card and the ones that renew annually and get forgotten. The list is longer than it feels.
The lines a single site usually carries
- The POS, with its add-ons and card processing
- Reservations and the book
- Online ordering, the direct path
- Delivery portals, one line each
- Phones and the after-hours message
- Scheduling
- Payroll
- Accounting and the bookkeeper's tools
- Marketing tools: the email list, the review responder, the loyalty app
For each line, five plain facts before any judgement
- What it costs a month, add-ons included
- Who actually logs in, by name
- What it duplicates: which other line does part of the same job
- When the contract ends
- How much notice a cancellation takes
The five questions asked of every line.
The same five, in the same order, for every line. The answers go on the worksheet in a few words each, and the last column stays blank until all five are in.
Ownership
Who owns it, and who owns the data inside it? An account opened in a former manager's name, or a guest list that lives on the vendor's side of the login, is a line you do not fully hold. Write the name on the account and where the data would go if you cancelled tomorrow.
Handoff
What has to be re-keyed into it, and what has to be re-keyed out of it? A line that takes ten minutes of typing a night to feed and another ten to read is charging you more than the invoice says. Name the person doing the typing and the system on the other side.
Reliability
How does it fail during service, and who notices first? Every tool fails; the question is whether the failure is quiet. A tablet that stops chiming and loses an hour of orders before anyone looks is a different line from a printer that jams in front of the whole pass.
Rollback
Can the old way run beside it? If this line vanished on a Friday at seven, is there a paper book, a phone, a manual close the manager on duty could fall back to without calling anyone? A line with no way back cannot be replaced safely either, which matters for the next question.
Acceptance test
What does working mean, in one sentence you can check on your own floor? Your sentence, about your room: every phone booking is in the book within a minute, in the host's hand. If you cannot write the sentence, you cannot tell whether the line is earning its cost, and neither can anyone selling you a replacement.
Keep is an answer.
Keep is the answer for any line that one named person owns, that takes no re-keying to feed, that fails loudly, that has a way back, and that passes a sentence you wrote, whatever a newer tool promises. The worksheet exists to make keep defensible, so the line is left alone on purpose.
How we are paid changes how you should read our version of this worksheet. Nobody pays us less when a line says keep, and nobody pays us more when it says cancel. There is no line on our invoice that a software company pays. The answer per line is the same answer whether or not anyone sells anything afterward.
Contract dates and forced migrations.
Three dates decide when a replace or a cancel can actually happen: the contract end, the notice a cancellation takes, and, where the vendor is moving everyone to a new version, the day the migration is forced. Write all three on the worksheet for every line, from the contract itself, in its own words. A line that reads replace with a contract end two years out reads keep for two years, and the plan should say so.
A forced migration is the one case where the POS moves to the front of the queue. If the old version is being switched off on a date, the choice is between the vendor's new version and someone else's, and the cutover is planned around that date rather than the operation's calendar. Find the date before anything else.
We are not lawyers, and this is not contract advice. Read the contract, or have your counsel read it, before you rely on any date or notice period you wrote down. The worksheet records what the contract says; it does not interpret it.
Replace the POS last.
Rank every replace and cancel by how much of the floor it touches. The lines that change nothing under the floor go first: the phones, the after-hours message, the large-party inbox. A re-recorded message that books instead of apologizing, or an inbox with one named owner and an auto-reply, can land on a Tuesday morning and be rolled back by lunch. Nobody at the pass notices.
The book and the direct ordering path come next. A guest touches them, so the old way runs beside the new one until it has survived real services. The POS goes last, because every ticket, every close and every seam in the building runs through it. If the bill says the POS must go, it goes at the end of the plan, on a date the contract sets, with the way back on paper.
The blank software bill.
One row per line on the bill, in your own hand, from the invoices and the contracts. Add rows until the invoices run out.
| Line | Monthly cost | Who logs in | What it duplicates | Contract end | Notice | Keep / Replace / Cancel |
|---|---|---|---|---|---|---|
How the assessment prices this for you.
On a walkthrough this worksheet is one section of the report. Every line on your bill comes back with the five answers, a keep, replace or cancel, and what each one does for the operation next to its cost, with the contract dates read from your own invoices and contracts. The two things fixed during field week come from the same ranking: whatever can be fixed in an hour without touching the floor.
Where a line says replace, the plan prices the cutover as a fixed-fee phase with a written rollback your manager on duty can pull, and the old way runs beside the new one until it has proven itself. The plan is yours either way, whoever builds it.
If the worksheet has more replace rows than you expected, and you want the bill priced by someone with no line on it that a software company pays: