Freshdesk SLA Policies & Business Hours Explained

What a Freshdesk SLA policy is and does

A Service Level Agreement (SLA) policy in Freshdesk is a set of time targets applied to tickets. Each policy defines, per priority level, how long the team has to hit specific milestones:

• First response time — how long until an agent sends the first reply to the customer.
• Next response time — how long the team has to respond to every subsequent customer reply, not just the first.
• Resolution time — how long until the ticket is resolved (closed/resolved status).
• Resolution reminders — on newer plans, a nudge before the resolution deadline lands.

Crucially, these targets are set per priority. A single SLA policy carries four rows — Urgent, High, Medium, and Low — and you'd typically give an Urgent ticket a one-hour first-response target and a four-hour resolution target, while a Low ticket might get a full business day. The instant a ticket is created and prioritized, Freshdesk calculates the concrete deadlines and writes them onto the ticket. You can see this in the raw ticket data: every ticket exposes an fr_due_by field (the first-response deadline) and a due_by field (the resolution deadline), both auto-populated from whichever SLA policy applied.

The SLA Policies admin and first-matching logic

The most important thing to understand about Freshdesk SLAs is that you can have more than one policy, and they're evaluated in order. Under Admin → Workflows → SLA Policies, policies sit in a top-to-bottom, drag-to-reorder list. When a ticket comes in, Freshdesk walks the list from the top and applies the first policy whose conditions match — then stops. No ticket gets more than one SLA policy.

Each non-default policy is scoped by conditions: you can target tickets by source (email, portal, chat), by group, by company, by product, or by ticket-field values. That lets you promise VIP customers a faster resolution than everyone else, or give phone tickets a tighter first-response target than portal tickets. The catch-all at the very bottom is the Default SLA policy — it matches any ticket the higher policies didn't, and it can't be deleted. Because evaluation stops at the first match, policy order is behavior: a broad policy placed above a specific one will swallow tickets the specific one was meant to catch. Freshdesk's own SLA policy documentation is the authoritative reference for the condition types and setup steps.

How business hours change the clock

A "4-hour resolution target" means nothing until you answer: four hours of what? Freshdesk lets each SLA target run against one of two clocks:

• Business Hours — the timer only counts your configured working hours. A ticket that arrives at 4:55 PM with a two-hour target, on a team that closes at 5 PM, doesn't breach at 6:55 PM — it breaches five minutes into the next business day, because the clock pauses overnight, on weekends, and on holidays.
• Calendar Hours (24×7) — the timer runs continuously, wall-clock. This is what you want for a follow-the-sun or always-on team where "urgent" genuinely means urgent regardless of the hour.

Business hours are configured under Admin → Business Hours, where you set working days, daily start/end times, your time zone, and a holiday calendar. You can define multiple business-hours calendars and assign them per group — so your EMEA team's clock and your APAC team's clock each pause at the right local times. Choosing the wrong clock is one of the most common SLA misconfigurations: put an Urgent target on Business Hours for a team that markets 24/7 support, and you'll technically "meet" SLA while a customer waits all night.

How you'd actually set it up

A realistic setup looks like this. First, define your business hours (or confirm the default calendar matches your real coverage). Then open SLA Policies and edit the Default policy so every priority tier has sane first-response, next-response, and resolution targets on the correct clock — this is your safety net. Next, add specific policies above it for the cases that deserve different treatment: a "Priority customers" policy scoped to your top companies with tighter targets, or a "Phone & chat" policy scoped by source with a very short first-response target. Drag them into the right order, most-specific-first. Finally, configure reminders and escalations on each policy: a reminder to the assigned agent when a target is approaching, and an escalation to a lead or manager when a target is missed — so a breach becomes a notification, not a surprise you find in a report a week later.

Once that's in place, Freshdesk does the rest automatically. Every incoming ticket gets its fr_due_by and due_by stamped from the matching policy, the SLA timer counts down against the right calendar, and the reminder/escalation chain fires on schedule. For the wider picture of how tickets, priorities, and automations fit together, see our Freshdesk features overview.

The honest limits of native Freshdesk SLAs

Freshdesk's SLA engine is excellent at what it does — but notice what it doesn't do. An SLA policy measures time; it doesn't do the work. It will faithfully tell you a ticket's first response is due in 47 minutes, then escalate loudly when nobody replies — but it can't write that first reply, look up the customer's order, or decide that a password-reset question could have been resolved instantly. The clock is a scoreboard, not a player.

There's also a subtler gap. SLA targets depend on priority being set correctly, and priority is set by humans (or basic keyword automations) who are often wrong under load. A mis-triaged ticket gets the wrong SLA policy and the wrong deadline before anyone notices. And SLAs are fundamentally reactive: they can escalate a looming breach, but they can't prevent one by clearing the ticket.

This is exactly the seam where an AI agent layer earns its place. Macha runs on top of Freshdesk as a native connector — it is not a Freshdesk alternative and not a help desk, it plugs into the Freshdesk you already run. (To be precise, Macha's Fresh connector is for Freshdesk the help desk — not Freshchat, Freshservice, or Freshcaller.) Instead of merely counting down the first-response clock, an AI agent can answer the ticket within seconds — grounded on your help center — so many tickets are resolved long before the SLA timer becomes relevant. On the ones it can't fully resolve, it can triage and set the right priority so the correct SLA policy applies, draft a reply for a human to approve, and add internal notes with the context a manager would otherwise chase. The result is fewer breaches by deflection and speed, not just louder escalations.

What makes this trustworthy rather than a black box is the tooling around the agent. Sources ground the agent on your real knowledge base so answers aren't invented. Custom Tools let it turn any REST API — your order system, a shipping lookup, a billing endpoint — into an action the agent can take mid-ticket, which is what lets it actually resolve rather than just deflect (custom tools docs). Studies let you batch-grade the agent against your own historical Freshdesk tickets before it ever touches a live queue, and Analytics logs every agent run so you can audit exactly what it did. If you're weighing whether to wire this together yourself or use a platform, our build an AI agent from scratch vs. platform breakdown covers the trade-offs, and AI agents for customer service sets the broader context. Worth being honest about the model, too: Macha is priced per AI action — it's automation, and outcomes vary with the knowledge and rules you connect — so it complements your SLA policies rather than replacing them (see pricing for how that works).

For the step-by-step of connecting an agent to your Freshdesk queue, see how to automate Freshdesk with AI.

Frequently asked questions

What is an SLA policy in Freshdesk? An SLA (Service Level Agreement) policy is a set of time targets Freshdesk applies to tickets — first response time, next response time, and resolution time — configured separately for each priority (Urgent, High, Medium, Low). When a ticket is created, Freshdesk stamps concrete deadlines onto it (visible as the fr_due_by and due_by fields) and tracks them automatically.

How does Freshdesk decide which SLA policy applies to a ticket? SLA policies are evaluated top-to-bottom in an ordered list, and Freshdesk applies the first policy whose conditions match the ticket — then stops. Policies can be scoped by source, group, company, product, or ticket fields. The Default SLA policy sits at the bottom as the catch-all and can't be deleted, so policy order directly controls behavior.

What's the difference between business hours and calendar hours for SLAs? Business Hours only counts your configured working hours, days, and holidays, so the SLA clock pauses overnight and on weekends. Calendar Hours (24×7) runs continuously against wall-clock time. You choose per target; use Business Hours for standard-shift teams and Calendar Hours for always-on or follow-the-sun support. Business hours are set under Admin → Business Hours and can be defined per group.

Can AI help me meet Freshdesk SLAs? Yes — but by doing the work, not just watching the clock. An AI agent layer like Macha runs on top of Freshdesk (Macha's Fresh connector is for Freshdesk, not Freshchat/Freshservice/Freshcaller). It can answer common tickets within seconds — grounded on your help center — so they're resolved before the SLA timer matters, and triage the rest to the correct priority so the right SLA policy applies. Freshdesk's own SLA engine still owns the targets and escalations; the AI reduces how often you approach them.

The bottom line

Freshdesk SLA policies turn a vague promise about speed into an enforced, per-priority set of deadlines, and business hours decide whether those deadlines count wall-clock time or only your working shifts. Set the Default policy as a sane safety net, layer specific policies above it in most-specific-first order, pick the right clock, and wire up reminders and escalations so a breach becomes a notification. Then remember what the SLA engine can't do — it measures, it doesn't resolve — and let an AI agent layer clear the easy tickets and triage the hard ones so you meet those targets by getting ahead of them, not just by being warned about them.

SLA behavior verified against Freshdesk's official documentation and the demousermacha.freshdesk.com account (July 2026). Freshdesk occasionally changes defaults and plan packaging — confirm specifics in your own Admin console.