How to Choose Operations Software for a 20–50 Person Team

Somewhere between twenty and fifty people, the way a company coordinates stops working. It is a reliably awkward band: too large for everyone to know what everyone is doing, too small to have the process infrastructure that larger companies take for granted.

This is when most teams buy software. It is also when most teams buy the wrong software, because the evaluation focuses on features rather than on what actually broke.

What actually changes at this size

At ten people, coordination is free. Everyone is in the same conversations. Nothing needs to be written down because nothing gets lost.

At forty, that has quietly stopped being true. Work happens in parallel across functions. The person who needs to approve something is not in the room. Someone joins and discovers that most of how the company works exists only in other people's heads.

The symptoms are consistent: managers spending their days asking for status; decisions stalling because nobody is sure who owns them; the same question answered repeatedly because the answer was never recorded; a new hire taking months to become useful.

Notice that none of those are task-tracking problems. They are problems of visibility, decision rights, and institutional memory. Buying a better task tracker does not fix them, which is why so many teams end up with one and still feel disorganised.

The four questions worth asking

Before evaluating anything, answer these about your own company.

Who owns what? If you cannot name a single owner for each significant piece of work, no tool will produce accountability. Software makes ownership visible; it does not create it.

How do decisions actually get made? Map the approvals you genuinely need — the ones with real consequence — and be honest about which existing steps are ritual. Automating an unnecessary approval makes it permanent.

What might you need to prove later? Client disputes, statutory inspections, an investor's diligence process, an employee disagreement. Anything you might need to evidence has to be recorded contemporaneously, with a history. This is the requirement most teams discover only when it is too late to satisfy it.

What happens when someone leaves? If a departure takes critical knowledge with it, the problem is that the knowledge lived in a person rather than in a system.

Point tools or a platform

Both are defensible. The trade-off is real and worth stating plainly.

Separate best-in-class tools give you the strongest individual product in each category and let you replace any one of them without disturbing the rest. The cost is integration work, several bills, several admin surfaces, and the coordination overhead of context living in one place and work in another.

A single platform gives you connected context — the conversation attached to the task, the approval logged against the decision, the document where the work happens — one bill and one place to manage access. The cost is that no single module will be as strong as the category leader, and you are more exposed to one vendor.

At twenty to fifty people the calculus usually favours consolidation, for an unglamorous reason: you probably do not have anyone whose job is maintaining integrations. If nobody owns the seams between tools, the seams are where things get lost.

Below about fifteen people, the honest answer is often that you do not need either yet.

What to test in a trial

Most trials get wasted on feature tours. Run yours differently.

Take one real process you actually struggle with and run it end to end. Not a demo scenario — a live one, with the people who do it.

Add your most sceptical team member first. Adoption is decided by whoever is least inclined to change, and finding out in week one is much cheaper than finding out in month three.

Try to get your data out. Export everything and look at what you get. If export is awkward during a trial, when the vendor is trying to win you, it will not improve later.

Attempt something you expect to be told is impossible. Vendor answers to hard questions tell you more than answers to easy ones.

Questions to put to a vendor

What does the export contain, exactly, and in what format?

Where is our data processed, and where is it stored? Get a specific answer with a region, not a reassurance.

What is the real minimum spend? Seat minimums, annual commitments and module gating are where quoted per-user pricing stops matching the invoice.

What does this product not do well? A vendor who cannot answer that has either not thought about it or is not being straight with you. The answer also tells you what you will still be buying separately.

What happens to our data if we leave?

On pricing

Read the total, not the per-user figure. A seat minimum means the advertised rate applies from a floor you may be below. Annual-only discounts are a commitment, not a saving, until you know you are staying. And check which features sit behind which tier before you conclude a plan fits — the feature that motivated the purchase has a habit of living one tier up.

The honest summary

The tool matters less than the clarity you bring to it. A team that knows who owns what, how decisions get made and what has to be recorded will do well with almost any competent system. A team without that clarity will be disorganised in an expensive new way.

Do the four questions first. The evaluation gets much easier afterwards, and considerably shorter.