Swish.ai is like putting a Ferrari engine in your Volvo

Arnon Yaffe | May 18th, 2021

“Swish.ai is like putting a Ferrari engine in your Volvo”, said one of our enthusiastic customers. How can Swish.ai have such an impact on your existing ITSM system? Let’s take a look under the hood…

What is the most dominant factor affecting the time it takes to process and resolve

an ITSM ticket? When I ask this question, the common answer I get is, “It depends on the nature of the ticket”. Indeed, the nature of the ticket is an important factor, but it’s not the single most important factor.

The single most dominant factor is ‘wait time’.

Most of a ticket’s lifecycle is spent waiting in a queue until someone becomes available to attend to it. And if the ticket is transferred between groups and assignees, then each transfer triggers another wait in the queue.

When I explain this, people can understand and relate to it because they can imagine themselves waiting in queues or simply stuck in heavy traffic, but it’s hard to get a grasp on ITSM ticket queues – because you don’t see them. They don’t pile up in anyone’s office. They are intangible and go unnoticed.

Similarly, what is the single most important factor affecting the time it would take you to commute into any metropolitan area? Everybody gets that one – traffic. A journey that may take a few minutes early Saturday morning may take hours during rush hour. Again, it’s the wait time, getting stuck in traffic jams and moving along slowly.

Like traffic congestion, ticket congestion is the single most dominant factor determining ITSM  MTTR  (Mean Time to Resolve). When tickets pile up, queues are created and the system slows down. 

To speed up the system, you need to identify and relieve the congestion bottlenecks. This concept introduced by Eliyahu M. Goldratt in the mid 80s is known as the Theory of Constraints (TOC) and has revolutionized manufacturing and supply chain operations. Eventually, TOC influenced Software Engineering with the advent of DevOps as an approach to optimize against the most dominant constraints in the software delivery processes. However, TOC never reached ITSM.

Another management philosophy that revolutionized the world is The Toyota Production System (TPS), born in the 1930s and evolved as “Lean Manufacturing” in the late 1980’s. Lean too, had a revolutionary impact on Software Engineering with the advent of Agile. But neither TOC nor Lean have had a substantial impact on ITSM.

As an Industrial Engineer, inspired by these philosophies and holding various executive IT Delivery positions, I have been practicing TOC and Lean, and looking for ways to apply them at scale. I wondered why ITSM is lagging behind while other industries are making quantum leaps?


The ITSM Delivery Challenge

There are good reasons why TOC and Lean are so difficult to apply to ITSM, and now that we’ve cracked it, we can look back and explain:

Information Technology Service Management is probably the most diverse and complex form of service management practice on the planet.  An IT organization in a typical enterprise manages hundreds and thousands of different applications, devices and services. There are numerous technology stacks and layers that interconnect and integrate with each other. The knowledge base required to maintain all these elements is vast and requires people from different skills sets. Employees, contractors, managed services providers, software vendors, saas vendors, on-shore, near-shore, off-shore, follow – the sun bots. You name it, IT has it. And this kaleidoscope of people and technology is on the constant move. New technologies, upgrades, new applications. Learning curves and compatibility issues – it never stabilizes. It never reaches a steady state, and you cannot standardize it. 

When you analyze business processes in any form of delivery management, you find a ‘Happy Path’ (a.k.a ‘Happy Flow’).  The happy path is the scenario that works out in the easiest and best way possible for the business. It is generally free of exceptions and features a ‘normal’ progression of events. ITSM Delivery does not have a ‘Happy Path’. Instead ITSM delivery has numerous Process Patterns corresponding to the variety of applications, services and devices. ITSM delivery is a Stochastic system, having a random probability distribution or pattern that may be analyzed statistically but could not be predicted precisely. Not until the advent of Business Process Mining combined with Artificial Intelligence.

“Since the strength of the chain is determined by the weakest link, then the first step to improve an organization must be to identify the weakest link.”

Eliyahu M. Goldratt

Swish.ai was founded with the idea of harnessing big data and data science technologies as innovative enablers for the successful application of TOC and Lean methodologies to IT Delivery. 

Swish.ai Principles for Applying TOC and Lean to ITSM

Measurement – As Peter Drucker taught, “If you can’t measure it, you can’t manage it”. So first things first – make ITSM processes tangible and measurable. Swish.ai established objective process flow metrics that measure performance and detect impending bottlenecks in real-time for every agent and every team. Swish.ai also monitors and measures incidents transitions between individuals and groups, providing objective measure of their contribution to the resolution as well as identifying ping-pongs and excessive ticket hops. 

The Focusing Process – The Theory of Constraints provides a specific methodology for identifying and eliminating constraints, referred to as the Five Focusing Steps. These are continuous cyclic steps that happen in real-time:

  1. Identify the Constraint – Identify the current constraint (the single part of the process that limits the rate at which the goal is achieved). Since ITSM Delivery has multiple delivery channels, Swish.ai monitors all the components of the delivery chain and pinpoints the constraint.
  2. Exploit – Make quick improvements to the throughput of the constraint using existing resources (i.e. make the most of what you have). Swish.ai uses Machine Learning and Natural Language Processing to quickly diagnose the incident, recommend resolution notes and route the ticket to the best available agent for that ticket. Often tickets that can be resolved by other, less loaded people still come in by default to the overloaded constraint. Swish.ai will identify and route them elsewhere.
  3. Subordinate – Review all other activities in the process to ensure that they are aligned with and truly support the needs of the constraint. Swish.ai monitors the entire ITSM delivery organization, identifies available resources across the globe and offloads excess ticket load to them via real-time load balancing.
  4. Elevate – If the constraint still exists (i.e. it has not moved), Swish.ai alerts the managers about the situation to involve human intervention. This may happen due to a system wide failure causing an influx of incidents or lack of resources due to absence of key players. In some cases, where Swish.ai spots a ‘chronic’, repetitive constraint, capital investment may be required, to increase the capacity of the constraint team – but only as a last resort.
  5. Repeat – The Five Focusing Steps are a continuous improvement cycle. Therefore, once a constraint is resolved the next constraint should immediately be addressed. Thus, Swish.ai creates a constraint driven cadence across the ITSM Delivery organization – improve the current constraint and immediately move on to the next constraint.

Application of Lean concepts by waste reduction, continuous improvement and standardised services.


  1. Shift Left – Swish.ai identifies recurring incidents and recurring patterns that can be shortened and simplified by application of Self-Service and automation. Shifting left speeds the resolution time of the incidents at hand but it has an additional advantage of reducing the overall volume of tickets. This has a contribution to reducing accumulation of work and speeding up the entire system.
  2. Automated Problem Detection –  With traditional human ticket categorization problem managers have a very difficult time investigating what the problems actually are (beyond the obvious top 5). Swish.ai AI ticket clustering reads through descriptions, worknotes and resolution notes and clusters similarities, effortlessly.
  3. Autonomous Ticket Routing – Swish.ai identifies new tickets and routes them directly to the most skilled and available agent for that specific problem, thus eliminating unnecessary assignments and transfers between people who cannot attend to or cannot resolve the problem.
  4. System Wide Failure Detection – When a system wide failure occurs it impacts several users simultaneously, resulting in multiple incidents triggering redundant work processes. Valuable time and effort are wasted until the IT realizes there is a system wide failure and that the incidents can be consolidated into a single effort. Swish.ai automatically identifies incidents with similar characteristics occurring concurrently and creates parent/child relationships to consolidate them to one effort.  
  5. Knowledge and Skill Set Management – Swish.ai maps your agents skills set based on actual performance crossed against the AI clusters, highlighting areas with lack of knowledge and opportunities for training and improvement at agent and/or caller levels.
  6. Business Process Improvement Opportunities – Swish.ai identifies and highlights “wasteful” workflows, for example excessive usage of the ‘pending’ state or redundant ‘rubber stamp’ approval stations in service requests.  

Swish.ai delivers outstanding service improvement coupled with exceptional efficiency that can be realised in substantial cost savings. On average the results achieved by implementing Swish.ai are

  • 50% – 63% mean time to resolve reduction,
  • 75% – 89% median time to resolve reduction,
  • 10% – 15% improvement in SLA
Scroll to Top