How often have you heard the term, “shift left”? It’s one of those things that’s hard to argue with: moving issue resolution closer to the customer. It also looks good on paper because it should reduce escalations and lower costs.

Unfortunately, the reality is often very different. Many organizations see “shift left” and treat it as a way to push work onto someone else, usually support teams. The point is that it’s a transfer of work, but not a transfer of capability. So often, support teams inherit issues they aren't trained, authorized or staffed to handle. Then suddenly leadership wants to know why quality has gone downhill.

Real shift-left means the issue can be resolved by the selected team – fix the problem, not just add documentation and send it to the next workgroup that has the appropriate knowledge, access or tools to resolve the issue. If only the ticket destination moves, the shift is not useful – the pain has been relocated, and often the total effort increases because more hands are touching it.

A practical way to look at the process is to examine the underlying data. Are there issues that are frequently escalated, but not really too complex to solve, as long as the rights and knowledge exist? Those are the best candidates for shifting an incident left. Other issues that require deeper knowledge, troubleshooting or specialized access aren't ideal to move, and forcing a move usually creates more rework than it saves.

The primary constraint for shift-left is knowledge. Analysts and technicians spend time and gain experience learning how to fix common escalations. The problem is that this knowledge isn't effectively documented anywhere. If teams don’t capture and document that knowledge in a usable format, shift-left remains theoretical. Metrics and KPIs are also a real consideration, as they may need adjustment if support teams are measured on speed, response time and volume. Adding work without adjusting expectations creates little incentive to take on higher-skill work.

Industry benchmarks clearly show a cost difference as an incident moves up the support tiers. Solving an incident at Level 1 is far less expensive than the same issue escalated to Level 2 or higher. These costs are additive – so if it’s not solved at one level the cost of the miss is added into each successive level. This is why shift-left is so attractive; the economics are compelling when the work stays in the lower tiers.

So, what can you do about it?

If you have a budget, review your knowledge base and identify quick-fix issues you can take on at lower tiers, provided access and knowledge are readily available. Start tracking the reduction in escalations and monitor the quality of the resolutions that stay at the lower tiers. Continue to review the data to identify new candidates for shift-left.

If your budget is tight, or your tools are less complex, start off small and pick the top five most frequent escalations that seem to be good candidates for shift-left – those that have good documentation and would require little training. Work with the team that currently handles the escalations and have them help write knowledge for the support team. Then measure those issues and determine whether they stay resolved or get reopened.

Shift-left can work well if the front-line support team gains real capabilities and not just additional volume. With care, it can reduce costs and improve both the customer and employee experience.