Service level agreement is one of the most important criteria for evaluating the qality of service delivery. In DaoDesk, you can create SLA plans (Service level agreement policies) that allow you to measure and improve the responsiveness of support staff to customer requests and increase customer satisfaction. Utilizing service level agreements in DaoDesk allows you to:

• Adhere to target metrics for providing timely first and subsequent responses to the customer, as well as staying within the request fulfillment timeframe;
• Customize business hours, weekends and holidays for each division (department) individually;
• Track the time of first response and time of request fulfillment, including the time of working hours;
• Track the time a request is in each of the statuses, including working hours;
• Display in each request how much time is left before the target metric is violated;
• Monitor SLA plan violations using reporting, filters and sorting.

SLA plan (target metrics)

The target metrics and work hours for each department are configured in the SLA Plans menu:

SLA plan with id 1 is the default plan - it cannot be deleted and is always selected in each new department by standard. If you delete a previously created plan that was selected in one or more departments, the SLA plan with id 1 will be automatically set in them.

Within each plan, various customizations are available.

SLA plan (target metrics):

• SLA on agent's first reply - the time for the employee to react (write the first response) in the request.
• SLA on agents' reply after customer response - time within which agent should react to subsequent customer responses.

As a rule, the reaction time for the first response should be the fastest - it is at this moment that the client wants to make sure that his/her request has reached the support service, it is accepted into work and the operator is connected to its solution. That's why the time for the employee's response after the customer's answer can be a bit longer than the time of the first response. After all, at this moment the operator has to familiarize himself with the client's problem, work through it and prepare a response with a solution. However, the best solution is for the employee to be in constant contact with the client: to inform him that the request is in process, how long to wait for feedback, etc., so that the operator has the last word, and the client does not think and wonder if he and his request have been forgotten.

• SLA for completion- time from the moment of request creation to the moment of its closing (transfer to the corresponding status) - how long the employee should process and close the request.

If any of the target metrics is violated, the corresponding SLA will be overdue in the request, and both the support manager and the executor of the request can be notified about it. Such violations can be tracked using filters, sorting and reports - more on this later.

To reduce the number of SLA violations, you can configure a reminder of a suitable SLA to be executed before the SLA is violated. In this way, operators will be notified that a request is about to be due and should be given maximum attention.

If an SLA has already been violated in a request, you can notify them about it both at the moment of the violation and N time after it. This is the responsibility of the “After-close SLA reminder” setting.  

To activate the reminder of suitable/violated SLA, as well as alerts when a violation has already occurred, you need to go to the “Manager” menu and create a corresponding rule by selecting one or more conditions. For example:

Working week, weekends and holidays

In each SLA plan it is possible to set the working week and weekends/holidays separately. The point is that within one company different departments (departments) can work different hours. For example, the first line can process requests 24/7, while the second line can work from 09:00 to 18:00 on weekdays.

Working hours are the most important tool for the correct use of target metrics. Let's take the example of a conditional department “2nd support line”, which works according to SLA plan with working hours from Monday to Friday from 09:00 to 18:00, and in this plan there is a metric “for the first response of an employee” - 15 minutes.

Now let's assume that the second line receives a new request at 08:00. If we had not configured the working hours in the SLA plan, then the SLA for the first response in this request would be violated already at 08:15 - at a time when the employees are not even at their workplace yet - you will agree that this is not very fair.

But since our working hours for this plan are specified from 09:00, the system will first wait until the working day starts and only then start the counter, so employees will have exactly 15 minutes of working time (when everyone is in their seats and the working day has started) to write a response and not violate the metric.

According to the same logic, the principle of counting in the parameters “time of first response according to SLA” and “time of fulfillment according to SLA” works in reports. For example, if the request came at 8:00 am, the working day in the system is set from 9:00, and the employee will answer at 9:15, then the response time according to SLA will be 15 minutes (9:00+15 minutes), because it is the working time that is taken into account, and the usual time of the first response will be 1 hour and 15 minutes (8:00 + 1:15).

There may be situations when one of the days falls on a weekend/holiday, and the day preceding it may be a shortened working day. These moments can be taken into account in the “Weekends” tab:

So if a department receives a new request on a holiday in the middle of the work week, the system will wait for the start of business hours, as in the previous case, and only then run the counters according to SLA metrics.

Now that we have created and configured the SLA plan, we need to bind it to departments. This can be done in the settings of any department:

SLA plan can be applied to an unlimited number of departments. After SLA plan binding, the specified metrics and settings will be applied to all requests of the selected department.

More info

What is important to remember when working with SLA:

• If you delete an SLA plan, the departments in which it was specified will automatically have a default SLA plan (c id 1).
• Employees cannot manually edit SLA metrics, except for “SLA request fulfillment” - this field is displayed on the right side of the request, but you can disable its editing for any group of employees in the “Groups, access rights” menu.
• When working with a request its SLA plan can be changed using the Dispatcher.
• If the SLA for the first/next response is violated, the request in the list is colored red. If an employee responds, the request stops being red, and the fact of violation can be tracked in reports. If the SLA for fulfillment is violated, the request remains red in the list of requests until the SLA for fulfillment is reset, or the SLA plan is changed, or until the request is closed.
• If a requisition is moved to the “completed” status, frozen, deleted to trash or blocked, SLA metrics are paused.

In detail: when SLA is paused, the system counts the amount of time left before the SLA is violated for fulfillment, taking into account working hours and holidays. But the SLA for first response/follow-up response is not recalculated after the pause is lifted, but the time that is set in the SLA plan is counted, provided that they have not been violated.

For example, the following metrics are set: SLA on first response 10 minutes, on subsequent response 10 minutes, on fulfillment 60 minutes and after 5 minutes the request was frozen. After the pause is lifted, the SLA for first and follow-up will be 10 minutes (according to the SLA plan) and the SLA for fulfillment will already be 55 minutes because 5 minutes were already spent before the request was frozen.

Hence, problems can arise if the SLA for fulfillment was set manually in the request, i.e. the specific date and time was set by the employee and not automatically. When pausing such a request, the actual time in minutes from the current time to the specified date is considered.

For example, the working time is set from Friday to Friday from 09:00 to 17:00. An employee manually set the SLA deadline for 20:00 of the same day at 18:00 and immediately froze the request (the SLA was paused). Then he unfroze the request at 18:05 - after that the SLA for fulfillment will still be counted as 120 minutes taking into account the working week (!). Thus SLA for fulfillment after unfreezing will be violated not at 20:05, but at 11:00 of the next working day, because the system counts working hours.