Custom Workflow Ideas for Your Professional Service Automation Platform

As a Managed Services and/or IT Support company, the most important tool in your toolbox is likely your Professional Service Automation Platform (or PSA). It is nearly impossible to successfully operate a modern day MSP without one, which is why companies such as Autotask (Datto), Kaseya, and Connectwise always appear to be in the middle of the Merger & Acquisition “Pacman” that is happening right now in the IT channel.

Adapting vs. Adopting Workflows

When you first implement a new Professional Service Automation Platform it can be a major “shake up” for your business. That is because for each step in your businesses’ daily process, you are forced to do one of two things; take the time to customize the system and adapt it to your business, or see what the system is already built to do and then adopt these as your own processes.

I believe that the best choice in this decision is to simply take this by a case by case basis. When we implemented Autotask as our PSA, we certainly adopted a lot of the processes therein. As soon as we were comfortable we immediately began developing custom workflows and testing different changes to optimize our Service Department’s productivity. One of the pillars of growth hacking is to constantly test, optimize, and automate and doing so through our PSA workflows was one way we kept our Help Desk lean and profitable.

Service Automation Workflow Ideas

As our business changed in size, revenue, and technology through the years, our workflows changed with it. That being said, here are a few that we believe stood the test of time and remain noteworthy.

• Managing Contracts – When we truly matured as an MSP, we made sure that contracts were updated annually and the billing was tight. What we found was that the PSA did not really have contract notifications or even auto-renew features out of the box. This led to some contracts expiring and billing not being processed in the following month. This might seem like reckless behavior, however asking a part time bookkeeper to adopt an IT Service platform and manage hundreds of contracts is no small feat. We aided this effort by developing workflow rules to notify account managers and operations personnel when a service ticket was created with an inactive contract. This was the backstop we needed to ensure that these issues were behind us.

• CC’ing Decision Makers – Several of our customers’ Decision Makers or Internal IT Departments requested to be copied on all ticket notification for their entire company. Most of them immediately regretted it when they saw the volume of emails this produced and the noise eventually became too much to process. We found that creating workflows to trigger these notification under certain circumstances was the best way to remedy this. Ultimately, they didn’t have a need to see every ticket update, they just wanted to ensure that nothing critical was being overlooked and that their users were not abusing the service.

• Removing Ticket Resource – Most MSPs will have their own preferred workflow for ticket queues and how tickets are assigned to technicians. We opted to have our Level 1 and 2 techs work directly from queues and only assign tickets when an issue was actively being worked on. The problem we found, was that when tickets are assigned to individuals, it becomes more of an “every man for themselves” attitude and less of a team effort. Issues also would arise in the even that someone called out sick or left for vacation and their tickets were not manually reassigned. We prevented this by creating a workflow to unassign resources from all Level 1 and 2 tickets when it went idle for a full business day. An available technician could then pick up where they left off without any need for collaboration.

• Customer Note Added – We always allowed our Service Technicians to provide us feedback on how they think the Department should operate. Through this feedback we found that it was difficult for the technicians to know what tickets were the most actionable at any given moment. We found a ticket to be the most actionable immediately after a customer added a note. This is why we created a workflow rule to change the status of a ticket to “Customer Note Added” whenever an external resource replied to it. The technicians could then sort their queue by status “Customer Note Added” and work the tickets accordingly. This cut down on the amount of time it took to close a ticket on average and thus reduced the overall size of the queues.

• Idle Ticket Follow Up – To be frank, end users don’t care whether a ticket is “open” or “closed.” Their motivation to work with the Help Desk to resolve a ticket is simply so they are no longer affected by whatever the underlying issue was. Sometimes technology issues come and go, and with that so does the responsiveness of end users. This leaves abandoned tickets in the queue all the time with a ton of follow ups but no user response. We decided to automate these follow up a series of notifications to the user when a ticket has become idle. If the user did not respond in a reasonable amount of time, the ticket was auto-closed and a Service Manager was notified. This seemed to really get our user’s attention and cut down significantly on our team’s time manually following up on tickets or scheduling remote sessions.

We hope you find these ideas helpful in developing your own custom workflows in your Professional Service Automation platform. If you have any workflow ideas of your own that you would like to share or if you have questions about how we developed ours, feel free to comment below.