Change management is supposed to reduce risk. The idea is simple: before you touch production systems, you document the change, get it approved, execute it carefully, and verify the outcome. Good process. Sound logic.
In practice, for most MSPs, a misconfigured Autotask change management setup does the opposite. It adds invisible overhead to every ticket that touches it, poisons your SLA data, and trains your technicians to work around the system entirely. Here's how to spot the damage and fix it.
The Change Request Approval Status field in Autotask tracks whether a change request has been approved by the required approvers. Simple enough. The problem is what happens while a ticket sits waiting for that approval.
Change tickets in a pending approval state don't move. They sit. And if your workflow rules aren't configured to handle this state explicitly, Autotask treats that waiting time the same as any other open ticket sitting in queue. Your SLA clock may still be running. Your dispatchers may still see the ticket as actionable. Your techs definitely see it as someone else's problem.
The result: a ticket that's technically open, practically blocked, and showing up nowhere in a report that would tell you it's stuck.
The other outcome is worse. Technicians figure out that change tickets are black holes, so they stop creating them. They resolve firewall rule changes, server migrations, and network reconfigurations under regular service request tickets. No approval trail. No backout plan. No impact analysis. When something breaks, nobody can reconstruct what changed or who approved it.
That's not a process problem. That's a liability problem.
If your change tickets live in the same queue as break/fix tickets, you have a configuration problem. Change tickets operate on a completely different timeline and require different handling at every stage. Mixing them creates dispatch confusion, SLA contamination, and technicians playing triage games with ticket types.
Here's the configuration framework I'd recommend, using Autotask's workflow rule engine:
The common ticket workflows documentation makes it clear that change management workflow is intended to run parallel to, not mixed with, your break/fix and alert workflows. Most MSPs skip this separation because they're in a hurry to "just get tickets flowing." That shortcut costs them six months of bad data and dispatcher headaches.
The Checklist feature in Autotask lets you define step-by-step tasks directly on a ticket. On change request tickets specifically, this is the closest thing to enforced execution discipline that Autotask gives you natively, and most MSPs ignore it entirely.
Here's why it matters: change requests typically have three phases that need sequential verification.
Without a checklist, your technician executes the change from memory or from notes in a separate document nobody else can see. When something goes wrong and you need to reconstruct what happened, you're guessing.
With a checklist, every step is time-stamped on the ticket. A manager doesn't have to babysit the change window. The technician has a clear sequence to follow. And if the customer calls back with an issue two days later, you can see exactly what was checked and what wasn't.
Build checklist templates for your most common change types (firewall changes, server patching, SSL renewals, network device replacements) and attach them as standard practice. The time investment in creating them is about 20 minutes. The time you save per incident when something goes sideways is considerably more.
Here's a pattern I see constantly: an MSP completes a significant change for a client, something like a server migration or a network redesign, the work takes 12 hours, and three weeks later someone notices it was never billed because it got absorbed into a flat-rate agreement that was never meant to cover it.
Autotask has a mechanism to handle this. Fixed Price contracts support a Change Order feature that allows you to modify scope formally when work falls outside the original contract. A Change Order is specifically designed to adjust the scope of work on a Fixed Price contract.
The critical point: Change Orders (the billing feature) and Change Management (the ITIL process feature) are separate systems in Autotask. They don't automatically talk to each other. You have to wire them together operationally.
The workflow that actually works:
MSPs that skip step 3 end up eating scope creep costs silently. The work gets done, the client is happy, and nobody notices the billing gap until a quarterly review. By then, the conversation with the client is awkward at best.
Before you fix anything, you need to know what's actually broken. Autotask provides a LiveReport called "Ticket Change Approval Status" specifically for reporting on change request tickets. If it's not published to your service desk view yet, it's available under Left Navigation Menu > Service Desk > Reports > LiveReports.
Run it. Look for:
That last one is hard to measure directly, but you can approximate it. Pull tickets with keywords like "migration," "firewall," "upgrade," or "replacement" from service request type and see how many of those should have been change requests. If the number is significant, your technicians have already voted with their behavior: the current change process is too painful to use.
Fix the friction first. The adoption follows.
The Autotask change management workflow is genuinely useful when configured correctly. The problem is almost never the feature. It's the default-out-of-the-box configuration that assumes you know what you're doing when you enable it.
Here's your starting list:
Change management done right doesn't slow your MSP down. It gives you a defensible record of every significant change, reduces repeat incidents, and makes sure the work that falls outside scope gets billed. The goal isn't bureaucracy. It's control.