Seven HRIS demo tests to run before you buy

Give the supplier the scenario before the meeting

Send the tests in advance and ask for a product specialist. Give the supplier time to configure the edition and connections your team would use.

Use fictional employee records. Specify your product edition, payroll destination, relevant countries and access roles. Ask which steps require paid modules or implementation work. Record those differences in the cost comparison.

Agree which tests the product must pass before the demonstration. The seven tests below are a starting protocol, not a claim that we have run them against any supplier.

1. Change pay next month without changing this month

The scenario: a manager approves a pay change today that takes effect on the first day of the next pay period. Then the effective date is corrected before payroll closes.

Ask to see: the pending value, current value, approval history, correction and downstream result. Can the operator tell which value the payroll system will receive and when?

Pass evidence: the correct current and future records, an understandable history, and a demonstrated payroll handoff. A future-dated field alone does not prove the receiving system honours it.

Walk away or rescope if: your required process depends on remembering to edit a second system manually and nobody has priced or owned that step. If a manual step is acceptable, record who performs it and how long it takes.

2. Make payroll reject an update

The scenario: submit a change with a deliberately invalid cost-centre code in the test environment.

Ask to see: how the error appears, who is notified, whether the rejected record is distinguishable from successful ones, and how a corrected record is retried.

Pass evidence: an operator can identify the exact failed change, fix the cause and confirm the receiving payroll record without creating a duplicate. Ask what happens if the connection times out after the receiving system accepted the update.

Walk away or rescope if: the demonstration ends at “the integration ran.” You still need to see that the receiving payroll record is correct. The integration checklist explains how to define the evidence.

3. Give a manager the right access—and no more

The scenario: a manager needs their team's leave requests but must not see a colleague's sensitive pay information or an employee-relations note.

Ask to see: the manager's actual account, search results, reports, export and mobile view. Move an employee between teams and check the change in access.

Pass evidence: the permitted tasks work and the restricted information is not exposed through another surface. Keep a record of role configuration and any exceptions.

Walk away or rescope if: the supplier shows an administrator's screen and describes what the manager would see. Log in as the manager and try to open the restricted information. This test is a procurement check, not a substitute for a security assessment.

4. Handle a leaver who still needs a record

The scenario: a fictional employee leaves, their ordinary access ends, and payroll or HR later needs an authorised correction or document.

Ask to see: what is disabled, what remains accessible to authorised staff, whether historical approvals survive, and how access or account status affects billing. Test downstream applications separately if offboarding is part of the purchase.

Pass evidence: the records you need remain retrievable by the right people, and access changes behave as the agreed workflow requires. Retention periods and employee access depend on jurisdiction and policy; set those requirements with the appropriate owners before testing.

Walk away or rescope if: a necessary record disappears, nobody can explain post-termination billing, or access removal exists only on the implementation slide.

5. Explain a leave balance after something changes

The scenario: an employee changes their working pattern partway through the year, then an approved leave booking is cancelled.

Ask to see: the policy used, effective dates, original calculation, adjustment and resulting balance. Use expected values independently calculated for your own policy.

Pass evidence: the operator can reconstruct the number and explain any manual adjustment. A balance that looks plausible is not evidence of correct calculation.

Walk away or rescope if: the answer is a hidden adjustment with no explanation. This checklist does not prescribe a country's statutory leave rules; it tells you to test the rules that apply to your workforce.

6. Import imperfect data without losing the exceptions

The scenario: a test file contains a duplicate worker ID, an invalid field and one valid new employee. Include a non-Latin name if your workforce needs that support.

Ask to see: accepted and rejected rows, error messages, duplicate handling and a safe retry of corrected records.

Pass evidence: the result reconciles to the input, the valid record is not silently duplicated, and the rejected records remain identifiable. Check which historical objects can actually be imported—not just the current employee profile.

Walk away or rescope if: a “successful upload” leaves the administrator searching for missing employees or recreating history by hand. Put migration responsibility and its acceptance criteria in the scope.

7. Export enough data to operate without the vendor

The scenario: an authorised administrator needs employee records, a relevant change history and selected documents for an agreed business purpose.

Ask to see: the exported files, field definitions, stable IDs, document relationships and restrictions. Open the result. Do not accept an export button as the demonstration.

Pass evidence: a person outside the product can understand the selected records and connect the files. Confirm whether the required export is self-service, chargeable, asynchronous or dependent on support.

Walk away or rescope if: the export omits material data and the only proposed answer is to keep paying for access indefinitely. Contractual and legal rights need separate review; this is a practical portability test.

Score evidence, not confidence

Seven tests produce a maximum of 14 points, but the number is deliberately secondary. If an essential permissions or payroll test fails, 12 points elsewhere do not rescue the purchase. Agree your vetoes first.

Ask your likely administrator to repeat the important steps. Record the result, not the salesperson's confidence. Treat something promised for a future release as unavailable for the decision you are making today.

A feature page is the starting point, not the acceptance test

UKG describes a connected HR, payroll, time and scheduling product; Zoho People presents core HR and workforce capabilities. Those descriptions help identify possible fit. They do not show how your configured workflow behaves when a record is wrong.

That is why this protocol asks for outputs. A smaller product that passes your important tasks can be a better purchase than a wider suite that needs more administration than you can provide. Keep the completed test results so you can compare what each product demonstrated.

Questions buyers ask