How to choose software that lasts a year

Why feature lists mislead

Most software decisions begin with a comparison table. Two or three products, a column each, a long list of features down the side, and a tick or a cross in every cell. The tool with the most ticks tends to win. This feels rigorous. It is not, because a feature you never use is worth nothing, and a feature you use ten times a day is worth almost everything. A comparison table treats both the same.

The better question is not "what can this software do" but "what will I do with it next Tuesday, and the Tuesday after that". Software you still use in a year is software that fits the work you repeat, not the work you imagined when you were excited by a demo. Government service designers put the same idea plainly: "If you don't know what the user needs are, you won't build the right thing." [1] The principle holds just as well when you are buying as when you are building. If you do not know what your own work needs are, you will not buy the right thing.

Start from your repeated work, not the catalogue

Before you open a single product page, write down the five to ten tasks that make up most of your week. Not the grand strategy. The actual repeated motions: logging a new enquiry, sending a quote, chasing a slow payment, answering the same customer question for the third time, writing the weekly update. These are the tasks a tool has to make faster or more reliable. Everything else is decoration.

Now take each task and walk it through the product end to end. How many clicks to log that enquiry. Whether the quote can be sent from the same place you had the conversation, or whether you have to copy details into a second system. Whether the customer's history is visible while you reply, or buried two screens away. A feature list will tell you that "quoting" exists. Only the walk-through tells you whether quoting fits your day. We have written before about why quotes and invoices belong next to the conversation; the point there is the same as the point here. A capability that lives in the wrong place is a capability you will route around until you stop using it.

The tasks you do rarely are the wrong test

People tend to evaluate software on its most impressive feature, which is usually the one they will touch least. The dramatic report. The complex automation. The clever dashboard. These are easy to be dazzled by and easy to overweight. Give them one tenth of the attention you give to the small, dull, frequent tasks. A tool that makes your ten-times-a-day task slightly worse will be abandoned, no matter how good its once-a-quarter task is.

Count the things that only show up later

Some costs of a tool are invisible on the day you choose it and painful six months in. Three are worth checking before you commit.

• Switching cost. Getting your data in is easy; getting it out again is the part nobody checks. Before you move in, confirm you can leave. Under data-protection law, "The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance." [3] A product that cannot hand you a clean export of your own records is one you cannot safely depend on. This is the whole argument of the data you should be able to export on any Tuesday.
• Integration cost. If the tool has to talk to the others you already run, that link is part of the purchase, not an afterthought. Links fail quietly and at the worst time.
• Habit cost. Every tool asks your team to change how they work. The more a product matches motions people already have, the more likely those motions survive first contact with a busy week.

Decide with evidence, not with the demo

The demo is a performance. It is run by someone who knows the product, on clean sample data, following a path chosen to go well. Your Tuesday is none of those things. So where you can, trial the tool on your own real work, with your own real data, doing your own real tasks, before you decide. Then watch what actually happens rather than what you hoped would happen. Service designers again: "Let data drive decision-making, not hunches or guesswork." [2] A trial gives you data. A demo gives you a hunch.

Two weeks of honest use will tell you more than two hours of being shown around. Did the team reach for the tool, or did they reach for the spreadsheet out of habit. Did the frequent task get faster or just different. Did anything break. We set out what to watch for over a longer run in what to measure in the first 90 days, and the short version is simple: pick a handful of numbers that would change your mind, then look at them. That discipline — letting numbers that change a decision do the deciding — is what separates a choice you keep from a choice you regret.

A short checklist

• List your five to ten most repeated tasks before looking at any product.
• Walk each task through the tool end to end; count the clicks and the copy-pastes.
• Weight the frequent dull tasks far above the rare impressive ones.
• Confirm you can export your own data cleanly before you move in.
• Treat integrations as part of the purchase, not a bonus.
• Trial on your real work, then judge by what happened, not by the demo.

Where 360REV fits

We built 360REV so the frequent tasks — the enquiry, the quote, the reply, the follow-up — sit in one place next to the customer's history, and so your records export in a standard format whenever you want them. That design choice only matters, though, if those are the tasks that fill your week. Run the walk-through above against us and against anyone else. The tool you still use in a year is the one that fitted the work you actually do, and the only way to know that is to test it on that work.