How to reduce costs for 24x7 Support

A 24x7 delivery model is a common approach to support. It is convenient and covers all time zones or working hours by default. But it's designed to cover peak workloads and has rapid idle time - To put it simply, it's often unnecessary and incurs enormous costs.

In times of constantly rising prices and where savings are a top priority, this is especially painful. Therefore, it is critical to perform an assessment of your needs and requirements against the cost drivers and components of 24x7 support.

The most important Price Components of 24x7 Support

24x7 support is certainly convenient, but it usually comes with high costs. Depending on how it is structured, it ensures quick turn-over time, short pick-up times and a user friendly end-to-end solving time as it is operated via a three-shift model.

However, to operate it under stable conditions, some components must be clearly addressed and adjusted accordingly. This must take place with the consideration that a reinforcement/increase will bring very strong price increases, as the following are strong price drivers:

• The level of experience and skills must be fairly balanced across shifts
• Skill sets must be provided at a scale that enables stable delivery
• Handover of open tickets across shifts is time consuming
• Night shifts often require surcharges

Moving away from a convenience driven to a demand driven support model can decrease costs. It requires an evaluation of needs, risks, and costs. Balancing those factors upon a clearly defined decision matrix can allow to lower costs and keeping core functions operating.

Language Service - because communication is crucial

One factor which can drive up costs is language service. Especially when operated in an international, multilingual environment IT support is confronted with tickets in different languages. One goal is to provide an as convenient service as possible to end users (easy opening of tickets, describe a topic in your own language, etc.).

If L1 support is operating in the same language as the user (e.g., via a local service desk) a huge number of tickets can be solved right away. For those tickets, which need to be transferred to L2, a potential issue can arise: translation.

Translation - the big price factor

If L2 and L3 are operated by an external service provider, a so-called language service/translation service is often part of the offer. This is very convenient for the local service desk, but increases the costs. In terms of cost, time also plays a critical factor. With translation between the end user/service desk and L2 and L3 support, an additional layer is added to the process.

Therefore, some possible solutions exist:

• Service Desk does the translation
  Careful consideration must be given to whether the local service desk cannot directly take over the translation for the tickets moved to L2.
• More standardization
  Drop down menus, lists and similar reduces the effort for translation.
• Limitation of Languages
  Define what languages are absolute necessary to be covered by translation service and which are not.

Decide which languages are necessary, which of them are optional, and for which there is simply no language service needed. Structure local support desks in a way that the solving rate is increased. This reduces the need for translation right from the beginning. Then evaluate if it is possible to move translation to L1.

On Call Service, as an alternative for 24x7 coverage

On call service is a good option to reduce the costs for true 24x7 support. Instead of having a team working 24x7 in front of a workstation to support you day and night, you could evaluate the option of a reduction to a shorter, full support, time range (e.g., 16x5).

In order to better estimate the required time coverage, it is highly recommended to evaluate the distribution of tickets on an average working day. This makes it possible to immediately see whether 24x7 support has a fairly balanced workload throughout the day or whether there are spikes and peaks.

Uneven distribution of requests opens up new opportunities

In case the distribution is not even balanced, the support is provided for non-critical applications, etc. a priority-based system can be developed.

• Tickets with high priority (e.g., P1 and P2) will be worked upon immediately
• Tickets with a medium to low priority (e.g., P3 to P5) will be worked upon in the next shift

Through this system, the typical three-shift system can be reduced to at least two shifts. Further reductions are still possible if the days are also limited, e.g. elimination of Saturday and Sunday. Then, the high-priority tickets are processed via the on-call service.

The on-call support agent only gets active when a ticket with a defined priority is issued. Otherwise, the agent will not start working. There are several ways to handle this:

• Usage of economies of scale of the supplier
  The agent supports other customers with the same technology stack and on-call option
• Usage of economies of scale within the dedicated support
  The agents work across service categories for the same customer (attention: different technology stacks may be an obstacle)
• The support agent is on stand-by mode only
  If a ticket arises, the agent will work on it. This can require sometimes a surcharge or a higher ticket price for P1 and P2, but the overarching effort is reduced as at least one shift is avoided.

When is 24x7 a good Idea?

There are of course relevant use cases for 24x7 support which underpin the relevance of it and justify a full-scale support. This is especially true for highly critical applications (customer facing, high impact on revenue, etc.). Important is, to do this categorization after an assessment with transparent criteria:

• Is this application highly critical (define a matrix to rate it)?
• What happens, if only high priority tickets would be immediately started to be worked on?

If the output of the assessment justifies true 24x7 support, have a look if there are other applications with the same technology stack and also a need for 24x7 support around. If yes, take advantage of it, group them and route them to the same support team, etc.

What is Off- / Near- / On-shore?

A key factor of cost composition for support is based on the delivery location. Some common termini within IT service provisioning are Onshore, Offshore, and Nearshore. It defines the location of a support agent or team.

Onshore

• Onshore resources are typically located in the same country as your company or subsidiary or at least in adjacent neighbouring countries
• These resources are typically used for projects that require a lot of face-to-face interaction
• Other reasons are:
  • Advantage can be drawn due to speaking the same main language
  • Time allocation is not a problem and can be hold more flexible
  • Travel times play in most cases only minor role
• This is usually associated with high labour costs, as the onshore plants are mostly located in 1st world industrialized countries

Nearshore

• Nearshore is not as obvious to classify as onshore or offshore
• Typically, Nearshore resources are defined by at least one of the following two points
  • Nearshore resources are located in the same time zone or in a time zone with very little deviation (1-2 hours)
  • Nearshore resources speak your native language at a high level
• It offers cheaper labour costs as classical onshore locations in North America and Western Europe and provides more flexibility for staffing

Offshore

• Support is placed on another continent, often with huge differences between time zones (e.g. India vs. US)
• Mostly placed in countries which offer large-scale support on common technology stacks (e.g. India)
• The main reason for offshore is usually the advantage of lower than average labor costs and high availability of resources

The location of the support influences the balance sheet – it can reduce or increase costs. A good mix is in general beneficial, but anyway a demand driven purchasing with transparent categories offers the greatest level of benefits.

This requires of course a certain maturity level of the vendor management office and a purchase process which supports it.

Differences of Shared vs. Dedicated Support

The difference of shared vs. dedicated support can have a huge impact on the cost side.

Of course, each model comes with pros and cons. An evaluation with a clear matrix and scheme can allow to make a guided decision to reduce costs.