Service Desk Implementation: A Starting from Scratch Task List

Finger pointing to lightbulb

For a service desk outsourcing vendor, there are many factors to consider when developing a scope of services and pricing that meet a potential new client’s needs. One key factor that significantly impacts implementation pricing is whether or not the prospective client is already using a ticketing system or is on the market for a new ITIL verified ITSM platform. Using a flexible approach, the service desk vendor should be familiar with the top industry standard ticketing systems and remain brand-neutral, especially when considering the significant investment clients have placed in their brand of choice. Admittedly, flexibility is an oft-touted selling point for most any service organization; however, it has genuine implications related to the cost as well as timeframes involved in developing and implementing the solution.

Implementing an entirely new ITSM platform from the ground up requires additional investment compared with leveraging one that is already in place. Either way, the client pays licensing and development fees whether directly to the software vendor or eventually another provider so it’s all a question of where and when they intend to distribute those budget dollars. Since upfront implementation costs can certainly be an issue for organizations with cash flow limitations, leveraging a previously deployed system is a much more attractive proposition for any prospective service desk vendor. By contrast, clients that need to set up a new ticketing system might want to review the extensive list of development tasks involved in starting from scratch.

  1. Set up Telephony/ACD and IVR. If the client does not opt for a service desk 24 x 7, what are the coverage hours and how are inbound contacts handled off hours? How are calls distributed to various IT groups? The implementation team works on greeting scripts, a menu of prompts or options such as allowing callers to identify themselves with a pin code, being able to exit the tree and leave a voice mail or be immediately escalated to an emergency response team versus waiting for a Level 1 agent. Also, the service desk development team must set up client location IDs in the queue and add a record for each queue name that the client uses (including the notify queue).
  2. Generate service catalog web forms for service requests (i.e. access, software, or new device requests, password resets, etc.) that bypass the service desk and keep IT operational costs low. The less involvement there is with the service desk, the more developers must build forms and design complex routing flows that route to specific management teams such as in the approval processes for purchasing and provisioning new devices or software or support teams for deployment.
  3. Add support groups and configure engineers within those groups for escalations requiring client IT access or an onsite presence. Did the client select optional Remote level 2 support? If so, developers must add that support group to the escalation process and engage those engineers before the solution goes live.
  4. Set up incident, problem, change, knowledge, and configuration management. All of these components comprise and follow the ITIL v3 recommended process framework.
  5. For change management, establish a Change Advisory Board, authenticate members, design the routing workflow and emergency approval processes.
  6. Configure the support group for assignment and management of problems. Identify individuals responsible for handling specific problems (i.e. server or network outages) within their IT organization. Once the service desk identifies and associates open incidents with a problem (i.e. root cause), the client’s IT team can update the repair status in the problem ticket. Once it’s resolved it will automatically close the incidents associated with that problem.
  7. Establish which end users are supported, develops CTIs, and notifications.
  8. Institute SLA reporting, create rules that track client-side SLAs such as time to engage and resolve incidents and configure their SLA reporting dashboard accordingly. Include Time to Engage (TTE) and Time to Resolve (TTR) rules and set up ITIL recommended target response times based on prioritization parameters.
  9. Configure daily SLAs for service desk supervisory monitoring and monthly reporting packages for monthly operational review.
  10. KPIs are also established for service desk team leads to measure individual agent performance metrics such as ring time, total handle or talk time, outbound calling, etc.
  11. Set up contractual SLAs governing the ACD, incident and service request management applications and make those metrics available to client management staff in the Interactive Report Card (IRC) so they can view contact statistics for any specified date range with full drill-down capability.
  12. Developers also set up incident metrics (similar to the aforementioned KPIs) broken down by the overall company, by individual support teams, and by service desk agents as well as client engineers. Example metrics include incident created and closed, ASA, abandon rate, customer satisfaction, and top 10 CTIs.
  13. Construct LDAP sync capabilities with the client’s Active Directory so end-user lists are automatically updated for support verification.
  14. Build knowledgebase articles and integrate them with the ITSM platform in a searchable format. Clients without an existing knowledgebase must have their specific resolution procedures documented by the service desk implementation team. That way they are accessible to both the service desk agents and end users and help to keep costs low by using the self-service portal. Even clients who have an existing knowledge base must have that documentation uploaded into the new platform.

Once all has been set up, configured, and integrated with the ITSM platform, development engineers perform testing before the solution is launched. They make sure the 800 number connects to the ACD, emails, chat sessions, and that web submits are received by the service desk with the originator of those inbound contacts recognized. Service desk development engineers test for all application functionality such as creating, updating, assigning, and resolving tickets as well as relevant files, URLs, notifications, and subtasks. Similar functions for service requests including administrative updates and conversion to an incident are also tested along with submit/assign/close aspects of problem and change management. Knowledge (update, approve, and publish) and configuration management including asset tracking features are tested for all data entry and submission scenarios.

Although these are standard tasks for a new client ITSM implementation, there may be additional customization requested or revealed during the discovery and data gathering process if not during the initial solution development phase. So long as those development tasks enable all value-add features in the ticketing system, ACD, and both the administrative and end-user portals, the results will be truly worth the time and effort.