Analyst Perspective

Formalize your project support plan to shift customer service to the service desk.

As a service support team member, you receive a ticket from an end user about an issue they’re facing with a new application. You are aware of the application release, but you don’t know how to handle the issue. So, you will need to either spend a long time investigating the issue via peer discussion and research or escalate it to the project team.

Newly developed or improved services should be transitioned appropriately to the support team. Service transitioning should include planning, coordination, and communication. This helps project and support teams ensure that upon a service failure, affected end users receive timely and efficient customer support.

At the first level, the project team and service desk should build a strategy around transitioning service support to the service desk by defining tasks, service levels, standards, and success criteria.

In the second step, they should check the service readiness to shift support from the project team to the service desk.

The next step is training on the new services via efficient communication and coordination between the two parties. The project team should allocate some time, according to the designed strategy, to train the service desk on the new/updated service. This will enable the service desk to provide independent service handling.

This research walks you through the above steps in more detail and helps you build a checklist of action items to streamline shifting service support to the service desk.

Mahmoud Ramin, PhD

Senior Research Analyst
Infrastructure and Operations
Info-Tech Research Group

Your Challenge

• IT suffers from a lack of strategy and planning for transitioning support processes to the service desk.
• Lack of effective communication between the project delivery team and the service desk leads to an inefficient knowledge transfer to the service desk.
• New service is not prioritized and categorized, negatively impacting service levels and end-user satisfaction.

Common Obstacles

• Building the right relationship between the service desk and project team is challenging, making support transition tedious.
• The service desk is siloed; tasks and activities are loosely defined. Service delivery is inconsistent, which impacts customer satisfaction.
• Lack of training on new services forces the service desk to unnecessarily escalate tickets to other levels and delays service delivery.

Info-Tech’s Approach

• Build touchpoints between the service desk and project delivery team and make strategic points in the project lifecycles to ensure service support is done effectively following the product launch.
• Develop a checklist of action items on the initiatives that should be done following project delivery.
• Build a training plan into the strategy to make sure service desk agents can handle tickets independently.

Service desk team:

• You receive a request from an end user to handle an issue with an application or service that was recently released. You are aware of the features but don’t know how to solve this issue particularly.
• You know someone in the project group who is familiar with the service, as he was involved in the project. You reach out to him, but he is very busy with another project.
• You get back to the user to let them know that this will be done as soon as the specialist is available. But because there is no clarity on the scope of the issue, you cannot tell them when this will be resolved.
• Lack of visibility and commitment to the service recovery will negatively impact end-user satisfaction with the service desk.

Project delivery team:

• You are working on an exciting project, approaching the deadline. Suddenly, you receive a ticket from a service desk agent asking you to solve an incident on a product that was released three months ago.
• Given the deadline on the current project, you are stressed, thinking about just focusing on the projects. On the other hand, the issue with the other service is impacting multiple users and requires much attention.
• You spend extra time handling the issue and get back to your project. But a few days later the same agent gets back to you to take care of the same issue.
• This is negatively impacting your work quality and causing some friction between the project team and the service desk.

• In such a situation, the project team sends impacted users a mass notification without a solid plan for training and no proper documentation.
• To provide proper customer service, organizations should involve several stakeholder groups to collaborate for a seamless transition of projects to the service desk.
• This shift in service support takes time and effort; however, via proper planning there will be less confusion around customer service, and it will be done much faster.
• For instance, if AppDev is customizing an ERP solution without considering knowledge transfer to the service desk, relevant tickets will be unnecessarily escalated to the project team.
• On the other hand, the service desk should update configuration items (CIs) and the service catalog and related requests, incidents, problems, and workarounds to the relevant assets and configurations.

• In this transition process, knowledge transfer plays a key role. Users, the service desk, and other service support teams need to know how the new application or service works and how to manage it when an issue arises.
• Without a knowledge transfer, service support will be forced to either reinvent the wheel or escalate the ticket to the development team. This will unnecessarily increase the time for ticket handling, increase cost per ticket, and reduce end-user satisfaction.

Info-Tech Insight

Involve the service desk in the transition process via clear communication, knowledge transfer, and staff training.

The project team is dedicated to projects, while the support team focuses on customer service for several products.

Siloed responsibilities:

• Project team transfers the service fully to the service desk and leaves technicians alone for support without a good knowledge transfer.
• Specialists who were involved in the project have deep knowledge about the product, but they are not involved in incident or problem management.
• Service desk was not involved in the planning and execution processes, which leads to lack of knowledge about the product. This leaves the support team with some vague knowledge about the service, which negatively impacts the quality of incident and problem management.

How to break the silos:

Develop a tiered model for the service desk and include project delivery in the specialist tier.

• Use tier 1 (service desk) as a single point of contact to support all IT services.
• Have tier 2/3 as experts in technology. These agents are a part of the project team. They are also involved in incident management, root-cause analysis, and change management.

The following questions help you with an efficient plan for support transition

Conduct administrative work in the application

• New user setup
• Password reset

Update documentation

• Prepare for knowledge transfer>

• Assess potential bugs

• Configure a module in ITSM solution

End-user training

• FAQs
• How-to questions

• Train technicians for troubleshooting

Support management (monitoring, meeting SLAs)

• Monitoring
• Meeting SLAs

Report on the service transitioning

• Transition effectiveness
• Four-week warranty period

• The final week of transition, the service desk will be called to a meeting for final handover of incidents and problems

• Project description will be useful for bringing the project forward to the change advisory board (CAB) for approval and setting up the service in the CMDB.

• Service priority is used for adding the next layer of attributes to the CMDB for the service and ensuring the I&O department can set up systems monitoring.

• This should be done early in the process in conjunction with the project manager and business sponsors.

• It should be done as the project gets underway and the team can work on specifically where that milestone will be in each project.

• What to include in the project description:
  • Name
  • Purpose
  • Publisher
  • Departments that will use the service
  • Service information
  • Regulatory constrains

• What to include in the service priority information:
  • Main users
  • Number of users
  • Service requirements
  • System interdependencies
  • Criticality of the dependent systems
  • Service category
  • Service SME and support backup
  • System monitoring resources
  • Alert description and flow

• Service level objectives (SLOs) will be added to CMDB to ensure the product is reviewed for business continuity and disaster recovery and that the service team knows what is coming.
• This step will be good to start thinking about training agents and documenting knowledgebase (KB) articles.
• What to include in SLO:
  • Response time
  • Resolution time
  • Escalation time
  • Business owner
  • Service owner
  • Vendor(s)
  • Vendor warranties
  • Data archiving/purging
  • Availability list
  • Business continuity/recovery objectives
  • Scheduled reports
  • Problem description

• Maintenance and change requirements: You should add maintenance windows to the change calendar and ensure the maintenance checklist is added to KB articles and technician schedules.
• What to include in maintenance and change requirements:
• Scheduled events for the launch
• Maintenance windows
• Module release
• Planned upgrades
• Anticipated intervals for changes and trigger points
• Scheduled batches

Leaders of successful change spend considerable time developing a powerful change message, i.e. a compelling narrative that articulates the desired end state, that makes the change concrete and meaningful to staff.

The message should:

• Explain why the change or new application is needed.
• Summarize what will stay the same.
• Highlight what will be left behind.
• Emphasize what is being changed due to the new or updated product.
• Explain how the application will be implemented.
• Address how this will affect various roles in the organization.
• Discuss the staff’s role in making the project successful.
• Communicate the supporting roles in the early implementation stages and later on.

Improve support:

• Support team gets involved in user acceptance testing, which will provide feedback on potential bugs or failures in the technology.
• Collaboration between specialists and tier 1 technicians will allow the service desk to gather information for handling potential incidents on the application.

Shift-left enablement:

• At the specialist level, agents will be more focused on other projects and spend less time on application issues, as they are mostly handled by the service desk.
• As you shift service support left:
• Cost per ticket decreases as more of the less costly resources are doing the work.
• Average time to resolve decreases as the ticket is handled by the service desk.
• End-user satisfaction increases as they don’t need to wait long for resolution.

For more information about shift-left enablement, refer to InfoTech’s blueprint Optimize the Service Desk With a Shift-Left Strategy.

1. Identify learning opportunities.
2. Prioritize the identified opportunities based on:

• Risk of lost knowledge
• Impact of knowledge on support improvement

• One-on-one meetings
• Mentoring sessions
• Knowledgebase articles
• Product road test
• Potential incident management shadowing

Info-Tech Insight

Allocate knowledge transfer within ticket handling workflows. When incident is resolved by a specialist, they will assess if it is a good candidate for technician training and/or a knowledgebase article. If so, the knowledge manager will be notified of the opportunity to assign it to a SME for training and documentation of an article.

For more information about knowledge transfer, refer to phase 3 of Info-Tech’s blueprint Standardize the Service Desk.

Developer/Technical Support

• Coach the service desk on the new application
• Document relevant KB articles

• Conduct informational interviews for new business requirements

Service Desk Agents

• Conduct informational interviews
• Shadow incident management procedures
• Document lessons learned

• Provide cross-training to support team

Info-Tech Insight

No matter how well training is done, specialists may need to work on critical incidents and handle emergency changes. With effective service support and transition planning, you can make an agreement between the incident manager, change manager, and project manager on a timeline to balance critical incident or emergency change management and project management and define your SLA.

2-3 hours

Document project support information and check off each support transition initiative as you shift service support to the service desk.

1. As a group, review the Project Handover Template that you filled out in the previous steps.
2. Download the Service Support Transitioning Checklist, and review the items that need to be done throughout the development, testing, and deployment steps of your project.
3. Brainstorm at what step service desk needs to be involved.
4. As you go through each initiative and complete it, check it off to make sure you are following the agreed document for a smooth transition of service support.

Determine critical success factors to help you find out key metrics:

High quality of the service

Effectiveness of communication of the transition

Manage risk of failure to help find out activities that will mitigate risk of service disruption

Smooth and timely transition of support to the service desk

Efficient utilization of the shared services and resources to mitigate conflicts and streamline service transitioning

Suggested metrics:

• Time to fulfill requests and resolve incidents for the new project
• Time spent training the service desk
• Number of knowledgebase articles created by the project team
• Percentage of articles used by the service desk that prevented ticket escalation
• First-level resolution
• Ratio of escalated tickets for the new project
• Problem ticket volume for the new project
• Average customer satisfaction with the new project support
• SLA breach rate