Your SLA dashboard looks clean, right up until a client's office closes for a bank holiday and your "4-hour response" clock keeps ticking against a queue nobody's watching. Most MSPs configure business hours once during onboarding and treat it like a smoke alarm: set it, forget it, and only notice a problem when something's already burned down.
The frustrating part is that the damage is invisible. Your Autotask reporting shows SLA breaches. Your service manager thinks the team is underperforming. Your technicians are confused because they weren't even working when the breach happened. Meanwhile, the actual culprit is a misconfigured schedule sitting quietly in your PSA settings.
This post walks through why business hours configuration is the foundation of accurate SLA tracking, the three mistakes that break it, how to audit and fix your current setup, and what accurate data actually unlocks downstream.
How Autotask's SLA Timer Logic Actually Works
Autotask's SLA engine follows exactly the business hours rules you define.
When a ticket comes in, the SLA clock starts running. Whether it pauses overnight, on weekends, or on bank holidays depends entirely on the schedule attached to that SLA definition. According to the Autotask documentation on establishing business hours for SLAs, you have two options for defining those hours: you can inherit them from an internal location, or you can configure custom hours directly on the SLA.
Each SLA can be set to one of three timeframe modes:
- Business Hours (runs only during configured working hours)
- Extended Hours (runs during standard plus additional support coverage hours)
- 24x7 (the clock never stops)
If your client is a 9-to-5 accounting firm and their SLA is running on a 24x7 schedule, every ticket they submit at 5:01 p.m. starts accruing against a clock that won't stop until someone picks it up the next morning. That's not a breach of effort. That's a breach of configuration.
The pause/resume logic only works correctly when the hours definition accurately reflects when your team is actually expected to respond. Get the definition wrong, and every SLA metric built on top of it is reporting a fiction.
The Three Business Hours Mistakes Nobody Audits
Most MSPs have at least one of these problems. Many have all three.
Mistake 1: One default schedule for every client
Autotask makes it easy to assign a single business hours definition globally, which means it's tempting to do exactly that during initial setup and never revisit it. The problem is that your clients don't all operate on the same schedule. A US client on Eastern time, a UK client on GMT, and a healthcare client with weekend support expectations cannot share the same schedule without somebody getting misrepresented in your SLA data.
Mistake 2: No holiday exceptions
This is the one that causes the Christmas surprise. Most business hours schedules in Autotask are configured with Monday through Friday hours and nothing else. No holiday windows. No exceptions. So when Christmas Day falls on a Tuesday and your client's office is closed, the SLA clock runs anyway. Your team isn't working. Nobody is responding. And by the time someone checks the queue on December 26th, the breach has already logged.
The Autotask SLA configuration does support holiday handling. You can choose whether the SLA clock runs on holidays using normal hours, custom holiday hours, or not at all. The setting is right there in the Hours tab. Most MSPs have never touched it.
Mistake 3: Misalignment between SLA hours and queue notification rules
This one is subtle and consistently overlooked. Your SLA definition might have business hours configured correctly, but your queue escalation notification rules run independently. If the notification rule says "send an escalation email when a ticket has been open for 3 hours" and that rule doesn't account for business hours, it will fire at 11 p.m., land in someone's inbox overnight, and by the time they see it at 8 a.m. the breach has already been logged.
Each of these mistakes is fixable in under ten minutes once you know where the settings live. The challenge is that nobody builds a recurring audit to catch them.
How to Audit Your Business Hours Configuration in Autotask
Run through this process at least once per quarter, and definitely after onboarding any new client.
Step 1: Pull your current business hours schedules
Navigate to Admin > Features & Settings > Service Desk (Tickets) > Service Level Management. Review every active SLA definition. Note which timeframe mode each one uses (Business Hours, Extended Hours, or 24x7) and which hours definition it references.
Step 2: Cross-reference against your client list
For each SLA tied to a specific client or client segment, confirm that the hours definition matches that client's actual operating hours. Pay attention to:
- Time zone (a client in London on an Eastern US schedule will have four or five hours of phantom SLA clock running every morning)
- Weekend coverage expectations
- Holiday handling settings
Step 3: Check the holiday configuration specifically
In each SLA's Hours tab, confirm whether "Use normal hours on holidays" or "Use hours specified in grid on holidays" is selected. If you've never configured this, there's a good chance your SLA clock is running through every public holiday on the calendar. Full details on these settings are in the Autotask business hours documentation.
Step 4: Check escalation notification timing
Review the notification rules attached to each queue. Confirm that escalation triggers align with business hours, not just raw elapsed time.
Step 5: Build a naming convention for schedules
If your MSP has been creating ad hoc schedules with names like "Client A hours" or "default," you're setting up future confusion. Switch to a structured naming convention like:
- US-Eastern-Standard-M-F
- UK-GMT-Standard-M-F
- US-Central-Extended-Weekend
When the next new client comes in, your onboarding team has a clear library to pull from rather than creating a new snowflake schedule that drifts out of sync over time.
What Accurate Business Hours Data Actually Unlocks
Once business hours are configured correctly, a few things start working the way they're supposed to.
Reporting reflects reality. SLA breach reports stop mixing genuine performance failures with configuration errors. Your service manager can finally see which technicians are struggling with response time versus which ones were simply logged off during a holiday that the system didn't know about.
Escalation rules fire at the right time. When notification rules and SLA definitions are aligned on the same schedule, escalation emails land when someone can actually act on them. That alone eliminates a category of breaches that are entirely artificial.
Dispatch queues surface the right tickets. If your MSP uses an SLA-driven work queue, like Rocketship's SmartWorkQ, the tickets at the top should be the ones genuinely at risk of breaching. When business hours are wrong, tickets breach silently, the priority rankings get polluted, and technicians lose confidence in the queue.
Automation actually works. This is where it compounds. If your MSP is evaluating or already using AI-based ticket triage or automated routing tools, those tools read the same underlying schedule data that Autotask uses. A broken schedule definition doesn't just affect manual workflow. It gives your automation layer bad inputs, which produces bad outputs. Even the smartest routing automation performs best when the schedule underneath it matches reality, so a definition that says 9 a.m. to 5 p.m. Eastern for a client in Berlin needs fixing first.
Business hours configuration is foundation-level data hygiene. Automation built on top of it depends on it being accurate.
Making This a Repeatable Process, Not a One-Time Fix
The real problem isn't that MSPs get this wrong initially. It's that nobody builds a mechanism to catch drift.
Clients change their operating hours. Staff in different time zones get added. Holiday calendars shift. Your Autotask configuration doesn't update itself to reflect any of that.
A few things worth building into your operations:
- Add a "business hours review" checkpoint to your client onboarding checklist
- Schedule a quarterly audit of SLA definitions, tied to your existing configuration review process
- When a client reports an SLA breach they believe is inaccurate, make "check the schedule configuration" the first step in your investigation, not the last
Getting this right won't dramatically change how your technicians work day to day. What it changes is whether you can trust your own data. And if you're trying to make decisions about staffing, client commitments, or automation investment based on SLA metrics, trust in that data is the prerequisite for everything else.
Accurate business hours make SLA management work. Rocketship makes it automatic. With your Autotask SLA schedules configured correctly, Rocketship instantly triages and dispatches tickets and uses SLA-driven work queues to keep the most at-risk tickets in front of the right technicians, so you stay ahead of SLA breaches instead of reacting to them. Need a hand? Our Autotask Consulting team can help, or grab the free Autotask Data Clean-Up Kit. You can also schedule a demo of Rocketship.
Share via: