When you work in tech support, you get to deliver a lot of good news. It's fun to report things like, "I successfully restored that file for you!" and "I gave you access to the folder as you requested."
People don't ask how you did something when the news is good.
Unfortunately, you frequently have to report bad news to a customer. When you do, you're accountable. Disappointed users expect you to explain why you can't restore the file or why you didn't grant system privileges.
How can you make sure those users are satisfied with the explanations they get for the bad news? One way is to try to make sure everyone on the help desk follows the same policies for communicating bad news. If you don't have formal or informal policies in place for reporting or escalating bad news, try customizing these samples for your shop.
Don't tell the users it's their fault
This should be a no-brainer, but it probably wouldn't hurt to establish a formal written or informal policy with everyone who interacts with end users. That policy would say: "Never tell an end user that a problem was his or her fault."
Telling users that they "must have done something" is bad news to the user's ears. Your job isn't to comment on what anybody did—your mission is to troubleshoot the computer system.
This policy includes in-person and on-the-phone contact. Users will ask, "Is it because of something I did?" If you want to script a standard response for everyone to use, try something like, "I don't know what happened, but I'm going to do my best to resolve the problem."
Don't authorize a reboot unless you're sure
Here's another no-brainer policy: "Don't authorize a reboot too soon."
By the time some users call about an application that "keeps locking up" on them, they've already tried rebooting their systems a few times. Rebooting may be the only option to undo a situation like that.
At other times, users will call when their systems aren't really locked up at all. Telling the user to "try rebooting" might be more than bad news—it could be the wrong course of action. The application may have lost focus and the user doesn't realize it, or a quick visit to the Task Manager may help explain and resolve what's going on.
Let the help desk manager report failed backups
A friend of mine who manages network storage for a manufacturing firm told me one of his analysts wasn't able to restore a file that had been lost. When the user asked why, the storage management analyst said, "Well, that server wasn't being backed up, so we had nothing to restore."
That answer was honest, but it sent the user into a rage, and everyone from the help desk manager to the CIO received flame e-mail about the fact that a critical server wasn't being backed up.
Eventually, investigation disclosed that a recent backup of the server had been made, though it had in fact fallen off of the regular backup schedule.
The good news of that story was that the server was put on a backup schedule. That experience prompted the IT department to establish the following policy statement regarding incomplete, nonexistent, or damaged backups: "The help desk manager must be notified immediately whenever a user file cannot be restored due to nonexistent or inadequate backups."
The intent of the policy was to make sure that bad news didn't get delivered until it was absolutely, positively confirmed to be bad news indeed. If you manage a technical team, it's not a bad policy to ask your analysts to go through you whenever they think they need to give bad news to a customer.
Imagine that you're a corporate computer user and your new, gung-ho network administrator sends a global e-mail message that says, "In 15 minutes, the Internet and company e-mail will be unavailable one hour for emergency maintenance."
That's bad news for the end users who have a Web-based teleconference scheduled in the next hour or who are trying to get work done using applications or data stored on company networks.
How do you avoid situations like that? Write policies like these that cover downtime and use of the global e-mail addresses:
- Network downtime must be scheduled in advance and approved by senior IT management.
- Emergency network downtime requests must be approved in advance by senior IT management.
Your intent with these policy statements it to make sure the people on the tech team know that they must, as a matter of course, get management approval before scheduling a system for downtime.
Appropriate use of company computers
What should a tech support person do upon discovering that an end user is engaging in computer-related activities that might turn into a "human resources incident?"
To help your staff respond appropriately, put in writing the company's expectations for appropriate use. For end users, write a rule of thumb that's as simple as this: "Use of company computers is restricted to work-related activities only."
For tech support professionals who detect security risks or other inappropriate uses of corporate computers, the rule of thumb might go something like this: "Tech support professionals must immediately report to management any unauthorized access to company network assets or any inappropriate use of company computers."
Then it's up to management to decide what to do about the potentially bad news.
What's your policy on bad news?
Who tells users bad news in your shop? Join the discussion with fellow TechRepublic members.