Push or Pull?

How best to assign customer support cases?

If you have ever worked in customer support, you've probably at some point debated how customer cases should be assigned to support agents. Perhaps you are bullish for automated case assignments?  Or maybe you’re hawkish for letting agents decide which cases they get to work?  Or how about a mix of both?

Here's the key question: which approach is the better one?

Pros and Cons

I’ve worked for and advised multiple technology support organisations over my career, all of which grappled with this topic at various times.  Some used an automated assignment engine to assign and reassign large case volumes.  A couple I dealt with used a combination of system-driven (to the group level) and human dispatcher (from group queue to individual agents) mechanisms to process assignments.  Others — all smaller volume operations — let their agents dispatch to themselves.  No solution was error free or without challenges.

Let’s consider some pros and cons to PUSH and PULL:

So, which is better?  Well, to use a well-worn MBA mantra, ‘it depends.’  A ‘best fit’ model is subject to the specific context and requirements of the support service provider.  But in general:

A pull model typically affords greater flexibility and autonomy amongst support agents.  This can help ensure agents do not get overwhelmed by too many cases and thereby can maintain a good work-life balance.  Agents often prefer pulling, especially when offered with minimal governance / management oversight, as they have greater control over their own workloads. 

Alternatively, a push model may be optimal when a high degree of control and coordination over case assignments is needed – typically as case volumes get very large and/or case inflows become very fast, relative to capacity.  It helps ensure that cases are handled by the ‘best fit’ agents, based on their skills, experience, workload and availability.  This can help to minimise the risk of delays or errors, and to ensure that cases are handled efficiently and effectively.

Success comes with volume, right? It's common for large customer support organisations to use a form of automated case assignment to improve efficiency, manage heavier workloads, and provide consistent and prompt customer service.

Let’s take a closer look at Auto-Assignment

With a PUSH model, cases can be assigned manually or automatically.  

As with pulling, manual assignment — using, for example, dispatchers and/or managers — becomes increasingly burdensome and expensive as case volumes become heavy.  Support organisations that deal with large case volumes almost always employ an automated assignment engine, eventually.  There are several solutions on the market that firms can leverage, from ServiceNow, IBM, Zendesk, Oracle, SAP, Freshdesk, Jira, and others.  Alternatively, some support organisations use their own bespoke assignment solutions – some, for example which I came across in past dealings, were/are rudimentary, but effective assignment engines built into in-house ticketing applications.

Auto-assignment engines use one, or a combination, of rule-based and / or machine learning algorithms to determine best agent-case pairings.  For example, a rule-based system can assign cases based on the specific technology or product that the customer is trying to use, while a machine learning algorithm can consider more dynamic factors such as an agent's past performance and case resolution time.  

Let’s keep it simple and focus on the rule-based: by considering a relatively straightforward, multi-variate formula of customer, agent and case-related factors. 

First, let’s consider a set of factors that a tech support organisation could include. Each factor is given a value relative to an agent that is being considered. The larger the value is for a given agent, the higher said agent will rank – for that factor – in the list of eligible agents. For example: if a case’s priority is 1 (very high), then the value given will be zero for the next agent being considered IF they are a new hire and so deemed not eligible.

Secondly, we add weights (w) to each factor.  The size of each weight determines the importance of its factor relative to the other factors.  For example, an organisation may consider an agent’s active queue size to be more important than their skill level; for a given new case, if Agent A has 20 active cases and knows a lot about the asked-about product while Agent B has 10 active cases but knows less than A about the product, then — ceteris parabus — the case will go to Agent B because their greater bandwidth is more important than the other agent’s higher skill level.  

A simple algorithm that sums the products of each ‘factor’ x ‘weight’ can then be used to score an agent’s suitability for a given case. The calculation will look like this:

This algorithm is used to score all eligible agents, and the agent with the highest score is assigned the case. It is a variant of one that I experienced in use years ago and yet can still be effective today. Such an algorithm can be augmented with machine learning (ML) by, for example, calculating additional factors from ML.

In conclusion …

It’s difficult to say if there is an optimal volume of support cases where a push model is better than a pull model, as it depends on various factors such as the organisation’s size, the type of support being provided, and the agents’ skills.  In general, a push model may be better for handling high support case volumes and large numbers of agents, where structure and efficiency are deemed more valuable.  In contrast, a pull model may be more suitable for organizations with a lower volume of support cases and / or fewer agents, where flexibility and agent autonomy are more important.

Then again, a hybrid approach — where both models are blended in different scenarios and situations — may be the best option to optimize support operations.  In this approach, cases are assigned based on their urgency, complexity, or other factors, but agents also have a degree of freedom to choose some cases they want to work on. For example, agents may be auto-assigned higher priority cases (P1 and P2), while left to select lower priority cases (P3 and P4) up to, say, a daily cap.  This can help balance the need for structure and flexibility and make the most effective use of agents' skills and time.

Ultimately, the method of support case assignment that's best for a given organization will depend on the specific needs and goals of its business.  By carefully considering the pros and cons of both push and pull, you can make an informed decision that will help ensure the best possible outcome for your customers and your team.

PS: If you want to delve further into this topic, the online article Taming of the Queue [Mathew Patterson, May 22] offers an entertaining and informative overview of various queue management techniques and considerations; that said, many of the offered tips can be factored into an auto-assignment model, if architected effectively.