Last week’s article was all about notifications and properly communicating with the Customer. If you have felt like 12 notifications per request is a lot of work, then don’t shoot the messenger, just read on.
Structuring the Customer-Facing communications program based on Status is so important because it not only communicates internally where the request is on the journey from cradle to grave, but it also enables automation. Thus, keeping the Customer informed becomes easy.
The Many Benefits of Using Automation
The financial benefit of using automation may be saving labor, but the richer benefit is providing a consistent Customer experience. A consistent Customer experience builds trust and quiets the noise.
Thanks to automation, the Customer is assured they will hear from you with a specific rhythm. The rhythm then allows them to relax and let you do your job. Now isn’t that worth a million Euros? (PS: please send the check to PO Box 10987, Portland ME, 04104-6987).
While automation is great at saving $ and providing a great Customer experience rhythm, automating everything just pisses the Customer off. There are times when picking up the phone meets the expectations of the Customer, and the extra labor to do so is merited.
For example: while the ticket contains a lot of information, it most likely is missing some of the context behind the request. Also, information in the ticket is not Customer-Facing; therefore, it does very little to build a relationship or increase Customer trust in the MSP organization.
To build trust, a stronger relationship, and gather context information, you need to pick up that phone. If you’re saying “Please, noooo!” I’ve got good news: This can be smooth and consistent just by supplementing these stops in the Customer journey with a little automation.
A Workflow Rule Map of Customer Communications
Here is the workflow rule mapping of the Customer-Facing communications journey that a request should take from cradle to grave:
Trigger: When status is changed from “New.”
When status is not equal to “Request for Information,” “Dispatched – Remote”, or “Dispatched – On-Site”
Action: Send Acknowledgment notification to the Customer, assigned resource, account manager, and add as a note in the ticket.
Request for Information:
Trigger: Status is changed to “Request for Information”.
Action: Pre-formatted notification is sent to the Initiating Resource.
Note: Pre-formatted means it already contains the 8 basic questions out of the phone script. The Initiating Resource edits the notification and forwards to the Customer and Account Manager, then adds it as a note in the ticket.
Dispatched – Remote:
Trigger: Service Call is added.
Status is equal to Dispatched – Remote.
Action: Scheduled Remote notification is sent to the Customer, Assigned Tech, Account Manager, and added as a note in the Ticket.
Dispatched – On-Site:
Trigger: Service Call is added.
Status is equal to Dispatched – On-Site.
Action: Scheduled On-Site notification is sent to the Customer, Assigned Tech, Account Manager, and added as a note in the Ticket.
Automation via Speed Codes:
Note: These are used when the Tech is entering his time at the point of disengagement. It is assumed that the culture holds the Tech accountable to call the Customer before engaging, during the engagement if necessary, and at the time of disengagement. The time entry speed codes set the notification template to be used and indicate who is to be notified.
Waiting Customer notification with Time Entry Summary notates why we are waiting on them and what response is expected. The notification is then sent to the Customer and Account Manager.
On-Hold notification with Time Entry Summary notates why it is on-hold (why the Tech is not completing it now), what the next steps are, when the Customer can expect re-engagement, as well as when they can expect to hear from the Tech again.
Escalation notification with Time Entry Summary notates why it is being escalated, to whom it is being escalated, when the Customer can expect to hear from the escalation Tech, and who the Customer should reach out to (the sender or Customer Service) if they have any questions or concerns.
Waiting Vendor notification with Time Entry Summary notates why it is Waiting Vendor, when the Tech expects to hear from the Vendor, and when the Customer can expect to hear from the Tech again.
Waiting Parts notification with Time Entry Summary notates what parts the Tech is Waiting on, when the Tech expects to have the parts in hand, and when the Customer can expect to hear from the Tech again.
Customer Verification Requested:
The Customer Verification Requested notification starts the Ticket closing process. The rest of the process is automated.
Note: To reduce the number of times a ticket is reopened by the Customer responding with a Thank You, send this notification from a different email address than the email processing address, one that is monitored by the Service Coordinators.
When the Customer responds, the Service Coordinator can attach the email to the Ticket, close the ticket, and/or let the Tech know it is not ready to be closed. (If you have come up with a way to manage the Customer’s response automatically, please speak up – inquiring minds want to know.)
Automation via Workflow Rules:
Once the Tech has put the status as Customer Verification Requested, and 48 hours pass with no response (which is the case 90% of the time), the Pending Close notification goes out. This reminds the Customer they are waiting on their verification and informs the Customer if we do not hear from them in 24 hours, their request will be closed out.
After the Pending Close notification goes out, and 24 hours pass, Request Completed notification goes out with the survey, and the ticket is then closed.
And there it is…pretty straightforward, huh? If you need more direction or have any questions, reach out to us anytime!