How to provide 24×7 support with ConnectWise Manage and OnPage
If you’re an MSP and you’re not providing 24x7x365 IT support, you’re cheating your clients out of services they really need to keep their businesses afloat and stay productive.
– Jaq Baldwin for MSP Blog
It might be seen as overkill, but you can’t live without it either. As soon as you remove after-hours service from your quote, you increase the chance of losing the deal. As such, after-hours service is a fact of life for most MSPs. While not the most pleasant aspect of the job, there are ways to make after-hours servicing is a more profitable and organized enterprise. With more businesses demanding support 24×7, MSPs who don’t offer after-hours service are at a serious disadvantage.
This point is reiterated when reviewing how to implement after-hours alerting for MSPs that use ConnectWise. These MSPs also get afterhours alerts but these alerts are in the form of tickets. How can tickets be turned into after-hours support vehicles?
We have put together a white paper that aims to explain how MSPs can both improve their offerings and ease the pain of after-hours service by:
- Suggesting changes to workflow
- Indicating how to rework policy to suit your team
- Providing ConnectWise tips that help you manage the incident
RETHINK YOUR AFTER-HOURS POLICY
Typically, labor covered under a managed service agreement (MSA) extends from 8AM to 5PM Monday through Friday. Labor that is conducted beyond the hours specified under an MSA can be billed at 1.5-times the regular rate if it is performed after 5PM or weekend hours.
Implementing a policy like this ensures fewer emergency after-hours calls from clients and forces them to consider whether an emergency is really worth the extra cost. This leaves you and your team only having to handle real problems after-hours. At the same time the extra money earned needs to go to the one handling the after-hours emergency as an incentive.
FINE TUNE YOUR AFTER-HOURS ALERTING
Now that you are charging more for after-hours service you need to be responsive to your customers and make sure the incident is resolved in a timely manner. Using e-mail and texts for automatically generated alerts has been a widely used practice since the early 90’s, but it is not an effective and efficient way of receiving alerts. Alert notifications are a crucial part of effective RMM management and missing even one single email or text can result in delayed incident resolution.
Texts are subject to the availability of solid network coverage and e-mails sent out by ConnectWise could end up in the recipient’s junk box or get buried under other e-mails. Both these methods are unreliable in the context of getting an urgent alert to the person(s) responsible for resolving the incident.
AVOID COMMON ALERT FAILURES
Alerts policies are decided based on what the client and MSP thinks are important parameters to monitor. If data points exceed the desired metrics, it might be necessary to create an alert. Or not. The issue though is that alerts can easily inundate afterhours personnel. Consequently, it is important to consider and establish alerting thresholds and decide what really needs an alert and what can wait until morning.
USE A DIGITAL ON-CALL SCHEDULER FOR AFTER-HOURS SERVICE ROTATIONS
A little bit of organization goes a long way. MSPs and their teams need to work together to set a schedule that works for everyone, with work being distributed equally. The nature of after-hours service is volatile and one cannot predict the kinds of emergencies that might pop up which is why these schedules need to be flexible.
CARRY OUT A POST-MORETEM
Peter Drucker is often quoted as having said that:
You can’t manage what you can’t measure
This is equally true in managing after-hours critical alerts. After the alert has been responded to and remediated, you need to look back at the situation and reconsider if the alert was triggered and responded to appropriately.
MSPs should ask if:
- The event was triggered by a real issue or by an issue that could have waited until the following day or by an issue that didn’t exist in the first place
- Was the alert delivered to the appropriate person? If not, was this because the alert was missed or was the person who received the alert unable to handle the issue?
- Was enough information provided to the MSP on-call so that they could handle the issue quickly? If not, the alerting information should to be updated so it is more robust.
To read more download our White Paper:
