SLA Policies

An SLA (Service Level Agreement) policy is essentially a timer that tracks whether your agents are responding to customers fast enough. You set rules like "agents must send the first reply within 1 hour" — if they don't, it counts as a breach. You can then see in reports exactly which conversations were handled on time and which weren't.

---

The Three Timers

Every SLA policy is built from three independent thresholds:

Each timer runs independently. A conversation can breach FRT (slow first reply) but still hit NRT and RT — the final outcome reflects all three.

Example: An SLA policy with FRT = 1 hour, NRT = 30 minutes, RT = 24 hours means:

• Agents must send their first reply within 1 hour of a new conversation opening
• After every customer message, agents must follow up within 30 minutes
• The entire conversation must be resolved within 24 hours

---

Accessing SLA Settings

Go to Settings → SLA in the KronChat left navigation. This section is available to administrators only.

---

Creating an SLA Policy

1. Click New SLA Policy
2. Fill in the policy details:

3. Click Save

Times can be entered in Minutes, Hours, or Days — select the unit from the dropdown next to each field.

---

Assigning an SLA to an Inbox

The most common setup is to assign an SLA at the inbox level. Every new conversation created in that inbox will automatically inherit the policy.

1. Go to Settings → Inboxes
2. Open the inbox you want to configure
3. In the Configuration tab, find the SLA Policy dropdown
4. Select the policy and save

Critical: Assigning an SLA to an inbox only affects conversations created after you save. Existing open conversations are not touched. If you have conversations that were open before you set up the SLA, see the section below on existing conversations.

---

Assigning an SLA to an Individual Conversation

An SLA can also be applied directly to a single conversation:

1. Open the conversation
2. In the right sidebar, find the Conversation Details panel
3. Select an SLA policy from the SLA dropdown

Once an SLA is assigned to a conversation it cannot be removed or changed. Assign carefully.

---

How SLA Tracking Works — In Detail

Understanding how the system works under the hood helps you avoid surprises.

Step 1: Stamping at conversation birth

When a new conversation is created, KronChat checks: does this inbox have an SLA policy assigned?

• If yes — it copies the SLA policy ID onto the conversation and creates an Applied SLA record. This record is the thing the system actually monitors.
• If no — no Applied SLA record is created, and the conversation is completely invisible to the SLA system.

This stamping happens once, at the moment the conversation is born. It does not happen again.

Step 2: The background job

Every 5 minutes, a background job runs and checks all Applied SLA records. For each one it asks:

• Has the agent sent a first reply yet? If not, is the FRT deadline past?
• After the last customer message, has the agent replied? If not, is the NRT deadline past?
• Has the conversation been resolved? If not, is the RT deadline past?

If any deadline has been crossed, the breach is logged and notifications are sent. If no Applied SLA record exists for a conversation, the job simply skips it — there is nothing to check.

Why conversations created before the SLA was set up don't get tracked

If your inbox had no SLA policy when a conversation started, no Applied SLA record was ever created for that conversation. Even after you later assign an SLA to the inbox, those existing conversations remain invisible to the monitoring job. The SLA only kicks in at conversation creation — it is not applied retroactively.

This is expected behaviour. The system is designed this way so that conversations are not suddenly marked as breached the moment you enable SLA tracking.

---

WhatsApp and Reopened Conversations

WhatsApp works differently from other channels. When a customer messages you on WhatsApp, KronChat checks if there is already an open (or recently resolved) conversation for that number. If there is, it reopens that same conversation rather than creating a new one.

This has an important implication for SLA:

• If a conversation was created before your SLA policy was set up, it has no Applied SLA record.
• When that customer sends a new message, KronChat reopens the same conversation — it does not create a new one.
• The "new conversation" creation flow that would inherit the SLA never triggers.
• So the reopened conversation continues to have no SLA tracking, even though your inbox now has an SLA policy.

Only genuinely new contacts (a phone number that has never messaged your inbox before) will automatically get SLA tracking when they start their first conversation.

---

Applying SLA to Already-Open Conversations

If you need to start tracking SLA on conversations that were created before your policy was set up, contact your KronGage administrator. An administrator can manually apply an SLA policy to existing open conversations — this creates the Applied SLA record directly, which the background job will then pick up on its next 5-minute cycle.

Once stamped, those conversations behave exactly as if they had inherited the SLA at creation.

---

SLA Breach Notifications

When a threshold is missed, KronChat notifies:

• The conversation assignee
• All conversation participants
• All account administrators

You can control which of these you receive in Notifications → Notification Preferences.

---

SLA Status

Each tracked conversation shows a running status:

---

SLA Report

The Reports → SLA report shows aggregate SLA performance across your workspace:

• Count of conversations that hit vs missed SLA
• Breakdown by inbox, team, agent, and label
• Filter by date range and SLA policy

Use this report to identify which inboxes or agents consistently miss targets and where to focus training or staffing.

The SLA report is covered in detail on the Reports page.