Most of the time, our maintenance and repair work only affects one desktop, or sometimes a few desktops. But occasionally, we do some work on a server or a piece of equipment that either will or might cause an interruption of critical systems during work hours.
This could be something as simple as updating the drivers on a network card. It includes adding rules or features to the firewall, upgrading the line of business application, and making major changes to the Exchange Server or an SQL server used by everyone in the office.
There are two keys to success in this scenario. The first is to take it seriously. I know that sounds obvious, but too many technicians only look at the job (which seems simple) and not at the customer (who just wants uptime). The second key to success is communication. You're going to go out of your way to communicate with the customer. And if there's a third-party technician involved (hardware, software, network, line of business), you will carefully manage all communications with them as well.
Here's our basic Standard Operating Procedure for major scheduled maintenance:
This document is intended to outline the procedure for implementing scheduled maintenance where any number of services, servers, or networks may experience an interruption that affects more than one person.
This process is to be performed by the service manager, or in close association with the service manager. In most cases, the maintenance is routine. But just in case something goes wrong, the service manager needs to know what's going on and must be available to re-route technicians and manage customer communications if needed.
Note that the customer might be very skittish about any downtime, even if you think it's a 10-second blink. The truth is, stuff can go wrong. That's why we have a policy. Because you have heightened the customer's awareness, they might request that the service be moved to another date or time.
The most likely customer feedback you'll get is either "That's a good day/time" or "That's a bad day/time." You probably don't know when your customers are performing payroll processing, insurance audits, or other activities that can't give way to simple maintenance. The customer will be grateful that you informed them of the procedure and gave them the opportunity to move it to another day.
Checklist for Major Scheduled Maintenance
Service Request/Ticket # __________
____ Email sent to customer informing them of maintenance on date of: __________
____ Acknowledgement received for date of: __________
____ Email sent to customer the day before scheduled maintenance.
____ Email sent to customer on morning of: __________ ____ Customer informed 30 minutes prior to maintenance window.
____ Maintenance completion date and time: __________
If you have a PSA system, you can create a workflow to make sure these steps are taken. If you don't have a PSA system, you may want to have both the tech and the customer rep sign a document on completion of a major project (e.g., a new router installation).
As you know, one of my themes is "Slow Down, Get more Done." This is a case where that's very important. There is a tendency in our business to jump right in, get to work, and start clicking things. But there are times when that's just not the right thing to do.
Most experienced technicians can look back on when they thought everything would go smoothly and it didn't. And the customer turned to them and wanted to know what went wrong. Even if the customer was very understanding, they still managed to comment that, "It would have been nice to have some warning."
This procedure might be overkill most of the time. But on the day that two minutes of expected downtime becomes an hour, you'll be glad you coordinated with the customer. This process is normally really uninteresting and just standard operating procedure. But it can go a long way to helping with customer relations.
Implementing this procedure is simple. Agree to a process similar to that outlined above. Talk to your team and make sure they understand that this is important. (No firefighters needed.)
As much as you can, build these processes into your PSA system. This kind of policy requires that everyone on the team:
(Used with permission of Karl W. Palachuk, SmallBizThoughts.com)
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.