What to look for on a recruitment CRM demo
A demo is a guided tour of the parts that are finished, given by the person who knows them best. Here is how to turn one into an actual test, what to insist on doing yourself, and the handful of questions that reveal more than the hour before them.
Ask AI about this
Buying a CRM is one of the few decisions an agency owner makes that everybody in the building lives with every day for years. The evidence usually gathered before making it is three sales calls and a feature comparison somebody built in a spreadsheet. The sales calls are the strongest evidence available and they are wasted, because they are run by the vendor.
The fix is not to be adversarial. It is to change what the hour is for. A demo run by the vendor tells you what the product can do at its best. A demo run by you tells you what it will be like on a Tuesday, and that is the thing you are actually buying.
Take the keyboard and drive it yourself
The most useful thing you can do on a demo is ask to drive, because everything else follows from it. A salesperson has performed their route four hundred times and will glide through screens that a new consultant would stop dead in front of. Watching that tells you the product has the feature. It tells you nothing about whether your people can find it.
Ask early, before the tour starts, so it does not read as a challenge halfway through. Then do five ordinary things without being told where to click: find a candidate, log a call on them, send their CV to a client, book an interview, and move them to the next stage. Time yourself roughly and notice where you got stuck.
Bring somebody who will use it. Owners and operations managers judge software on what it reports. Consultants judge it on what it costs them per hour, and they are the ones who will either use it or quietly build a spreadsheet beside it. A consultant who spends twenty minutes driving will tell you more afterwards than the whole hour of slides.
Bring your own data, especially the ugly data
Demo data is always clean, and clean data is where every product looks the same. Bring three things with you: the worst formatted CV in your inbox, a job specification a client actually sent you, and an email reply that is genuinely ambiguous about what the person meant.
The CV tests parsing under real conditions. Two columns, a photo, a table of dates, an employer name tucked into a footer. Watch which fields come back filled, and then watch the fields it could not read, because the interesting behaviour is there. A product that leaves them empty is telling you the truth. A product that fills them with something plausible is showing you exactly what it will do to two thousand records a year.
The ambiguous email does the same job for the AI features. Something with a first name that could be two of your people, or a reply that half accepts and half asks a question. Ask what the software does with it and where it puts the result. The answer you want involves a confidence score and a person. Ours reports how sure it is and hands anything below three quarters back to a recruiter, and I would make every vendor on your list answer the same question in the same words.
Ask what is theirs and what is resold
Ask which parts of the product the vendor's own engineers build and which are somebody else's, then ask what happens to the second list if that relationship ends. The first answer comes easily and the second one is where you learn something.
It matters because resold components behave like separate products wearing a matching logo. Support goes through two companies and takes twice as long. The feature you need sits on somebody else's roadmap. Pricing moves when a third party changes theirs. And the integration between the two sides is a promise that holds until one of them changes something, at which point it usually fails quietly rather than loudly.
The phone system, video recording and narration, e-signature, sourcing, campaigns, the candidate and client portals, and the desktop and mobile apps are built by us rather than resold. That is a checkable claim, and the point of telling you is that you should require the same list from everyone you are talking to and compare them side by side.
Ask to see the changelog, not the roadmap
A roadmap is a list of things that would be good to have and a changelog is a record of what was actually done, so ask for the second one. Ask whether it is public, whether it is dated, and read the last three months of it rather than the highlights.
What you are looking for is rhythm and content. Rhythm tells you whether anybody is still working on the product, and a gap of several months in a market moving this quickly is the answer to a question you were going to ask later. Content tells you what kind of work gets done. A changelog full of small corrections, menus that behave, lists that keep your place, forms that carry details across, is a product being maintained by people who use it. A changelog that is entirely large feature announcements is a product being sold.
We ship every week and publish a dated public changelog, which I mention only because it is the specific thing I would ask every vendor for. If they do not have one, ask why, and treat a private spreadsheet produced on request as a different answer from a page anyone can read.
| Ask for | What you learn | The answer to worry about |
|---|---|---|
| The keyboard | Whether a new consultant can find things unaided | A reason why it is easier if they drive |
| Your worst CV parsed | How the product behaves on real documents | Every field filled, including the unreadable ones |
| An ambiguous email handled | Whether the AI is allowed to be unsure | A confident answer with nothing marking it as a guess |
| The list of what they build | How many suppliers you are really taking on | Hesitation, or a partner named for a core feature |
| The public changelog | Whether the product is maintained or parked | No changelog, or one that is months old |
| A named migration plan | How your history gets across | "Our team will handle it" with no detail |
| Support, and who answers | What happens on the bad day | A queue with no route to anyone technical |
Ask what happens after you sign
The demo is about the product and most of the risk is in the six weeks after you buy it, so spend part of the hour there. Migration, training, support and what it costs to leave are the four subjects, and all four have concrete answers that a vendor either has ready or does not.
On migration, ask specifically what comes across: candidates, contacts, companies and jobs are the easy part, and the hard part is the history. Notes, emails, call logs, CV files, pipeline stages, the dates things happened. An agency that arrives at a new CRM with records but no history has lost the thing that made those records valuable. Ask who does the work, how long it takes, and what is expected of your team.
On support, ask who actually replies and how quickly, and ask what happens when the problem is a real fault rather than a question. On leaving, ask how you get your data out, in what format, and whether that includes the documents rather than just the rows. Nobody enjoys asking that in a sales meeting, and a vendor confident in their product answers it without flinching.
Run the same test on every vendor, including us
Give every vendor the same CV, the same job specification, the same ambiguous email and the same list of questions, because a demo is only evidence when it is comparable. Three tours of three different products tell you which salesperson you liked. Three runs of the same test tell you which software you should buy.
Write down what you saw the same day, before the follow up emails arrive and rearrange your memory. A short note per vendor on the five things you drove, what happened to the unreadable fields, and how the changelog looked will be worth more in a fortnight than any of the material they send you.
My own opinion is that most agencies buy on the demo and regret it on the maintenance. The features shown in an hour are broadly similar across the serious products in this market, and what actually differs is whether anyone is still tidying the thing up, whether the software admits when it does not know, and how many separate companies you have quietly signed up to. Those three are all checkable in an afternoon, and almost nobody checks them.
Siva is an engineer at Recruitly.
