ITIL change control without a separate tool
Why change management fails when it lives outside the ticket, and what changes when classification and approval happen on the record itself.
Most teams that adopt ITIL change control adopt it twice. Once in the service desk, where the work actually happens, and once in a governance tool that exists so an auditor has something to look at. The second system is the one nobody opens.
The failure mode is not the process
When change control is a separate system, raising a change is extra work on top of doing the work. The engineer already has a ticket open. Filing the same information again, in a different tool, with a different identifier, is friction that gets skipped under time pressure — and time pressure is exactly when unreviewed changes are most dangerous.
What follows is predictable. The governance tool fills up with changes raised after the fact, backdated to satisfy the process. The record exists, but it documents a decision that was never actually made in advance. That is worse than no record, because it looks like control.
What changes when classification lives on the ticket
If the ticket itself carries the change classification, there is no second system to skip. A ticket that is a change is marked as one, at the point the engineer is already working. The three ITIL categories do most of the work:
- Standard — pre-authorised, low risk, well understood. No approval step, because approving them individually teaches people that approval is a formality.
- Normal — needs review before work starts. This is where an approval board belongs.
- Emergency — needs review too, but on a compressed path, with the record created as the work happens rather than before it.
The category that matters most is Standard. Teams that gate everything end up with approvers who rubber-stamp, because most of what crosses their desk is routine. Pre-authorising the routine cases is what keeps attention available for the ones that deserve it.
Approval boards should include the client
For a managed service provider, the person with the most context on business risk is often not on the provider payroll. An approval board that mixes your engineers with the client own contacts produces better decisions than one that only contains people who report to you — and it removes the conversation where a client asks who authorised a change and the answer is that you did.
Set the approval threshold deliberately. Requiring the full board gives any member a veto, which is right for high-risk production work. A lower threshold lets a change carry without unanimous sign-off, which is right when the board is large and the change is routine.
Enforcement has to be server-side
A gate that only exists in the interface is a suggestion. If the rule is that unapproved changes cannot be started or closed, that rule needs to hold at the API, not just in the button state. Otherwise the first person to hit an edge case — a bulk update, an integration, a direct database fix — quietly proves the control does not exist.
This is the difference between a process that survives an audit and one that survives contact with a busy Friday afternoon.