Downtime Communication: IT vs. Marketing

Earlier this week, Mary Brandel shared some valuable insight about how IT pros can unintentionally sabotage an otherwise thriving customer relationship and/or compromise themselves and their department with internal stakeholders. In her post, “6 Blunders to Avoid When Dealing with End Users” she covers being mindful of techie lingo, communicating at the right level, understanding the business, treating internal users differently than external customers, over-promising, and establishing the wrong priorities. In short, the article calls attention to some common limitations within IT staff: communicating with customers. This isn’t a matter of intelligence or willingness. As Mary so aptly put it:

“Most IT pros will do whatever it takes to ensure they perform well on the job – they’ll update certifications, take online courses at home, come in early, leave late. So after all that effort, it would be a shame if their careers were stifled because of something as pedestrian as poor interactions with end users.”

It isn’t a matter of IT staff not caring, it’s a matter of IT not having the skillset. There are two obvious solutions to this problem: 1) include customer interaction in training and/or professional development for IT staff 2) have another team handle the customer interaction side of IT communications.

IT staff specialize in anticipating and preventing and/or identifying and fixing problems – it’s a waste of their time and talents to assign the communications piece to them too. Especially when it feels like something is at the “on fire” level of urgent fix.

Downtime Communication vs. Issue Resolution

Depending on the issue, it’s arguably just as important to communicate with customers promptly as it is to resolve the problem quickly. Shep Hyken recently called attention to TurboTax’s recovery from a significant gaffe with their end users, highlighting the 5 steps they took to remedy a crisis-level situation. In short:

1. Acknowledged the problem
2. Apologized for the problem
3. Fixed the problem
4. Took accountability
5. Acted quickly

Not every issue will require a remedy plan (some are small enough “bumps” in the road that a post-mortem issue report will more than suffice), but for major issues, you should model your communication after a plan like the above. With IT focused on resolving the issue, you’ll want to task another team with timely communication.

Downtime Communication from Marketing

There are at least four reasons why marketing staff are better candidates for communicating with customers about IT issues than IT staff themselves.

1. As already mentioned, during a crisis you probably want IT focused on fixing the problem at hand. Marketing will likely want control of the message to customers anyway.
2. As Mary Brandel points out in her article, IT staff sometimes struggle to communicate in terms non-technical staff can understand (she calls this techie lingo).
3. Relatedly, Mary also makes an excellent point about communicating at the right level: “…IT professionals can end up aiming too low (and insulting [users]) or too high (and confusing them).”
4. Marketing is paid to understand your customers and communicate with them effectively.

But what about the technical issue itself? How can Marketing understand it? After all, they spend their time interacting with customers, not working with hardware and virtual environments. The key is to set up the basics of downtime communication when NOT in the midst of a crisis. This way, IT can verify that the messages Marketing plans to send correspond to the potential issues appropriately.

There are tools available today that allow you to integrate your IT staff’s own internal monitoring and alert system with a customer communication system. Using StatusCast, you can quickly and easily set-up marketing-friendly alerts to end users, “translating” the techie lingo of IT’s application performance management system into something more intelligible to end users. Once the initial set-up is complete, the alerts can be programmed to go out automatically or to wait for approval before being released to end users.

You can learn more about how an application status page can help improve downtime communication here.