This week we’re going to look at setting up SLA based escalations.

Escalations are defined by setting a time limit by which your agents must respond to a ticket – if the ticket is not responded to or updated appropriately, it will escalate. When a ticket escalates, a few things happen:

• The ticket appears in the Escalated Tickets window of the Dashboard, making escalated tickets highly visible even if the agent has not seen the email notification.
• If the ticket is locked to an agent, the system unlocks it so that other agents can take action on the ticket.

SLA based escalations work in conjunction with Services, which in turn work in conjunction with Customers.

Let’s say that ACME Inc. is a new customer of ours and we will be providing them several services. One of these services is called High Priority Service. In our OTRS system, we have previously created High Priority Service and connected it to High Priority SLA to define escalation times. Now all we have to do is connect High Priority Service to the Customer record for each person from ACME Inc. who will be able to submit tickets.

If an individual from ACME Inc. creates a ticket through the customer portal, they will be able to choose through dropdown menus which Service and SLA apply to the ticket.

If an individual from ACME Inc. sends an email ticket, OTRS will recognize the Customer based on email address, but an internal agent will have to associate the correct service with the Ticket. Alternately, PostMaster Filters can be configured to set the Service and SLA based on a subject or body search.

If an individual from ACME Inc. opens a ticket via phone, the agent handling the phone call will be able to select the appropriate Service and SLA once they identify the Customer.

This example uses a B2B scenario, but the system works just as well in a B2C scenario, because tickets get created by individuals, not organizations. In OTRS, Customer records represent individuals. If you want to link all of the Customers to an organization, use the CustomerID field as the common field. In our example above, the CustomerID field for each individual would contain ‘ACME Inc.’.

Directions:

Define your Services: Navigate to the Admin / Services dialog, and define your service catalog; sub services are supported. We’ll connect Services with SLAs in the next step.

Define your SLAs: Navigate to the Admin / Service Level Agreements dialog, and define your SLAs. In this step, you need to select which Services the SLA will apply to. In the screenshot below you can see that the Security SLA we are creating applies to Security, Security::Access Control, and three other services. The ‘::’ indicates a sub service:

• Escalation – first response time: Applies to new tickets only. If the first response time is reached and no email or phone contact has been logged, the ticket is escalated.
• Escalation – update time:  If an article is added, such as a follow-up by email or the customer portal, the escalation update time is reset. If there is no customer contact, either email or phone, added to a ticket before the update time is reached, the ticket is escalated.
• Escalation – solution time: If the ticket state is not set to ‘closed’ before the solution time is reached, the ticket is escalated.

• Escalation times are set in minutes, so if you want tickets to escalate after 2 hours, enter 120 into the appropriate field. To disable escalations, set the appropriate field to 0.

• Notify by – define when the system sends escalation ‘warning’ emails, that tell Agents a ticket will escalate soon. These are sent based on a percentage of the escalation time; if you set the escalation time to 120, and Notify by to 50%, an escalation warning email will get sent after 60 minutes. If you don’t want escalation warnings, leave the field blank. To use this feature, you must enable escalation notification emails in the GenericAgent.pm file (see below).

Enable Escalation Notification Emails: enabling escalation notifications causes an email to get sent for every ticket that escalates, and enables the sending of warning emails (defined above).

Who will receive the notifications: all agents who have at least read permission into the queue which contains the escalated ticket, and who also have that queue selected in their My Queues dialog. To learn more about agent notifications, see this article.

To enable escalation notifications, edit GenericAgent.pm located at /opt/otrs/Kernal/Config, and un-comment these lines:

When you’re done it should look like this:

Create a Calendar: You have the option to choose a calendar to use for the escalations. Calendars define when the escalations can actually happen. For example, you can limit escalations to just business hours, so that tickets won’t continue to escalate during off hours. If you don’t define a calendar, tickets will escalate Mon-Fri, 8am-8pm, based on the default system calendar (as defined in SysConfig -> Framework -> Core::Time). In the screenshot above you can see that we have defined and selected Calender 2 for 24/7 escalations.

To edit calenders, go to Admin / SysConfig and search for ‘Calendar’. In the search results you’ll see Core::Time::Calender1, Core::Time::Calender2, etc. Edit one of these calendars to define the active escalation hours. When you’re done, click ‘Submit’.

Connect your Customers: Once you have defined your Services and SLAs, you need to create Customers via Admin / Customers, and then connect each customer to the appropriate service via Admin / Customers <-> Services. From the Customers <-> Services panel, you can connect individual services to each customer, or you can define which services will be available to all customers by default by clicking ‘Edit default services’.