Choosing & switching software

Most software decisions do not fail on the software. They fail on the question before it. "We need appointment management" is not a requirement but a product category — a requirement sounds like this: I spend two hours every Sunday evening on the rota because the hours are not added up anywhere. The first sentence leads to a comparison of vendors; the second leads to a question you can actually test.

A trial proves less than most people hope. It shows whether the interface appeals, and almost never whether the system survives the month in which three things go wrong at once. What a trial can prove has to be decided beforehand: map a real week onto it, with your own services, your own prices and at least one special case you would normally settle over the phone.

The most expensive question comes last and is overlooked first: how do you get out again? Customer records, appointment history, invoices and images belong to you — but only if you can get them in a format another system can read. An export that produces a PDF list is not data portability.

Then there is the contract: term, notice period, what happens on a price rise, and how long the data stays retrievable after the end. Those are four lines that cost two minutes before signing and a year afterwards. The articles in this section take the order seriously — requirement first, then the trial, then the way out, and only after that a comparison of vendors.