Why tiering your customer service?

In recent posts, we’ve talked about how the Theory of Constraints justifies the focus on improving the “process bottleneck” in the service process queues, we’ve taught how to find the maximum number of items that is acceptable in stock for each queue, and even how helpdesk software can help with the operacional organization. But after all, why structure the service into “levels” or “queues”?

The classic structure

It’s common to see IT companies with customer support teams split between L1, L2 and L3. The attributions of each level can vary a lot from one company to another, but in most cases there is a hierarchical or progressive understanding between these levels.

The classic role of a L1 agent is to record, sort-out, prioritize, and address tickets. L1 may also solve simpler or easy-to-manage issues. Their main objective is to maintain the flow and avoid accumulation of unaddressed requests. Some companies automate ticket screening, but in most cases the ticket only receives an SLA after manual verification by an L1 agent, due to the need for agility.

L2 usually receives more complex requests, escalated from L1. Service desk resolutions and configurations can be performed here. Not all companies treat L2 as a mandatory step between L1 and L3, but it is common for L2 to escale more specialized requests to L3, as we will see below.

Finally, the L3 is the most specialized tier among those mentioned, and its function is the one that most depends on the reality of each company. In some cases, L3 is the “technical” support, which acts as a developer to resolve issues that would not be possible by user access. The L3 agent can also act as a “link” between the support team and the development team, not acting directly on the code. It is also possible to find companies where L3 works traveling to the client’s location.

The essential point here, regardless of your team’s particularities, is that all levels must have some type of contact with the customer and agents prepared to fulfill the requests they receive. Remember: a step that only passes on information is an unnecessary one.

Specialization vs. Dynamicity

Here at Deskflows we believe less in “functions” and more in each tier’s “roles”. This means that we would not recommend static assignment of agents between levels, since some dynamism can be necessary to adapt your team to constantly changing demand. Thus, we defend that teams should have some agents acting as “pivots”, who can be directed to the queue wherever they are needed.

Thereby, we will introduce here the first advantage of structuring your support around levels: the specialization of the context, not the agents.

This means that, while acting in a well-defined role, the agent will know what tools they have at their disposal, what is expected of their performance, with which points of contact they should interact and where to look for the information they need.

Dividing the ticket handling into levels allows a more in-depth analysis without impacting the speed of resolution, as each interaction takes place within a specialized context.

Process accuracy

In addition to the tiering of the team, the requests themselves are subdivided, for example, into types and categories. This organization allows specific operational procedures and rules that will be applied from ticket to ticket, and the agent needs to know how to act in each case.

In that sense, a process divided into service levels makes life easier.

For example, it can be determined that a ticket of type “question” (which does not require any action in the software) is answered by L1 itself, or a ticket of type “bug” and category “login screen” is classified with maximum priority and directly assigned to the L3.

On the other hand, L3 will receive demands that have already been prioritized and will have to carry out a more in-depth analysis according to this prioritization.

Note how the process will be thought from the perspective of levels of analysis, and how the performance of each level can be well defined and measured. In this regard, over time your operation will generate data that can be analyzed according to parameters that make more sense within each tier: perhaps the response time is more critical on the L1 cotext, but backlog (stock) should be monitored more closely on L3 level.

Thereby, we will introduce here the first advantage of structuring your support around levels: the specialization of the context, not the agents.

As well as the process design, the improvement plans will also be directed to the L1, L2 or L3 tier.

Knowledge management and team integration

Finally, as a direct consequence of the previous points, knowledge management, integration of new agents and training in general will be facilitated if organized into “modules”, which will be the support levels.

Some companies write “manuals” that document all standard processes and procedures. In these cases, these manuals will be divided into “chapters” for each level of support and will facilitate consulting.

An agent can be integrated with support within L1, for example, lowering the area’s barriers of entry. Over time, more experienced agents can transition between levels as they are able to fulfill requests in other contexts.

At the same time, agents who find some difficulty in their adaptation may work more specifically on the necessary points within their work context.

Remember: a layer that only passes on information is an unnecessary one.

Do you use any type of segmentation in your customer service process?

What advantages or disadvantages do you think we could have listed above?

Tell us what you think!