Data Centers

Prevent unnecessary user downtime with good communication

How you inform your end users about system availability can make or break their level of trust in you. Learn to communicate clearly and effectively with your users to end confusion about downtime.


Although it can be difficult for support techs to adopt the users’ perspective, and commit time to documenting and communicating issues to them, it's an important part of your job. These tasks should fall into the category of routine preventative maintenance. After all, end users are integral parts of the organization, just as hard drives and operating systems are integral to a computer system. If you expect them to continue running as smoothly and error-free as the PCs you support, you must provide the proper input.

In a previous article, I presented some methods for handling situations where users misdiagnosed their own PC problems. But another user-related issue that can be just as frustrating to you and damaging to your credibility with your users is miscommunication about system availability. If you're not clear with your users about when an outage exists, who the outage affects, and how long the outage will last, users can assume they're experiencing downtime when that may not actually be the case.

The view from the user's perspective
Consider the following incident: A user reports that he cannot print. The tech assigned to the case fixes the problem but fails to inform the user. The user, completely unaware that the problem has been resolved, doesn't try to print again that day. Instead, he waits until the end of the day to complain to his boss, who in turn calls the IT manager, infuriated that his employee was unable to print a presentation in time for his meeting.

You could dismiss this incident as not your problem. You might think that the user should have at least tried to print again, or that he or she could have used a different printer or tried to print from someone else’s computer. But in the mind of the user, that particular printer was an unavailable system for several hours, which affected his or her ability to perform a required task.

Effective communication prevents confusion
In the above example, simply letting the user know that he or she could now print would have prevented the entire episode. Informing a user that his problem has been resolved is an important aspect of a support tech's job. It takes only a minute to leave a voice mail, e-mail, or sticky note saying that the issue has been resolved. Or to further ensure that the correct information has been passed along from the support tech to the user, you could establish a process for user sign-off on any computer problem. That way, a work order wouldn't be closed until the user agrees that the problem has been resolved to his or her satisfaction.

Proactive, appropriate communication with the users is often the most powerful tool in preventing problems. For example, if the IT department schedules downtime, users should always be informed of the date and time, estimated length of the outage, and exactly what services will be unavailable.

Informing users that a particular NetWare server is going to be down from 9:00 until 10:00 P.M. on Tuesday is not nearly as informative as telling them exactly which services will or won't be affected during the downtime. During one such outage, a user received the above message about the NetWare server. He later complained that he had almost lost a client because he wasn't able to give the client a timely response to an e-mail message. The user had received notification of the NetWare server downtime and had interpreted it as meaning that he could not use his computer at all during that time. If the user had been specifically informed that e-mail wouldn't be affected by the outage, this incident may have been prevented.

Document system availability for users
Consider the following incident: In a routine meeting with department heads, our IT department was blind-sided by an unannounced agenda item to discuss solutions for the excessive Internet downtime. All we could do was protest that there had been no Internet downtime, but we couldn't properly defend this position or determine what had caused this misperception because nothing had been documented.

To prevent this type of problem from occurring again we began documenting all system downtime using a report template.

The data we gather using this document is now distributed to all department heads as the weekly system availability report. The actual report we send to the department managers is different from this template in three significant respects:
  1. The report is entitled System Uptime; we changed the emphasis from what is down to what is up.
  2. The systems are not subdivided by servers, but according to services, thereby making the report more meaningful to the users.
  3. All systems are reported, not just those that experienced some downtime. This puts a positive spin on the report, emphasizing the significant amount of uptime we achieved.

Such a report takes minutes to prepare and provides useful information to all users. Implementing such a report might just reduce some of the complaints about the lack of communication between users and your IT department.

Editor's Picks