Most software selections are decided in the first demo and justified for the next 6 weeks. The fix costs an afternoon: write down what has to be true before you watch anything, in your own words, weighted, and agreed with the people who'll use it. Then run every candidate through 1 real case of yours, score against the list you wrote, and take 2 reference calls with firms your size. The order matters more than the effort, because the first demo you watch becomes the criteria you judge everything else by.
Key takeaways
- Write the criteria first. A demo watched before you've decided what matters will decide what matters.
- Shortlist to 3 candidates on paper. More than that and the process collapses into whoever demos best.
- Test on 1 real case of your own, including the awkward part. Demo clients are built to make software look good.
- The questions that separate vendors are about data, failure and exit, and none of them appear on a feature grid.
- Take reference calls and ask what went wrong, not whether they're happy.
Why most selections go wrong
3 failure modes, and they're all about sequence rather than judgement.
The first demo sets the bar. You watch a product, it does something impressive you hadn't thought to want, and that capability quietly becomes a requirement. Every later candidate gets measured against a feature you didn't need on Monday.
The loudest capability wins. Demos are built around what shows well in 40 minutes. The things that decide whether you're still happy in year 2, how the tool behaves when data is missing, what the audit trail looks like, how support answers on a Friday, don't demo well and so don't get shown.
The person who won't use it decides. In a bigger firm that's the partner who signs. In a small firm it's more subtle: the principal chooses on the advice workflow, and the person who spends most of their day in the system was never asked.
Step 1: write your criteria before you see anything
Take an afternoon before you book a single call.
Start from your own week, not a feature list. Where do the hours go? Which handoff breaks most often? What did you have to redo last month? Those answers are your requirements. A vendor's feature grid is their sales structure, and adopting it hands them the frame.
Separate must-have from nice. Be strict. If everything is a must-have you've built a wish list, not a decision tool. A useful test: would you rule a product out for failing this, on its own? If not, it's a nice to have.
Weight them. Not all must-haves matter equally. Give the top 3 more weight than the rest, and write down why, because in 6 weeks you'll have forgotten and someone will relitigate it.
Get the users to sign it off. Whoever spends the most hours in the system should have edited the list before it's final. This is the cheapest way to avoid choosing something your firm quietly refuses to adopt.
Step 2: shortlist on paper, then stop
Cut to 3 candidates before any demo. Websites, published pricing, a couple of comparison pages, 20 minutes each.
3 is the number because each proper evaluation costs real time and a fourth candidate rarely changes the answer. What it does is push the decision past the point where anyone remembers what the first one did.
Rule products out for concrete reasons and write the reason down. "Feels less polished" isn't a reason. "No write-back to our back office" is.
Step 3: run 1 real case through each
This is the step that decides whether the process was worth running.
Pick a case of your own, not the demo client. Ideally one that's slightly awkward: a joint arrangement, an odd legacy product, a client whose objectives changed halfway through. Demo data is clean by construction, and clean data hides exactly the failures you need to see.
Then measure the same things for every candidate:
- Time to a usable first draft, and how much editing it needs before you'd sign it.
- Every point you had to type something the system should already know. Count them.
- What happens at the awkward part. Does it handle it, flag it, or invent something?
- What exists when you're done. A document, or a document plus a trail showing what it was built from and who approved it.
If a vendor won't let you run your own case, that's information. Note it and move on.
Step 4: the questions vendors don't expect
Feature answers are rehearsed. These aren't:
- "What happens when the data isn't there?" You want a clear result, an honest "not available", or an error with a reason. A system that fills gaps with something plausible will eventually do that in front of a client.
- "Show me the audit trail for the case we ran." Not a screenshot from the marketing site. The one we made 10 minutes ago.
- "Which of these is shipped, and which is roadmap?" Ask per capability, and write down the answers with dates. Buy what exists today.
- "Where does our client data go, and is it used to train shared models?" Country, sub-processors, retention. In writing, because your own records need it.
- "How do we get everything out, in what format, and what does it cost?" Ask on the way in. The answer is different once you're leaving.
- "What does support look like at 4pm on a Friday in tax year end week?" Ask for the actual response times, not the target.
- "What's changed in the product in the last 6 months?" A real answer tells you the pace. A vague one tells you something too.
Step 5: reference calls, asked properly
Ask the vendor for 2 references from firms your size, and ask your own network for 1 they didn't choose.
The question isn't "are you happy". Nobody says no to that on a call the vendor arranged. Ask instead:
- What took longer than you expected?
- What do you still do outside the system?
- What did you have to change about how you work?
- Has anyone in your team refused to use it, and what happened?
- If you were choosing again, what would you ask that you didn't?
You're listening for the shape of the problems, not for a verdict. Every product has problems. You're deciding which set you can live with.
Step 6: the commercial terms that matter
The demo is about the product. The contract is about the next 3 years.
- Minimum seats. A per-user price with a floor is a different number for a solo adviser than the pricing page suggests.
- What's inside the price. Cashflow, research, document sending and storage are separate line items at some vendors. Add everything up before comparing.
- Uplift. What can they raise it by, and with how much notice.
- Notice and term. How long you're committed and how you leave.
- Exit and export. Format, cost, and how long they keep your data afterwards.
- What "beta" means here. Which parts, what changes, and what happens to your price when it ends.
What to do in the first 90 days
Choosing well and adopting well are different projects, and firms that get the first right still lose the benefit by skipping the second.
Move new cases onto it first and leave work in flight where it started. Pick 1 person to own the setup and the templates rather than letting everyone configure their own. Measure hours per case at week 1 and week 12, honestly, including the checking. And keep the thing you're replacing running until a full case has gone through end to end.
Any figures a vendor gives you, ours included, are designed to support a business case rather than guarantee an outcome. Ask what has to be true for them to hold, then test it on your own case.
Frequently asked questions
How long should choosing advice software take?
4 to 6 weeks is enough for a small firm: an afternoon on criteria, a week to shortlist, 2 to 3 weeks running a real case through 3 candidates, then references and contract. Longer than that and the early evaluations go stale. Much shorter and you're choosing on demos, which is the thing the process exists to prevent.
What questions should I ask a software vendor?
The ones about data, failure and exit. Where client data goes and whether it trains shared models, what the system does when a value isn't available, what's shipped versus roadmap, how you export everything and what that costs, and what support response times genuinely are. Feature questions get rehearsed answers and rarely separate candidates.
Should I run a pilot or a proof of concept?
Run a proof of concept on your own real case before you sign, then treat the first 90 days as the pilot. A long free trial with nobody driving it produces no evidence, because everyone reverts to the old process under pressure. A single real case with someone accountable for finishing it tells you more in a week.
Who should be involved in choosing?
Whoever spends the most hours in the system, always, alongside whoever signs. In a small firm that's often an administrator or paraplanner rather than the principal, and their veto is worth more than another demo. Adoption fails quietly when the daily user was consulted after the decision.
What's the most common mistake firms make?
Watching demos before deciding what matters. The first product you see reframes the whole comparison around its strengths, and everything after it gets scored on someone else's terms. Writing the criteria down first costs an afternoon and is the single highest return step in the process.