Efficiency Secret Revealed:
The Hidden Cost of Multi-Tasking in the Support Center
by Dave Brown, Support Center University
A great many support centers suffer from a serious efficiency problem – and they don’t even realize it’s an issue! In fact, many managers are under the mistaken impression that they are encouraging productivity - when they are actually hampering it!
This article discusses a very common flaw in support center process design. I’m going to tell you how I discovered the problem and how it affects the typical complex support center. Once you understand the issue, you’ll be able to estimate the impact to your own department. I will also share several alternative approaches that you can use to avoid the problem and increase the efficiency of your operation.
Most of the consulting projects that I’m involved with are focused purely on the ‘support side’ of the business. Of course, there’s always some level of interaction between Support and Development. Occasionally, a company will ask that I actually work within the Development/Engineering department to improve their processes. Those projects are a treat for me and I always learn something new. It was while performing one of these projects that I discovered what has become a key concept.
I was working with a Development group that was responsible for creating new products, enhancing existing products, and resolving complex issues that were escalated by Support. The first two activities (the non-support tasks) could be described as ‘traditional’ R&D type work. Projects were scheduled and engineers were assigned tasks that typically took days, weeks, or even months to complete. This work required a lot of focus and concentration. However, the other work (responding to customer support) could not be ‘scheduled’. It was reactionary and it required relatively quick response. It interrupted the project work.
In this particular environment, the same people performed the traditional R&D work and reacted to the demands of Support. As I studied the process, I realized that the interruptions from Support really disrupted the R&D work. Once I realized how much this was hurting productivity, I did further research. I found that the phenomenon was recognized among software development experts. Numerous published articles discussed the issue and one noted author, Tom DeMarco, referenced a research study, “We…came to the conclusion that…each [task] switch imposes a direct penalty of a bit more than twenty minutes of lost concentration.” (Source: Tom DeMarco, 2002, “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”, Broadway Publishing).
Drawing on my operations management background, I related this to a well-known manufacturing reality. Henry Ford is famous for inventing the assembly line and most people recognize that the concept was to ‘move the work to the worker’ (rather than move the worker). But there is more to it. The other point of an assembly line is limiting the scope of what a person does. It is inefficient to have people switching back and forth between tasks - multi-tasking. It is much more efficient to line up the work and do the same task repeatedly. It is OK to move someone around on the assembly line – a few hours here and a few hours there. However, you obviously lose some productivity when they switch from one job to another. Therefore, you wouldn’t want them to move to another job on the assembly line two or three times an hour. You’d lose too much productivity.
How it applies to the service center…
It may not be so obvious, but we have the same issue when people are switching tasks in a complex service/support environment – when we ask people to be responsible for taking calls while working their open cases. Every time they take a phone call – interrupting their train of thought while solving that complex problem – there’s a loss of productivity. When they finish that call, they cannot just ‘flip a switch’ and pick up exactly where they left off. There will be a few minutes lost as they remember what they were thinking and get back into the problem. What is the cost in productivity? 2 minutes? 5? 10? In the complex Development environment it’s 20 minutes. But let’s be conservative and say it is 5 minutes in a Support environment. Now how many times a day does this happen? Well, how many calls a day do your support people take? Even a small support center that only takes 100 calls/day – times 5 minutes per call equals 500 minutes or 8.33 hours! Do the math and see what this might be costing you.
Don’t confuse activity with productivity. Just because we can blend tasks and keep someone busy all the time does not mean that we are getting the most productivity from them! It is often more efficient to organize the work and minimize the task switching. This is also less stressful on the engineers and allows them to do a better job from a quality standpoint.
The key is to separate the concentration-heavy research from the interrupt-driven calls/emails. There are several ways to do this.
Traditional Tiered Model: In a traditional tiered model, ‘Level 1’ (L1) is responsible for the initial contact – whether it be a phone call, email, or web case – and Level 2 (L2) handles the research/follow-up (and is off the phones). If L1 can’t resolve it, the issue is escalated to L2. L2 can work on these cases without being interrupted by inbound calls/cases – while L1 stays focused on handing the inbound calls/cases. While this model comes with its own challenges, the separation of duties allows you to avoid the multi-tasking problem.
Scheduled Research Time: Some organizations schedule their staff ‘off the phone’ for some portion of the day to work on their ‘open cases’. They call it research or follow-up time. This works well – as long as the person is truly isolated from the inbound calls.
Rotational Tiered Model: This approach is essentially a hybrid of the previous two approaches – and it is my preferred approach. This approach calls for two ‘tiers’ – a ‘Frontline’ and a ‘Backline’. However, these are not permanent roles that people are assigned to. They are jobs ‘on the assembly line’ and people rotate – spending a portion of their day in each role.
We determine how many people are needed on the Frontline – the group that takes the initial call/email – and this varies hour by hour based on the predicted volume. The engineers/techs rotate between the roles/tiers – based on need. We always keep enough people on the Frontline to achieve service level targets and we give people enough time on the Backline to work their open case-load. This approach is much more fluid and adapts to the needs of the business.
The common theme in all three approaches – and the key to improving productivity – is that people are not expected to handle new, incoming cases while they are working on their existing, open cases. You must separate these two, distinct types of work. Doing so will result in dramatic improvements in productivity and organizational capacity.
The lesson here is that blending tasks and having your staff multi-task is not always beneficial. Some tasks can be combined effectively and the result is increased utilization. However, other tasks require concentration and, therefore, productivity is reduced by interruptions and ‘task-switching’. Still other tasks benefit from repetition. When designing a process, we need to be aware of the unique aspects of the various tasks. Designing a process that takes these task characteristics into consideration allows us to maximize productivity at each step and thereby optimize organizational capacity.
About the Author
Dave Brown is a management consultant, teacher, and author. Dave is considered an expert in the area of process improvement, staffing models, and change management. He teaches management training programs for Support Center University (www.SupportCenterU.com) and also consults with technology companies to establish world-class service operations. Reach Dave at his office in Boulder, Colorado (303-494-4932) or by email at dave.brown@SupportCenterU.com.