Choose practice-management software by first writing down the small number of jobs you need it to do — scheduling work, showing job status, tracking deadlines, holding client records, planning capacity and connecting to the rest of your stack — then scoring two or three shortlisted systems against those jobs using your own real work rather than a vendor demo. The licence fee is the smallest part of the cost: for a ten-person firm, migration, configuration, training and the productivity dip together usually outweigh three years of subscription. And no system will impose a process you have not already agreed, so decide how the work should flow before you decide what records it.
Decide what the system is for before you look at one
Practice-management software is the most common purchase a growing firm makes when it feels operationally stuck, and it is the one most often regretted. The pattern is consistent: three demos in a fortnight, a decision made on the strength of the slickest interface, an implementation that runs twice as long as promised, and eighteen months later a system that half the team uses for half its purpose while the real coordination still happens in email and someone’s spreadsheet.
The reason is rarely the software. It is that the firm asked the wrong question. “Which system should we buy?” is a question about products. The question that actually determines the outcome is “how should work move through this firm?” — and that one has to be answered by the firm, not by a vendor. A practice-management system is a set of rails. Rails are extremely useful once you know where the trains are meant to go, and completely useless as a way of deciding the route.
This is the same point made in what is operating discipline, and it is worth stating bluntly here because it saves firms a great deal of money: software records whether the work happened. It has never once made the work happen. If three people currently prepare a VAT return three different ways, buying a system gives you three different ways recorded in a database. The system will make the inconsistency visible faster, which is genuinely valuable, but it will not resolve it.
So the sequence matters. Agree the route first — even roughly, even on one job type — then choose the rails. In practice that means having a defensible answer to five questions before you take a single demo:
- What are our recurring job types? Usually a short list: year-end accounts, corporation tax, personal tax, VAT, payroll, bookkeeping, company secretarial.
- What are the stages each one passes through? Not the ideal ones — the real ones, including the waiting.
- Who decides a job is finished? If the answer is “whoever notices”, that is a process decision the software cannot make for you.
- Where does work currently get stuck? The answer is nearly always records from clients or the review stage — see common workflow bottlenecks in accountancy firms.
- What single number would tell us next month whether this was worth it? Jobs completed against jobs scheduled is the usual honest answer.
A firm that can answer those five will run a competent selection in six weeks. A firm that cannot will spend six months evaluating features it has no way of valuing.
The seven jobs a practice-management system has to do
Feature lists are designed to be uncomparable. Every vendor has a hundred features and no two use the same words for the same thing, which is why comparison spreadsheets with sixty rows produce paralysis rather than clarity. Reduce it instead to the seven jobs the system is actually being hired for, and score only those.
| The job | What good looks like | The question that tests it |
|---|---|---|
| Hold the client record | One place for entity data, deadlines, services, fees and AML status — and it is the place people actually look | “Show me every client where we hold a service but no agreed fee.” |
| Schedule the work | Jobs are created automatically from the client’s year end and appear on someone’s list before the deadline is frightening | “Create next year’s 600 jobs in front of me.” |
| Show status at a glance | Anyone can see what stage every job is at without asking a person | “Show me every job stuck waiting on client records for more than 14 days.” |
| Chase for you | Records requests and reminders go out on a schedule without a human remembering | “Show me the reminder sequence and where it stops.” |
| Plan capacity | You can see next quarter’s workload against the hours you actually have | “Show me March’s planned work against available hours by person.” |
| Connect to the rest of the stack | Real, supported links to your accounts production, tax, bookkeeping and e-signature tools | “Which of these is a supported integration and which is a Zapier workaround?” |
| Give the data back | You can export everything you put in, in a usable format, without paying for the privilege | “Export the full client and job history to CSV now, on this call.” |
Two of those rows carry more weight than the rest. Capacity planning is the one most firms skip in selection and most need within a year, because it is the difference between knowing you are busy and knowing which week in March breaks — the mechanism described in how to increase capacity without hiring. And the export question is the single best five-second test of a vendor, not because you intend to leave, but because a system that makes leaving hard has told you how it intends to compete.
Ask each question live, in the demo, against something resembling your data. A vendor who can answer all seven on screen is demonstrating the product. A vendor who takes them away and comes back with a document is demonstrating a roadmap.
Worked example: the three-year cost of a ten-person implementation
Firms compare systems on the per-user monthly price because it is the only number both vendors publish. It is also the smallest number in the decision. The figures below are illustrative — an invented ten-person firm, not a client, with costs framed as a rough UK guide rather than quoted rates — but the proportions are the point, and they hold across almost any firm of that size.
Assume ten users at £35 per user per month, which sits inside the broad band UK practice-management products occupy; internal time is costed at £60 an hour for staff and £150 an hour for owner time, consistent with the other worked examples on this site.
| Cost line | Illustrative basis | Three-year cost |
|---|---|---|
| Licences | 10 users × £35 a month × 36 months | £12,600 |
| Productivity dip | 10 people losing 5% of an eight-week bedding-in period — 140 hours at £60 | £8,400 |
| Selection and decision | 30 hours of owner time across demos, references and contracting at £150 | £4,500 |
| Configuration | 60 hours building job templates, stages and client data at £60 | £3,600 |
| Training | 10 people × 6 hours at £60 | £3,600 |
| Migration and setup fee | One-off vendor charge for data import and onboarding | £1,500 |
| Total | Of which £21,600 falls in the first year | £34,200 |
Three things follow from that shape. The first is that a £10-a-user price difference between two shortlisted systems is worth £3,600 over three years — real money, but less than the productivity dip, and nothing like enough to justify choosing the system that fits your workflow less well. Firms routinely trade a decade of daily friction for a saving smaller than one bad implementation month.
The second is that the largest controllable line is the bedding-in period, and it is controllable. A dip of five per cent over eight weeks assumes a phased rollout with configured templates and a named internal owner. Firms that go live across every job type at once, with the configuration half-finished, commonly see a bigger dip lasting a full quarter — and at that scale the disruption alone exceeds three years of licence fees.
The third is that £21,600 of the total lands in year one, most of it as your own team’s time rather than an invoice. It never appears in the management accounts as an implementation cost. It appears as a busy quarter with disappointing output, which is exactly the pattern described in why busy firms aren’t always profitable.
A six-week selection that does not become a project
Selection expands to fill whatever time it is given, and a firm that spends four months evaluating has usually lost more in owner attention than the software will cost. Six weeks is enough for a decision of this size, provided the sequence is fixed in advance.
- Week 1 — write the brief. One page: your job types, the seven jobs above weighted for your firm, the integrations that are non-negotiable, and the one number that will prove it worked. Weighting matters more than the list. If capacity planning is the reason you are buying, it cannot carry the same weight as document storage.
- Week 2 — longlist and cut. Four or five candidates, cut to three on the non-negotiables alone. If a system does not integrate with your accounts production software, no amount of interface quality rescues it.
- Weeks 3–4 — scripted demos. Send the same seven questions to each vendor in advance and insist they are answered on screen, in that order. An unscripted demo shows you the product’s best angle; a scripted one shows you the product.
- Week 4 — two reference calls each. Ask for firms of your size, and ask three questions: what took longer than expected, what does the system still not do, and what would you check if you were choosing again. Vendors supply happy references; those three questions still produce useful answers from them.
- Week 5 — trial on real work. Load one job type and twenty real clients into the top two. A fortnight of genuine use tells you more than every demo combined, and it surfaces the data problems in your own records early, which is where they are cheapest to fix.
- Week 6 — decide and contract. Score against the weighted brief from week one, not against the memory of the demo. Then negotiate the contract terms in the next section before signing.
Two rules protect that timetable. One person owns the decision and can commit the firm — a committee of four partners will not converge in six weeks. And the scoring model is written down before the first demo, because a scorecard built afterwards is a justification, not a decision. A simple weighted sheet is enough:
| Scored on | Suggested weight | Why it earns that weight |
|---|---|---|
| Fit to your actual workflow | 30% | The friction you will feel daily for years |
| Integrations with your existing stack | 20% | Rekeying is the hidden tax of a poor fit |
| Capacity and deadline visibility | 15% | Usually the reason the firm is buying at all |
| Ease of adoption for the whole team | 15% | An unused system delivers none of its value |
| Data ownership, export and contract terms | 10% | Cheap to check now, expensive to discover later |
| Total three-year cost | 10% | Real, but the smallest lever in the decision |
The questions that separate vendors
By the shortlist stage the products look similar. The differences that matter are mostly contractual and operational, and none of them appear in a demo unless you ask.
- Can we export everything, at will, in a usable format? Not a PDF pack on request. A full CSV or API export of clients, jobs, notes and history that you can run yourself. Ask them to do it live.
- Is there a real API, and is it included? Some vendors charge for API access or restrict it to higher tiers. It matters more than firms expect, because it determines whether you can ever automate the gaps yourself — the practical route described in using AI in accountancy practice operations.
- Where is the data hosted, and what are the processor terms? You are the controller for your clients’ personal data and the vendor is your processor, so you need written terms that meet the UK GDPR requirements for processors, including on sub-processors and breach notification. Ask for the data-processing agreement before you sign, not after.
- Can the system delete data on a retention schedule? This one is specific to regulated firms and is routinely overlooked. Regulation 40 of the Money Laundering Regulations 2017 requires you to keep customer due diligence records for five years from the end of the business relationship — and at the end of that period requires you to delete the personal data obtained for those purposes, unless another legal obligation, consent or the prospect of legal proceedings applies. A system with no concept of retention makes that a manual job forever.
- How does it handle Making Tax Digital work? Making Tax Digital for Income Tax began on 6 April 2026 for sole traders and landlords with qualifying income over £50,000, extends to those over £30,000 from April 2027 and to those over £20,000 from April 2028, with quarterly updates filed from compatible software. HMRC’s own published estimate is that around 780,000 sole traders and landlords are in that first wave. Whether your practice-management system schedules and tracks four quarterly touchpoints per affected client, rather than one annual job, is now a material selection criterion.
- What does support actually mean? Hours, channel, and response time in writing. “Email support” with a two-day turnaround is a different product from a phone line in January.
- What is the renewal and price-increase mechanism? Ask what the last two years’ increases were. A discounted first year followed by an uncapped renewal is a common structure and an entirely fair one — provided you priced it in.
- Who owns implementation on our side? Not a vendor question, but the one that most reliably predicts the outcome. If nobody in the firm has time to own configuration, the implementation will stall at the point where the vendor’s responsibility ends and yours begins.
That last point deserves emphasis, because it is where most disappointing implementations actually fail. The vendor migrates the data and runs the training; everything after that — the job templates, the stage definitions, the decision about who closes a job, the insistence that everyone uses it in week nine — belongs to the firm. It is several weeks of unglamorous work that has to happen alongside client deadlines, which in a founder-led practice usually means it happens slowly or not at all. Deciding, before you sign, who does it and what they will stop doing to make room, is worth more than any feature comparison.
What to do this week
- Write down your recurring job types and the real stages each passes through. If two people produce different lists, you have found the problem the software was going to be blamed for.
- Weight the seven jobs for your firm before you look at any product, and note which one is the reason you are considering this at all.
- Cost your own implementation honestly — configuration hours, training hours, and an eight-week dip — and put that total next to the licence quote.
- If you already have a system, run the export test on it. Discovering now that you cannot get your data out is far better than discovering it during a migration.
- Name the internal owner and agree what comes off their desk. If there is no candidate, resolve that before you buy, not after.
Choosing well is not difficult, but it is a piece of work — a fortnight of thinking about how the firm should run, followed by a disciplined six-week process and a properly owned implementation. Firms that do it get a system the whole team uses and a clear view of every job in the practice. Firms that skip straight to the demos get a licence fee and a familiar feeling. If you want the process run properly alongside the rest of the operation, that is precisely the work described in the Optivo Monthly COO and sequenced in the Optivo method.
Common questions
How long does it take to move practice-management systems?
For a firm of around ten people, plan on six weeks to select and a full quarter to implement properly, with a further quarter before it feels normal. The vendor’s data migration is rarely the long part — it is configuring job templates and stages to match how your firm actually works, then getting every person to use it consistently. Firms that compress this into a fortnight tend to go live with default settings that fit nobody, which is the most common route to a half-used system. Avoid going live in the run-up to 31 January, and phase it by job type rather than switching everything on at once.
How much should practice-management software cost per user?
As a rough UK guide, per-user monthly pricing for practice-management products sits in a wide band, and the difference between two shortlisted systems is usually a few pounds per user per month. On a ten-person firm a £10 difference is around £3,600 over three years — real money, but smaller than the productivity dip during implementation and far smaller than the cost of daily friction with a system that fits your workflow badly. Price the whole three years including your own configuration and training time, then treat the licence as roughly a third of the decision, not the whole of it.
Should we just use the system from the same vendor as our accounts production software?
It is a legitimate advantage and worth weighting, because a supported native integration removes rekeying and one whole category of support argument. It is not decisive on its own. Score it as part of the integrations weighting rather than treating it as a shortcut past the rest of the evaluation, and test the integration live rather than accepting that it exists — “integrated” covers everything from genuine two-way sync to a nightly file drop. If the bundled option scores well on workflow fit too, it is usually the sensible answer. If it only wins on convenience, that is not enough.
Do we need to migrate all our historical data?
Usually not, and attempting it is a common way to delay a go-live by months. Migrate current client records, live jobs and the data you are legally required to hold, then keep the old system in read-only mode for a defined period so history remains available. Be deliberate about anti-money-laundering records: regulation 40 of the Money Laundering Regulations 2017 requires customer due diligence records to be kept for five years from the end of the business relationship, so those need a home you can rely on. Historical time entries and closed jobs from four years ago rarely justify the migration effort.
Our team barely uses the system we already have. Will a new one fix that?
Almost certainly not, and this is the most expensive mistake in this whole area. Low adoption is usually a process problem wearing a software costume: nobody agreed one way of doing the job, so the system records several, and people fall back on email because it is faster than fighting the mismatch. Before spending on a replacement, write down the agreed route for one high-volume job and configure the existing system to match it. If adoption improves, you have saved £34,000 and a disrupted quarter. If it genuinely cannot support the route, you now have a specific, evidenced requirement for the new system.
Who should own the software decision in a firm?
One person who can commit the firm, supported by two people who do the work daily. A committee of partners will not converge inside six weeks, and a decision made purely by whoever is most interested in technology tends to optimise for capability rather than adoption. The owner sets the weighted brief, runs the scripted demos and makes the call; the practitioners test on real work in week five and have a genuine veto on usability. Name the implementation owner at the same time, and agree what comes off their desk to make room — that single decision predicts the outcome better than the choice of product.
Let’s build a firm that runs without you in the middle of it.
A confidential, no-obligation call to understand your firm, where it’s stuck, and whether Optivo is the right fit. If it’s not, I’ll tell you.