Set support SLA's for Clients in WHMCS with Response Times
What is the Service Level Agreement
SLA (Service Level Agreement) is the practice of providing guaranteed availability of specialists to solve any problem within a specified timeframe. In essence it is comparable to our 360° Support for WHMCS.
When we receive a support ticket from a "Free" customer, reply is not guaranteed. On the other hand customers with "Pro", "Business" and "Enterprise" plans can benefit guaranteed replies and interventions. Long story short, SLA is for customers who are willing to pay for increased safety, reliability and quickest support.
A well defined and typical SLA includes repercussions for service provider not meeting its commitement. For example if we are not able to meet the requirements as stated in the SLA, we refund 5% for each failure.
In WHMCS all support tickets are the same. There's not way to make exceptions for clients that are looking for better support. The good news is that Mercury can handle SLA in WHMCS!
If you're looking for a way to simply show to customers WHMCS ticket response time and provide "flat" Premium & Emergency support, please continue reading the just linked article.
First thing first, we need to let Mercury knows your working hours, breaks and holidays. Begin by visiting Addons > Mercury > Settings and expand Support section. Here is where you define you:
- Working days
- Working hours (and breaks)
For example we are open from Monday to Friday and work from 09:00 to 13:00. We take an hour lunch break and resume at 14:00 till 18:00. Then we have holidays (Christmas, national events...). Here is our configuration.
We recommend you to be very precise as Service Level Agreement is based on timeframes. If you're having trouble configuring values, please take a look at WHMCS ticket response times where we provide in-depth description.
Still in this section there's a setting named SLA Reminders. As the name suggests, it sends reminders and warnings about tickets that require your immediate intervention to avoid incurring penalties.
Here you should select staff members who play a role in answering to support tickets. All selected persons receive reminders and warnings about SLA-based tickets that look like follow.
The email includes relevant information including a "countdown" and a direct link to both support ticket and customer involved. Hopefully your staff won't fail to meet the service level.
Customizing and Selling SLA
It's now time to move to Setup > Products/Services > Products/Services. Create as many SLA products as you want. All it takes is a name, a description and of course pricing. Here's is an example of our "Pro" SLA that costs 199 € monthly.
Keep in mind there are no restrictions on how to sell this product. It can have a setup fee, multiple recurring cycles and it can even be any of your existing product/service.
For example you could use it on a VPS server with full managed support or for a hosting plan with SEO/Marketing consulting included in the price.
Now that the product exists and the pricing has been set, we need to make it a SLA service. Go back to Addons > Mercury > Settings and open SLA tab. The image below is self-explanatory. What you see is how we configured one SLA of us. Keep reading to learn more about parameters.
|Dropdown that lists WHMCS products/services. Here you should select the product we created previously||Required|
|Outside Working Hours||Enable to extend intervention outsite office hours||Optional|
|First Response||Time your support team have to get back to a customer's first request before they fail to meet requirements||Required|
|Subsequent Reply||Same as above but works for subsequent reply on the same ticket. Leave empty for no requirement to meet||Optional|
|Notify Every||If set to 15 minutes, the module checks & send SLA Reminders every 15 minutes as long as there's at least one SLA-tickets still opened||Optional|
|Penalty||If set to 5% and you fail to respond twice, next renewal will be default price minus 10%. Leave empty for no penalty||Optional|
Support Outside Office Hours
To avoid any possible confusion, let us show you the difference between working with and without Outside Working Hours. Let's suppose you have the following configuration:
- Working days: Monday to Friday
- Working hours: 09:00 to 13:00 and 14:00 to 18:00
- Reply due within: 60 minutes
|Monday @ 09:00||Due within 10:00||Due within 10:00|
|Monday @ 12:50||Due within 13:50||Due within 14:50|
|Friday @ 17:50||Due within 18:50||Due within next Monday at 09:50|
|Chirstmas @ 09:00||Due within 10:00||Due within next working day at 10:00|
Customers with Multiple SLA
Customers can purchase multiple SLA services but this scenario is not advisable since it doesn't make much sense. In case a customer has more than one service level agreement, Mercury bases all calculations and timeframes on the one with highest recurring price.
SLA on Closed Tickets
The "close" event removes any obligation. You are not forced to reply to closed tickets as it assumes you've seen and solved the problem. Let us give you some examples to make things clearer:
- A customer adds a reply to thank you for solving the problem and closes the ticket
- Same as above but you close the ticket
- Ticket auto-closes due to inactivity or Escalation Rules
In all the above examples your reply is not needed.
SLA and Old Tickets
Once a customer has a SLA, all tickets benefit guaranteed replies. This includes tickets opened before purchase. Reminders, expirations and penalties indiscriminately apply to all tickets but for old ones you are responsible only for new replies.
In other words support team don't incur a penalty for performances prior to the purchasing of SLA.
Answering to Support Tickets with SLA
It's quite simple. All you have to do is respond to tickets before they expire. Pay attention to reminders and WHMCS Support Tickets page. We made a lot of changes to let you focus on tickets with SLA. Take a look at the following animated gif to see how it works.
Penalties for Violations to SLA
If penalties for failure to comply to service level are in use, the module automatically "refunds" the customer directly on next renewal invoice. The refund is actually a discount to avoid invoicing complications.