Questions to ask a recruitment software vendor

Most agency owners go into a software demo with a list of features and come out with a quote. The features all work, because the person driving has done that route four hundred times and knows which corners to avoid. Nothing in that hour tells you what the product will be like in eighteen months, which is the only thing you are actually buying.

The questions below are the ones that survive contact with a salesperson. Each has an answer that can be checked, either in the room or in the week afterwards, and each of them separates a vendor who is still building from one who is collecting rent on something finished years ago. Ask them of every vendor on your list, including us.

What is the first question to ask a recruitment software vendor?

Ask which parts of the product they built themselves and which parts they resell from somebody else. A modern recruitment CRM is not one piece of software. It is a record system with a phone system, a video tool, an e-signature service, sourcing, campaigns, candidate and client portals, and usually a desktop or mobile app hanging off it. Some of those a vendor wrote. The rest are other companies' products with the vendor's logo on the invoice.

This matters for three practical reasons. A resold component is priced by the company that owns it, so your renewal is partly out of your vendor's hands. It is supported by that company too, which is why a call quality problem turns into two support queues and a fortnight of being told it is the other side. And when the commercial relationship between the two companies ends, which happens more often than anyone advertises, the feature leaves your product on a timetable nobody consulted you about.

Our phone system, video and narration, e-signature, sourcing, campaigns, portals, and the desktop and mobile apps are built by us rather than resold. I raise that here not to win the point but because it is the answer you should be testing every vendor against, ours included, and it takes one question to get.

How can you tell whether the product is still being built?

Ask for the changelog, dated, in public, and read the last three months of it. A roadmap is a list of intentions and costs a vendor nothing to write. A changelog is a record of what actually shipped, with dates on it, and it is very hard to fake for long.

Read it for two things. The first is rhythm, which is whether entries appear steadily or in a burst before a funding announcement and then nothing for a quarter. The second is the boring items, the menu that now closes properly and the list that stops losing your selection when more rows load. Those are the repairs nobody buys software for and every consultant feels twice a day, and a product that fixes them is a product somebody is still looking after.

If a vendor has no public changelog, ask why. The honest answer is usually that releases are infrequent enough that publishing them would be embarrassing. We ship every week and publish a dated public changelog, so this is a check you can run on us this afternoon without asking permission.

What should you ask about the AI in a recruitment CRM?

Ask what it does when it is not sure. Every product on your shortlist now has AI in it, and the demos all look the same because they are all built on the same handful of models. The difference between them is entirely in what happens at the edges, and the edges are where your data lives.

A language model will always produce an answer. Hand it an email signed with a first name that matches two of your consultants and it will pick one, confidently, and write that to the record. The resulting entry looks exactly like a correct entry. There is no mark on it saying this one was a guess, which means a year later you have a database that nobody in the building fully trusts and no way to tell the good rows from the invented ones.

So do not accept the tidy demo case. Bring a genuinely ambiguous one, an email or a CV with something missing or contradictory in it, and watch. Software that writes an answer anyway has told you what it will do with several thousand of your messages a month. Ours reports how sure it is and hands the low-confidence cases back to a recruiter, which is the behaviour I would be looking for from anyone.

What should you ask about getting your data out?

Ask them to run an export while you are watching, and ask what it contains. Every vendor will tell you the data is yours. The question is whether you can retrieve it without their cooperation, how long it takes, and whether what comes out is your business or just a list of names.

Candidate and client records usually export cleanly. The parts that go missing are the ones that took you years to accumulate: CV files and attachments, the notes and call logs on each record, the history of who moved through which pipeline and when, custom fields, and the email threads. A migration that arrives without those is a fresh start wearing your contacts as a costume. Ask specifically about each category, and ask for a sample file rather than a description.

Which costs do not appear on the quote?

Ask for the total cost of year one, not the monthly licence, and make them itemise it. The per-seat price is the part of the bill that is easy to compare, which is why it is the part that gets competed down and the part vendors show you first.

The rest of year one usually contains an implementation or onboarding fee, a data migration charge, training days, and a set of per-use charges for things your consultants do every day. Text messages, call minutes, e-signature envelopes, CV database credits, job board postings and email volume are all commonly metered. Ask for the unit price of each, then multiply by what your team actually did last month, which your current system can tell you.

How do you test a vendor's support before you sign?

Send a real support question during the trial, from a normal email address, and time the reply. Every vendor's sales engineer answers in minutes. That person is not who you will be dealing with in March.

Ask a question with a genuine answer required, not a tour request, and see what comes back. What you are measuring is whether a person read it, whether they understood the recruitment problem behind it rather than the button you mentioned, and how many replies it takes to reach something useful. Also worth asking outright: who fixes a bug, how you are told it is fixed, and whether that ever shows up in the changelog you read earlier.

What does a good answer sound like

Ask this	A straight answer	A warning sign
Which of these did you build	Names each component and who owns it	Describes the integration rather than the owner
Show me the changelog	Sends a public dated link, unprompted	Offers the roadmap instead
What does the AI do when unsure	Shows a confidence score and a handback to a person	Explains which model it uses
Export my data now	Runs it live, shows notes and files in the output	Says it can be arranged by the support team
Total for year one	Itemised, with every metered unit priced	A per-seat figure and a promise of flexibility
Who answers support in March	Names the team and the route to an engineer	Points at a help centre

What to do with the answers

Write the answers down in the room, because six weeks later every demo blurs into the others and you will be choosing on a feeling about a person. Six questions, a few minutes each, and the differences between your shortlist stop being about features and start being about whether the company behind each one is still doing the work.

My own view, from sitting with agencies through a lot of these decisions, is that the changelog question predicts more than the other five put together. Products do not become unusable in one bad release. They become unusable through two years of small breakages that nobody was paid to fix, and the changelog is the only place that shows up before you have signed.

---

Anshika leads Customer Success at Recruitly.