Giva Blog
Help Desk, Customer Service, Cloud & Security Insights, with a Side of Altruism!

User Support For Service Level Agreements

I was discussing creating a rough draft of the Service level Agreements and how to get all the departments in your organization on board. It will take time and work to get all the appropriate departments to agree that this is the right approach. Show them "what's in it for me". That's the best way to get cross functional consensus on your service level agreements. No customer service/call center or IT help desk software can do this work for you. Cultivate you allies in the organization. Explain the benefits of having Service Level Agreements from their perspective. Before sitting down with them, ask yourself, "how can Service level Agreements make these other departments succeed?" When you know the answer, run it by a few people to "reality test" it. Will these departments understand and believe the benefits?

If you have measured the actual case resolution times based on approximate severity levels and you have created a straw man SLA including this data, then you are ready to get the rest of your organization involved.

1. Meet with individual managers to explain how their department did on your test of priorities and response time.

2. Explain how the SLA goals will impact how they are already doing.

3. Use your existing allies within other service groups to prepare the way for broad acceptance.

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Creating Service Level Agreements (SLAs)-Part 2

1) Escalation procedures. State the escalation path and time for each severity level.

2) Telephone, Web and Email response times. For example: Phone requests will be answered in less than 20 seconds, Web requests within 30 seconds and email within four hours.

3) First contact resolution by the Support Center. For example: The Support Center will resolve at least 70% of all cases it receives.

4) Reporting methods.

a) Weekly management reports on the Web

b) Monthly performance metrics on the Web

c) Quarterly Customer Satisfaction Surveys results on the Web

5) SLA contract period.

a) When the current draft is effective

b) When it will be reviewed?

c) How to request changes

6) Examples of cases by severity level and case type.

7) Sample of the customer satisfaction survey questions.

 

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Definition of Service Level Agreements (SLAs) for IT Help Desk

Here is more on getting your SLA written.

1) Definition of terms. Do not assume that everyone will know what you are talking about. You need to define terms to the lowest common level. Be as specific as possible.

2) Service delivery elements

a) Service coverage times. State clearly what business hours are supported and what is supported after hours. Failure to do this will mean you can be called at any time of the night for the most minor of problems or requests. Be sure to consider the various time zones you cover. Keep consistent and list the time zone you are in (e.g., 7AM – 7PM EST).

b) Environment(s) included. What do you cover? If you only support standard hardware and software, be sure to state it here.

c) Environments excluded. If the Support Center will take cases for non-standard hardware and will charge back costs to the customer, then list that here.

d) Specific applications and network services coverage. List specific applications by name, the times they are supported and the times they are not supported. If there are maintenance windows for databases and servers when they will not be available, then make sure to list these windows.

e) Methods for requesting service. For example, for all level 1 and 2 cases the request for service may be via the phone. For example, for level 3 and 4 cases the request for service shall only be via the Web.

f) Customer responsibilities. Some examples are: How to submit a request, what standards are supported, and when customers should be available for the technician.

g) Service tracking and reporting procedures. Some examples are: IT will log 100% of all requests, phone calls will be randomly recorded for quality and performance metrics will be posted on the web.

 

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Creating Service Level Agreements (SLAs) for Customer Service

Creating a rough draft

There are several components to an SLA. It is important that the language is familiar to your environment. Use a straw man to introduce the concept to your organization. This will help the rest of the project team understand the complexity and importance. The following is an example of the categories that should be included in your SLA. However, remember that it must be clear, well written, and easy to read and not very long.

1) Introduction

a) Purpose of the SLA

b) Mission of IT (This is not just between the Support Center and customers)

c) Customers covered under the SLA

d) Locations

e) Owner of the SLA document and communications path

f) Services covered. This is only a high level statement.

2) Service Goal.

a) Overall goal. Example: Resolve 100% of all severity level 1 and 2 cases in the timeframe specified. This is the first place that you are making a statement about what is important. You cannot be a success treating all cases equally. Level 1 and 2 are high severity level cases that directly impact the productivity of a number of customers/locations of the company. You must make sure these get done on time. Getting the others done on time is a bonus.

b) Specific goals. List the severity levels and the time the case should be responded to and the time it should be resolved.

 

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Service Level Management- IT Service Desk

Here are some more reasons why service level agreements may not work. Here are a few lessons to remember as you make progress in your organization.

Gotcha! Service Level Management: Why it fails1

1. No alignment and buy in at all levels of management. It is important that all levels within the organization understand the value of implementing a service level management culture. Without this commitment throughout the organization, it will be difficult for the line staff to understand it, want to participate in it and for the Support Center staff to enforce it.

2. No existing Operational Level Agreements (OLA) within IT. Some organizations believe they can implement customer SLAs without first having established their own internal IT support OLAs. OLAs are basically a service level agreement between each service group. The Support Center should have an OLA between each service department it sends cases to.

3. Underestimating the scope. An organization implementing service level management must understand that this is a company-wide initiative. It will have impacts on staffing, technology, and the company’s culture. This is NOT a project assigned only to the Support Center.

 

1 Original article by Char LaBounty of LaBounty & Associates, Inc.

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm 

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Measuring Service Level Agreements- Mutual Expectations

Service Level Management is a formal way for setting customer expectations BEFORE the customer has the need to request service. It is a methodology for introducing and implementing reasonable expectations between you and the customers you support. These are most often contained in a document called a Service Level Agreement (SLA). The SLA establishes a two-way accountability for service, which is negotiated and mutually agreed upon. It is really a contract that documents operational and interpersonal relationships, establishes mutual expectations, and provides a standard to measure performance.

Without SLAs in place, you are effectively telling your customers that you will provide support to them, at any time, under any conditions, without any limitations to the systems and services they have. However, this is not the worst part. The worst part is that you cannot possibly ever meet your customers’ service expectations because every customer will have a different expectation and that expectation will change every time they call.

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm 

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Is My IT Help Desk Service Level Management Working?

There are a lot of reasons why service level agreements may not work. Here are a few lessons to remember as you make progress with your IT help desk or service desk organization.

Gotcha! Service Level Management: Why it fails1

1. Too Complex. The most common pitfall is that the SLA documents are too complex. These documents should be short and very precise in defining the services you provide and the level of service you and your customers agree on. If they are longer than 3-5 pages, then you are doing it wrong.

2. No measurements. If you do not have the technology and tool sets to track and report the timed-service events by responsiveness and resolution for the various severity level classifications, then SLAs will fail. Without continuous feedback on performance, the loop is incomplete and the SLAs become documents and nothing more.

3. Unrealistic management expectations. Often management does not acknowledge the amount of time needed to implement service level management, and therefore they do not staff it adequately. This cannot be a part time job! It must be managed full time.

4. Unrealistic objectives and goals. Frequently, IT management and customers set unrealistic objectives and goals. This usually happens because there were inadequate measurements done prior to implementing the SLA. It is critical to baseline the current service performance prior to beginning to negotiate the SLAs with customers.

 

1 Original article by Char LaBounty of LaBounty & Associates, Inc.

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm 

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Establishing Service Level Agreements (SLAs)

Here are a few more thoughts on how to get started establishing service level agreements in your organization.

Know your current support metrics. One of the biggest objections of those that provide service is an unwillingness to commit to service goals that cannot be met. The biggest objection of those receiving service from you is that you take too long in delivering the service. Both of these objections are based on “gut feelings.” If you have actual cycle times (time to resolve cases) by severity levels, then both of these objections go away. That is the power of real numbers. If you do not have a process in place for setting severity levels for cases, it is better to postpone the start of the project until you have done this. Set up your own guidelines within your Support Center team and then religiously assign severity levels for every case. You do not even have to tell anyone outside of the Support Center. You will be surprised by how much informal severity level setting is already taking place. This is also a good time for a customer satisfaction survey. It will provide a baseline for measuring improvements.

Can your IT help desk software measure time to respond and time to resolve Service Level Agreements? Your help desk software application will need to do this for you to be successful with managing service level agreements.

Team meeting. Hold a project team meeting to explain the goal and determine tasks and timelines. It is in the team meetings that many of the fears come out. If a support group says that the Support Center can not be accurate in setting the priorities, then ask them the following. Ask them to create a document with the types of cases they normally receive, the type of questions and documentation they need in the case and what the priorities should be by case types. This will be used to instruct the Support Center on setting priorities. When the Support Center does not set priorities correctly, you will want a process for notifying and training the individual who handled the case.

 

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm 

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

Service Level Agreements for IT Service Desks

Getting Started: Establishing An SLA

1. Understand the time commitment. Do not underestimate the time and commitment involved in this process. Your entire organization needs to be committed to implementing SLAs. Once you start this process, you are clearly defining your service commitment to your customers. The creation of an SLA is not just the function of the Support Center because it is not just an agreement between the Support Center and customers that call there for help. Ultimately, everyone in IT supports the customer through the Support Center. The Support Center will not only be setting customer expectations for cases it resolves, but also for those cases elevated to 2nd and 3rd level support groups. Everyone needs to be committed to the service goals of the SLA.

2. Understand your customers’ needs. Become familiar with your customer’s daily operations, processes, and business initiatives. Take time to develop a list of all services and products that require SLAs.

3. Identify participants. Identify all the stakeholders that should participate in the service management process. This includes your customers, as well as any other internal/external organizations that assist the Support Center in providing support to your customers. Be sure to include the decision-makers. While this task may seem daunting, this process is an excellent tool for building cross-departmental teams.

Here is a great White Paper on Implementing Service Level Agreements. See https://www.givainc.com/white-papers/index.htm 

Select Implementing Service Level Agreements: "The Critical Element in Service Delivery"

TCO-Call Center/Customer Service Cloud Software

The other day I talked about the TCO of Call Center/Customer Service & Help Desk Software-Acquisition Costs. The following is a listing of the important lifetime costs that you want to make sure you carefully quantify. Ask the vendors that you are considering to put together an analysis to show you what the TCO will be of their solution over 3 years. That is a reasonable time horizon. Most traditional software vendors will actually make you repurchase the entire application every 3 years or so. It is important that you understand this. Carefully read the software license agreements for this important detail. Annual Software Maintenance Agreements will only buy you incremental upgrades with moderate feature enhancements and bug fixes. They never include new User Interfaces and rewrites which are major product releases. How else do you think the traditional software industry has created so many billionaires and multimillionaires. Customers enjoying the economics of the SaaS model are saying the party is over. Are you taking advantage of this sea change or would you rather help your company pay for another software billionaire's yacht?

Here are the Lifetime Costs to consider:

Support Costs:

Cost for Support:

Call Tracking System and add-ons?

Database Support?

Day-to-Day Administration:

Average time to set up a security group?

Average time to add, change or delete users from their system accounts?

Average time to make changes to pull-down lists?

Can I make changes to the system during business hours?

Future Customization:

How much is involved and how long does it take to do a detailed design for changes?

Does any of the following require consulting services and average time to:

Add labeling to a view?

Resize a field?

Move a field?

Add a form?

Add a button?

Add a Menu?

Add a field to the database table?

Add a view?

Average time to modify views for display on different type platforms and monitor resolutions?

Workflow changes:

Average time to modify the way certain calls notify the service technician?

Does this require consulting programming costs or can it be done in house?

Average time to change the way certain calls are routed?

Average time to develop a feature that automatically creates multiple tickets (parent/child and predecessor/successor) based on workflow logic that is maintained by the service groups affected?

Average time to design, write, and debug triggers and stored procedures?

Average time to design, write and debug an application program integration (API) utility?

Average time to document changes made to the system and where are these stored?

Average time required for testing changes?

Are there utilities to help with the testing?

Once changes are made, average time for end users to review and gain acceptance?

Average time to move the changed functions from the development server to the production server?

Upgrades:

Are upgrades backward compatible?

Average time to test, and implement upgrades?

Do upgrades require consulting time? If so, what is the average cost?

People Costs:

Is the system reliable? How much downtime is anticipated a year?

Average time for a user to become proficient?

Ease of client installation?

Creating New Applications:

Do you have templates or down-loadable applications outside the help desk area?

If so, how much do they cost?

If not, how long does it take to create a simple application?

Network Costs:

Average time to log on and load the client program when close to server and from a distance?

What is the average length of time for a query to return 1000 calls when close to server and from a distance?

Average time to submit a call when close to server and from a distance?

If we go to multiple servers, what is the average cost for each server (Application, hardware, software, etc.)?

Will this take consulting to implement?

Do you integrate with network monitoring applications such as LanDESK or SMS?

What is the cost to integrate with a network monitoring application?

Future Application Integrations:

Do you have an Asset Management (AM) application? Cost to integrate?

Do you integrate with remote control/access applications? Cost to integrate?

Do you integrate with Autodiscovery applications to inventory software on the desktops? Cost to integrate?

Do you have a Change Management (CM) application? Cost to integrate?

Do you have a knowledge management application? Cost to integrate?

Do you integrate with enterprise financials such as SAP? Cost to integrate?

Do you integrate with Report Writing packages? Cost to integrate?

Do you integrate with two-way paging applications? Cost to integrate?

Do you integrate with palm computers such as Palm Pilot? Cost to integrate?

 

Newer Entires     1   ...   37   38   39   40   41   42   43     Older Entries