Service Desk

Here is where the Service Support business starts and ends. At least from end users perspective. Customer problems and needs should be streamlined here and all feedback should come from here.

Other Service Support disciplines (Problem, Change, Release, Configuration Management) are PROCESSES, and Service Desk is a FUNCTION. Since Service Desk acts as a Single Point Of Contact (SPOC) for customers, and most of the time other disciplines are initiated from SD, it is rightfully the first SS discipline defined in the Blue book.

Support organizations have a Service Desk. Sometimes they call it differently, but it performs basic ITIL SD processes, so it is a SD. Sometimes people call it SD, and in reality it is a simple HelpDesk or even just a Call Centre. The difference?

• Call Centre's primary function is to handle large volume of calls, and hence the name. These calls can be outgoing (we sell something - telesales of commodities or simple products) or incoming, with prospect or customers inquiries and feedback. Main tools used here are some CRM or a good contact management with CTI and case tracking, e-mail, fax integration and an electronic catalogue.
• Help Desk mainly resolves a large number of Incidents from a known, probably large customer pool. Incidents and enquiries are usually simple, since they are constricted to a technology niche of a supported product (cell phones, telecommunications...), so the typical employee of a HD is briefly educated, given an issue tracking tool and a simple knowledge base, and maybe a couple of taps on his shoulder. Help Desk operation is a stressful business, and life expectancy of the operator is 6 months to 2 years. After that all his savings go to his therapist.
• Service Desk shares some features with the former two, since all three entities are interfaces of service business to the customer, and they are most responsible for the customer satisfaction. They use the same or similar technology.But SD's perspective is much broader, and encompasses all disciplines of Service Support and Service Delivery.

SD Primary function is to handle incidents and problems, but it also receives RFCs, deals with service and maintenance contracts, SW licenses, Configuration Management, and contributes to all five disciplines of Service Delivery.

What is the typical situation of support without SD?
Nicely put, customers perceive you as a disorganized untrustworthy bunch of nerds

• Changes to your IT infrastructure are uncoordinated and disorganized, and most of them cause bursts of incidents
• Your main job is to put out these fires that come out of nowhere
• Most of the problems occur in a repetitive manner You over-depend on your best engineers, who are most competent to resolve incidents initiated by their irresponsible unauthorized changes
• Support resources are undermanaged, while some people can behave like on vacation, others work their head off, and no one can be sure who is who
• Poor feedback to customers (this should be about their satisfaction, remember?)
• Poor feedback to management - without reports, their function is meaningless, and your job is at stake
• Evidently, implementation of SD will change these drawbacks into advantages, dramatically rising customer satisfaction, i.e. retention.

OK, What basically does Service Desk do?

I will briefly mention key activities here:

• receiving calls, first-line Customer liaison.
• recording and tracking Incidents and complaints - first line operators key task is proper classification of an incident.
• keeping Customers informed on request status and progress - every communication, even an automatic one, strongly influences customer satisfaction level. Structured, uniform automatic notifications reassures the customer that an organized business entity is taking care of his problem.
• making an initial assessment of requests, attempting to resolve them or refer them to someone who can, based on agreed service levels.
• monitoring and escalation procedures relative to the appropriate SLA .
• managing the request life-cycle, including closure and verification - a request should not be closed before a customer verifies it.
• communicating planned and short-term changes of service levels to Customers.
• coordinating second-line and third-party support groups.
• providing management information and recommendations for service improvement - crucial task that takes a lot of SD manager's time is keeping the management happy and improving the vertical visibility of SD efforts.
• identifying Problems highlighting Customer training and education needs
• closing Incidents and confirmation with the Customer - an incident should not be closed before a customer verifies it.
• contributing to Problem identification.

Key point of modern SD is common with all quality control standards: puts things into perspective, and customer satisfaction into focus. Highly skilled IT people tend to behave like spoiled children, self centered and often distracted by technology features, computer games, inadequate sexual performances... Implementing standards, policies and procedures sets them back on track and reminds them where the food comes from. Also, ServiceDesk methodology relieves 2nd and 3rd level engineers (expensive ones) from the stress by removing frequent interrupts of customers requests. Work comes to them adequately prioritized and categorized and they can perform it in an organized way.

If you plan to implement a SD, a lot of useful advice can be found in ITIL Service Support book. Buy it. Read it. Certify your people. Do not overdo it, but ensure that all the key people are acquainted with the stuff and speak the same language, this will raise the collective state of mind in your organization.

ITIL is a framework, not a methodology. It is fairly descriptive (good for learning), and it doesn't prescript every little detail of work. When you plan SD implementation, there will be a lot of vague and undefined issues, and ITIL should be referred to during plan phase brainstorming to silence that loud category of people that like to speak about things they don't know much of.

"Those that have something to say, say nothing because those who have nothing to say, have to say something."

One of the key points in SD implementation is technology. What IT product will you choose for SD automation? Your current needs, if you are in pre-firefighting phase, may blur your real future needs. That's why ITIL education is good. Warns you of the problems that will arise when you get rid of your pathetic little initial pains.

Choose the tool that will ensure you GROWTH. Select a well known vendor and implement his functionality modules as you move forward. Do not choose a cheap solution that will choke you in the future. At some point, either you will have to choose a new, expensive solution and get fired for that, or you will get fired in the first place and someone new taking your place will select a high-end solution. In both cases you lost a lot of the money for your company and people will spit on every mention of your name.

Even if you follow this safe recommended path, there is a chance that you will make a bad decision. For example, ask all the former Peregrine customers ;-)

If your company core business is not development, DO NOT build a solution yourself. Period.

I have to say some more about existing solutions later, and this should suffice for this post.

If this all looks like too much, you can always consider outsourcing the SD. There are criteria mentioned in ITIL about an outsourcing decision, consider them. Sometimes renting of an apartment is better then buying it. Rarely, though.