/sla-business-hours

name: "Freshdesk SLA & Business Hours"
description: >
  Freshdesk SLA policies and business-hours calendars: policy and calendar
  fields, per-priority respond_within / resolve_within targets, how the
  business-hours vs 24x7 clock computes a ticket's fr_due_by and due_by, and
  breach / at-risk detection through the Freshdesk REST API v2.
when_to_use: >-
  When inspecting Freshdesk SLA policies and business-hours calendars, or reasoning about how they
  drive due_by / fr_due_by and breach detection on tickets. Use when: freshdesk sla, freshdesk sla
  policy, freshdesk business hours, freshdesk due_by, freshdesk first response, sla breach
  freshdesk, escalation freshdesk, or freshdesk response time.

Freshdesk SLA Policies & Business Hours

Overview

SLA policies define the response and resolution targets a Freshdesk account commits to, and business-hours calendars define when the SLA clock runs. Together they compute each ticket's `fr_due_by` (first-response deadline) and `due_by` (resolution deadline). This skill covers listing policies and calendars and reasoning about deadlines and breaches through tools named `freshdesk_sla_list` and `freshdesk_business_hours_list`.

Anti-triggers

A Freshdesk SLA policy is helpdesk configuration that computes ticket deadlines. It is not the commercial SLA in a signed agreement, and not an on-call response target.

• **The SLA a contract commits you to** — coverage hours, response

credits, and the agreement the customer signed are `halopsa-contracts` or `autotask-contracts`. Freshdesk's policy is how the helpdesk approximates that commitment; the two can legitimately disagree.

• **MTTA/MTTR for on-call responders** — those measure how fast a page

was answered, not helpdesk SLA attainment; use `pagerduty-analytics`.

• **Escalation rotas and who is on-call after hours** — coverage windows

here only pause a clock; they do not page anyone. Use `pagerduty-oncall`.

• **Acting on a breached ticket** — re-prioritising, reassigning, or

replying is `freshdesk-ticketing`; this skill explains the deadline, it does not change it.

SLA Policies

List SLA Policies

GET /api/v2/sla_policies

Each policy describes targets per priority and the conditions under which it applies.

Key SLA Policy Fields

| Field | Type | Description | |-------|------|-------------| | `id` | Integer | Unique identifier | | `name` | String | Policy name | | `is_default` | Boolean | Applies when no other policy matches | | `active` | Boolean | Whether the policy is in force | | `applicable_to` | Object | Conditions (company, group, source) that select the policy | | `sla_target` | Object | Targets keyed by priority | | `escalation` | Object | Who is notified, and when, as deadlines approach or pass |

SLA Targets by Priority

Targets are defined per priority level (recall the encodings: 1 Low, 2 Medium, 3 High, 4 Urgent). Each target typically specifies:

| Target | Drives | Description | |--------|--------|-------------| | `respond_within` | `fr_due_by` | Time allowed for the first agent response | | `resolve_within` | `due_by` | Time allowed to resolve the ticket | | `business_hours` | clock mode | Whether the target counts only business hours or calendar (24x7) time | | `escalation_enabled` | escalations | Whether breach/approach escalations fire |

Higher-priority tickets get tighter targets — an Urgent (4) ticket usually has a much shorter `respond_within` and `resolve_within` than a Low (1) ticket.

Business Hours

List Business Hours

GET /api/v2/business_hours

Each calendar defines the working week, daily hours, time zone, and holidays.

Key Business-Hours Fields

| Field | Type | Description | |-------|------|-------------| | `id` | Integer | Unique identifier | | `name` | String | Calendar name | | `is_default` | Boolean | Default calendar for the account | | `time_zone` | String | Time zone the hours are expressed in | | `business_hours` | Object | Working hours per weekday | | `holidays` | Array | Dates excluded from the SLA clock |

How Targets + Business Hours Drive Deadlines

When a ticket is created or its priority changes, Freshdesk selects the matching SLA policy and computes deadlines:

1. **Select the policy** — match the ticket against each policy's `applicable_to` conditions (company, group, source); fall back to the `is_default` policy. 2. **Pick the target** — choose the `sla_target` entry for the ticket's `priority`. 3. **Choose the clock** — if the target uses business hours, the SLA clock only advances during the calendar's working hours and skips holidays; if it is 24x7, the clock runs continuously. 4. **Compute `fr_due_by`** — created-time plus `respond_within`, advanced through the chosen clock. 5. **Compute `due_by`** — created-time plus `resolve_within`, advanced through the chosen clock. 6. **Pause on Pending** — when a ticket moves to Pending (status 3) awaiting the customer, the resolution clock can pause depending on policy configuration, shifting `due_by` accordingly.

Urgent (priority 4) ticket created Fri 16:00, business-hours calendar Mon-Fri 09:00-17:00
  respond_within = 1h  -> fr_due_by = Fri 17:00  (1 business hour)
  resolve_within = 8h  -> due_by    = Mon 15:00  (1h Fri + 7h spilling into Mon)

Breach Detection

To detect breached and at-risk tickets:

1. **Pull the unresolved queue** — search tickets with `status:2 OR status:3`. 2. **Read SLA timestamps** — fetch each ticket with `include=stats` to get `fr_due_by`, `due_by`, and whether first response / resolution has occurred. 3. **Classify against now:**

| Condition | State | |-----------|-------| | `fr_due_by` in the past and no first response sent | First-response breached | | `due_by` in the past and not resolved | Resolution breached | | `due_by` within the next escalation window | At risk | | Both deadlines comfortably ahead | Healthy |

4. **Prioriti