Analyst Perspective

"Customer service issues are rarely based on personality but are almost always a symptom of poor and inconsistent process. When service desk managers are looking to hire to resolve customer service issues and executives are pushing back, it’s time to look at improving process and the support strategy to make the best use of technicians’ time, tools, and knowledge sharing. Once improvements have been made, it’s easier to make the case to add people or introduce automation.

Replacing service desk solutions will also highlight issues around poor process. Without fixing the baseline services, the new solution will simply wrap your issues in a prettier package.

Ultimately, the service desk needs to be the entry point for users to get help and the rest of IT needs to provide the appropriate support to ensure the first line of interaction has the knowledge and tools they need to resolve quickly and preferably on first contact. If your plans include optimization to self-serve or automation, you’ll have a hard time getting there without standardizing first."

Sandi Conrad

Principal Research Director, Infrastructure & Operations Practice

Info-Tech Research Group

A method for getting your service desk out of firefighter mode

This Research Is Designed For:

• The CIO and senior IT management who need to increase service desk effectiveness and timeliness and improve end-user satisfaction.
• The service desk manager who wants to lead the team from firefighting mode to providing consistent and proactive support.

This Research Will Also Assist:

• Service desk teams who want to increase their own effectiveness and move from a help desk to a service desk.
• Infrastructure and applications managers who want to decrease reactive support activities and increase strategic project productivity by shifting repetitive and low-value work left.

This Research Will Help You:

• Create a consistent customer service experience for service desk patrons.
• Increase efficiency, first-call resolution, and end-user satisfaction with the Service Desk.
• Decrease time and cost to resolve service desk tickets.
• Understand and address reporting needs to address root causes and measure success.
• Build a solid foundation for future IT service improvements.

Executive Summary

Situation

• The CIO and senior IT management who need to increase service desk effectiveness and timeliness and improve end-user satisfaction.
• If only the phone could stop ringing, the Service Desk could become proactive, address service levels, and improve end-user IT satisfaction.

Complication

• Not everyone embraces their role in service support. Specialists would rather work on projects than provide service support.
• The Service Desk lacks processes and workflows to provide consistent service. Service desk managers struggle to set and meet service-level expectations, which further compromises end-user satisfaction.

Resolution

• Go beyond the blind adoption of best-practice frameworks. No simple formula exists for improving service desk maturity. Use diagnostic tools to assess the current state of the Service Desk. Identify service support challenges and draw on best-practice frameworks intelligently to build a structured response to those challenges.
• An effective service desk must be built on the right foundations. Understand how:
  • Service desk structure affects cost and ticket volume capacity.
  • Incident management workflows can improve ticket handling, prioritization, and escalation.
  • Request fulfillment processes create opportunities for streamlining and automating services.
  • Knowledge sharing supports the processes and workflows essential to effective service support.

Info-Tech Insight

Service desk improvement is an exercise in organizational change. Engage specialists across the IT organization in building the solution. Establish a single service-support team across the IT group and enforce it with a cooperative, customer-focused culture. Don’t be fooled by a tool that’s new. A new service desk tool alone won’t solve the problem. Service desk maturity improvements depend on putting in place the right people and processes to support the technology

Directors and executives understand the importance of the service desk and believe IT can do better

Source: Info-Tech, 2019 Responses (N=189 organizations)

Service Desk Importance Scores

No Importance: 1.0-6.9

Limited Importance: 7.0-7.9

Significant Importance: 8.0-8.9

Critical Importance: 9.0-10.0

Service Desk Effectiveness Scores

Not in Place: N/A

Not Effective: 0.0-4.9

Somewhat Ineffective: 5.0-5.9

Somewhat Effective: 6.0-6.9

Very Effective: 7.0-10.0

Info-Tech Research Group’s IT Management and Governance Diagnostic (MGD) program assesses the importance and effectiveness of core IT processes. Since its inception, the MGD has consistently identified the service desk as an area to leverage.

Having an effective and timely service desk correlates with higher end-user satisfaction with all other IT services

On average, organizations that were satisfied with service desk effectiveness rated all other IT processes 46% higher than dissatisfied end users.

Organizations that were satisfied with service desk timeliness rated all other IT processes 37% higher than dissatisfied end users.

“Satisfied” organizations had average scores =8.“Dissatisfied" organizations had average scores “Dissatisfied" organizations had average scores =6. Source: Info-Tech Research Group, 2019 (N=18,500+ respondents from 75 organizations)

Standardize the service desk the Info-Tech way to get measurable results

More than one hundred organizations engaged with Info-Tech, through advisory calls and workshops, for their service desk projects in 2016. Their goal was either to improve an existing service desk or build one from scratch.

Organizations that estimate the business impact of each project phase help us shed light on the average measured value of the engagements.

"The analysts are an amazing resource for this project. Their approach is very methodical, and they have the ability to fill in the big picture with detailed, actionable steps. There is a real opportunity for us to get off the treadmill and make real IT service management improvements"

- Rod Gula, IT Director

American Realty Advisors

Info-Tech’s approach to service desk standardization focuses on building service management essentials

Info-Tech draws on the COBIT framework, which focuses on consistent delivery of IT services across the organization

The service desk is the foundation of all other service management processes.

Standardize the Service Desk – project overview

Info-Tech delivers: Use our tools and templates to accelerate your project to completion

Project Summary

Service Desk Standard Operating Procedures

Service Desk Maturity Assessment Tool

Service Desk Implementation Roadmap

Incident, knowledge, and request management workflows

Workshop Overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Step 1.1:Assess current state

Standardizing the service desk benefits the whole business

Embrace standardization

• Standardization prevents wasted energy on reinventing solutions to recurring issues.
• Standardized processes are scalable so that process maturity increases with the size of your organization.

Increase business satisfaction

• Improve confidence that the service desk can meet service levels.
• Create a single point of contact for incidents and requests and escalate quickly.
• Analyze trends to forecast and meet shifting business requirements.

Reduce recurring issues

• Create tickets for every task and categorize them accurately.
• Generate reliable data to support root-cause analysis.

Increase efficiency and lower operating costs

• Empower end users and technicians with a targeted knowledgebase (KB).
• Cross-train to improve service consistency.

Assess current service desk maturity to establish a baseline and create a plan for service desk improvement

A current-state assessment will help you build a foundation for process improvements. Current-state assessments follow a basic formula:

1. Determine the current state of the service desk.
2. Determine the desired state of the service desk.
3. Build a practical path from current to desired state.

Ideally, the current-state assessment should align the delivery of IT services with organizational needs. The assessment should achieve the following goals:

1. Identify service desk pain points.
2. Map each pain point to business services.
3. Assign a broad business value to the resolution of each pain point.
4. Map each pain point to a process.

Expert Insight

“How do you know if you aren’t mature enough? Nothing – or everything – is recorded and tracked, customer satisfaction is low, frustration is high, and there are multiple requests and incidents that nobody ever bothers to address.”

Rob England

IT Consultant & Commentator

Owner Two Hills

Also known as The IT Skeptic

Assess the process maturity of the service desk to determine which project phase and steps will bring the most value

1.1.2 Measure which activity will have the greatest impact

The Service Desk Maturity Assessmenttool helps organizations assess their service desk process maturity and focus the project on the activities that matter most.

The tool will help guide improvement efforts and measure your progress.

• The second tab of the tool walks through a qualitative assessment of your service desk practices. Questions will prompt you to evaluate how you are executing key activities. Select the answer in the drop-down menus that most closely aligns with your current state.
• The third tab displays your rate of process completeness and maturity. You will receive a score for each phase, an overall score, and advice based on your performance.
• Document the results of the efficiency assessment in the Service Desk Project Summary.

The tool is intended for periodic use. Review your answers each year and devise initiatives to improve the process performance where you need it most.

Where do I find the data?

Consult:

• Service Manager
• Service Desk Tools

Step 1.2:Review service support best practices

This step will walk you through the following activities:

1. 1.2.1 Identify roles and responsibilities in your organization
2. 1.2.2 Map out the current and target structure of the service desk

This step involves the following participants:

• Project Sponsor
• IT Director, CIO
• IT Managers and Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

Identifying who is accountable for different support practices in the service desk will allow workload to be distributed effectively between functional teams and individuals. Closing the gaps in responsibilities will enable the execution of a shift-left strategy.

Deliverables

• Roles & responsibilities guide
• Service desk structure

A RACI chart outlines which positions are Responsible, Accountable, Consulted, and Informed

Build a single point of contact for the service desk

Regardless of the service desk structure chosen to meet your service support requirements, end users should be in no doubt about how to access the service.

Provide end users with:

• A single phone number.
• A single email address.
• A single web portal for all incidents and requests.

A single point of contact will ensure:

• An agent is available to field incidents and requests.
• Incidents and requests are prioritized according to impact and urgency.
• Work is tracked to completion.

This prevents ad hoc ticket channels such as shoulder grabs or direct emails, chats, or calls to a technician from interrupting work.

A single point of contact does not mean the service desk is only accessible through one intake channel, but rather all tickets are directed to the service desk (i.e. tier 1) to be resolved or redirected appropriately.

Build a tiered generalist service desk to optimize costs

A tiered generalist service desk with a first-tier resolution rate greater than 60% has the best operating cost and customer satisfaction of all competing service desk structural models.

The success of a tiered generalist model depends on standardized, defined processes

Define the structure of the service desk

1.2.2 Map out the current and target structure of the service desk

Estimated Time: 45 minutes

Instructions:

1. Using the model from the previous slides as a guide, discuss how closely it matches the current service desk structure.
2. Map out a similar diagram of your existing service desk structure, intake channels, and escalation paths.
3. Review the structure and discuss any changes that could be made to improve efficiency. Revise as needed.
4. Document the outcome in the Service Desk Project Summary.

Participants

• CIO
• IT Managers
• Service Desk Manager
• Service Desk Agents

Use a shift-left strategy to lower service support costs, reduce time to resolve, and improve end-user satisfaction

Shift-left strategy:

• Shift service support tasks from specialists to generalists.
• Implement self-service.
• Automate incident resolution.

Work through the implications of adopting a shift-left strategy

Overview:

Identify process gaps that you need to fill to support the shift-left strategy and discuss how you could adopt or improve the shift-left strategy, using the discussion questions below as a guide.

Which process gaps do you need to fill to identify ticket trends?

• What are your most common incidents and service requests?
• Which tickets could be resolved at tier 1?
• Which tickets could be resolved as self-service tickets?
• Which tickets could be automated?

Which processes do you most need to improve to support a shift-left strategy?

• Which incident and request processes are well documented?
• Do you have recurring tickets that could be automated?
• What is the state of your knowledgebase maintenance process?
• Which articles do you most need to support tier 1 resolution?
• What is the state of your web portal? How could it be improved to support self-service?

Document in the Project Summary

Step 1.3: Identify service desk metrics and reports

This step will walk you through the following activities:

• 1.3 Create a list of required reports to identify relevant metrics

This step involves the following participants:

• Project Sponsor
• IT Managers and Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

Managers and analysts will have service desk metrics and reports that help set expectations and communicate service desk performance.

Deliverables

• A list of service desk performance metrics and reports

Engage business unit leaders with data to appreciate needs

Service desk reports are an opportunity to communicate the story of IT and collect stakeholder feedback. Interview business unit leaders and look for opportunities to improve IT services.

Start with the following questions:

• What are you hearing from your team about working with IT?
• What are the issues that are contributing to productivity losses?
• What are the workarounds your team does because something isn’t working?
• Are you able to access the information you need?

Work with business unit leaders to develop an action plan.

Remember to communicate what you do to address stakeholder grievances.

The service recovery paradox is a situation in which end users think more highly of IT after the organization has corrected a problem with their service compared to how they would regard the company if the service had not been faulty in the first place.

The point is that addressing issues (and being seen to address issues) will significantly improve end-user satisfaction. Communicate that you’re listening and acting, and you should see satisfaction improve.

Info-Tech Insight

Presentation is everything:

If you are presenting outside of IT, or using operational metrics to create strategic information, be prepared to:

• Discuss trends.
• Identify organizational and departmental impacts.
• Assess IT costs and productivity.

For example, “Number of incidents with ERP system has decreased by 5% after our last patch release. We are working on the next set of changes and expect the issues to continue to decrease.”

Engage technicians to ensure they input quality data in the service desk tool

You need better data to address problems. Communicate to the technical team what you need from them and how their efforts contribute to the usefulness of reports.

Tickets MUST:

• Be created for all incidents and service requests.
• Be categorized correctly, and categories updated when the ticket is resolved.
• Be closed after the incidents and service requests are resolved or implemented.

Emphasize that reports are analyzed regularly and used to manage costs, improve services, and request more resources.

Info-Tech Insight

Service Desk Manager: Technical staff can help themselves analyze the backlog and improve service metrics if they’re looking at the right information. Ensure their service desk dashboards are helping them identify high-priority and quick-win tickets and anticipate potential SLA breaches.

Produce service desk reports targeted to improve IT services

Use metrics and reports to tell the story of IT.

Metrics should be tied to business requirements and show how well IT is meeting those requirements and where obstacles exist.

Tailor metrics and reports to specific stakeholders.

Technicians require mostly real-time information in the form of a dashboard, providing visibility into a prioritized list of tickets for which they are responsible.

Supervisors need tactical information to manage the team and set client expectations as well as track and meet strategic goals.

Managers and executives need summary information that supports strategic goals. Start by looking at executive goals for the support team and then working through some of the more tactical data that will help support those goals.

One metric doesn’t give you the whole picture

• Don’t put too much emphasis on a single metric. At best, it will give you a distorted picture of your service desk performance. At worst, it will distort the behavior of your agents as they may adopt poor practices to meet the metric.
• The solution is to use tension metrics: metrics that work together to give you a better sense of the state of operations.
• Tension metrics ensure a balanced focus toward shared goals.

Example:

First-call resolution (FCR), end-user satisfaction, and number of tickets reopened all work together to give you a complete picture. As FCR goes up, so should end-user satisfaction, as number of tickets re-opened stays steady or declines. If the three metrics are heading in different directions, then you know you have a problem.

Rely on internal metrics to measure and improve performance

External metrics provide useful context, but they represent broad generalizations across different industries and organizations of different sizes. Internal metrics measured annually are more reliable.

Internal metrics provide you with information about your actual performance. With the right continual improvement process, you can improve those metrics year over year, which is a better measure of the performance of your service desk.

Whether a given metric is the right one for your service desk will depend on several different factors, not the least of which include:

• The maturity of your service desk processes.
• Your ticket volume.
• The complexity of your tickets.
• The degree to which your end users are comfortable with self-service.

Info-Tech Insight

Take external metrics with a grain of salt. Most benchmarks represent what service desks do across different industries, not what they should do. There also might be significant differences between different industries in terms of the kinds of tickets they deal with, differences which the overall average obscures.

Use key service desk metrics to build a business case for service support improvements

The right metrics can tell the business how hard IT works and how many resources it needs to perform:

1. End-User Satisfactions:
   • The most important metric for measuring the perceived value of the service desk. Determine this based on a robust annual satisfaction survey of end users and transactional satisfaction surveys sent with a percentage of tickets.
2. Ticket Volume and Cost per Ticket:
   • A key indicator of service desk efficiency, computed as the monthly operating expense divided by the average ticket volume per month.
3. First-Contact Resolution Rate:
   • The biggest driver of end-user satisfaction. Depending on the kind of tickets you deal with, you can measure first-contact, first-tier, or first-day resolution.
4. Average Time to Resolve (Incident) or Fulfill (Service Requests):
   • An assessment of the service desk's ability to resolve tickets effectively, measuring the time elapsed between the moment the ticket status is set to “open” and the moment it is set to “resolved.”

Info-Tech Insight

Metrics should be tied to business requirements. They tell the story of how well IT is meeting those requirements and help identify when obstacles get in the way. The latter can be done by pointing to discrepancies between the internal metrics you expected to reach but didn’t and external metrics you trust.

Use service desk metrics to track progress toward strategic, operational, and tactical goals

Cost per ticket and customer satisfaction are the foundation metrics of service support

Ultimately, everything boils down to cost containment (measured by cost per ticket) and quality of service (measured by customer satisfaction).

Cost per ticket is a measure of the efficiency of service support:

• A higher than average cost per ticket is not necessarily a bad thing, particularly if accompanied by higher-than-average quality levels.
• Conversely, a low cost per ticket is not necessarily good, particularly if the low cost is achieved by sacrificing quality of service.

Cost per ticket is the total monthly operating expense of the service desk divided by the monthly ticket volume. Operating expense includes the following components:

• Salaries and benefits for desktop support technicians
• Salaries and benefits for indirect personnel (team leads, supervisors, workforce schedulers, dispatchers, QA/QC personnel, trainers, and managers)
• Technology expense (e.g. computers, software licensing fees)
• Telecommunications expenses
• Facilities expenses (e.g. office space, utilities, insurance)
• Travel, training, and office supplies

Create a list of required reports to identify metrics to track

1.3.1 Start by identifying the reports you need, then identify the metrics that produce them

1. Answer the following questions to determine the data your reports require:
   • What strategic initiatives do you need to track?
     • Example: reducing mean time to resolve, meeting SLAs
   • What operational areas need attention?
     • Example: recurring issues that need a permanent resolution
   • What kind of issues do you want to solve?
     • Example: automate tasks such as password reset or software distribution
   • What decisions or processes are held up due to lack of information?
     • Example: need to build a business case to justify infrastructure upgrades
   • How can the data be used to improve services to the business?
     • Example: recurring issues by department
2. Document report and metrics requirements in Service Desk SOP.
3. Provide the list to your tool administrator to create reports with auto-distribution.

Participants

• CIO
• IT Managers
• Service Desk Manager
• Service Desk Agents

What You'll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Step 1.4: Review ticket handling procedures

This step will walk you through the following activities:

• 1.4.1 Review ticket handling practices
• 1.4.2 Identify opportunities to automate ticket creation and reduce recurring tickets

This step involves the following participants:

• Project Sponsor
• IT Managers and Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

Managers and analysts will have best practices for ticket handling and troubleshooting to support ITSM data quality and improve first-tier resolution.

DELIVERABLES

• List of ticket templates and recurring tickets
• Ticket and Call QA Template and ticket handling best practices

Start by reviewing the incident intake process to find opportunities for improvement

If end users are avoiding your service desk, you may have an intake problem. Create alternative ways for users to seek help to manage the volume; keep in mind not every request is an emergency.

Identify opportunities for improvement in your ticket channels

The two most efficient intake channels should be encouraged for the majority of tickets.

• Build a self-service portal.
  • Do users know where to find the portal?
  • How many tickets are created through the portal?
  • Is the interface easy to use?
• Deal efficiently with email.
  • How quickly are messages picked up?
  • Are they manually transferred to a ticket or does the service desk tool automatically create a ticket?

The two most traditional and fastest methods to get help must deal with emergencies and escalation effectively.

• Phone should be the fastest way to get help for emergencies.
  • Are enough agents answering calls?
  • Are voicemails picked up on time?
  • Are the automated call routing prompts clear and concise?
• Are walk-ins permitted and formalized?
  • Do you always have someone at the desk?
  • Is your equipment secure?
  • Are walk-ins common because no one picks up the phone or is the traffic as you’d expect?

Ensure technicians create tickets for all incidents and requests

Why Collect Ticket Data?

If many tickets are missing, help service support staff understand the need to collect the data. Reports will be inaccurate and meaningless if quality data isn’t entered into the ticketing system.

Set ticket handling expectations to drive a consistent process

Set expectations:

• Create and update tickets, but not at the expense of good customer service. Agents can start the ticket but shouldn’t spend five minutes creating the ticket when they should be troubleshooting the problem.
• Update the ticket when the issue is resolved or needs to be escalated. If agents are escalating, they should make sure all relevant information is passed along to the next technician.
• Update user of ETA if issue cannot be resolved quickly.
• Ticket templates for common incidents can lead to fast creation, data input, and categorizations. Templates can reduce the time it takes to create tickets from two minutes to 30 seconds.
• Update categories to reflect the actual issue and resolution.
• Reference or link to the knowledgebase article as the documented steps taken to resolve the incident.
• Validate incident is resolved with client; automate this process with ticket closure after a certain time.
• Close or resolve the ticket on time.

Use the Ticket and Call Quality Assessment Tool to improve the quality of service desk data

Build a process to check-in on ticket and call quality monthly

Better data leads to better decisions. Use the Ticket and Call Quality Assessment Toolto check-in on the ticket and call quality monthly for each technician and improve service desk data quality.

1. Fill tab 1 with technician’s name.
2. Use either tab 2 (auto-scoring) or tab 3 (manual scoring) to score the agent. The assessment includes ticket evaluation, call evaluation, and overall metric.
3. Record the results of each review in the score summary of tab 1.

Use ticket templates to make ticket creation, updating, and resolution more efficient

Implement measures to improve ticket handling and identify ticket template candidates

1.4.1 Identify opportunities to automate ticket creation

1. Poll the team and discuss.
   • How many members of the team are not creating tickets? Why?
   • How can we address those barriers?
   • What are the expectations of management?
2. Brainstorm five to ten good candidates for ticket templates.
   • What data can auto-fill?
   • What will help process the ticket faster?
   • What automations can we build to ensure a fast, consistent service?
   • Note:
     • Ticket template name
     • Information that will auto-fill from AD and other applications
     • Categories and resolution codes
     • Automated routing and email responses
3. Document ticket template candidates in the Service Desk Roadmap to capture the actions.

Participants

• Service Desk Manager
• Service Desk Agents

What You'll Needs

• Flip Chart
• Whiteboard

Phase 2

Design Incident Management Processes

Step 2.1: Build incident management workflows

This step will walk you through the following activities:

• 2.1.1 Review incident management challenges
• 2.1.2 Define the incident management workflow
• 2.1.3 Define the critical incident management workflow
• 2.1.4 Design critical incident communication plan

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

Workflows for incident management and critical incident management will improve the consistency and quality of service delivery and prepare the service desk to negotiate reliable service levels with the organization.

DELIVERABLES

• Incident management workflows
• Critical incident management workflows
• Critical incident communication plan

Communicate the great incident resolution work that you do to improve end-user satisfaction

End users think more highly of IT after the organization has corrected a problem with their service than they would have had the service not been faulty in the first place.

Info-Tech Insight

Use the service recovery paradox to your advantage. Address service desk challenges explicitly, develop incident management processes that get services back online quickly, and communicate the changes.

If you show that the service desk recovered well from the challenges end users raised, you will get greater loyalty from them.

Assign incident roles and responsibilities to promote accountability

The role of an incident coordinator or manager can be assigned to anyone inside the service desk that has a strong knowledge of incident resolution, attention to detail, and knows how to herd cats.

In organizations with high ticket volumes, a separate role may be necessary.

Everyone must recognize that incident management is a cross-IT organization process and it does not have to be a unique service desk process.

An incident coordinator is responsible for:

• Improving incident management processes.
• Tracking metrics and producing reports.
• Developing and maintaining the incident management system.
• Developing and maintaining critical incident processes.
• Ensuring the service support team follows the incident management process.
• Gathering post-mortem information from the various technical resources on root cause for critical or severity 1 incidents.

The Director of IT Services invested in incident management to improve responsiveness and set end-user expectations

Practitioner Insight

Ben Rodrigues developed a progressive plan to create a responsive, service-oriented culture for the service support organization.

"When I joined the organization, there wasn’t a service desk. People just phoned, emailed, maybe left [sticky] notes for who they thought in IT would resolve it. There wasn’t a lot of investment in developing clear processes. It was ‘Let’s call somebody in IT.’

I set up the service desk to clarify what we would do for end users and to establish some SLAs.

I didn’t commit to service levels right away. I needed to see how many resources and what skill sets I would need. I started by drafting some SLA targets and plugging them into our tracking application. I then monitored how we did on certain things and established if we needed other skill sets. Then I communicated those SOPs to the business, so that ‘if you have an issue, this is where you go, and this is how you do it,’ and then shared those KPIs with them.

I had monthly meetings with different function heads to say, ‘this is what I see your guys calling me about,’ and we worked on something together to make some of the pain disappear."

-Ben Rodrigues

Director, IT Services

Gamma Dynacare

Sketch out incident management challenges to focus improvements

Common Incident Management Challenges

End Users

• No faith in the service desk beyond speaking with their favorite technician.
• No expectations for response or resolution time.
• Non-IT staff are disrupted as people ask their colleagues for IT advice.

Technicians

• No one manages and escalates incidents.
• Incidents are unnecessarily urgent and more likely to have a greater impact.
• Agents are flooded with requests to do routine tasks during desk visits.
• Specialist support staff are subject to constant interruptions.
• Tickets are lost, incomplete, or escalated incorrectly.
• Incidents are resolved from scratch rather than referring to existing solutions.

Managers

• Tickets are incomplete or lack historical information to address complaints.
• Tickets in system don’t match the perceived workload.
• Unable to gather data for budgeting or business analysis.

Info-Tech Insight

Consistent incident management processes will improve end-user satisfaction with all other IT services.

However, be prepared to overcome these common obstacles as you put the process in place, including:

• Absence of management or staff commitment.
• Lack of clarity on organizational needs.
• Outdated work practices.
• Poorly defined service desk goals and responsibilities.
• Lack of a reliable knowledgebase.
• Inadequate training.
• Resistance to change.

Prepare to implement or improve incident management

2.1.1 Review incident management challenges and metrics

1. Review your incident management challenges and the benefits of addressing them.
2. Review the level of service you are providing with the current resources. Define clear goals and deliverables for the improvement initiative.
3. Decide how the incident management process will interface with the service desk. Who will take on the responsibility for resolving incidents? Specifically, who will:
   • Log incidents.
   • Perform initial incident troubleshooting.
   • Own and monitor tickets.
   • Communicate with end users.
   • Update records with the resolution.
   • Close incidents.
   • Implement next steps (e.g. initiate problem management).
4. Document recommendations and the incident management process requirements in the Service Desk SOP.

Participants

• Service Desk Manager
• Service Desk Agents

What You’ll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Distinguish between different kinds of tickets for better SLAs

Different ticket types are associated with radically different prioritization, routing, and service levels. For instance, most incidents are resolved within a business day, but requests take longer to implement.

If you fail to distinguish between ticket types, your metrics will obscure service desk performance.

Common Service Desk Tickets

• Incidents
  • An unanticipated interruption of a service.
    • The goal of incident management is to restore the service as soon as possible, even if the resolution involves a workaround.
• Problems
  • The root cause of several incidents.
    • The goal of problem management is to detect the root cause and provide long-term resolution and prevention.
• Requests
  • A generic description for small changes or service access
    • Requests are small, frequent, and low risk. They are best handled by a process distinct from incident, change, and project management.
• Changes
  • Modification or removal of anything that could influence IT services.
    • The scope includes significant changes to architectures, processes, tools, metrics, and documentation.

Info-Tech Insight

Organizations sometimes mistakenly classify small projects as service requests, which can compromise your data, resulting in a negative impact to the perceived value of the service desk.

Separate incidents and service requests for increased customer service and better-defined SLAs

Defining the differences between service requests and incidents is not just for reporting purposes. It also has a major impact on how service is delivered.

Incidents are unexpected disruptions to normal business processes and require attempts to restore services as soon as possible (e.g. the printer is not working).

Service requests are tasks that don’t involve something that is broken or has an immediate impact on services. They do not require immediate resolution and can typically be scheduled (e.g. new software).

Focus on the big picture first to capture and streamline how your organization resolves incidents

Document your incident management workflow to identify opportunities for improvement

Workflow should include:

• Ticket creation and closure
• Triage
• Troubleshooting
• Escalations
• Communications
• Change management
• Documentation
• Vendor escalations

Notes:

• Notification and alerts should be used to set or reset expectations on delivery or resolution
• Identify all the steps where a customer is informed and ensure we are not over or under communicating

Collaborate to define each step of the incident management workflow

2.1.2 Define the incident management workflow

Estimated Time: 60 minutes

Option 1: Whiteboard

1. Discuss the workflow and draw it on the whiteboard.
2. Assess whether you are using the best workflow. Modify it if necessary.
3. Engage the team in refining the process workflow.
4. Transfer data to Visio and add to the SOP.

Option 2: Tabletop Exercise

1. Distribute index cards to each member of the team.
2. Have each person write a single task they perform on the index card. Be granular. Include the title or the name of the person responsible.
3. Mark cards that are decision points. Use a card of a different color or use a marker to make a colored dot.
4. Arrange the index cards in order, removing duplicates.
5. Assess whether you are using the best workflow. Engage the team to refine it if necessary.
6. Transfer data to Visio and add to the Service Desk SOP.

Participants

• Service Manager
• Service Desk Support
• Applications or Infrastructure Support

What You’ll Need

• Flip Chart Paper
• Sticky Notes
• Pens
• Service Desk SOP
• Project Summary

Formalize the process for critical incident management to reduce organizational impact

Discuss these elements to see how the organization will handle them.

• Communication plan:
  • Who communicates with end users?
  • Who communicates with the executive team?
It’s important to separate the role of the technician trying to solve a problem with the need to communicate progress.
• Change management:
Define a separate process for regular and emergency change management to ensure changes are timely and appropriate.
• Business continuity plan:
Identify criteria to decide when a business continuity plan (BCP) must be implemented during a critical incident to minimize the business impact of the incident.
• Post-mortems:
Formalize the process of discussing and documenting lessons learned, understanding outstanding issues, and addressing the root cause of incidents.
• Source of incident notification:
Does the process change if users notify the service desk of an issue or if the systems management tools alert technicians?

Critical incidents are high-impact, high-urgency events that put the effectiveness and timeliness of the service desk center stage.

Build a workflow that focuses on quickly bringing together the right people to resolve the incident and reduces the chances of recurrence.

Document your critical incident management workflow to identify opportunities for improvement

Workflow should include:

• Ticket creation and closure
• Triage
• Troubleshooting
• Escalations
• Communications plan
• Change management
• Disaster recovery or business continuity plan
• Documentation
• Vendor escalations
• Post-mortem

Collaborate to define each step of the critical incident management workflow

2.1.3 Define the critical incident management workflow

Estimated Time: 60 minutes

Option 1: Whiteboard

1. Discuss the workflow and draw it on the whiteboard.
2. Assess whether you are using the best workflow. Modify it if necessary.
3. Engage the team in refining the process workflow.
4. Transfer data to Visio and add to the SOP.

Option 2: Tabletop Exercise

1. Distribute index cards to each member of the team.
2. Have each person write a single task they perform on the index card. Be granular. Include the title or the name of the person responsible.
3. Mark cards that are decision points. Use a card of a different color or use a marker to make a colored dot.
4. Arrange the index cards in order, removing duplicates.
5. Assess whether you are using the best workflow. Engage the team to refine it if necessary.
6. Transfer data to Visio and add to the Service Desk SOP.

Participants

• Service Manager
• Service Desk Support
• Applications or Infrastructure Support

What You’ll Need

• Flip Chart Paper
• Sticky Notes
• Pens
• Service Desk SOP

Establish a critical incident management communication plan

When it comes to communicating during major incidents, it’s important to get the information just right. Users don’t want too little, they don’t want too much, they just want what’s relevant to them, and they want that information at the right time.

As an IT professional, you may not have a background in communications, but it becomes an important part of your job. Broad guidelines for good communication during a critical incident are:

1. Communicate as broadly as the impact of your incident requires.
2. Communicate as much detail as a specific audience requires, but no more than necessary.
3. Communicate as far ahead of impact as possible.

Why does communication matter?

Sending the wrong message, at the wrong time, to the wrong stakeholders, can result in:

• Drop in customer satisfaction.
• Wasted time and resources from multiple customers contacting you with the same issue.
• Dissatisfied executives kept in the dark.
• Increased resolution time if the relevant providers and IT staff are not informed soon enough to help.

Info-Tech Insight

End users understand that sometimes things break. What’s important to them is that (1) you don’t repeatedly have the same problem, (2) you keep them informed, and (3) you give them enough notice when their systems will be impacted and when service will be returned.

Automate communication to save time and deliver consistent messaging to the right stakeholders

In the middle of resolving a critical incident, the last thing you have time for is worrying about crafting a good message. Create a series of templates to save time by providing automated, tailored messages for each stage of the process that can be quickly altered and sent out to the right stakeholders.

Once templates are in place, when the incident occurs, it’s simply a matter of:

1. Choosing the relevant template.
2. Updating recipients and messaging if necessary.
3. Adding specific, relevant data and fields.
4. Sending the message.

When to communicate?

Tell users the information they need to know when they need to know it. If a user is directly impacted, tell them that. If the incident does not directly affect the user, the communication may lead to decreased customer satisfaction or failure to pay attention to future relevant messaging.

What to say?

• Keep messaging short and to the point.
• Only say what you know for sure.
• Provide only the details the audience needs to know to take any necessary action or steps on their side and no more. There’s no need to provide details on the reason for the failure before it’s resolved, though this can be done after resolution and restoration of service.

You’ll need distinct messages for distinct audiences. For example:

• To incident resolvers: “Servers X through Y in ABC Location are failing intermittently. Please test the servers and all the connections to determine the exact cause so we can take corrective action ASAP.”
• To the IT department head: “Servers X through Y in ABC Location are failing intermittently. We are beginning tests. We will let you know when we have determined the exact cause and can give you an estimated completion time.”
• To executives: “We’re having an issue with some servers at ABC Location. We are testing to determine the cause and will let you know the estimated completion time as soon as possible.”
• To end users: “We are experience some service issues. We are working on a resolution diligently and will restore service as soon as possible.”

Map out who will need to be contacted in the event of a critical incident

2.1.4 Design the critical incident communication plan

• Identify critical incidents that require communication.
• Identify stakeholders who will need to be informed about each incident.
• For each audience, determine:
  1. Frequency of communication
  2. Content of communication

Some questions to assist you:

• Whose work will be interrupted, either by their services going down or by their workers having to drop everything to solve the incident?
• What would happen if we didn’t notify this person?
• What level of detail do they need?
• How often would they want to be updated?

Measure and improve customer satisfaction with the use of relationship and transactional surveys

Customer experience programs with a combination of relationship and transactional surveys tend to be more effective. Merging the two will give a wholistic picture of the customer experience.

Relationship Surveys

Relationship surveys focus on obtaining feedback on the overall customer experience.

• Inform how well you are doing or where you need improvement in the broad services provided.
• Provide a high-level perspective on the relationship between the business and IT.
• Help with strategic improvement decisions.
• Should be sent over a duration of time and to the entire customer base after they’ve had time to experience all the services provided by the service desk. This can be done as frequently as per quarter or on a yearly basis.
• E.g. An annual satisfaction survey such as Info-Tech’s End User Satisfaction Diagnostic.

Transactional Surveys

Transactional surveys are tied to a specific interaction or transaction your end users have with a specific product or service.

• Help with tactical improvement decisions.
• Questions should point to a specific interaction.
• Usually only a few questions that are quick and easy to complete following the transaction.
• Since transactional surveys allow you to improve individual relationships, they should be sent shortly after the interaction with the service desk has occurred.
• E.g. How satisfied are you with the way your ticket was resolved?

Add transactional end-user surveys at ticket close to escalate unsatisfactory results

A simple quantitative survey at the closing of a ticket can inform the service desk manager of any issues that were not resolved to the end user’s satisfaction. Take advantage of workflows to escalate poor results immediately for quick follow-up.

If a more complex survey is required, you may wish to include some of these questions:

Please rate your overall satisfaction with the way your issue was handled (1=unsatisfactory, 5=fantastic)

• The professionalism of the analyst.
• The technical skills or knowledge of the analyst.
• The timeliness of the service provided.
• The overall service experience.

Add an open-ended, qualitative question to put the number in context, and solicit critical feedback:

What could the service desk have done to improve your experience?

Define a process to respond to both negative and positive feedback

Successful customer satisfaction programs respond effectively to both positive and negative outcomes. Late or lack of responses to negative comments may increase customer frustration, while not responding at all to the positive comments may give the perception of indifference. If customers are taking the time to fill out the survey, good or bad, they should be followed up with

Take these steps to handle survey feedback:

1. Assign resources to receive, read, and track responses. The entire team doesn’t need to receive every response, while a single resource may not have capacity to respond in a timely manner. Decide what makes the most sense in your environment.
2. Respond to negative feedback: It may not be possible to respond to every customer that fills out a survey. Set guidelines for responding to negative surveys with no details on the issue; don’t spend time guessing why they were upset, simply ask the user why they were unsatisfied. The critical piece of taking advantage of the service recovery paradox is in the follow-up to the customer.
3. Investigate and improve: Make sure you investigate the issue to ensure that it is a justified complaint or whether the issue is a symptom of another issue’s root cause. Identify remediation steps to ensure the issue does not repeat itself, and then communicate to the customer the action you have taken to improve.
4. Act on positive feedback as well: If it’s easy for customers to provide feedback, then make room in your process for handling the positive results. Appreciate the time and effort your customers take to give kudos and use it as a tool to build a long-term relationship with that user. Saying thank you goes a long way and when customers know their time matters, they will be encouraged to fill out those surveys. This is also a good way to show what a great job the service desk team did with the interaction.

Analyze survey feedback month over month to complement and justify metric results already in place

When you combine the tracking and analysis of relationship and transactional survey data you will be able to dive into specific issues, identify trends and patterns, assess impact to users, and build a plan to make improvements.

Once the survey data is centralized, categorized, and available you can start to focus on metrics. At a minimum, for transactional surveys, consider tracking:

• Breakdown of satisfaction scores with trends over time
• Unsatisfactory surveys that are related to incidents and service requests
• Total surveys that have been actioned vs pending

For relationship surveys, consider tracking:

• Satisfaction scores by department and seniority level
• Satisfaction with IT services, applications, and communication
• Satisfaction with IT’s business enablement

Image Source: Info-Tech End User Satisfaction Report

Prioritize company-wide improvement initiatives by those that have the biggest impact to the entire customer base first and then communicate the plan to the organization using a variety of communication channels that will draw your customers in, e.g. dashboards, newsletters, email alerts.

Info-Tech Insight

Consider automating or using your ITSM notification system as a direct communication method to inform the service desk manager of negative survey results.

Step 2.2: Design ticket categorization

This step will walk you through the following activities:

• 2.2.1 Assess ticket categorization
• 2.2.2 Enhance ticket categories with resolution and status codes

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

The reviewed ticket categorization scheme will be easier to use and deploy more consistently, which will improve the categorization of data and the reliability of reports.

DELIVERABLES

• Optimized ticket categorization

Design a ticket classification scheme to produce useful reports

Reliable reports depend on an effective categorization scheme.

Too many options cause confusion; too few options provide little value. As you build the classification scheme over the next few slides, let call routing and reporting requirements be your guide.

Effective classification schemes are concise, easy to use correctly, and easy to maintain.

Keep these guidelines in mind:

• A good categorization scheme is exhaustive and mutually exclusive: there’s a place for every ticket and every ticket fits in only one place.
• As you build your classification scheme, ensure the categories describe the actual asset or service involved based on final resolution, not how it was reported initially.
• Pre-populate ticket templates with relevant categories to dramatically improve reporting and routing accuracy.
• Use a tiered system to make the categories easier to navigate. Three tiers with 6-8 categories per tier provides up to 512 sub-categories, which should be enough for the most ambitious team.
• Track only what you will use for reporting purposes. If you don’t need a report on individual kinds of laptops, don’t create a category beyond “laptops.”
• Avoid “miscellaneous” categories. A large portion of your tickets will eventually end up there.

Info-Tech Insight

Don’t do it alone! Collaborate with managers in the specialized IT groups responsible for root-cause analysis to develop a categorization scheme that makes sense for them.

The first approach to categorization breaks down the IT portfolio into asset types

WHY SHOULD I START WITH ASSETS?

Start with asset types if asset management and configuration management processes figure prominently in your practice or on your service management implementation roadmap.

Building the Categories

Ask these questions:

• Type: What kind of asset am I working on?
• Category: What general asset group am I working on?
• Subcategory: What particular asset am I working on?

Need to make quick progress? Use Info-Tech Research Group’s Service Desk Ticket Categorization Schemes template.

Info-Tech Insight

Think about how you will use the data to determine which components need to be included in reports. If components won’t be used for reporting, routing, or warranty, reporting down to the component level adds little value.

The second approach to categorization breaks down the IT portfolio into types of services

WHY SHOULD I START WITH SERVICES?

Start with asset services if service management generally figures prominently in your practice, especially service catalog management.

Building the Categories

Ask these questions:

• Type: What kind of service am I working on?
• Category: What general service group am I working on?
• Subcategory: What particular service am I working on?

Need to make quick progress? Use Info-Tech Research Group’s Service Desk Ticket Categorization Schemes template.

Info-Tech Insight

Remember, ticket categories are not your only source of reports. Enhance the classification scheme with resolution and status codes for more granular reporting.

Improve the categorization scheme to enhance routing and reporting

2.2.1 Assess whether the service desk can improve its ticket categorization

1. As a group, review existing categories, looking for duplicates and designations that won’t affect ticket routing. Reconcile duplicates and remove non-essential categories.
2. As a group, re-do the categories, ensuring that the new categorization scheme will meet the reporting requirements outlined earlier.
   • Are categories exhaustive and mutually exclusive?
   • Is the tier simple and easy to use (i.e. 3 tiers x 8 categories)?
3. Test against recent tickets to ensure you have the right categories.
4. Record the ticket categorization scheme in the Service Desk Ticket Categorization Schemes template.

Participants

• Service Desk Manager
• Service Desk Agents

What You’ll Need

• Flip Chart
• Whiteboard
• Service Desk Ticket Categorization Scheme

Enhance the classification scheme with resolution and status codes for more granular reporting

Resolution codes differ from detailed resolution notes.

• A resolution code is a field within the ticketing system that should be updated at ticket close to categorize the primary way the ticket was resolved.
• This is important for reporting purposes as it adds another level to the categorization scheme and can help you identify knowledgebase article candidates, training needs, or problems.

Ticket statuses are a helpful field for both IT and end users to identify the current status of the ticket and to initiate workflows.

• The most common statuses are open, pending/in progress, resolved, and closed (note the difference between resolved and closed).
• Waiting on user or waiting on vendor are also helpful statuses to stop the clock when awaiting further information or input.

Common Examples:

Resolution Codes

• How to/training
• Configuration change
• Upgrade
• Installation
• Data import/export/change
• Information/research
• Reboot

Status Fields

• Declined
• Open
• Closed
• Waiting on user
• Waiting on vendor
• Reopened by user

Identify and document resolution and status codes

2.2.2 Enhance ticket categories with resolution codes

Discuss:

• How can we use resolution information to enhance reporting?
• Are current status fields telling the right story?
• Are there other requirements like project linking?

Draft:

1. Write out proposed resolution codes and status fields and critically assess their value.
2. Resolutions can be further broken down by incident and service request if desired.
3. Test resolution codes against a few recent tickets.
4. Record the ticket categorization scheme in the Service Desk SOP.

Participants

• CIO
• Service Desk Manager
• Service Desk Technician(s)

What You’ll Need

• Whiteboard or Flip Chart
• Markers

Step 2.3: Design incident escalation and prioritization

This step will walk you through the following activities:

• 2.3.1 Build a small number of rules to facilitate prioritization
• 2.3.2 Define escalation rules
• 2.3.3 Define automated escalations
• 2.3.4 Provide guidance to each tier around escalation steps and times

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

The reviewed ticket escalation and prioritization will streamline queue management, improve the quality of escalations, and ensure agents work on the right tickets at the right time.

DELIVERABLES

• Optimized ticket prioritization scheme
• Guidelines for ticket escalations
• List of automatic escalations

Build a ticket prioritization matrix to make escalation assessment less subjective

Most IT leaders agree that prioritization is one of the most difficult aspects of IT in general. Set priorities based on business needs first.

Mission-critical systems or problems that affect many people should always come first (i.e. Severity Level 1).

The bulk of reported problems, however, are often individual problems with desktop PCs (i.e. Severity Level 3 or 4).

Some questions to consider when deciding on problem severity include:

• How is productivity affected?
• How many users are affected?
• How many systems are affected?
• How critical are the affected systems to the organization?

Decide how many severity levels the organization needs the service desk to have. Four levels of severity are ideal for most organizations.

Collect the ticket prioritization scheme in one diagram to ensure service support aligns to business requirements

Prioritize incidents based on severity and urgency to foreground critical issues

2.3.1 Build a clearly defined priority scheme

Estimated Time: 60 minutes

1. Decide how many levels of severity are appropriate for your organization.
2. Build a prioritization matrix, breaking down priority levels by impact and urgency.
3. Build out the definitions of impact and urgency to complete the prioritization matrix.
4. Run through examples of each priority level to make sure everyone is on the same page.

Document in the SOP

Participants

• Service Managers
• Service Desk Support
• Applications or Infrastructure Support

What You'll Need

• Flip Chart Paper
• Sticky Notes
• Pens
• Service Desk SOP

Define response and resolution targets for each priority level to establish service-level objectives for service support

Build clear rules to help agents determine when to escalate

2.3.2 Assign response, resolution, and escalation times to each priority level

Estimated Time: 60 minutes

Instructions:

For each incident priority level, define the associated:

1. Response time – time from when incident record is created to the time the service desk acknowledges to the customer that their ticket has been received and assigned.
2. Resolution time – time from when the incident record is created to the time that the customer has been advised that their problem has been resolved.
3. Escalation time – maximum amount of time that a ticket should be worked on without progress before being escalated to someone else.

Participants

• Service Managers
• Service Desk Support
• Applications or Infrastructure Support

What You'll Need

• Flip Chart Paper
• Sticky Notes
• Pens

Use the table on the previous slide as a guide.

Discuss the possible root causes for escalation issues

WHY IS ESCALATION IMPORTANT?

Escalation is not about admitting defeat, but about using your resources properly.

Defining procedures for escalation reduces the amount of time the service desk spends troubleshooting before allocating the incident to a higher service tier. This reduces the mean time to resolve and increases end-user satisfaction.

You can correlate escalation paths to ticket categories devised in step 2.2.

Build decision rights to help agents determine when to escalate

2.3.3 Provide guidance to each tier around escalation steps and times

Estimated Time: 60 minutes

Instructions

1. For each support tier, define escalation rules for troubleshooting (steps that each tier should take before escalation).
2. For each support tier, define maximum escalation times (maximum amount of time to work on a ticket without progress before escalating).

Create a list of application specialists to get the escalation right the first time

2.3.4 Define automated escalations

Estimated Time: 60 minutes

1. Identify applications that will require specialists for troubleshooting or access rights.
2. Identify primary and secondary specialists for each application.
3. Identify vendors that will receive escalations either immediately or after troubleshooting.
4. Set up application groups in the service desk tool.
5. Set up workflows in the service desk tool where appropriate.
6. Document the automated escalations in the categorization scheme developed in step 2.2 and in the Service Desk Roles and Responsibilities Guide.

Participants

• Service Managers
• Service Desk Support
• Applications or Infrastructure Support

What You'll Need

• Flip Chart Paper
• Sticky Notes
• Pens

Phase 3

Design Request Fulfilment Processes

Step 3.1: Build request workflows

This step will walk you through the following activities:

• 3.1.1 Distinguish between requests and small projects
• 3.1.2 Define service requests with SLAs
• 3.1.3 Build and critique request workflows

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

Workflows for service requests will improve the consistency and quality of service delivery and prepare the service desk to negotiate reliable service levels with the organization.

DELIVERABLES

• Workflows for the most common service requests
• An estimated service level for each service request
• Request vs. project criteria

Standardize service requests for more efficient delivery

Definitions:

• An incident is an unexpected disruption to normal business processes and requires attempts to restore service as soon as possible (e.g. printer not working).
• A service request is a request where nothing is broken or impacting a service and typically can be scheduled rather than requiring immediate resolution (e.g. new software application).

• Service requests are repeatable, predictable, and easier to commit to SLAs.
• By committing to SLAs, expectations can be set for users and business units for service fulfillment.
• Workflows for service requests should be documented and reviewed to ensure consistency of fulfillment.
• Documentation should be created for service request procedures that are complex.
• Efficiencies can be created through automation such as with software deployment.
• All service requests can be communicated through a self-service portal or service catalog.

PREPARE A FUTURE SERVICE CATALOG

Standardize requests to develop a consistent offering and prepare for a future service catalog.

Document service requests to identify time to fulfill and approvals.

Identify which service requests can be auto-approved and which will require a workflow to gain approval.

Document workflows and analyze them to identify ways to improve SLAs. If any approvals are interrupting technical processes, rearrange them so that approvals happen before the technical team is involved.

Determine support levels for each service offering and ensure your team can sustain them.

Where it makes sense, automate delivery of services such as software deployment.

Distinguish between service requests and small projects to ensure agents and end users follow the right process

The distinction between service requests and small projects has two use cases, which are two sides of the same resourcing issue.

• Service desk managers need to understand the difference to ensure the right approval process is followed. Typically, projects have more stringent intake requirements than requests do.
• PMOs need to understand the difference to ensure the right people are doing the work and that small, frequent changes are standardized, automated, and taken out of the project list.

What’s the difference between a service request and a small project?

• The key differences involve resource scope, frequency, and risk.
• Requests are likely to require fewer resources than projects, be fulfilled more often, and involve less risk.
• Requests are typically done by tier 1 and 2 employees throughout the IT organization.
• A request can turn into a small project if the scope of the request grows beyond the bounds of a normal request.

Example: A mid-sized organization goes on a hiring blitz and needs to onboard 150 new employees in one quarter. Submitting and scheduling 150 requests for onboarding new employees would require much more time and resources.

Projects are different from service requests and have different criteria

A project, by terminology, is a temporary endeavor planned around producing a specific organizational or business outcome.

Common Characteristics of Projects:

• Time sensitive, temporary, one-off.
• Uncertainty around how to create the unique thing, product, or service that is the project’s goal.
• Non-repetitive work and sizeable enough to introduce heightened risk and complexity.
• Strategic focus, business case-informed capital funding, and execution activities driven by a charter.
• Introduces change to the organization.
• Multiple stakeholders involved and cross-functional resourcing.

Info-Tech Insight

Projects require greater risk, effort, and resources than a service request and should be redirected to the PMO.

Standard service requests vs. non-standard service requests: criteria to make them distinct

• If there is no differentiation between standard and non-standard requests, those tickets can easily move into the backlog, growing it very quickly.
• Create a process to easily identify non-standard requests when they enter the ticket queue to ensure customers are made aware of any delay of service, especially if it is a product or service currently not offered. This will give time for any approvals or technical solutioning that may need to occur.
• Take recurring non-standard requests and make them standard. This is a good way to determine if there are any gaps in services offered and another vehicle to understand what your customers want.

Standard Requests

• Very common requests, delivered on an on-going basis
• Defined process
• Measured in hours or days
• Uses service catalog, if it exists
• Formalized and should already be documented
• The time to deal with the request is defined

Non-Standard Requests

• Higher level complexity than standard requests
• Cannot be fulfilled via service catalog
• No defined process
• Not supplied by questions that Service Request Definition (SRD) offers
• Product or service is not currently offered, and it may need time for technical review, additional approvals, and procurement processes

The right questions can help you distinguish between standard requests, non-standard requests, and projects

Where do we draw the line between a standard and non-standard request and a project?

The service desk can’t and shouldn’t distinguish between requests and projects on its own. Instead, engage stakeholders to determine where to draw the line.

Whatever criteria you choose, define them carefully.

Be pragmatic: there is no single best set of criteria and no single best definition for each criterion. The best criteria and definitions will be the ones that work in your organizational context.

Common distinguishing factors and thresholds:

Distinguish between standard and non-standard service requests and projects

3.1.1 Distinguish between service requests and projects

1. Divide the group into two small teams.
2. Each team will brainstorm examples of service requests and small projects.
3. Identify factors and thresholds that distinguish between the two groups of items.
4. Bring the two groups together and discuss the two sets of criteria.
5. Consolidate one set of criteria that will help make the distinction between projects and service requests.
6. Capture the table in the Service Desk SOP.

Participants

• Service Desk Manager
• Service Desk Agents

What You'll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Distinguishing factors and thresholds

Don’t standardize request fulfilment processes alone

Everyone in IT contributes to the fulfilment of requests, but do they know it?

New service desk managers sometimes try to standardize request fulfilment processes on their own only to encounter either apathy or significant resistance to change.

Moving to a tiered generalist service desk with a service-oriented culture, a high first-tier generalist resolution rate, and collaborative T2 and T3 specialists can be a big change. It is critical to get the request workflows right.

Don’t go it alone. Engage a core team of process champions from all service support. With executive support, the right process building exercises can help you overcome resistance to change.

Consider running the process building activities in this project phase in a working session or a workshop setting.

Info-Tech Insight

If they build it, they will come. Service desk improvement is an exercise in organizational change that crosses IT disciplines. Organizations that fail to engage IT specialists from other silos often encounter resistance to change that jeopardizes the process improvements they are trying to make. Overcome resistance by highlighting how process changes will benefit different groups in IT and solicit the feedback of specialists who can affect or be affected by the changes.

Define standard service requests with SLAs and workflows

WHY DO I NEED WORKFLOWS?

Move approvals out of technical IT processes to make them more efficient. Evaluate all service requests to see where auto-approvals make sense. Where approvals are required, use tools and workflows to manage the process.

Example:

Approvals can be the main roadblock to fulfilling service requests

Review the general standard service request and inquiry fulfillment processes

As standard service requests should follow standard, repeatable, and predictable steps to fulfill, they can be documented with workflows.

Review the general standard service request and inquiry fulfillment processes

Ensure there is a standard and predictable methodology for assessing non-standard requests; inevitably those requests may still cause delay in fulfillment.

Create a process to ensure reasonable expectations of delivery can be set with the end user and then identify what technology requests should become part of the existing standard offerings.

Document service requests to ensure consistent delivery and communicate requirements to users

3.1.2 Define service requests with SLAs

1. On a flip chart, list standard service requests.
2. Identify time required to fulfill, including time to schedule resources.
3. Identify approvals required; determine if approvals can be automated through defining roles.
4. Discuss opportunities to reduce SLAs or automate, but recognize that this may not happen right away.
5. Discuss plans to communicate SLAs to the business units, recognizing that some users may take a bit of time to adapt to the new SLAs.
6. Work toward improving SLAs as new opportunities for process change occur.
7. Document SLAs in the Service Desk SOP and update as SLAs change.
8. Build templates in the service desk tool that encapsulate workflows and routing, SLAs, categorization, and resolution.

Participants

• Service Desk Managers
• Service Desk Agents

What You'll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Info-Tech Insight

These should all be scheduled services. Anything that is requested as a rush needs to be marked as a higher urgency or priority to track end users who need training on the process.

Analyze service request workflows to improve service delivery

3.1.3 Build and critique request workflows

1. Divide the group into small teams.
2. Each team will choose one service request from the list created in the previous module and then draw the workflow. Include decision points and approvals.
3. Discuss availability and technical support:
   • Can the service be fulfilled during regular business hours or 24x7?
   • Is technical support and application access available during regular business hours or 24x7?
4. Reconvene and present workflows to the group.
5. Document workflows in Visio and add to the Service Desk SOP. Where appropriate, enter workflows in the service desk tool.

Critique workflows for efficiencies and effectiveness:

• Do the workflows support the SLAs identified in the previous exercise?
• Are the workflows efficient?
• Is the IT staff consistently following the same workflow?
• Are approvals appropriate? Is there too much bureaucracy or can some approvals be removed? Can they be preapproved?
• Are approvals interrupting technical processes? If so, can they be moved?

Participants

• Service Desk Managers
• Service Desk Agents

What You'll Need

• Service Desk SOP
• Project Summary
• Flip Chart
• Whiteboard

Step 3.2: Build a targeted knowledgebase

This step will walk you through the following activities:

• 3.2.1 Design knowledge management processes
• 3.2.2 Create actionable knowledgebase articles

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

The section will introduce service catalogs and get the organization to envision what self-service tools it might include.

DELIVERABLES

• Knowledgebase policy and process

A knowledgebase is an essential tool in the service management toolbox

Knowledge Management

Gathering, analyzing, storing & sharing knowledge to reduce the need to rediscover known solutions.

Knowledgebase

Organized repository of IT best practices and knowledge gained from practical experiences.

• End-User KB

Give end users a chance to resolve simple issues themselves without submitting a ticket.

• Internal KB

Shared resource for service desk staff and managers to share and use knowledge.

Use the knowledgebase to document:

• Steps for pre-escalation troubleshooting.
• Known errors.
• Workarounds or solutions to recurring issues.
• Solutions that require research or complex troubleshooting.
• Incidents that have many root causes. Start with the most frequent solution and work toward less likely issues.

Draw on organizational goals to define the knowledge transfer target state

*Source: McLean & Company, 2013; N=120

It’s better to start small than to have nothing at all

Service desk teams are often overwhelmed by the idea of building and maintaining a comprehensive integrated knowledgebase that covers an extensive amount of information.

Don’t let this idea stop you from building a knowledgebase! It takes time to build a comprehensive knowledgebase and you must start somewhere.

Start with existing documentation or knowledge that depends on the expertise of only a few people and is easy to document and you will already see the benefits.

Then continue to build and improve from there. Eventually, knowledge management will be a part of the culture.

Engage the team to build a knowledgebase targeted on your most important incidents and requests

WHERE DO I START?

Inventory and consolidate existing documentation, then evaluate it for audience relevancy, accuracy, and usability. Use the exercise and the next slides to develop a knowledgebase template.

Produce a plan to improve the knowledgebase.

• Identify the current top five or ten incidents from the service desk reports and create related knowledgebase articles.
• Evaluate for end-user self-service or technician resolution.
• Note any resolutions that require access rights to servers.
• Assign documentation creation tasks for the knowledgebase to individual team members each week.
• Apply only one incident per article.
• Set goals for each technician to submit one or two meaningful articles per month.
• Assign a knowledge manager to monitor creation and edit and maintain the database.
• Set policy to drive currency of the knowledgebase. See the Service Desk SOP for an example of a workable knowledge policy.

Use a phased approach to build a knowledgebase

Use a quarterly, phased approach to continue to build and maintain your knowledgebase

Continual Knowledgebase Maintenance:

• Once a knowledgebase is in place, future articles should be written using established templates.
• Articles should be regularly reviewed and monitored for usage. Outdated information will be retired and archived.
• Ticket trend analysis should be done on an ongoing basis to identify new articles.
• A proactive approach will anticipate upcoming issues based on planned upgrades and maintenance or other changes, and document resolution steps in knowledgebase articles ahead of time.

Every Quarter:

1. Conduct a ticket trend analysis. Identify the most important and common tickets.
2. Review the knowledgebase to identify relevant articles that need to be revised or written.
3. Use data from knowledge management tool to track expiring content and lesser used articles.
4. Assign the task of writing articles to all IT staff members.
5. Build and revise ticket templates for incident and service requests.

Assign a knowledge manager role to ensure accountability for knowledgebase maintenance

Assign a knowledge manager to monitor creation and edit and maintain database.

Knowledge Manager/Owner Role:

• Has overall responsibility for the knowledgebase.
• Ensures content is consistent and maintains standards.
• Regularly monitors and updates the list of issues that should be added to the knowledgebase.
• Regularly reviews existing knowledgebase articles to ensure KB is up to date and flags content to retire or review.
• Assigns content creation tasks.
• Optimizes knowledgebase structure and organization.
• See Info-Tech’s knowledge manager role description if you need a hand defining this position.

The knowledge manager role will likely be a role assigned to an existing resource rather than a dedicated position.

Develop a template to ensure knowledgebase articles are easy to read and write

QUICK TIPS

• Use non-technical language whenever possible to help less-technical readers.
• Identify error messages and use screenshots where it makes sense.
• Take advantage of social features like voting buttons to increase use.
• Use Info-Tech’s Knowledge Base Article Template to get you started.

Analyze the necessary features for your knowledgebase and compare them against existing tools

Service desk knowledgebases range in complexity from simple FAQs to fully integrated software suites.

Options include:

• Article search with negative and positive filters.
• Tagging, with the option to have keywords generate top matches.
• Role-based permissions (to prevent unauthorized deletions).
• Ability to turn a ticket resolution into a knowledgebase article (typically only available if knowledgebase tool is part of the service desk tool).
• Natural language search.
• Partitioning so relevant articles only appear for specific audiences.
• Editorial workflow management.
• Ability to set alerts for scheduled article review.
• Article reporting (most viewed, was it useful?).
• Rich text fields for attaching screenshots.

Determine which features your organization needs and check to see if your tools have them.

For more information on knowledgebase improvement, refer to Info-Tech’s Optimize the Service Desk With a Shift-Left Strategy.

Document your knowledge management maintenance workflow to identify opportunities for improvement

Workflow should include:

• How you will identify top articles that need to be written
• How you will ensure articles remain relevant
• How you will assign new articles to be written, inclusive of peer review

Design knowledgebase management processes

3.2.1 Design knowledgebase management processes

1. Assign a knowledge manager to monitor creation and edit and maintain the database. See Info-Tech’s knowledge manager role description if you need a hand defining this position.
2. Discuss how you can use the service desk tool to integrate the knowledgebase with incident management, request fulfilment, and self-service processes.
3. Discuss the suitability of a quarterly process to build and edit articles for a target knowledgebase that covers your most important incidents and requests.
4. Set knowledgebase creation targets for tier 1, 2, and 3 analysts.
5. Identify relevant performance metrics.
6. Brainstorm elements that might be used as an incentive program to encourage the creation of knowledgebase articles and knowledge sharing more generally.
7. Set policy to drive currency of knowledgebase. See the Service Desk SOP for an example of a workable knowledge policy.

Participants

• Service Desk Manager
• Service Desk Agents

What You’ll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Create actionable knowledgebase articles

3.2.2 Run a knowledgebase working group

Write and critique knowledgebase articles.

1. On a whiteboard, build a list of potential knowledgebase articles divided by audience: Technician or End User.
2. Each team member chooses one topic and spends 20 minutes writing.
3. Each team member either reads the article and has the team critique or passes to the technician to the right for peer review. If there are many participants, break into smaller groups.
4. Set a goal with the team for how, when, and how often knowledgebase articles will be created.
5. Capture knowledgebase processes in the Service Desk SOP.

Audience: Technician

• Password update
• VPN printing
• Active directory – policy, procedures, naming conventions
• Cell phones
• VPN client and creation set-up

Audience: End users

• Set up email account
• Password creation policy
• Voicemail – access, change greeting, activities
• Best practices for virus, malware, phishing attempts
• Windows 10 tips and tricks

Participants

• Service Desk Manager
• Service Desk Agents

What You’ll Need

• Service Desk SOP
• Flip Chart
• Whiteboard

Step 3.3: Prepare for a self-service portal project

This step will walk you through the following activities:

• 3.3.1 Develop self-service tools for the end user
• 3.3.2 Make a plan for creating or improving the self-service portal

This step involves the following participants:

• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

The section prepares you to tackle a self-service portal project once the service desk standardization is complete.

DELIVERABLES

• High-level activities to create a self-service portal

Design the self-service portal with the users’ computer skills in mind

A study by the OECD offers a useful reminder of one of usability’s most hard-earned lessons: you are not the user.

• There is an important difference between IT professionals and the average user that’s even more damaging to your ability to predict what will be a good self-service tool: skills in using computers, the internet, and technology in general.
• An international research study explored the computer skills of 215,942 people aged 16-65 in 33 countries.
• The results show that across 33 rich countries, only 5% of the population has strong computer-related abilities and only 33% of people can complete medium-complexity computer tasks.
• End users are skilled, they just don’t have the same level of comfort with computers as the average IT professional. Design your self-service tools with that fact in mind.

Take an incremental and iterative approach to developing your self-service portal

Use a web portal to offer self-serve functionality or provide FAQ information to your customers to start.

• Don’t build from scratch. Ideally, use the functionality included with your ITSM tool.
• If your ITSM tool doesn’t have an adequate self-service portal functionality, then harness other tools that IT already uses. Common examples include Microsoft SharePoint and Google Forms.
• Make it as easy as possible to access the portal:
  • Deploy an app to managed devices or put the app in your app store.
  • Create a shortcut on people’s start menus or home screens.
  • Print the URL on swag such as mousepads.
• Follow Info-Tech’s approach to developing your user facing service catalog.

Some companies use vending machines as a form of self serve. Users can enter their purchase code and “buy” a thin client, mouse, keyboard, software, USB keys, tablet, headphones, or loaners.

Info-Tech Insight

Building the basics first will provide your users with immediate value. Incrementally add new features to your portal.

Optimize the portal: self-service should be faster and more convenient than the alternative

Design the portal by demand, not supply

Don’t build a portal framed around current offerings and capabilities just for the sake of it. Build the portal based on what your users want and need if you want them to use it.

Make user experience a top priority

The portal should be designed for users to self-serve, and thus self-service must be seamless, clear, and attractive to users.

Speak your users’ language

Keep in mind that users may not have high technical literacy or be familiar with terminology that you find commonplace. Use terms that are easy to understand.

Appeal to both clickers and searchers

Ensure that users can find what they’re looking for both by browsing the site and by using search functionality.

Use one central portal for all departments

If multiple departments (i.e. HR, Finance) use or will use a portal, set up a shared portal so that users won’t have to guess where to go to ask for help.

You won’t know unless you test

You will know how to navigate the portal better than anyone, but that doesn’t mean it’s intuitive for a new user. Test the portal with users to collect and incorporate feedback.

Self-service portal examples (1/2)

Image source: Cherwell Service Management

Self-service examples (2/2)

Image source: Team Dynamix

Keep the end-user facing knowledgebase relevant with workflows, multi-device access, and social features

Workflows:

• Easily manage peer reviews and editorial and relevance review.
• Enable links and importing between tickets and knowledgebase articles.
• Enable articles to appear based on ticket content.

Multi-device access:

• Encourage users to access self-service.
• Enable technicians to solve problems from anywhere.

Social features:

• Display most popular articles first to solve trending issues.
• Enable voting to improve usability of articles.
• Allow collaboration on self-service.

For more information on building self-service portal, refer to Info-Tech’s Optimize the Service Desk with a Shift-Left Strategy

Draft a high-level project plan for a self-service portal project

3.3.1 Draft a high-level project plan for a self-service portal project

1. Identify stakeholders who can contribute to the project.
   • Who will help with FAQ creation?
   • Who can design the self-service portal?
   • Who needs to sign off on the project?
2. Identify the high-level tasks that need to be done.
   • How many FAQs need to be created?
   • How will we design the service catalog’s web portal?
   • What might a phased approach look like?
   • How can we break down the project into design, build, and implementation tasks?
   • What is the rough timeline for these tasks?
3. Capture the high-level activities in the Service Desk Roadmap.

Participants

• Service Desk Manager
• Service Desk Agents

What You’ll Need

• Flip Chart
• Whiteboard
• Implementation Roadmap

Once you have a service portal, you can review the business requirements for a service catalog

A service catalog is a communications device that lists the IT services offered by an organization. The service catalog is designed to enable the creation of a self-service portal for the end user. The portal augments the service desk so analysts can spend time managing incidents and providing technical support.

The big value comes from workflows:

• Improved economics and a means to measure the costs to serve over time.
• Incentive for adoption because things work better.
• Abstracts delivery from offer to serve so you can outsource, insource, crowdsource, slow, speed, reassign, and cover absences without involving the end user.

There are three types of catalogs:

• Static:Informational only, so can be a basic website.
• Routing and workflow: Attached to service desk tool.
• Workflow and e-commerce: Integrated with service desk tool and ERP system.

Image courtesy of University of Victoria

Understand the time and effort involved in building a service catalog

A service catalog will streamline IT service delivery, but putting one together requires a significant investment. Service desk standardization comes first.

• Workflows and back-end services must be in place before setting up a service catalog.
Think of the catalog as just the delivery mechanism for service you currently provide. If they aren’t running well and delivery is not consistent, you don’t want to advertise SLAs and options.
• Service catalogs require maintenance.
It’s not a one-time investment – service catalogs must be kept up to date to be useful.
• Service catalog building requires input from VIPs.
Architects and wordsmiths are not the only ones that spend effort on the service catalog. Leadership from IT and the business also provide input on policy and content.

Sample Service Catalog Efforts

• A college with 17 IT staff spent one week on a simple service catalog.
• A law firm with 110 IT staff spent two months on a service catalog project.
• A municipal government with 300 IT people spent over seven months and has yet to complete the project.
• A financial organization with 2,000 IT people has spent seven months on service catalog automation alone! The whole project has taken multiple years.

“I would say a client with 2,000 users and an IT department with a couple of hundred, then you're looking at six months before you have the catalog there.”

– Service Catalog Implementation Specialist,

Health Services

Draft a high-level project plan for a self-service portal project

3.2.2 Make a plan for creating or improving the self-service portal

Identify stakeholders who can contribute to the project.

• Who will help with FAQs creation?
• Who can design the self-service portal?
• Who needs to sign off on the project?

Evaluate tool options.

• Will you stick with your existing tool or invest in a new tool?

Identify the high-level tasks that need to be done.

• How will we design the web portal?
• What might a phased approach look like?
• What is the rough timeline for these tasks?
• How many FAQs need to be created?
• Will we have a service catalog, and what type?

Document the plan and tasks in the Service Desk Roadmap.

Examples of publicly posted service catalogs:

University of Victoria is an example of a catalog that started simple and now includes multiple divisions, notifications, systems status, communications, e-commerce, incident registration, and more.

Indiana University is a student, faculty, and staff service catalog and self-service portal that goes beyond IT services.

If you are ready to start building a service catalog, use Info-Tech’s Design and Build a User-Facing Service Catalog blueprint to get started.

Phase 4

Plan the Implementation of the Service Desk

Step 4.1: Build communication plan

This step will walk you through the following activities:

• 4.1.1 Create the communication plan

This step involves the following participants:

• CIO
• IT Director
• IT Managers
• Service Desk Manager(s)
• Representation from tier 2 and tier 3 specialists

Outcomes

The communication plan and project summary will help project managers outline recommendations and communicate their benefits.

DELIVERABLES

• Communication plan
• Project summary

Effectively communicate the game plan to IT to ensure the success of service desk improvements

Communication is crucial to the integration and overall implementation of your service desk improvement.

An effective communication plan will:

• Gain support from management at the project proposal phase.
• Create end-user buy-in once the program is set to launch.
• Maintainthe presence of the program throughout the business.
• Instill ownership throughout the business, from top-level management to new hires.

Build a communication plan to:

1. Communicate benefits to IT:
   • Share the standard operating procedures for training and feedback.
   • Train staff on policies as they relate to end users and ensure awareness of all policy changes.
   • As changes are implemented, continue to solicit feedback on what is and is not working and communicate adjustments as appropriate.
2. Train technicians:
   • Make sure everyone is comfortable communicating changes to customers.
3. Measure success:
   • Review SLAs and reports. Are you consistently meeting SLAs?
   • Is it safe to communicate with end users?

Create your communication plan to anticipate challenges, remove obstacles, and secure buy-in

Why:

• What problems are you trying to solve?

What:

• What processes will it affect (that will affect me)?

Who:

• Who will be affected?
• Who do I go to if I have issues with the new process?

When:

• When will this be happening?
• When will it affect me?

How:

• How will these changes manifest themselves?

Goal:

• What is the final goal?
• How will it benefit me?

Create a communication plan to outline the project benefits

Improved business satisfaction:

• Improve confidence that the service desk can solve issues within the service-level agreement.
• Channel incidents and requests through the service desk.
• Escalate incidents quickly and accurately.

Fewer recurring issues:

• Tickets are created for every incident and categorized correctly.
• Reports can be used for root-cause analysis.

Increased efficiency or lower cost to serve:

• Use FAQs to enable end users to self-solve.
• Use knowledgebase to troubleshoot once, solve many times.
• Cross-train to improve service consistency.

Enhanced demand planning:

• Trend analysis and reporting improve IT’s ability to forecast and address the demands of the business.

Organize the information to manage the deployment of key messages

Create the communication plan

4.1.1 Create the communication plan

Estimated Time: 45 minutes

Develop a stakeholder analysis.

1. Identify everyone affected by the project.
2. Assess their level of interest, value, and influence.
3. Develop a communication strategy tailored to their level of engagement.

Craft key messages tailored to each stakeholder group.

Finalize the communication plan.

1. Examine your roadmap and determine the most appropriate timing for communications.
2. Assess when communications must happen with executives, business unit leaders, end users, and technicians.
3. Identify any additional communication challenges that have come up.
4. Identify who will send out the communications.
5. Identify multiple methods for getting the messages out (newsletters, emails, posters, company meetings).
6. For inspiration, you can refer to the Sample Communication Plan for the project.

Participants

• CIO
• IT Managers
• Service Desk Manager
• Service Desk Agents

Step 4.2: Build implementation roadmap

This step will walk you through the following activities:

• 4.2.1 Build implementation roadmap

This step involves the following participants:

• CIO
• IT Director
• IT Managers
• Service Desk Manager
• Representation from tier 2 and tier 3 specialists

Outcomes

The implementation plan will help track and categorize the next steps and finalize the project.

DELIVERABLES

• Implementation roadmap

Collaborate to create an implementation plan

4.2.1 Create the implementation plan

Estimated Time: 45 minutes

Determine the sequence of improvement initiatives that have been identified throughout the project.

The purpose of this exercise is to define a timeline and commit to initiatives to reach your goals.

Instructions:

1. Review the initiatives that will be taken to improve the service desk and revise tasks, as necessary.
2. Input each of the tasks in the data entry tab and provide a description and rationale behind the task.
3. Assign an effort, priority, and cost level to each task (high, medium, low).
4. Assign ownership to each task.
5. Identify the timeline for each task based on the priority, effort, and cost (short, medium, and long term).
6. Highlight risk for each task if it will be deferred.
7. Track the progress of each task with the status column.

Participants

• CIO
• IT Managers
• Service Desk Manager
• Service Desk Agents

Document using the Roadmap tool.

Related Info-Tech Research

ImplementHardware and Software Asset Management

The Standardize blueprint reviews service desk structures and metrics and builds essential processes and workflows for incident management, service request fulfillment, and knowledge management practices.

Once the service desk is operational, there are three paths to basic ITSM maturity:

• Having the incident management processes and workflows built allows you to:
  • Introduce Change Management to reduce change-related incidents.
  • Introduce Problem Management to reduce incident recurrence.
  • Introduce Asset Management to augment service management processes with reliable data.

Solicit targeted department feedback on core IT service capabilities, IT communications, and business enablement. Use the results to assess the satisfaction of end users, with each service broken down by department and seniority level.

Works cited

“Help Desk Staffing Models: Simple Analysis Can Save You Money.” Giva, Inc., 2 Sept. 2009. Web.

Marrone et al. “IT Service Management: A Cross-national Study of ITIL Adoption.” Communications of the Association for Information Systems: Vol. 34, Article 49. 2014. PDF.

Rumburg, Jeff. “Metric of the Month: First Level Resolution Rate.” MetricNet, 2011. Web.

“Service Recovery Paradox.” Wikipedia, n.d. Web.

Tang, Xiaojun, and Yuki Todo. “A Study of Service Desk Setup in Implementing IT Service Management in Enterprises.” Technology and Investment: Vol. 4, pp. 190-196. 2013. PDF.

“The Survey of Adult Skills (PIAAC).” Organisation for Economic Co-operation and Development (OECD), 2016. Web.

Contributors

• Jason Aqui, IT Director, Bellevue College
• Kevin Sigil, IT Director, Southwest Care Centre
• Lucas Gutierrez, Service Desk Manager, City of Santa Fe
• Rama Dhuwaraha, CIO, University of North Texas System
• Annelie Rugg, CIO, UCLA Humanities
• Owen McKeith, Manager IT Infrastructure, Canpotex
• Rod Gula, IT Director, American Realty Association
• Rosalba Trujillo, Service Desk Manager, Northgate Markets
• Jason Metcalfe, IT Manager, Mesalabs
• Bradley Rodgers, IT Manager, SecureTek
• Daun Costa, IT Manager, Pita Pit
• Kari Petty, Service Desk Manager, Mansfield Oil
• Denis Borka, Service Desk Manager, PennTex Midstream
• Lateef Ashekun, IT Manager, City of Atlanta
• Ted Zeisner, IT Manager, University of Ottawa Institut de Cardiologie