For those of you out there who keep the Customer fully informed as needed, kudos to you. Pat yourself on your back…because no one else will.
How can you tell if you are not in this group?
Has the Customer ever…
- Complained about getting too many emails from you (over-communicating)?
- Asked for an update (under-communicating)?
If so, then we have some work to do…but no worries, because this article was written with you in mind. If this never happens, feel free to find something more valuable to do with your time – or read along to validate your good work and/or pick up some additional tips.
You may be shocked that a Customer asking for an update is seen as a failure on your part. To my knowledge, this comes from Curtis Mchale who cleverly said: “You failed if the client asks for an update.”
Beyond Customers asking for an update, it is a well-known fact that 80% of Customers leave an MSP due to poor Customer Service, not lack of technical expertise. Let that powerful stat sink in for a minute.
While Customer Communication, Customer Satisfaction, and Customer Experience are not exactly the same, Customers will not be satisfied or have a Great Experience if you do not properly Communicate.
However, if you do, then the benefits are extremely rewarding. Your customers will trust you, become loyal to you and look to your MSP for help over the next guy. Even better, they are more likely to refer you to others.
What Defines Great Communication at Your MSP
So, what is great Customer Communication? It is journey–mapping the Customer experience, and asking yourself, “If I were the Customer, what would I want to know at this step in the process?”
How you present the information is just as important as knowing what to say at each step in the Journey. Firing off an email using the default notification template is not communicating. Why not? Because it is a lot of data and very little information.
Personally, when I receive emails using the default notification template, the first things that go through my mind: Why am I receiving this email, and what in this email do I need to know?
More than one MSP has changed their notification templates to be clear and concise. For examples of what we are talking about, feel free to download the tried and true notification templates.
What to know: 9 times out of 10 when the Customer says they are receiving too many emails from you (over-communicating), what they are really saying is they receive a lot of emails and they have no idea why they are receiving them or what information therein is important to them.
To illustrate what we mean by journey-mapping, let’s use the recommended status list, which represents each step in the Customer’s journey from New to Complete.
A Breakdown of the Recommended Status List
New/Acknowledged: If the average time to Triage a new Customer request is over an hour, then using an automated Acknowledgment is expected. Keep the email brief.
We recommend a banner across the top, letting them know this is an Acknowledgment, and it is an automated response. Hint: a “Thank You” and some marketing swag can be a nice touch.
Request for Information: Sometimes, the Customer’s request is thin, and in order for the Tech to engage, they need more information. When this happens, the Acknowledgment is replaced with an RFI notification.
This is a pre-formatted notification that comes to the person changing the status to Request for Information. They can edit the pre-formatted notification to request exactly what information is needed and forward the notification to the Customer.
Note: the pre-formatted information requested matches your call script. You do have one, right? If not, email me and we will be happy to provide you with one.
Ready to Resolve: We strongly recommend focusing on the average time to Triage a request being less than an hour (20-minutes should be the goal). Here is a link to an article on How to Triage a new Customer request which will help you reach that goal.
From my experience, once this goal is met, sending two emails within 20-minutes is overcommunicating. It is best to forgo the automated notification and replace it with a post Triage Acknowledgment since it can provide richer information.
Keep the banner, drop the “this is an automated …” line, and add who the ticket is assigned to and when can the Customer expect to hear from the Tech (Hint: Resolution Plan SLA). This also allows the Customer to request expedited service for a good business reason, of which the MSP may be unaware.
Dispatched – Remote/On-Site: Here, the acknowledgment banner lets the Customer know that the engagement has been scheduled for a specific date and time, along with who will be engaging.
This notification also informs the Customer to expect a phone call or doorbell. Of course, the acknowledgment should also allow wiggle room for the Tech to change his mind and if so, they will let the Customer know to expect a doorbell or phone call.
Pick up the Phone: It is strongly recommended that an MSP build a culture where the Techs are expected/required to call the Customer before engaging, during the engagement if necessary, and before disengaging.
At the time of disengagement, the Customer is owed an update. Which update they receive depends on the status of the ticket. Each status should trigger a different banner in the notification.
- Customer Verification Requested – Tech believes the request has been completed.
- Waiting Customer – Tech needs something from the Customer before completing the engagement (waiting on vendor or parts may also be the case, and the Customer needs to know that).
- On Hold – For whatever reason, the Tech cannot complete the engagement at this time and is expected to complete it in the near future.
- Escalated – Tech has requested Sr. Tech support (Note: Tech retains ownership and Customer communication responsibility. They should only request what they need help with, and not expect ownership of the engagement to transfer to the Sr. Tech).
Other key points to know: Techs should be held accountable for Real-Time Time Entry. While this directly informs the Service Manager what they spent their time on, a more important indirect benefit is rich documentation, including the next steps in the ticket.
The rich documentation not only can be pulled into the notification, updating the Customer as expected/required, but if the Customer is high maintenance and requests an update, the Service Coordinator is empowered to provide the update. All of this happens without interrupting the Tech, who is most likely engaged on other requests.
If you found this article (or the whole series) helpful, we’d appreciate hearing from you! And if you are totally confused and need some direction, we are here to help. Reach out to us anytime…