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.
- It is our preference that all work that may result in service interruption requires one of our technicians to be onsite during the maintenance. That means we will do the work onsite rather than remotely. If work is to be performed by a third-party technician, we would like to be there. We will follow this process whenever practical.
- Inform the customer technical contact(s) via email as far in advance as possible. Prior notice of one week is ideal. The email must include names of servers, LOBs, and services affected, as well as desired start time and expected duration of interruption. A copy of the email should be sent to our support email address with the service ticket number in the subject line. This guarantees that the email parser will attach the email to the appropriate service ticket.
- Send an email to customer technical contact(s) the day before the scheduled maintenance.
- Inform customer technical contact(s) via email in the morning of the day of the approved maintenance date.
- Inform customer technical contact(s) verbally 30 minutes prior to approved maintenance window.
- Once the maintenance has been performed, verify that all affected services/servers/LOB applications have been brought back up and are running properly. Have the customer contact verify that everything works.
- After verifying success, inform customer technical contact(s) that the maintenance has been completed.
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).
Controlling firefighters and heroes
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:
- Be aware of the policy
- Practice the policy
- Correct one another’s errors
- Support one another with reminders
Summing up this blog post in three points
- Scheduled maintenance is a perfect time to plan ahead, keep the customer informed, and do the job right.
- This is a good example of over-communicating with the customer. The goal is not to “cover your butt” so much as to keep the customer informed.
- If you don’t have a folder with email templates, start one. Then create a template for communicating this process.
(Used with permission of Karl W. Palachuk, SmallBizThoughts.com)