Swarming support models with ServiceNow

Changing your IT support model from the tried and true, to something quite new is no easy feat. While having the right technology available to assist in this transformation is important, there is a significant cultural change that is required of the people involved. I won’t dive into organisational change here and instead focus on the technology used and the outcomes.

Firstly, what is the difference between the traditional tiered support model and this new swarm model and why might an organisation adopt it?

Tiered Support Model

The traditional tiered support model is the most well-known structure for IT Service Management. Practitioners of ITIL will be very familiar with it, as will most people who have worked in IT. This model is typically made of four tiers with each tier providing a higher level of support than the previous one. The first tier, often called Level zero or Tier 0 is a self-service level where end-users are given information and leverage automation to solve their own support issues. A password reset service is a common example. The next tier, Tier 1 is the frontline service desk, charged with answering phones and emails, basic troubleshooting, and issue identification. They handle a high volume of simple requests and have a broad range of general skills to solve customer issues. If the issue cannot be solved at this level, it is escalated to Tier 2 support. This level has specialist skills and perform more advanced troubleshooting and issue resolution. If the issue still cannot be resolved, it is escalated to a higher tier consisting of experts in their field. They will handle a small number of complex issues but are also often engaged in other tasks outside of support or they may be an external vendor.

This hierarchical structure has many benefits which is why it is so well known. Customer requests are funnelled to a single point of contact no matter the nature of their request. Most issues are resolved at the first tier and issues that warrant specialist skills are escalated to appropriate teams. In doing so, specialist and expensive resources are protected from working on simple tasks and allows them to focus on complex issues.

However, it does have some drawbacks. Teams are operating in silos so there is little knowledge sharing and upskilling occurring for the lower tiers. Issues can often circulate between teams like a ‘hot potato’ when it is not clear what the nature of the fault is. It assumes there is a high volume of simple issues with a few complex ones and while that may be common it is not universal. The practice of escalation incurs a cost in time as issues are passed from one queue to another. As new agents begin to work on the issue there is also a loss of familiarity with the issue’s history or why it was escalated.

Swarming Support Model

Swarming is an alternative to the tiered support model that aims to address these drawbacks. In direct contrast, swarming has no tiered support groups. It utilises a team-based approach to provide faster and more efficient support to customers by eliminating the need for issues to be transferred between support tiers. By bringing together a team of experts with different areas of expertise, swarming support models can quickly identify and resolve complex issues. Additionally, swarming support models help staff up-skill and cross-skill as they work closely with more experienced staff. Swarming also encourages innovation to resolve issues as experts are exposed to issues that would otherwise not have come to their attention.

At AC3, our customer support teams have been operating under a swarm model. Our model consists of a few different types of swarms with unique responsibilities.

As customer issues arrive, they are prioritised and sent to either the Priority swarm or Dispatch swarms. When there are no critical issues the Priority swarm will assist the Dispatch swarm with incoming issues. All monitoring alerts are sent to the Alert swarm for triage and resolution. Complex or long-term issues move to the Backlog swarm. Since the introduction of this model customers have noticed an improvement in response times which has been a key metric. The model has also been positively received by the operations teams as they can see the benefits in knowledge sharing and working collaboratively.

Routing work to the swarms

So, with this operating model in place, we looked at how ServiceNow could support the flow of work to the right teams and individuals. In addition, to provide reporting insights for the team leads to measure against the old model and fine tune the new model.

The model has clear rules on what task is assigned to each swarm based on task priority, channel and age. With each swarm defined as an assignment group this was a simple solution of assignment rules utilising attributes of the issues that are captured during submission to automate that flow of work to the respective teams.

Forming the Swarms

A bigger challenge was that the swarms now had to contain a diverse set of skills, and the members of each swarm would change on a regular basis. The team leads needed to ensure they had staff with skills in the areas that are in demand. Identifying staff skills and the skills required to resolve issues has become important to understand each time resources are scheduled. Previously this may have been done within each siloed team, but we now needed a central view across all support staff and a measurement of skills that are in demand on a week-by-week basis. This is where ServiceNow’s Skill Management application helped. This application allows an organisation to define a catalogue of skills and within those skills, levels of ability. These can be technical skills as is the primary case for AC3 or other skills such as spoken languages which a customer contact centre might need. Once that skill taxonomy is defined, those skills are then assigned to staff and tasks. This allows us to look at the demand for certain skills vs the ability to supply those skills.

Mapping skills to staff can be handled easily through discussion between managers and staff. My recommendation is don’t be too granular with skill levels unless you have an objective way to measure that. It’s easier to agree someone has Oracle knowledge than it is to quantify that knowledge into expert, intermediate or beginner. If there is a need to differentiate skill levels, then some ideas we discussed were using years of experience practising the skill or what level of certification the staff member held. Once the initial mapping of skills is done the ongoing maintenance can be delegated to the managers and their staff. Additional benefits of having a view of skills-attained versus skills-missing was that it helped inform personal development plans and recruitment decisions.

Assigning skills to a ticket can be achieved by associating skills to the category and subcategories that AC3 records against all tickets. In some scenarios, such as a regular service request or a monitoring alert the category and subcategory are known ahead of time. However, for the common ‘Report an Incident’ form we don’t ask our customers to categorise the incident, that’s our job, we simply ask for a summary so that we can begin the investigation. In these cases, manual categorisation is required. A future goal will be to use ServiceNow’s AI capabilities to predict the categorisation based on the summary provided by the customer.

Assigning work to Swarm members

Now we had assignment rules for routing work to the swarms and within those swarms we knew the staff skills available, and the skills required to do the work. We now needed to complete that last step of assigning work to the right individual. This is where Advanced Work Assignment gave us that next level of ticket routing.

Incidents and Service Requests would arrive via different contact channels, monitoring alerts, service portals, phone and email. They are then assigned skills based on their category and subcategory. Afterwards they are sorted into Service Channels which are effectively the queue for the Dispatch, Priority and Alert swarms. Once in these queues, the best fit agent is assigned the task. This best fit is based on the required skills, that they are online, available and have capacity. The agent can decline the assignment, which is recorded, and the system attempts to find the next best match.

The service channels will spill over to other swarms if they have exhausted all assignment options. The Backlog swarm is tasked with the hard stuff that the other swarms can’t resolve quickly. We declined to automatically assign work to them and instead use a dashboard to show what was aging and needed their attention. This encouraged a handover between the swarms which is needed for more complex work which was the case typically because they took longer to resolve.

Conclusion

While AC3 ultimately transitioned to customer-aligned support teams, the swarming implementation provided valuable insights. The experience demonstrated that swarming models may be better suited to internal support organisations rather than multi-customer environments. However, the technological and process improvements developed during this implementation continued to benefit the organisation in its evolved form.

The key to success lies in maintaining flexibility and a willingness to adapt based on operational feedback, both the good and the bad. Organisations considering similar transitions should focus on building robust skill management processes, implementing appropriate technology support, and fostering a collaborative culture while remaining mindful of their specific operational context. Swarming might not have been the buzz for us, but you may be surprised, so try it.