Choose an AI tool by the task your agency needs completed and the evidence you can collect in a trial. “Built for recruitment” is not enough to establish that a product handles nanny-agency records, confidential household information or your review process appropriately. A narrower tool that fits one real job may be more useful than a broad platform you cannot supervise.
This is a requirements-based buying guide, not a ranked vendor list. It proposes a small evaluation an agency can run before committing to a purchase or sharing live records. No named product, quoted price or partnership is being recommended.
Write one buying brief in ordinary language
Describe the current problem without mentioning a product. For example: “Recruiters spend time rewriting already approved status facts into candidate updates.” Specify what a successful output contains, what information it may use and which person reviews it.
Then state the boundary. A draft assistant should not quietly become a messaging service, database administrator or candidate assessor. List actions the tool must leave to people, especially sending, editing source records and communicating decisions. Ask how those actions are disabled in the proposed account configuration.
The UK government's recruitment procurement guidance recommends defining purpose, examining supplier evidence and piloting tools before deployment. It provides a useful procurement reference, not a certification of any product. DSIT: Responsible AI in Recruitment.
Compare the simplest workable approaches
Include a non-AI option in the comparison. An approved template, a better database field or a clearer assignment rule might solve the problem. You need a baseline to judge whether the AI feature adds value after review and correction.
For each approach, describe the entire task from retrieving inputs to storing the approved result. A tool that writes quickly but requires awkward copying, repeated formatting and manual cleanup may not improve the whole process. Have the person who will use it walk through those steps.
Distinguish an existing system's optional feature from a separate service. The practical questions include account ownership, record access, integration effort and what happens if the feature is switched off. Do not assume an existing supplier's new AI function has the same data arrangements as the rest of its service.
Separate must-haves from attractive extras
Use this original requirements card before booking demonstrations:
- Task: the specific output and permitted inputs.
- Review: who can inspect, edit and approve the result.
- Evidence: how the output can be checked against its sources.
- Access: which staff and records the tool can reach.
- Control: whether sending and source-record changes can be disabled.
- Recovery: how to correct an error and resume the ordinary process.
- Exit: how approved work and necessary records can be retained appropriately.
For every requirement, name the demonstration or document that would establish it. “We take privacy seriously” does not answer whether a recruiter can accidentally search restricted notes. “Human in the loop” does not explain what the reviewer sees or can override.
Put optional preferences in a separate list. A pleasing interface or impressive writing style should not compensate for a failed essential requirement. Resolve the essential conditions first, then compare convenience and cost among the remaining options.
Run the same fictional test for each option
Create a small test pack with invented people and households. Include a straightforward task, a missing fact, contradictory notes and a request outside the tool's authorized role. Keep the expected outcome beside each case so the evaluation does not depend on whether you liked the prose.
For a candidate-update assistant, the missing-fact test might omit the family decision. The acceptable result states that the decision is unknown or asks for clarification. A confident invented explanation fails, even if it sounds empathetic.
Ask the supplier to show the actual configuration being proposed, not only a prepared demonstration. Have your own staff complete the exercise and record the assistance required. Distinguish behavior you observed from a feature the salesperson says will arrive later. A roadmap promise should not count as a working capability.
Make the cost comparison about the complete workflow
Request a written quote for the intended setup, including the relevant number of users, usage assumptions, implementation work and support. Ask which costs change as use grows and what happens at a limit. Avoid comparing headline subscriptions with different included services.
Estimate staff time for setup, training, review and maintenance. Identify who will own those tasks when the person who championed the tool is away. A low subscription is not a low total cost if the process needs constant intervention.
Keep expected savings provisional until measured. Do not convert a fast demonstration into annual savings by multiplying its best result across every agency task. Your trial should include ordinary messy work and unsuccessful attempts, with the time needed to return to the existing method.
Use a fictional decision record, then set a review point
Fictional example: A two-recruiter agency compares an approved message template with two unnamed drafting tools. Tool A writes elegant messages but cannot reliably distinguish an old status from a current one in the test pack. Tool B respects the supplied status but takes longer to review than the template.
The agency keeps the template for now. It records the problem each tool failed to solve and the evidence that would justify another trial. That is a completed buying decision, even though it produces no purchase.
If a tool does meet the requirements, approve a bounded rollout with a named owner, a review date and conditions for pausing use. Save the test results and supplier answers with the decision. Recheck material changes to the product or workflow rather than treating the original evaluation as permanent approval.
The useful purchase is one your team can explain: what it does, why it passed, what it costs and how people remain responsible for its outputs.
Sources
DSIT: Responsible AI in Recruitment, checked October 27, 2026. The buying card, trial pack and unnamed-tool example are original NAJ editorial tools, not vendor testing results or legal assurance.