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.
Why Your Approval Chain Is Silently Killing Ticket Velocity
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.
The 4 Workflow Rules That Actually Separate Change from Break/Fix
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:
- Queue isolation rule: Any ticket with ticket type "Change Request" routes automatically to a dedicated change management queue, not your general service queue.
- Approval state notification rule: When a change ticket enters pending approval status, trigger an immediate notification to the assigned change advisory board. Don't rely on approvers checking the portal voluntarily.
- Approval state SLA pause rule: Configure workflow conditions so SLA metrics are contextually appropriate for change tickets. Change requests have planned windows, not emergency response timelines.
- Approval completion handoff rule: When approval status flips to Approved, automatically reassign the ticket to the scheduled technician and notify dispatch. For multi-tiered approval boards (Technical Advisory, then Financial Advisory), chain these rules so the second board gets notified automatically when the first approves.
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.
Checklists: The Feature Nobody Uses Until They Have a Failed Rollback
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.
- Pre-change: Backup confirmed, maintenance window communicated, rollback plan documented
- Execution: Each configuration step checked off in order
- Post-change: Service verification, monitoring check, customer notification sent
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.
The Billing Gap: Change Work That Never Makes It to an Invoice
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:
- Change request ticket gets created and approved through change management workflow
- Before execution begins, the assigned tech or dispatcher checks whether the work is covered under the existing contract scope
- If not covered, a Change Order is created against the Fixed Price contract before work starts, not after
- The change ticket is linked to the corresponding billing record so there's a clear audit trail from approval to invoice
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.
Reading Your Own Change Management Health
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:
- Change tickets that have been in pending approval status for more than 5 business days (approval bottleneck)
- Change tickets with no checklist items (execution discipline gap)
- Change tickets closed without a corresponding billing entry on accounts with Fixed Price contracts (revenue leakage)
- High ratio of service request tickets to change request tickets for work that should be change-controlled (technicians routing around the process)
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.
What to Do Starting Monday
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:
- Audit your queue setup: Verify change request tickets route to an isolated queue, not your general service queue
- Check your approval notification rules: Approvers should get notified automatically when they have pending change tickets, not discover them on a weekly check
- Build three checklist templates: Pick your three most common change types and define the pre/execution/post steps
- Map change tickets to contract scope: For every Fixed Price contract account, establish who checks scope coverage before a change gets executed
- Run the Change Approval Status LiveReport: Establish a baseline before you change anything, so you can measure improvement
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.