Is your Service Delivery Operation more like a Lamborghini or a Model T?
Do you think a Model T, or a Lamborghini is best for your MSP Service Delivery Team? I am not sure anyone I know desires to purchase a brand-new Model T; on the other hand, just about everyone I know would love to drive a brand-new Lamborghini Aventador. Both are considered revolutionary products: one in how it was built and one in aspects of design and performance. In fact, the Lamborghini Aventador website comes right out and proclaims that "Revolutionary thinking is at the heart of every idea from Automobili Lamborghini.".
Thank goodness back in 2014, Autotask had Revolutionary thinking! I am talking about the vision to move us from a single list of tickets (Model T) queue view to being able to look at up to 12 lists of tickets each one sorted in an order that makes sense (Aventador) in a widget/dashboard view.
Why any MSP would like to have their Techs fumbling through a list of tickets, wasting time reviewing "Waiting" and "On-Hold" tickets, never knowing what to work on next, is beyond me.
For me, I would much rather have all Techs in the world knowing what to work on next, when they were scheduled to work with a Customer, with "Waiting" and "On-Hold" tickets within view, but not in my way. Yes, I would prefer them to be using dynamic, proactive dashboards rather than queue views.
There was a time when we needed Queues for Customer request segmentation. But today, using the Queue views and separating workflows by queues, is so limiting, cumbersome, and risky; that the best MSPs are reducing the list to just a few.
So, where do queues fit in then? Does that mean we only need one queue – well, yes? But old habits die young. And even Advanced Global is not comfortable with only one queue. Autotask strongly recommends Recurring, Merged, Client Portal, and Post Sales queues. As a matter of fact, in some cases, they require these, as the PSA tool cannot tell one of these types of tickets from another. We recommend Sales, Procurement, Projects, and Triage beyond a single support queue, but quite frankly, these are nothing more than a blankee (meaning a child's source of support).
The 9 Queues your MSP needs in Autotask
The purpose of hanging on to a few queues is to make it easier to communicate with the Customer, hide certain types of tickets from their Client Portal view, and reporting (which to Advanced Global is the only reason we need). At the end of the day, MSP processes need only 9 queues (* = Autotask required queue, **= Autotask recommended queue):
· Support
· Triage
· Monitoring Alert*
· Client portal*
· Projects
· Recurring Tickets**
· Merge**
· Post Sales*
· Sales
Why: (Just to be clear, this is reality, not philosophy, so there is no "why not")
Support
Support is the primary Service Delivery queue and, thanks to Autotask Dashboard/Widget vision, is the only queue the Support Team needs. Using one support queue has fewer chances of a ticket being overlooked, and there is less mechanisms moving tickets around that could go haywire**.
Triage
If the only ticket being Triaged has the status "New," then a Triage queue is not needed. However, in our reality, re-triaging is a real thing and an MSP process that we need to accommodate. Just putting a ticket back into "New" status is not the best as it sends a confusing message as to what the next steps are.
Monitoring Alert*
This is a queue provided by Autotask, and it makes sense to keep the high volume of alert tickets from swamping the Triage queue. Also, the best practice is to have a more technical person "triage" the monitoring alert queue, as it takes a higher skill to determine if the ticket is noise (self-healing, false/positive, non-issue) or if it needs remediation engagement. The other challenge is that the high intake volume for both alerts and new requests is early morning. This means it is a time of day when two people are needed to triage tickets in a timely fashion.
Client portal*
This queue is hardcoded by Autotask and required. Taskfire tickets sit in this queue by design, and until Taskfire is sunsetted, it is needed. The best practice is to have a Workflow Rule that moves new tickets to the Triage queue, and for the most part, this queue should be empty.
Projects
We recommend a project queue for several reasons. Projects are a very different type of Customer request and need a very special workflow. It is the only workflow where the Customer is not notified of every service call scheduled, where a unique skill set is always needed to work the tickets, and where tickets remain open longer than any response SLA. Because they have a huge impact on Customer communication, Workflow rules, and the most important Live Reports, it is best to keep them in a separate location.
Recurring Tickets**
Today, once again, because of Autotask's Revolutionary thinking. I am not talking about the Just In Time (JiT) Recurring Tickets, but the feature request board where we can scream at them enough to get them to listen and see the JiT Recurring Tickets light. If you are using the JiT Recurring Tickets, then a Recurring Queue is not needed. However, if the recurring tickets are for a specific date and time, you need to create them in advance so time can be blocked out for the work, and the other work can be planned*** to go around the Resource's block. In this case, managing a high volume of recurring tickets is burdensome, and having a queue for recurring tickets makes the ticket management job easier.
Merge**
Autotask recommends this queue, and we agree, because the software can not tell the difference between one ticket and another. We need to help the software identify what type of ticket this is, and in this case, the identity is that this ticket has been absorbed or merged into another one. Therefore, do not tell the Customer their request has been completed, and please, please, please remove them from the completed ticket reports.
Post Sales*
This is a required queue by Autotask and is used to facilitate the opportunity won wizard. When an opportunity closes, a procurement ticket is created automatically and put into this queue.
Sales
Advanced Global's #1 goal is to free MSPs from Service Delivery issues so they can thrive, grow, and go sell something. We also would prefer Sales stays out of Service Delivery; therefore, the best practice is to move their tickets into a queue where they can sit until the cows come home.
** "Hay-wire is the light wire that was used in baling machines to tie up bales of hay. At the turn of the 20th century, the expression 'a hay-wire outfit' began to be used in the USA. This was used to describe companies that patched-up faulty machinery using such wire, rather than making proper long-term fixes. In 1905, The US Forestry Bureau Bulletin described a 'Hay wire outfit' as 'a contemptuous term for loggers with poor logging equipment'. By 1920, the use of haywire to mean 'awry' or 'out of control' was recorded in Dialect Notes, Volume 82: Hay wire. Gone wrong or no good. Slang." The saying 'Go hay-wire' - meaning and origin. (phrases.org.uk)
*** Planned (I know this word is not in an MSPs vocabulary, so we are providing it here)
"arranged, organized, or done in accordance with a plan:" Planned Definition & Meaning | Dictionary.com
Hopefully, this article has cleared up any misunderstanding on when to use a queue and when another queue is not needed. And why we believe that the world changed in 2014 with the release of the new Autotask User Interface (UI). Many MSPs are leveraging the new “Aventador” dashboards and the efficiencies that come with them, while reducing the number of queues needed. We trust this information has been enlightening. If you have questions or would like help implementing these dashboards, please schedule a call.
-Steve & Co.
