Service Desk Communications

[vanroygm]

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

[ARoll]

Couple of approaches pending how you have your service desk setup:

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"

[dboylan]

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.

[m_croon]

We have been using SMS for years, very simple and very reliable.

[UKVIKING]

It is also depends on the who and the what is being conveyed

For example:

One company decided to SMS every 15 minutes to the senior mgmt about every Major outage (P1s) - initial, updates etc

Since the company was a global telco/isp/hosting company - we averaged 1-10 P1s a day - every day.

... (music)

The SMS messages overloaded every ones' crackberry....

So they change it to the initial only to interested mgmt and then when major updates were done.

A P1 usually lasted 1-2 hours between the time open and the time closed

The other thing is what was the purpose of the notification.
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Guerino1]

Hello Vanroygm,

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.

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[UKVIKING]

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)

Change Management is POWER & CONTROL. /....evil laughter

[vanroygm]

Thanks for all the feedback

[Guerino1]

Hello Vanroygm,

I guess the points are to ensure:

- A single communications channel to ensure one message
- Controlled communications (who, what, when, where, why)
- Consistent communication content, procedures, protocol (using things like templates)
- A single, unified view of the IT organization, out to the business(es) it services
- Etc.

In the end, it really doesn't matter which group does it. What matters is that you do it correctly and manage the process.

I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL

[baxman]

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

[Ed]

Hi baxman

The quandry you pose is one that is very real for a lot of people.

The fact is, you are damned if you send, and damned if you don't.

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

I hope this helps

Regards

Ed

[Ed]

Sorry

Made an assumption here

We also post all this stuff on our Forward Schedule of Change to make detailed info available to all who want to look

Regards

Ed

[midhasum]

Hi!

We create a global incident and pop up comes up, as and when user log in to software to report a problem or create incident.