BMC Remedy Service Desk allows us to relate each support group to a support level. This classification comes from an ITIL recommendation. Most Remedy implementations declare the level of the support group but don’t utilize it extensively. It is easy that in a multi-tenancy environment each company uses it’s own classification criteria for support levels. Or worse, each Remedy administrator selects a level when creating the group almost randomly.
As in a lot of other configurations, having a consolidated criteria can provide us with a lot of information when analyzing the service.
In this post I will review the support level concept and provide a recommended classification.
ITIL Recommendation about support tiers
The ITIL recommendation about organizing support groups in tiers hasn’t changed from version 2 to version 3. The main idea that ITIL wants to transmit us is to classify the support staff in experience and scope. When a user reports an incident or service request it is first handled by all-purpose technicians, not experienced in any particular technology (cheaper staff). If the incident requires it, it can be escalated to more experienced users (more expensive). This approach minimizes the use of valuable resources to only needed situations, reducing the overall cost of the service, while maintaining quality.
To achieve it, each support group is classified in tiers, being tier one the first line (the ones that hang up the phone when the client calls). If tier one can’t resolve the issue, it is escalated to the proper tier 2. If tier 2 can’t resolve it, it goes to tier 3, etc.
A pragmatic approach
Normally support groups are not created by experience, but by technology. Inside your windows administration support group you can have senior and junior admins. Also there are more characteristics that must be considered when defining the support groups, like:
- Your groups schedule could be not homogeneous. Some groups can have 24×7 support and other only 8×5.
- Some groups will pertain to external companies, providing in-house support. This includes providers or manufacturers groups.
- Your groups can be localized.
Use of levels in BMC Remedy Foundation
When installing the application, five tiers are provided:
- Help Desk
- Tier 1
- Tier 2
- Tier 3
- Functional Tier
Let’s make a question: Why do you want to declare the levels of your support groups? I can give you the most important return: To classify incidents by difficulty, cost or anything related with the tier that solved the incident. It is a very informative KPI the percentage of incidents resolved at first line, second line, etc., being the objective to maximize the number of resolved incidents at first like. In fact I think that this KPI reports the performance of the problem management process, since a good documentation, allows the first line to resolve more incidents.
A classification example
This is my idea of a good classification in Remedy. You can use it directly or adapt it to your needs.
- Help Desk: Normally you will define only one support group as the help desk. This fact is aligned with the ITIL recommendation of defining a SPOC (Single Point of Contact). The Help Desk is the face with the clients. Is the people that hang up the phone and try to resolve incidents in first place. Normally Help Desk support group is also propietary of the incident.
- Tier 1: General use technicians. They are very similar to Help Desk level, with the next differences. They are localized and can go to the users location to resolve the incident. They can work remotely a large amount of time. Help Desk support members can’t dedicate a lot of time in an incident.
- Tier 2: Specialist, admins and experienced technicians. They are closely related to one or more technologies. Tier 2 members will only be used when the incident is not documented and Tier 1 members can’t resolve the issue. A Remedy Admin support group will fit in this line. Tier 2 support groups normally play an important role in other processes like problems and changes.
- Tier 3: Manufacturers, providers and developers. If your company is large enough to have in-house vendor support groups or you have developers of your own tools, then these groups will be classified as tier 3. These groups play important roles in problem and release management.
- Functional Tier: Not everything in your IT organization is IT. You can have procedures, business rules and other concepts that can create and resolve incidents. It is a good practice to create functional support groups. These groups are conformed by people outside your IT department. For instance imagine that you have an invoicing application. A user may want to create a duplicate invoice, but the button is grayed and disabled for one invoice. The user creates an incident thinking that this is an error, but there is a business rule that doesn’t allow it. A Tier 3 member will answer “It is grayed because the financial department requires it”. But you can have a support group of key financial users that can answer a more elaborated answer or even raise a problem or RFC if see an error in procedures.
Final Recommendation
You can use this classification or not. Anyway, define one criteria and spread it over your organization to consolidate it. It will be very usefull when you create reports and say that 60 % of incidents are solved at Help Desk level, because it has a meaning.
