Communicating about outages and changes is an important part of what we do every day. But can we do a better job about how we communicate these events?
When a system or application goes down, contacting the customer and telling them the system or application is down is redundant. They probably already know that there’s a problem. Stating the obvious won’t win us any points and probably just frustrates them. What they really want to know is what happened, who’s impacted, when it’s going to be fixed. Those are the key things we need to communicate when stuff breaks. Communicate that we know what’s happened, we recognized the scope of the problem, and explain – in layman’s terms – what we’re doing to fix it and when we’re expecting the system to be back up. Follow up at regular intervals with updates and any changes to our estimates. If you have an IVR at the service desk, put a message in the greeting that makes folks aware that there’s a problem with a certain system and we’re working on it – nip the call in the bud at that point so the service desk doesn’t get backed up with unnecessary calls.
Don’t go silent once the problem is fixed, follow up with a communication stating that, and at some point in the near future it would be good to send an after-action report the details what happened and what IT is doing to prevent the problem from happening in the future.
Major changes to the technical environment should be handled in the same way. Clear communication explaining what’s being done – and don’t forget to explain why it’s being done – what we expect the impact to be on the business, whether that’s down time, reduced functionality, or if they need to arrange training for their staff. Be clear about the schedule, send regular reminders, and reassure them that we’re prepared if there’s a failure and we need to roll it back. The over-arching message in all of this communication should be that we care about their ability to do business and are being very careful to make sure there is as little impact as possible.
There’s loads of other communicating we can do outside of big events, though. Sit down with your business leadership and find out if there’s anything specific they’d like to see on a regular basis. Maybe our First Call Resolution (FCR) for the service desk, or the First Contact Resolution (FConR) for 2nd level support. Maybe they don’t care about first contact, but want to see the overall time it took us to resolve issues (MTTR). There are lots of potential metrics – take a look at the HDI 2015 Support Center Practices & Salary Report and/or the HDI 2015 Desktop Support Practices & Salary Report to find what other organizations are monitoring.
Even if your business partners respond that there’s nothing they want to see on a regular basis, we can still occasionally send out a marketing communication, celebrating our successes. Make the business aware that we’re not just there to inconvenience them with outages or deployments, but that we are working hard to respond to their issues quickly and successfully.