This article assumes you have never set one of these up before.

What an SLA is

SLA stands for service level agreement. It is a promise about speed: how quickly you will reply to a customer, and how quickly you will finish dealing with them.

You do not need a signed contract for it to be worth having. Most teams set targets so that everybody agrees what "too slow" means, and so the inbox can warn them when a conversation is heading that way.

In Gruvi the promise is called a policy. A policy holds the targets. Every conversation is given one when it arrives.

What you are promising

A policy covers three separate promises, measured independently.

First response: Time to the first real reply after the customer writes. This is the one customers notice.
Every next response: The same promise on every later message. It starts again each time the customer writes back.
Resolution: Time from the conversation starting to it being resolved or closed, whichever comes first.

They fail for different reasons, which is why all three exist. A fast first reply followed by three weeks of silence meets the first promise and misses the other two.

Where to set them up

1Click Skills in the left-hand sidebar.
2Open the Your skills tab.
3Scroll to Built into Gruvi, find Set up SLA targets, and click Manage.

You land on a page headed Response time targets. It lists your policies in the order they are applied, and tells you how many you have.

How a conversation finds its policy

A conversation falls through the list from the top. The first policy whose scope matches sets its targets, and the search stops there. Only one policy ever applies.

At the bottom sits the default policy. It covers every conversation the ones above do not, and it cannot be reordered or deleted. If you never create a policy of your own, everything uses this one.

Order matters more than anything else on this page. A broad policy sitting above a narrow one will swallow it, because the search stops at the first match. Put your most specific policies at the top.

How to create a policy

1On the Response time targets page, click New policy. It is added above the default.
2Give it a Name you will recognise later, usually the group of customers it covers.
3Under Who this covers, click Add condition and build the test that decides which conversations it applies to.
4Choose All if every condition must be true, or Any if one is enough.
5Set the targets, as described below.
6Click Publish changes at the top right.

A condition is a field, a comparison and a value, read as one sentence. Company is ISAA is a complete condition, and it is how one customer ends up on tighter promises than everybody else.

Setting the targets

The targets are a grid. Each of the three promises has a row for each of the four priorities: Urgent, High, Normal and Low.

1Type a number into the box for the priority you want.
2Click min, hr or days beside it to choose the unit.
3Repeat for each priority that should have a target.

Any cell can be left as No target, and that promise then stops being measured for that priority.

Low priority carries no target by default, and that is on purpose. A thread downgraded to Low stops counting rather than sitting in your list falsely overdue. Clearing any cell does the same thing.

Business hours or around the clock

Under How time is counted, pick one. It applies to all three promises.

Business hours: Counts only your scheduled hours, skipping nights, weekends and holidays.
Around the clock: Counts calendar time, day and night, every day.

Business hours is the honest choice for most teams. If you are marked as always open, a question arriving on Friday evening accrues overdue time all weekend, and every Monday looks like a failure.

The page shows which workspace hours it is using, with a link to change them.

Warning somebody before the deadline

Under As time runs out, the Deadline approaching section sets a warning for each of the three promises. Enter how long before the deadline it should fire, and the assignee gets a nudge while there is still time to do something.

Below that, After the breach lets you add steps that fire once a deadline has been missed. Chloe can be brought into any step, on her own or alongside a person.

Each step fires once per cycle. A thread that breaches, recovers, then breaches again on a new cycle starts fresh.

The Live preview on the right reads the policy back to you as a short story: when the clock starts, when the warning fires, and what happens at the deadline. Read it before publishing. It is quicker than checking the grid.

Whether an AI reply counts

At the bottom, under How the clock behaves, is a single switch: A grounded answer from Chloe satisfies first response.

It is on by default. A real answer from Chloe stops the first-response clock. A canned acknowledgement does not.

Leave it on if Chloe answers on Autopilot, because from the customer's side they have been answered. Turn it off if you want this number to measure your team rather than your inbox. With it on, first-response times improve without anybody getting faster.

Checking it does what you think

At the top of the Response time targets page is See where a conversation lands, listing a few of your real threads. Click one and Gruvi tells you which policy it matched.

Do this after every change. It takes a second, and it catches the mistake almost everybody makes, which is a broad policy sitting above a narrow one.

What happens after you publish

Changes apply to conversations that start after the change. Conversations already running keep the policy they were given.

Once a policy is live you see it on the threads themselves: a countdown while time remains, and a red overdue badge once the target has passed. The panel behind that badge names the policy that was applied, which is worth checking before you conclude that somebody dropped the ball.

Set up SLA targets