How to evaluate reasonable adjustments software

Why this purchase is different from most HR tools

Most HR software is judged on convenience. Reasonable adjustments software is judged on whether the record it produces would survive scrutiny. The records it holds may one day be read by a solicitor, an employment tribunal, or a regulator, and the difference between a defensible process and an indefensible one is usually the quality of the record, not the intention behind it.

That changes what matters in an evaluation. A form builder with a new label can collect requests. A system of record has to show who asked for what, when, what was decided, why, and what happened next. The sections below cover the five areas that separate the two.

1. Audit trail quality

This is the core of the product, so test it hardest. Ask the vendor to show you the full history of a single adjustment, from first request to final outcome, and check what the system captured without anyone having to remember to write it down.

• Timestamps applied by the system, not typed in by users.
• The original request as the employee wrote it, unedited.
• Every decision recorded with who made it and the reason given, including refusals and alternatives offered.
• A record that cannot be silently edited after the fact. Look for versioning or an append-only history.

A refusal with no documented reasoning is weak by default. If the system does not force a reason to be recorded when a request is declined, the audit trail has a hole exactly where you will need it most.

2. Data residency and security

Adjustment records routinely contain health information, which is special category data under UK GDPR. That raises the bar on where the data lives and who can see it.

• Ask where data is hosted. UK or EU residency keeps you inside the UK GDPR adequacy framework without extra transfer mechanisms.
• Ask about role-based access. An employee's record should be visible only to the people they have shared it with, with HR seeing anonymised aggregates rather than individual detail by default.
• Ask about authentication. Two-factor authentication should be standard, not an enterprise add-on.

The Information Commissioner's Office publishes guidance on handling special category data. If a vendor cannot explain their lawful basis and safeguards in plain English, treat that as an answer in itself.

3. The three-persona workflow

An adjustments process has three distinct users with three distinct jobs, and software built for only one of them fails the other two.

• Employees need a structured, private way to describe what they need, ideally with guided templates so they are not left staring at a blank text box.
• Managers need to respond, agree actions or propose alternatives, and see clear guidance on what is expected of them.
• HR needs the whole picture: request volumes, decision patterns and overdue actions, without being pulled into every individual conversation.

In a demo, ask to see the same request from all three perspectives. If the manager view is an email notification and the HR view is a spreadsheet export, the workflow is one persona wide.

4. Review cycles

Adjustments are not one-off decisions. Roles change, teams change, conditions change, and an adjustment agreed in January can quietly stop working by June. The Equality Act duty is ongoing, so the record needs to be ongoing too.

• Can a review date be set when an adjustment is agreed, with reminders that actually fire?
• Does the record follow the employee through a manager or team change, so they do not have to explain everything again?
• Can an adjustment be marked as no longer working, and does that trigger a follow-up rather than a dead end?

5. Reporting

Reporting is where an adjustments system earns its budget line. The useful questions are organisational: how long do requests take, how often are they declined and for what reasons, and where are agreed actions stalling.

Check that reporting is anonymised by design. HR needs patterns, not a browsable list of individual health disclosures. Check too that reports can be produced on demand, because the moment you need one is rarely a moment you planned for.

Ask what the software actually knows about adjustments

A generic case-management tool can route tickets, but it cannot help a manager who does not know what a reasonable response looks like. Ask what domain knowledge is built in. TryMosaic, for example, is built on a taxonomy of 177 adjustments across 18 categories, co-designed with an occupational therapist, so requests and suggestions start from a structured evidence base rather than a blank field.

Whatever vendor you assess, apply the same test: does the product understand adjustments, or is it a workflow engine wearing the vocabulary?

Questions to put to any vendor

• Show me the complete history of one adjustment, including a refusal.
• Where is our data hosted, and who inside your company can access it?
• What does the employee see, what does their manager see, and what does HR see?
• What happens when an agreed action is overdue?
• How does an employee's record survive a manager change?
• What can I export if we ever leave?

This guide is general guidance on evaluating software, not legal advice. For advice on your organisation's specific duties under the Equality Act 2010, speak to a qualified adviser.