Headache Pills.jpg

10 ways to reduce post-go-live IT support headaches

You’re implementing a new IT service and keeping IT’s customers satisfied from the start is vital. Your reputation and the reputation of IT is riding on it. A lot may have gone into preparedness, customer training, testing… but things will still go wrong.  Customers will still have requests, experience faults or just have questions. This means that post go-live IT support is critical to keeping customers happy.

Here’s some things to consider getting in place to increase the chances of being able to provide good post go-live support for the new service and to minimise business disruption:

  1. Consider having an IVR (telephony call routing system) in place that separates out calls related to the new service for a few weeks. Queue them to the best trouble-shooters on the team (using IVR/ACD call routing), and give these trouble-shooters more training and briefing on the new system(s). Do consider overflowing these calls to the rest of the Service Desk if those top trouble-shooters are all on a call or unavailable at one time.
  2. Depending on the nature of your release, and the distribution of your customers (e.g. all on one site vs. spread each across lots of sites), and how important it is to makes this release successful, consider providing on-site support for the initial period (e.g. 2 weeks) post go live.
  3. Consider training and clearly identifying business Super Users for the system who can provide first-level, local support to their colleagues.
  4. Ask the relevant people (vendors, support teams, project staff) to provide knowledge (how to fix faults, procedures for service requests etc.). Then ensure it is entered correctly into the Knowledge Base that the Service Desk and support staff use.
  5. Ask yourself, IT support staff, vendors, whether the 80/20 rule applies – will 20% of the types of fault or request generate 80% of the calls to the Service Desk? Then ensure that the Service Desk staff are particularly well versed in handling those types of calls from day 1.
  6. Ask vendors, support staff, project team members for lessons learnt from prior implementations they’ve been part of, and then apply any learnings as appropriate.
  7. Set a tone with vendors, 2nd Level Support and other stakeholders that the Service Desk will not get it right week one, but that they will improve week by week. Any misdiagnosis and mis-assignment should be viewed as everyone’s problem and everyone needs to work as a team to help the Service Desk improve.
  8. Make sure that the Service Desk not only know the techie names related to the new IT service, but that they also know what names/terms the customers will use. These are not always one in the same.
  9. Ensure that the Service Desk are crystal clear on the release schedule, and that they understand the importance of successful diagnosis/call-routing. The Service Desk must understand the business criticality of the new service.
  10. Ensure that there are no single points of failure in the support teams so that if one person is sick you don’t find there is a knowledge gap that can’t be plugged.

This is not intended to be an exhaustive list, just a series of thought provokers. Hopefully it has given you a few good ideas to get started with! Now ask yourself, what might you need to get in place to successfully provide support to customers of your new service?

Leave a Reply

Your email address will not be published. Required fields are marked *