Choosing HR Software Before You Have a Shortlist

TL;DR

• The core decision: whether you write requirements before seeing products, because the order determines who is steering the choice.
• When doing nothing is right: when the friction is a process nobody owns rather than a capability nothing provides.
• What has to be true: somebody can state, in writing, what must be possible after the purchase that isn't possible now.
• How the options split: by where the shortlist came from, which predicts the outcome better than any feature comparison.
• Decision rule: if you can't describe the problem without naming a product, you're not ready to look at products.
• Outcome to expect: a shorter shortlist, chosen for stated reasons you can defend in a year.

Three Links in Your Inbox

You get asked to look at HR software on a Tuesday. By Thursday you have three links: one from somebody senior who saw a demo, one from a colleague whose friend uses it, one from a vendor who has been emailing for months and finally got a reply.

Nobody has written down what the software is supposed to do. But the shortlist exists now, and from this point everything that happens is a comparison between those three, plus maybe one more added for balance.

This is how most HR software gets chosen, and the order is the problem. A demo is not a neutral information source. It's a designed experience, built by people who are extremely good at building it, showing a product working on data prepared to make it work. Watching three of them without written requirements produces a preference, and a preference feels exactly like a decision from the inside.

Recommended Tools

Best tools for HRIS Software

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

What makes this hard to resist is that requirements-gathering looks like the boring part and demos look like progress. Booking a demo feels like moving. Writing down what must be true feels like delay, especially when somebody senior has already named a product and is asking why this is taking so long.

So the reframe worth holding onto: the selection work is almost entirely the work of writing down what has to be true afterwards. The shortlist is a consequence of that, not the start of it. Get the order right and the demos become useful, because you finally have something to test them against other than how impressive they felt.

When You Genuinely Do Not Need to Act Yet

Your current setup is genuinely fine. Things get done, nobody has lost anything important, and the complaints you hear are about volume of work rather than about capability. Software does not reduce volume by itself. If nobody can name something that's impossible today and would be possible after, there's no requirement yet.

Friction is starting to show. A task keeps getting missed, one person is the only route for something, or a manager asked for information you couldn't produce. These are worth writing down and they're frequently process problems rather than capability gaps. Try fixing them in place first, because the answer tells you what you actually need.

It has become a real cost. Somebody spends a recurring, measurable part of each month on work a system would absorb, or the same failure has happened three times, or growth has made an arrangement that depended on one person's memory into a genuine risk. Now there's a case, and it's a case you can write down.

The edge case that forces it. An obligation you can't currently satisfy: evidencing something about employee records, handling personal data in a way your current arrangement doesn't support, or an audit question you couldn't answer. What's required differs sharply by jurisdiction and by sector, and several requirements have been changing. Establish what applies where you operate with local advice, and let that be the requirement rather than accepting a vendor's account of what you need.

Five Questions This Reader Asks at 11pm

How do I choose HR software? By writing down what must be true afterwards, then finding products that can do it, in that order. That sounds like a truism until you notice that almost nobody does it, because a shortlist arrives before anybody has written anything. The practical version is a page: what breaks today, what must be possible after, what must not get worse, and who has to be able to use it. Everything else is comparison shopping.

Who should be involved? Fewer people than a committee and more than one. You need whoever does the work daily, because they know what actually happens rather than what's supposed to. You need whoever will be asked for the data afterwards, usually finance. And you need one decision-maker who can say no. Large selection committees produce requirements lists where everything is mandatory, which is the same as having no requirements.

How long does this take? The requirements work is days, not weeks, if somebody just does it. What stretches is the arguing, and the arguing is the valuable part, because it surfaces disagreements about how the organisation actually runs. Demos and procurement add their own timeline. If somebody is pushing for a decision inside a fortnight, the thing being compressed is the part that prevents regret.

Do we need a formal RFP? Usually not, and the instinct to write one often comes from wanting the process to feel rigorous. A structured requirements document you send to three vendors gets you most of the benefit. A long formal document gets you long formal answers written by people who write them for a living, which is a worse signal than a conversation. Where procurement rules require one, keep the requirements sharp and the boilerplate short.

Somebody senior has already picked one. What now? Don't fight the product, supply the requirements. Write down what must be true, share it, and evaluate the named product against it honestly, including where it fits well. Frequently it does fit, and you've now got a documented reason rather than a preference. Where it doesn't, you have something specific to point at, which is a far better position than an argument about taste.

Requirements Worth Writing Down

Most requirements documents fail in one of two directions: a list of features copied from a vendor site, or a list of aspirations nobody can test. What works is narrower and more awkward to write.

The third row is the one teams skip and regret. Every system makes something better and something worse, and the thing that gets worse is usually speed for the person doing it most often. If a manager currently approves something in one tap and the new process takes a form and two screens, that's a real cost and it belongs in the comparison rather than being discovered in month two.

The last row is the cheapest insurance available here. Writing down what you're not trying to solve gives you a way to decline a feature that demos beautifully and serves a problem you don't have. Without it, scope grows in every demo, because each vendor shows something impressive and somebody in the room starts imagining it as a requirement.

A note on the sixth row. Obligations around employee data, access and records differ by jurisdiction and by sector, and vendors will tell you what their product supports rather than what you're required to do. Those aren't the same thing. Establish the requirement independently, with local advice, and bring it to the conversation as a constraint rather than a question.

Five Diagnostic Questions You Can Self-Assess Against

Can you describe the problem without naming a product? Try it out loud. If the sentence needs a brand name to make sense, you're describing a solution and you haven't found the problem yet. This single test catches most premature shortlists, and it's uncomfortable precisely because the pressure to move usually comes from somebody who has already named one.

What have you tried to fix without buying anything? If the answer is nothing, do that first. A surprising share of software requirements dissolve when somebody owns the process for a fortnight, and the ones that survive are much better specified afterwards because you now know exactly where the limit is.

Who will use this most, and have you asked them? The person who runs a process daily knows things the process documentation doesn't contain. If the requirements were written without them, expect to discover during rollout that a step everybody described as simple has three exceptions that matter.

What would make you say no to a product you liked? Decide in advance. A disqualifying condition written before the demos is worth more than any scorecard afterwards, because it's the only thing that survives being impressed. If you can't name one, you don't yet have requirements, you have preferences.

Who is signing, and do they agree with the requirements? Get this alignment before the demos rather than after. Selections stall at the end far more often than in the middle, and it's almost always because the person with the budget was evaluating against criteria nobody wrote down.

Six Ways Teams Arrive at a Shortlist, Reviewed

Somebody senior names a product

The most common starting point and the most awkward to handle. Somebody saw a demo at an event, heard it from a peer, or used it at a previous organisation. It earns its place more often than people admit: senior sponsorship unblocks budget for work that genuinely needed doing, and a product that worked well somewhere similar is a reasonable prior.

Where it falls short is that it arrives with no requirements attached and considerable momentum. Evaluating it properly can look like resistance, which makes people quietly skip the evaluation and hope. The failure shows up months later as a series of small mismatches that nobody attributes to the decision.

Use the sponsorship, supply the requirements yourself, and evaluate the named product honestly and first. If it fits, you've lost nothing and gained a documented reason.

There's a version of this that goes badly and it's worth recognising early. If the sponsor treats the evaluation as a formality and reacts to any finding as obstruction, the exercise has become theatre, and continuing it wastes everybody's time while creating a paper trail that implies a rigour nobody applied. Better to say plainly that the decision appears to be made, ask what would change it, and spend the effort on implementation instead.

A peer recommendation

Somebody in a similar role says theirs works well. It earns its place because it's the only source here with real operating experience behind it, and because peers will tell you about the annoyances a vendor won't mention.

Where it falls short is that the recommendation carries their context and not yours. Organisations that look alike from outside differ in the ways that determine fit: how many people need access, how much of the process runs through managers, what the reporting expectations are. A recommendation is most useful for the specific complaint attached to it, which is the part people remember to mention.

Ask them what they'd change and what they were surprised by. Those two answers are worth more than the recommendation.

Be careful about when they implemented, too. Somebody who went live several years ago is describing a product that has changed, a contract negotiated in different conditions, and an implementation team that may no longer exist in the same form. Their operating experience is still the most valuable input available; their account of what buying it is like now is out of date in ways neither of you can easily see.

An analyst grid or comparison site

A ranked view of the market from somebody who covers it. It earns its place for discovery, which is a real problem: you cannot evaluate a product you've never heard of, and these sources are how most teams find the third and fourth candidate.

Where it falls short is that the ranking is built against generalised criteria that aren't yours, and the economics behind some comparison content are not always visible to the reader. A product positioned well for a market is not necessarily positioned well for you, and the ranking will not tell you which is which.

Use them to build a longlist and then ignore the order. The ranking is somebody else's weighting of requirements you haven't written yet.

One signal within them is genuinely useful regardless of the ranking, which is the segmentation. Where a source consistently places a product with a particular size or type of organisation, that reflects an accumulated pattern of who ends up happy, and it's a better guide than the score. A product repeatedly described as suiting large complex operations will be heavy for a small team no matter how well it ranks overall.

An incumbent vendor upselling a module

Whoever already supplies something adjacent offers to cover this too. It earns its place on genuine advantages: one contract, one support relationship, and data that's already in the right place, which removes an integration you'd otherwise build and maintain.

Where it falls short is that adjacency is not capability. A module built to extend a product's reach is frequently thinner than a product built for the job, and the convenience is felt by whoever manages vendors while the thinness is felt daily by whoever uses it. There's also a quiet lock-in effect: each added module makes leaving harder, which is worth being deliberate about rather than drifting into.

Evaluate the module against the same requirements as anything else. If it wins, the convenience is a genuine bonus.

One question worth asking the incumbent directly: how many customers use this module compared with the product you already have. A module with a small installed base is a product in an early stage wearing a familiar name, and the roadmap promises attached to it deserve the same scepticism you'd apply to any young product. The existing relationship tells you about their support, not about this software.

A formal requirements exercise

Writing down what's needed, then going to market against it. It earns its place because it's the only approach here where the criteria exist before the persuasion starts, which is the whole argument of this piece.

Where it falls short is over-formalisation. A long document with weighted scoring feels rigorous and frequently produces a worse decision, because weights get assigned to make the arithmetic come out somewhere, and everything becomes mandatory when a committee writes it. It also takes longer, which matters when the current arrangement is actively hurting.

Keep it to a page or two, keep the must-haves genuinely few, and write down what you're not solving.

The discipline that makes short requirements work is ranking rather than listing. Force the group to put the must-haves in order, because the ordering conversation is where you discover that two people meant different things by the same line, and because a ranked list still guides a decision when every candidate fails something. An unranked list of equally essential items provides no guidance at exactly the moment you need it.

Starting from the problem and working outward

Describing what breaks, trying to fix it without buying, and letting the residue define the requirement. It earns its place because it's the only route that reliably tells you whether you need software at all, and it produces the sharpest requirements when you do.

Where it falls short is patience and politics. It's slower, and it can read as inaction to somebody who has already decided. It also requires somebody to actually own the process improvement attempt, which is real work that competes with everything else.

Do a compressed version: two weeks of somebody genuinely owning the problem. Whatever survives that is a requirement worth paying for.

Write down what you tried and what happened, even briefly. It becomes the most persuasive part of the business case later, because it demonstrates the problem is structural rather than a matter of effort, and it pre-empts the question every budget holder asks about whether this could be solved without spending anything.

The Decision Table

The last row deserves more attention than it gets. Renewal dates create artificial urgency that reliably compresses the requirements work rather than the demo schedule, because demos feel like progress. A short extension is usually available for the asking, and vendors know that a compressed evaluation favours whoever is already in the building.

The second row is where a lot of selections shouldn't have started. A task missed repeatedly is a signal, and it points at ownership at least as often as at capability. Two weeks of somebody actually owning it will tell you which, and that's a cheap experiment compared with a purchase.

What a Demo Cannot Tell You

A demo shows a product working. It's genuinely useful for that, and it's close to useless for the things that determine whether you'll be happy in a year.

What it's like on your data. Demo environments are populated to make flows look clean. Your data has people with two positions, a contract type nobody could categorise, three start dates for the same person because they left and came back. Ask for a trial with a sample of your actual records, including the awkward ones.

What the daily user experiences. Demos are run by experts who know exactly where to click, on the happy path, without interruption. The relevant experience is a manager who opens this twice a month, has forgotten where everything is, and has four minutes. Put that person in the room and let them try it unaided.

What configuration costs afterwards. Almost everything is configurable in a demo. The question is who configures it, how long a change takes, and whether it needs the vendor. Ask them to make a specific change live on the call, not to describe that it's possible.

What breaks at the edges. Every product has a set of assumptions about how organisations work. The mismatches show up in the exceptions: the person who reports to two managers, the position that spans departments, the contract that doesn't fit the available types. Bring your three strangest real cases and ask them to model each one.

Watch how they react to the request rather than only the result. A vendor who has seen these cases before will name the trade-off immediately and tell you which of the three options is least bad. One who insists all three are straightforward has either not understood the case or is managing the room, and both are useful to know before you sign anything.

What support is actually like. Everybody says support is excellent. The useful questions are specific: what's included at this price, what the route is when something breaks, and whether you get a named contact or a queue. Ask a current customer if you can.

What it will cost to leave. Rarely discussed and worth knowing at the start. Can you export the record, including history, in a form another system could take? A product that makes leaving hard is making a bet about your future negotiating position.

The same question has a second use. A vendor who answers it easily and specifically is telling you something about how they expect the relationship to go, and a vendor who becomes vague is telling you something too. Neither answer is a reason to rule anybody out on its own, and both are worth writing down next to the price.

Where Selections Go Wrong

The second row is the most common mechanical failure. A committee writes requirements, every contributor marks their item as essential, and you end up with a list where nothing can be traded. Scoring against it produces near-identical totals, at which point the decision reverts to whoever was most impressive, which is exactly what the process was meant to prevent.

The fourth row explains a lot of failed rollouts. Something always gets slower, usually for managers, and a team that hasn't stated that trade in advance experiences the complaints as a surprise and treats them as resistance. Naming it beforehand converts the same complaints into an expected cost people were warned about.

What to Put in Writing

The fifth row is small and does the most work. One written condition that would rule a product out, agreed before anybody has been impressed, is the only mechanism that reliably survives a good demo. It doesn't need to be dramatic. It needs to be specific enough that you'd notice it being violated.

Questions to Ask Before You Commit

On the problem. Can you describe it without a brand name? A bad answer needs one.

On trying. What did you attempt without buying? A bad answer is nothing.

On users. Did you ask whoever does this daily? A bad answer is that HR knows.

On trade-offs. What gets worse? A bad answer is nothing.

On limits. What would rule a product out? A bad answer is that it depends.

On obligations. Where did the compliance requirement come from? A bad answer is a vendor.

What Getting This Wrong Costs

The first cost is the one nobody records: the capability you bought and never used. A purchase made without requirements tends toward the product that demonstrated most breadth, because breadth is impressive in a demo. The modules get configured during implementation, then quietly go unused because nobody had a problem they solved. It shows up at renewal, when somebody in finance asks what you're paying for.

The second cost is adoption, which is where most of the real damage happens. A system chosen without the daily users, and without stating what would get slower, meets exactly the resistance you'd predict. Managers find a way around it, data gets partial, and the reporting built on it describes a process nobody is really following. That's worse than the spreadsheet you replaced, because it looks authoritative.

The third cost is the years. HR systems are sticky in a way that makes a mediocre choice expensive well beyond its price. Data accumulates, processes get built around it, people learn it, and the cost of moving grows every quarter. A decision made in three weeks on a compressed timeline can shape how the function works for the better part of a decade.

So before booking anything, get one page written: what breaks, what must be possible after, what must not get worse, what you're not solving, and one condition that rules a product out. If that page is hard to write, that difficulty is the finding. It means the problem isn't understood yet, and no demo will clarify it.

When You Are Ready to Go Further

None of this needs a procurement process to start. It needs one page, written by somebody who has spoken to whoever does the work daily, agreed with whoever signs, before any product is seen.

The step after that is to make the demos work for you rather than at you. Send the requirements ahead, ask each vendor to demonstrate your three strangest real cases rather than their prepared flow, and have the person who'll actually use it twice a month drive for ten minutes unaided. Vendors who can do this comfortably are showing you something a scripted demo cannot.

Then, before signing, ask the question almost nobody asks: how do we get our data out, with its history, in a form something else could read. The answer tells you what kind of relationship this is going to be.

HROpsLab publishes independent comparison work across HR tooling, applicant tracking and payroll. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is looking at what your current tooling actually supports here, our comparison work is one place to start.

Frequently Asked Questions

If you can't describe the problem without naming a product, you're not choosing yet. You're shopping.