A Manifesto for Systems Support

I started out in Tech Support and -later in my career- spent 5 years managing the Systems Development Support team at a rapidly expanding company.

Recently, when tasked with implementing an ITSM process from scratch, I decided to bring together my thoughts and experience relating to support and this was the end result.

The Manifesto

A central support function is key to ensuring effective incident management. A healthy support function is empowered and has the necessary tools and information at it’s fingertips.

Support should be highly available and highly accessible, so that issues are quickly captured and don’t fall between the cracks. It’s too easy for issues to become lost or incur delays when reported to the wrong person. The incident reporter shouldn’t have to waste time trying to figure out an appropriate owner from a list of potential candidates, or being ping-ponged around when ownership isn’t forthcoming. Often issues come about as a result of changes, the support function needs visibility of changes being made across the business so that they can attempt to match incoming requests with them.

The support function acts as a single point of contact for incident reporting and maintains a central awareness of active issues. Without this centralisation, time can be wasted by multiple people (or multiple departments) investigating the same issue. Having a central point of communication means that engineers can get on with resolving issues, without the additional overhead of dealing with messages from various affected parties.

The support function ensures the quality and priority of reported issues. Sufficient detail needs to be provided to perform an effective investigation. We also need to be confident that the issue is a fault on our platform, rather than the customer’s device or infrastructure. In addition, we need to understand how widespread the issue is and the level of impact to the business/customers.

Care should be taken around use of SLAs, to ensure that the focus remains on quality and resolving the request to the customer’s satisfaction. That being said, a balance needs to be had to ensure tickets are being progressed, particularly when the resolution isn’t obvious. Caution is needed with certain SLAs, such as ticket closure, to avoid trading active tickets for new tickets – because the issue wasn’t resolved. Use data to drive conversation rather than setting artificial targets.

Failure demand is demand caused by a failure to do something or do something right for the customer, generating follow-up work. Identifying and ensuring that instances of failure demand are dealt with, is critical for ensuring business efficiency. Support is a good place to detect failure demand. When something has gone wrong, people usually raise a support request.

The support function should be dependable, approachable and understanding. The only way we find out about issues is if people tell us about them. Patience and diplomacy, often under pressure, require a level of self control. Support should be a reassuring voice in what can often be stressful situations. As a customer of support you want to feel like your request is valued and that the team is doing what they can to help.

A Manifesto for Systems Support

Leave a comment