The Ideal Service Board Layout and Their Swim Lanes

Below are the threads of a chapter for my upcoming book Agile Service Delivery – The Ultimate Secret to Making Work Flow, spawned from an email sent to me asking for clarification on service boards/queues.

I was recently asked what it is that I recommend for how to set up service boards or queues in a PSA or ticketing system and how I viewed Swim Lanes for them. This is an expanded narrative of the email I sent in response.

The Boards
I recommend that for the Service Desk, you use three simple boards: Help Desk (or Triage), Support Desk (or Field Service or Escalation), and NOC (or Back Office).
Note: Autotask is screwy and forces the use of a stupid inbound sorting queue - ignore that for the sake of this narrative. Also, I choose to use the terms Board not Queue, and Issue not Ticket, although they are each the same, respectively, so you can interchange them as you like.

Basic Flow Rules
1) All Issues created for or by carbon-based life forms (humans) begin life on the Help Desk board.
2) All Issues created by non-carbon-based life forms (RMM agents, scripts, apps that send email, etc.) begin life on the NOC board.
3) All Issues created by the team (us) in the normal course of work are, by default, created on the Support Desk board.

Important safety tip: Rule number three does not apply to the tickets we create while helping out by answering the phone or covering for someone on Help Desk. Those follow the rules of intake script and either land on the Help Desk if rapid response, or are immediately escalated based on their criteria. Nor does it mean we implicitly cannot create a ticket on the NOC board. The idea behind the default is that typically, when we come across something that we know needs to be fixed, it is likely not a Help Desk issue (rapid response and bothering the client), and further, it is not likely a NOC issue (something that can be done remotely in the middle of the night with minimal direct client interaction).

By creating these issues we came across on the Support Desk board, they can quickly be qualitized and moved to the appropriate board without clogging Triage and without having to wait for the NOC cycle.

What is the NOC Cycle?
In any size team and especially in smaller teams, one person is primarily in charge of the NOC board. Their daily cycle includes massaging the board a minimum of once a day and up to three times a day. This is outside of addressing alerts like Server Down and Network Unavailable. So the NOC cycle simply means one of the regular passes through the NOC board to check on it and qualitze everything.

Help Desk Defined
Any "Request" that can be completed in under 30 minutes remotely (or whatever limited time allowed), without third-party intervention by a Tier 1 technician, i.e. rapid response, easy to fix.

If you have only a few people (< 15 or so), you cannot run a true Service Desk Help Desk where the tech can answer every call and stay on the phone until it is resolved or escalated. Thus, the simple rules.

Help Desk is for rapid response for simple things. One technician is assigned as the primary and, ideally, there is a secondary tech in case the primary gets hit by a car, dies, quits, goes to lunch, takes a long break, goes on vacations, etc.

Support Desk Defined
This is where the bulk of the reactive work is done and escalated to. Issues can be pushed out to the Help Desk or to NOC provided they meet all the requirements of that board. i.e. If it were reported by a client (email, phone, etc.) or a server (script, agent, etc.) to either the Help Desk or NOC board, would it be left there after being qualitized? If not, it stays on the Support board and will be resolved under the normal course of flow. One technician is assigned as the primary, as mentioned above.

NOC Defined
All the work we could do remotely, as we have time to do so, with minimal direct client interactions, and can easily be outsourced or automated. The more mature we are, the more we can be proactive with the work on the NOC. One technician is assigned as the primary, as mentioned above.

Escalation Basics
If Help Desk cannot solve the Issue in under 30 minutes, remotely, without third-party intervention, it gets thrown over the fence to Support Desk. Likewise, if NOC needs something done on-site or requiring much direct interaction with the client or end loser, it gets thrown over the fence to Support Desk.

Distributed Service Coordination
If each Issue has a Born-on Date (creation date), Priority, and Skill required to complete the work successfully without further escalation (Qualitized), then we can work a blind process where the techs are free-running and working Issues as fast as they can WITHOUT any Service Dispatch required.

They work Issues on their assigned Board from highest Priority to lowest, from oldest Issue to newest, and what is in their skill range. When they run out of work, they jump over and back up the other techs on another Board (according to assignment, i.e. I'm primary on Help Desk and a backup on Support Desk or NOC). In this way, we can easily create a sprint of service to the customers by swarming Issue types (same issue affecting many companies), client Issue bloat (one client experiencing many issues, causing undue stress on their network or teams).

There is a lot more to it, but these are the basics.

I should mention that the Information Technology Infrastructure Library (ITIL) dictates almost all of what I've laid out, i.e. no big surprises - the need for a specific Help Desk, NOC, Support Desk, etc. They refer to all of this as the Service Desk, and they dictate you will have Priorities, Escalation, Teams, and so on.

To this, I add that Agile Service Delivery tells us that the Swim Lane can be anything we want it to be.

Swim Lane Defined
Categories we break work down into to make it easier to approach. For example, Tier/Skill Level, Network Type, Client, User Type, Client Team, pretty much anything you like. The term comes from the agile discipline known as Kanban.

From the Agile Service Delivery Master Class

Kanban Defined (very loosely)
Kanban is simply a flavor of Agile made most famous by Toyota that is one of the main secrets to making work visible. It simply means putting your Issues onto small cards and putting them up on a board for everyone to see, organized in a left-to-right flow representing progress from New to Completed. To make it simple, imagine turning your service statuses on their side. Assuming your statuses progress from New to In Progress to Waiting to Closed, i.e. the Issue progresses ever toward being closed and only pausing on a Waiting status when absolutely necessary. Your Kanban board would look like the image above.

How To Use a Swim Lane
Once you’ve established the flow of a technician’s day, the flow of a ticket including escalation and defined skill levels of the team members, you can now simply create swim lanes to keep them on track.

I always recommend swim lanes primarily be based on skill or tier. When the team or department gets bigger, you can create other swim lanes, but this is the absolute best starting point.

So now, the tech works their assigned board (let’s say Help Desk), from Highest Priority to Lowest Priority, from Oldest to Newest and what is solidly in their Swim Lane (say Tier 1). When they run out of work on their assigned board, they go back up someone (let’s say on Support Desk). There, again, they only work tickets in their Swim Lane.

But Manny, what if there aren't any tickets in their Swim Lane on the Support Board? After all, you said it’s mostly full of issues escalated from Help Desk or NOC, right? Right-o you are! But just because it was escalated from Help Desk because it broke the time requirement or remote access or third-party doesn’t mean it can’t be worked by a Tier 1. Also, there are some simple rules about pushing work down to elevate techs.

It works like this: A ticket gets thrown over the fence as the Tier 1 doesn’t know how to fix it and assumes it needs a Tier 2. They change the Issue to be Tier 2, put in their notes, and throw it over the fence (escalate). Then, they run out of issues and go help out on the Support Board. Low and behold, a Tier 2 looked at the issue and added an internal note with the exact link to resolve the issue and set it back to a Tier 1 skill required. Now, this is only one example, and maybe my next blog will only be about elevating the techs from above.

Final Note on Swim Lanes
Do NOT limit the ability for a team or department to choose the field they use for creating a Swim Lane; by doing so, you significantly limit their ability to truly be agile.

Important Side Note on Why Multiple Boards is a Bad Thing
1) ITIL identifies several disciplines a complete Service Desk will have:
• Incident Management
• Problem Management
• Configuration Management
• Change Management
• Release Management
• Risk Management
• Service Level Management (SLAs)
• Capacity Management
• Service Continuity Management
...And that's the old ITIL 3.0 - We just got ITIL 4.0, and it has a few additions.

If a mature company did as you see these other MSPs and IT service providers doing, how many Boards would they have in order to represent these disciplines, let alone the Tier 1, 2, 3, etc.? The answer is already built into Autotask. When you create a new ticket, it is designated as a Request, Incident, or Problem (ConnectWise doesn't do that yet that I know of). The idea being, we can have a separate team or department or agile group with a specific discipline focus and point them at the work, and we don't need 10 or 20 Boards to sort the work. That is the definition of silo!

Remember, Agile is a highly accountable team moving through work and only getting help in coordination, versus the stack and run – a service dispatcher pushing work onto the team.

Side Note on Cost of Multiple Boards
An open Issue is technically inventory. It is a quantum of service we are doing for the client. It is not considered delivered and off our floor (out of our stock) until it is closed and billable or attributable to the value we give the client in exchange for the Managed Services revenue we charge.

The number one rule of inventory is that you never move it if you do not have to! It costs you time and money every time you do. And the number one rule of touching an Issue (not just me saying this, but Agile rules too) is that you don't touch the Issue (even to move it) if it does not add value!

So, if you have people moving Issues from this board to that board and back and then forgetting to assign it or whatever, that is creating a rogue Issue. Too many touches without actually adding value!

My favorite saying about multiple Boards is this: The more boards you have, the more places you have to lose a ticket.

BTW, the team behind the PSA in the U.K. that I have been collaborating with – Harmony PSA (a fully Agile solution, by the way) – made it a point early on to ensure the entire database was indexed specifically so that any user can create any trigger, report, or sort using any field in the system. ConnectWise and Autotask could take a hint here.

#AgileServiceDelivery