Choose software based on the steps it must actually run
A selection grid to compare review software on a real scenario: population, templates, PDFs, access rights, tracking, costs and support.
Write down the problem before the feature list
Describe what is blocking you (hard-to-find forms, managers with wrong reporting lines, ambiguous tracking, training needs with no follow-up), with the person affected and the consequence.
Then rank the requirements: essential, useful, to review later.
Have every vendor work through the same scenario
With a blank template, a fictitious org chart and the situations below, follow a campaign through to the sign-off of a report and the review of a training need.
A checklist you can use during the demo
-
Employees
- Situation to show
- Employee who is absent or in several groups
- What to record
- Checks, corrections and who keeps data up to date
-
Form
- Situation to show
- Shared section and job variant
- What to record
- Configuration needed and version upkeep
-
Supervision
- Situation to show
- A change of manager
- What to record
- Access scope and handover of expected steps
-
PDF history
- Situation to show
- Scanned report with an ambiguous field
- What to record
- Reconstruction, proofreading and human validation
-
Monitoring
- Situation to show
- Prepared, validated and incomplete records
- What to record
- Status definitions and consistency of exports
-
Training
- Situation to show
- Need with several decision-makers
- What to record
- Origin, process, decision and scheduling kept distinct
-
AI
- Situation to show
- Inaccurate or unavailable suggestion
- What to record
- Status of the output, correction and human review
-
Data
- Situation to show
- User outside the scope, departure
- What to record
- Access, archiving, retention and data return
Assess AI by its use, not its label
Fluent text can be wrong or unsuitable. With your DPO, examine purpose, roles, service providers and the applicable regime: a “Human validation” label is neither enough to attest compliance nor to rule out a high-risk use.
During the demo, ask these questions:
Compare the full cost on an identical scope
Compare quotes on an identical scope (headcount, modules, support), specifying units, amounts excluding tax, billing frequency and commitment. Add internal work: data, templates, pilot managers, administration.
An existing license or a per-user price does not, on its own, describe the cost of the project.
Keep a record of what was shown
After the demo, classify each requirement: shown, to configure, service to be quoted, or availability not confirmed. A feature announced for later does not count at launch.
Have the conclusion (possible start, points to check, owners) reviewed by HR, a pilot manager and the data or HRIS owner.
The steps
-
Step 1: Define requirements
Link each expectation to a problem, a person, a step.
-
Step 2: Compare demos
Same template, same fictitious situations for all.
-
Step 3: Review cost and data
Check the full quote, access, retention and data flows.
-
Step 4: Decide on confirmed facts
Separate what is shown, to configure or to validate.
Your checklist
Sources and references
To read the original texts and dig deeper at the source.
Helpful answers
Your questions, simply answered.
Pointers to assess your project and prepare the right questions.
All questionsShould we require every feature from the start?
No. Identify the steps essential to the first launch and their dependencies; the rest can wait, with its own scope and cost.
How do we compare AI promises?
Ask for an example output, where it comes from, a correction and an unavailability case, then check the purpose and the data protection documents.
What should we keep after a demo?
A grid: what was shown, conditions, limits and points to confirm, matched against the quote and contractual commitments.
