Before You Book the Demo, Do the Readiness Work
The 2026 SHRM National Conference in Orlando had no shortage of sparkle when I attended last week.
I stayed at Universal’s Cabana Bay resort, which felt delightfully retro in a very Mad Men meets I Dream of Jeannie kind of way. The keynotes were fantastic and included Simon Sinek and Oprah Winfrey. Christina Aguilera performed a high-energy concert with dancers, her major hits, and the kind of production value that makes you briefly wonder whether your conference badge has transported you into a music video.
SHRM also bought out Disney’s Hollywood Studios one night for attendees, which was both very fun and a reminder that even with a great experience, logistics still matter. When 20,000+ people are all trying to do the same thing, the design underneath the experience becomes very visible.
My view from the SHRM volunteer leader section at the front of the general session area at the start of the 2026 SHRM National Conference.
And somewhere between the keynotes, the many AI-heavy session titles, and the exhibit hall floor energy, I found myself thinking about a quieter question:
What needs to happen before anyone books a software demo?
The exhibit hall itself was a good reminder of why that question matters. At a conference this size, the software choices feel endless. Huge booths, polished messaging, friendly sales teams, clever giveaways, beautiful screens, and plenty of promises about making work easier. None of that is bad. In fact, a lot of those vendors have genuinely useful products.
But when the marketplace is that crowded and well-produced, it becomes even more important to know what you are looking for before you start looking. Otherwise, the loudest or shiniest option can start to feel like the best option, even when it is simply the best-presented option.
That idea came into sharper focus during a SHRM-facilitated session I attended called “SHRM Tech: A Peer Data-Driven Approach to HR Technology Evaluation and Selection.” The session walked through SHRM’s framework for HR technology selection, which includes several practical stages:
initial assessment,
assessing organizational needs,
defining project parameters,
identifying available packages,
selecting a project committee,
optional RFPs,
demonstrations and evaluation, and
choosing between finalists.
Those later steps matter, of course. But the steps that felt most important to me were earlier in the process: the initial assessment and the work of understanding organizational needs.
In my experience, that is where small and mid-sized organizations often rush through the details.
Not because they are careless. Usually, it’s the opposite. They’re overwhelmed, understaffed, and trying very hard to make a good decision with limited time or capacity, and a tool or workflow that is already causing pain. By the time the search for new software begins, people may already be tired of the workaround, the spreadsheet, the manual handoff, the “just ask Karen because she knows where that lives” system of institutional memory.
So the team starts looking at technology vendors, and they book demos. They may also ask peers what tools they use.
Next, they probably watch polished vendor walkthroughs with clean dashboards, tidy workflows, and fictional employees who always complete their tasks on time.
And somewhere in that process, the demo quietly becomes the discovery process. That’s where things can get dicey.
A demo should not be where an organization discovers what it needs. It should be where the organization tests whether a vendor can meet the needs that it has already clarified.
The demo is not the decision
During that SHRM concurrent session, we were asked to sit by organization size. I grew to appreciate that detail more than I initially expected.
Here’s why: The broad steps of technology selection may apply across many types of organizations, but the way those steps play out should look different depending on the size, complexity, capacity, and culture of the organization. A large enterprise may have a procurement team, IT governance process, formal implementation office, and multiple layers of approval. A small nonprofit or mid-sized consulting firm may have an HR leader, an operations person, a finance partner, and one very tired department-of-one trying to keep the process moving between other priorities.
That’s the same category of decision, but in very different realities.
In that SHRM-led concurrent session, I sat near and spoke with another consultant who does fractional CHRO work in New York City and is often involved in HR software selection for nonprofit clients. We found ourselves nodding at the same pattern: many small and mid-sized organizations engage vendors before they have done enough work to define their true business requirements.
When that happens, the software vendor ends up leading the conversation.
That isn’t necessarily because the vendor is doing anything wrong. After all, a good vendor wants to show what their product can do, and their demo is designed to highlight strengths, new features, differentiators, and the parts of the product that look especially impressive on screen.
The problem is that without clear requirements specific to your organization, everything starts to look potentially useful.
A feature that wasn’t on anyone’s radar suddenly feels exciting.
A dashboard looks beautiful, even if no one has clarified who will use it or what decision it will support.
An automation sounds efficient, even if the underlying workflow is still unclear.
An AI feature gets everyone’s attention, even if the team hasn’t yet defined where human review, judgment, capability, or accountability belongs.
This is how organizations end up buying software that is technically capable…but practically misaligned.
The tool may be good — even excellent. It just may not be the right fit for the actual work, team, or change the organization is ready to make.
Clarify the need before you compare the tools
Before an organization starts booking demos, there are some less glamorous questions worth asking.
What problem are we really hoping to solve?
Which current workflows are broken, redundant, unclear, or too dependent on one person or department?
Where are we losing time, trust, visibility, or data integrity?
What do we need a system to do now, and what do we need it to support as the organization scales?
Who needs to be involved in this decision, and who has final approval rights?
What are our true requirements, and what would simply be “icing on the cake”?
Do we truly have the internal capacity to evaluate, select, implement, and support this tool well?
Would outside support help us make a better decision before we get too far into the selection process?
These questions aren’t as fun as watching a polished product walkthrough. They also don’t necessarily come with ready-made animations or a friendly sales engineer clicking through a beautifully configured test environment.
But they are the questions that make a demo useful. Without them, the organization is vulnerable to choosing based on what looks good instead of what solves the right problem.
This software selection strategy applies far beyond HR technology, of course. The same pattern shows up with CRMs, project management tools, marketing automation platforms, and plenty of other operational software decisions.
Consider this common scenario: A team feels the pain of the current state. Someone says, “We need a better system.” They may be right. But “better” needs definition.
Better for whom?
Better at what?
Better compared to which current pain?
Better in a way the team can realistically adopt?
A new tool will not automatically create clarity the organization has not yet built. In fact, technology often amplifies whatever clarity or confusion already exists. I’ve written before about why teams may need to fix the operational clarity around their tools before adding another one.
If decision rights are murky before implementation, they will likely be murky inside the new system. If workflows are inconsistent now, the software may simply give the inconsistency a more expensive place to live. If no one has agreed on what information matters, a reporting dashboard will not magically create shared meaning.
I say this with affection for software. I love good tools and clean workflows, and I really love a system that reduces manual effort. But the tool is only part of the system.
The people, process, communication, ownership, and adoption plan matter just as much.
Decide what matters before you are dazzled
One of the most practical takeaways from the SHRM session was the importance of deciding evaluation criteria before vendor demos begin. That sounds obvious until you have been in a really good demo.
A strong demo can be persuasive, and it can make a feature you didn’t even think you needed feel essential simply because it’s presented well. This is why having a weighted rubric is so helpful.
However, you don’t need a complex, 14-tab spreadsheet that becomes its own special project. Just a clear, agreed-upon system to evaluate what matters most to your organization.
For example, if one of your biggest problems is messy handoffs during onboarding, that should carry more weight than a flashy analytics feature no one has capacity to use yet.
If your organization needs employee self-service, clean manager approvals, or better compliance reporting, those needs should be weighted accordingly.
On the other hand, if ease of administration matters because the system will be managed by a team of one, that should be treated as a critical requirement, not an afterthought.
Finally, if integration with your existing tools is essential, that should be defined before people fall in love with a platform that does not “play nicely” with the rest of your tech stack.
A rubric created after the demo often reflects what impressed people. A rubric created before the demo reflects what matters. That distinction can save an organization a lot of time, money, and frustration.
Right-size the selection process, too
This is also where the selection process itself should be right-sized (and where I get on my soapbox a bit).
An RFP, or request for proposal, has its place. Some organizations are required to use them because of procurement policies, government rules, funder requirements, or internal governance. In those cases, the RFP is part of the reality of the decision.
However, in my opinion, for many small and mid-sized organizations, a formal RFP can add complexity without necessarily improving the outcome.
It can also unintentionally screen out vendors that might be a very good fit. Many software providers serving the small and medium business (SMB) space already have clear pricing tiers, transparent feature lists, public product documentation, and a straightforward sales process. They may not respond to a lengthy RFP, especially if the opportunity is not large enough to justify the time required.
That doesn’t mean your organization should skip due diligence though. Quite the opposite! It means your business should choose a process that helps your team learn what you actually need to learn.
A structured discovery process can have clear requirements, targeted vendor questions, reference checks, and a well-guided demo. Sometimes bringing in someone who has been through similar selections before can help the team avoid making the process bigger, fuzzier, or more political than it needs to be.
Ask vendors to show you your reality
Once your organization has clarified its needs, the demo conversation changes for the better.
Instead of simply accepting a canned walkthrough, the team can guide the vendor toward what it actually needs to see. For example:
Show us how a new hire moves from an accepted offer to the first day of employment.
Show us how a manager approves a job change.
Show us how an employee updates information.
Show us how data moves from intake to reporting.
Show us what the administrator has to configure manually.
Show us what happens when something does not follow the ideal path.
That last one matters, because real work doesn’t always follow the expected route.
People miss deadlines. Data comes in messy. Managers forget approvals. Someone discovers that the old process involved two undocumented steps and a shared inbox that no one wants to admit is super important.
A useful demo should help the organization see how the tool handles real-life scenarios, not just the cleanest possible version of the ideal process. That requires preparation from the organizational side. Someone has to translate internal needs into vendor scenarios, know which workflows matter most, and separate the truly important questions from the “while we have you, can it also…” inquiry spiral.
That work can be done internally if the team has the time, clarity, and experience. However, when the decision is cross-functional, politically sensitive, time-consuming, or likely to shape how people work for years, it can be a game-changer to bring in outside support earlier rather than later.
The best tech decisions start before the tech conversation
By the time a company has watched a few demos, people often already have opinions. That’s human nature, as we like what looks easy, polished, and possible.
I believe the best technology decisions usually begin before the shiny part…with slower, quieter questions about the work. This is part of the invisible work that makes change stick, especially in small and mid-sized organizations where capacity is tight.
What’s unclear?
What’s too manual?
What’s creating rework?
Where are people frustrated?
What information do leaders need but cannot reliably access?
What has the current process outgrown?
What does the organization need from the system, and what does the system need from the organization?
Every tool asks something of the people who use it: cleaner data, clearer ownership, more consistent workflows, different habits, new decisions, or stronger communication. If the organization is not ready for those changes, even a good tool can unfortunately disappoint.
So before you book the demo, do the readiness work.
Clarify the why. Name the requirements. Decide who gets to provide input and who makes the decision. Separate needs from wants. Weight what matters most. Ask vendors to show you the reality of your work, not just the prettiest version of their product.
If the process already feels like a bigger project than your team can reasonably hold on top of regular work, that may be a sign to bring in someone like me to offer project-based change and strategy support before the search gets too far down the road.
The right software can absolutely make work easier, but only when the organization has done enough work to know what “easier” actually needs to mean.
Need help on your next software selection project?
Contact me at Mosaic BizOps for an exploratory conversation.
