To maintain consistent support delivery and accurately hold your teams accountable, BusinessChat employs a centralized Service Level Agreement (SLA) engine. This framework measures your actual operational speed while adjusting for your company’s real working hours, ensuring your metrics aren't unfairly penalized overnight or during weekends.
1. What is the Global SLA? (Time-to-Resolve)
BusinessChat Work Items focus on a single, primary SLA metric per configuration template: Time-to-Resolve (TTR).
TTR quantifies the total elapsed time from the exact second a work item is generated until it is successfully pushed to a terminal state.
The TTR target is configured strictly in hours (e.g., 4 hours, 24 hours, 1 business day) per individual Ticket or Incident Type.
Category Exclusion: SLAs apply exclusively to the Tickets and Incidents categories. Tasks are entirely self-managed by due dates and do not support SLA clocks.
2. Structural SLA Clock Pausing Behavior
The TTR countdown timer is controlled strictly by the top-level Parent Stage of a work item's active status. The system handles transitions according to rigid architectural rules to protect your workspace metrics:
Running States (Submitted & In Progress): The moment an item is created or moves into an active sub-status (e.g., "New", "Under Investigation"), the TTR clock runs continuously.
The Only Pause State (Waiting on Customer): The SLA clock pauses only when an item sits inside a sub-status mapped to the Waiting on Customer parent stage. This ensures your team is not held accountable while genuinely blocked by an external customer dependency.
The Internal Trap: Sub-statuses configured for internal blocks (such as "Waiting on 3rd Party Vendor" or "Internal Review") must sit under the In Progress stage. Because your business still maintains ultimate accountability for the customer's case, the SLA clock continues running by default.
Terminal States (Resolved & Canceled): Reaching a terminal state stops the SLA clock completely.
3. SLA Resumption via Manual Reopens
If a closed case must be revisited, the system prevents agents from taking shortcuts or creating messy duplicate tickets.
Moving a ticket out of Resolved or Canceled back into an active state triggers a native Reopen.
The system utilizes the exact same ticket ID and increments your permanent reopen_count metric.
Crucially, the original SLA Time-to-Resolve clock resumes counting exactly from where it left off, combining your historical open durations until the case is finalized again.
4. Custom Business Calendars & Time Zones
To ensure SLA targets remain honest, admins can exclude non-working days and off-hours from the clock calculation.
SLA Calendar Logic: When configuring an SLA target, the system evaluates time elapsed based on your organization's designated Business Time Zone.
Excluding Rest Days: Admins can flag specific days of the week (e.g., Friday and Saturday, or Saturday and Sunday) to be completely excluded from the TTR calculation. Time spent sitting in an active queue during an excluded rest day will not tick against your active SLA limits.
5. Step-by-Step: How to Configure SLAs and Calendars
Step 1: Access SLA Settings
Click on your Profile Icon in the workspace platform and select Settings.
Navigate to Work Items Settings and select your desired Ticket Type or Incident Type config page, either to edit an existing one or create new.
Step 2: Establish the Time-to-Resolve Target
Scroll down to the SLA Section.
Input your required resolution window in total hours (e.g., enter 24H for a single calendar day target).
Step 3: Map or Create a Business Hours Calendar
Click the SLA Calendar Dropdown.
Select an existing pre-configured corporate calendar template, or click New Calendar to build a custom workspace schedule.
From the popup menu, define your unique team shifts, input daily active working hour limits, and uncheck your specific regional rest days. Define which days to exclude if any. Click Save.
Step 4: Finalize and Deploy
Click Save to instantly deploy the SLA rules across your active queues for the updaed ticket/incident type.