How we picked
Change management is the ITIL process that fails most often in practice, and it almost never fails because the software lacked a feature. It fails because the workflow was designed by someone who wanted rigor and used by people under deadline pressure, so the team invents a shadow path: implement first, raise a retroactive change ticket Monday, tick emergency. We picked tools on how well they support a process that engineers will actually follow — which means risk-tiered paths, generous use of pre-approved standard changes, and approvals that reach the approver where they work rather than in an email they'll read Thursday.
The second criterion is what happens between raising the change and implementing it. Good change tooling checks the proposed window against a calendar, warns on collisions with other scheduled work, and either pulls the affected configuration items from a CMDB or at least makes you name them. Weak tooling accepts a free-text date and a paragraph. ServiceNow is the deepest here, with change risk scoring, conflict detection, and automated approval routing driven by CI criticality. Freshservice covers the same ground at a fraction of the configuration effort, and for most mid-market IT organizations that trade is correct.
We also included two tools that most change-management lists skip. Wavity earns a spot because no-code approval chains matter more than ITIL certification for teams whose change process spans non-IT approvers — a finance sign-off, a clinical safety review. And OTRS Community Edition is here because it remains a genuinely free, self-hosted way to run an ITIL-shaped change process, which matters for public sector and academic teams with a zero-license budget and a sysadmin who can maintain it.
What to prioritize
- Risk-tiered approval paths, not one universal workflow. A firewall rule change and a marketing site copy update should not traverse the same five approvers. Confirm the tool routes by change type, risk score, and affected service, and that the risk score can be computed from field values rather than picked from a dropdown by the person who wants it approved fastest.
- A change calendar with real conflict detection. You want the tool to say "three other changes touch this service in that window" before submission, not after. Ask whether conflict checking uses CI relationships or just overlapping timestamps — the latter catches far less than you'd hope on shared infrastructure.
- Rollback plan as a required field. Sounds trivial; it's the highest-leverage configuration in the whole process. Make the rollback plan and the back-out trigger mandatory before an approval can be requested. Every tool listed supports required fields on the change form. Almost nobody enables it.
- Approvals that reach approvers in Slack, Teams, or email with one-click action. If approving requires logging into the ITSM portal, your median approval latency will be measured in days and your emergency-change rate will climb to compensate. Test the mobile approval flow specifically — approvers are frequently executives on phones.
- Immutable audit trail with approver identity and timestamps. For SOC 2 or ISO 27001, you need to show who authorized what and when, and that the record wasn't retro-edited. Ask whether approval history is append-only. This is a yes/no question with a real answer and it eliminates weak candidates fast.
- Post-implementation review that's actually enforced. A change closed without a PIR is a change you learn nothing from. Look for automatic PIR tasks on failed or backed-out changes at minimum, and reporting on change success rate by team and by type — that metric, tracked over two quarters, is what turns the process from overhead into something operations people defend.