While this story is funny at first blush; at a deeper core level, it also highlights the absolute importance of the service desk team members asking the right questions. Reasons abound to support the importance of asking the right questions. Let us examine some of the most popular reasons and theories.

First, a major issue shared by most service desks is the overwhelmingly high volume of calls, which usually results in longer wait times for customers. Wait time is the number one complaint that customers have about the service desk, and anything that can speed up this process will undoubtedly increase customer satisfaction. Thus, it is extremely important that when a customer does speak with a service desk team member, that the team member can quickly diagnose the problem and get the proper technician or department involved. The ultimate effectiveness of this series of actions is foremost dependent upon “correctly understanding the problem.”

Therefore, regardless of how frantic or chatty a customer may be in explaining the problem, the service desk analyst must ensure that he or she has systematically asked the standardized questions designed to diagnose the problem and then guides the customer towards the correct solution. Moreover, diagnosing the problem correctly the first time will speed up wait time significantly because an incident ticket will not be sent to the wrong assignment group—thus eliminating the customer’s need to waste time waiting in the wrong group’s queue or to repeat his or her stories to a new support engineer.

Furthermore, collecting data metrics on your products is an intricate part of any business model. Data collection regarding service support normally comes from two areas: 1) the service desk and 2) the service provider.

Using Information Technology Service Management (ITSM) software, the service desk logs an incident under a certain category when the call comes in, and the service provider engineer will log the problem under the appropriate resolution category when the incident is resolved. Thus, managers can review and decide where they need to spend money on resolving product issues, either by patches or upgrades. If your service desk is misdiagnosing the incidents, or not quite fully understanding the incidents and miscategorizing them; as a result, the manager will not receive the accurate and precise metrics that they require. Thus, the whole company becomes affected for many change releases because the proper resources were not working on the right problems. This whole process begins with your service desk team members asking the right questions and ensuring that they completely understand the problems being explained by the customers.

Finally, one of the main objectives of your service desk is to instill customer confidence. When a good service desk member quickly guides a customer through explaining his or her problems, and then either resolves the incident or connects the customer to the correct service provider for resolution, the customer gains great confidence in both the product, and, by extension, the company. However, as a manager, you do not want customer confidence to be exclusively dependent on the temperament of your service desk team members. While you may have a fantastic service desk team, every member has bad days, and every team member makes mistakes. Thus, it is extremely important that the service desk manager has good service desk practices that ensure the proper and standardized questions will be asked up front—every single time; and that each and every problem will get answered and resolved in a timely manner. Moreover, the incident will be logged under the proper category; and if it is a reoccurring problem, it will be addressed in the form of future patches and versions.

In sum, the first contact with the customer is important because it affects the entire service desk process. Additionally, it is equally important for service desk managers to ensure that their service desk team members are asking the right questions. Many service desk managers often overlook and underestimate this aspect of the service desk. If you already have a good bank of clear and concise questions, make sure you continually review and test these questions to validate that they are still the right ones. Otherwise, the whole company will eventually be affected.

Share on Facebook

While this is a good definition for someone who understands the vernacular of ITIL, it isn’t easily understood by the layman. Let’s dissect the definition and put it into terms the general population can understand. The IT Service provider is the organization that has been hired by the Customer to perform a service, for example, answer calls. The service level agreement is the document, which can be a few brief lines or it can be a hundreds of pages, which describes each service level target(s). These service targets are based on the customers business needs. For example, if Large Corp. sells their products worldwide, they may have a need to have a call center that is available 24×7. This one business objective, call center available 24×7, could produce multiple service level targets such as:

Call Center is available to take calls 99.99% of the time each month.

No more than 5% of calls will abandon each month.

99% of all incoming calls must be answered within 30 seconds.

All of the service level targets must be agreed upon by both parties. Once both parties agree to all of the service level targets, they are assembled into the Service Level Agreement document. The service level targets will each have a description that identifies the expectation, how it will be measured and penalties, if missed. For example:

Call center must answer all incoming calls within 30 seconds

Measurement period: 1 month

Report(s): ASA Report 101 – monthly

Penalty: $10,000

The SLA is a joint goal between the IT Service Provider and the Customer. Although penalties do reduce costs and they do send a strong signal to service providers to improve their service, neither you nor the service provider “win” if an SLA is missed. Think of an SLA as a shared goal.

It should be noted that the term Service Level Agreement is used in many companies when discussing agreements between two internal groups, such as the Procurement Department will process all purchase requests by the Engineering Department within 5 business days. Technically, per ITIL, this is not a Service Level Agreement, but instead an Operational Level Agreement.

Share on Facebook