I am curious how others have their Service Desk Communicate to their users when they have high priority incidents. We currently use email but are looking for other methods. Does anyone use a website or popup notification on computers? We don't want to over communicate with emails to the business about issues. Any information would be appreciated. Thanks

1) Phone announcement - Pre-recorded message that plays when callers call into the service desk prior to hitting hte options that makes them aware of an known issue

2) Web submission - if you are utilizing a portal or web interface into your incident and service request system, a dashboard announcement of sorts of current known issues with their ETR. Can add as little or as much detail as deemed necessary for your organization.

3) dashboard announcement on your main intranet page - essentially a portlet on your home intranet page which highlites current known issues(can work in parter with #2)

4) Desktop notificiation - This is geared more towards IT which may be actively using your tool that you access users incidents and service requests. Some of the tools, remedy for example, have the ability to create an alert that pops up on the desktops.

Just a few options _________________Adam
Practitioner - Release and Control
Blue Badge

"Not every change is an improvement, but every improvement requires a change"

We also had an integration with a scrolling test display board by Symon. It would allow us to push a message to the board from our Remedy based help desk software. Again, it was primarily deployed in the Tech offices at our facilities. But it was a great way to instantly push out urgent messages to all sites.

Many enterprises I deal with do not allow the Service Desk to communicate anything out to clients, at all. Sometimes they are allowed to communicate only with the person that reported the Incident.

In most mature enterprises we deal with, communications is handled through a single group, usually Service Delivery or another group that represents the Integration Project Managers that manage all projects for infrastructure and engineering teams.

In all cases, communications is "scoped" by things like:

Severity of the Incident

Severity of the Business(es) being impacted

Severity of the individual Resources/Stakeholders within the Business(es) being impacted

Severity of the Product and/or Service being impacted

Etc.

This leads them to a formula of who should be communicated, when, how often, etc.

Also, the group that acts as the single point of communications, out to the rest of the enterprise, use repeatable and concise templates for communicating.

The key is to ensure consistency in communications and make sure that the business(es) and their people all know that they're getting the most recent information from a single and solid source for that information. This way, they won't get mixed messages from different groups.

Frank is correct in some respect. Most HD, SD dont have the front line people contact any one other than the caller who raised the incident

However, the concept of the function Service Desk means that all communication to the customers should come through the function Service Desk.

In 1 org, the Duty Manager would send the communications - which would be a template with fill in fields to those impacted by an incident, to management, to others interested

In another, a separate Service Support Team (called Analysts - until I pointed out that Service Support Analyst was merely ass-backwards....then they changed it to Specialists....SSS) would have a set of customers/clients/users that they were responsible for.

In another, there were Customer Service mgmt staff...

They were merely performing the function that the Service Desk function does.

A lot of companies use contract support for their help desks.....there fore they want to manage any communication separately_________________John Hardesty
ITSM Manager's Certificate (Red Badge)

We are also trying to improve our process for notifying end users when they might be impacted by a change or an incident. We appreciate hearing about how others handle their communication.

Our process basically works like this:

1. An e-mail is drafted using a template. The wording is kept as brief as possible, in plain English, and clearly describes the change or incident and the impact or action required by the end user.

2. The draft e-mail is proof-read by a handful of people to ensure clarity, accuracy, etc.

3. The e-mail is sent to the people who are impacted and the Help Desk. But this is where we need the improvement. We have to accurately determine who will be impacted and send the e-mail to that group of people. The user community has been complaining that they receive too many e-mails. On the flip side, many users depend on the communications and if we make a judgement call to not send an e-mail, we sometimes hear about it from the users.

So we are trying to figure out a way to notify only the people who are impacted and who care. We would like to hear about your communication process._________________D. Baxter
IT Change Coordinator
California Franchise Tax Board

One approach could be to select 'superusers' for each area. This would mean instead of mailing a whole division who may be affected by a network outage, you only mail the nominated users. They would undertake to pass the communication to the people who need to know. As they are much closer to the coal face, they should have a far clearer idea of who this is.
As the superusers have already agreed to catch mails, you are far less likely to get complaints regarding too many mails.
Obviously the Service Desk must always be included in any mailing list as they are going to catch the calls from the users, and therefore have a direct need to know - again this could be just the team leaders, rather than all the agents.

This is a method I have used for some years now, and we get very few complaints