ServiceTree will be replacing its full-stack software with a plugin that seamlessly integrates with ConnectWise Manage and Autotask.
Are you a tech working at a service desk, or managing the tech team? Ever find yourself getting bored; nothing to do? Nope, didn’t think so. The days of a quiet service desk are long gone!
One of the reasons for this is clients’ ever-increasing dependence on technology. Most businesses expect their staff to work non-official extended business hours via their laptops, phones and tablets.
And coupled with this is an expectation that service desk support should also be available to support these users and their technology during these extended business hours.
So the question is, how do you increase the output of your service desk without succumbing to crazy long hours?
I know automation sounds like old news, but if you’ve ever really examined a service desk, you’ll be shocked at how little automation is used in the day to day running of tickets. Most service desks are run within a very manual structure, where techs work on individual tickets from open to close, with zero automation.
It’s a little different with some of the level 3 techs. After all, they’re the king of techies – and some of these guys do automate some of their work. However, it’s normally done as an ‘it would be cool if I could get X to do Y’, rather than a deliberate decision to automate X because it would deliver better, quicker service.
There are two main reasons why service desks are not automated:
1. The business doesn’t see the benefit of service desk automation
2. The software being used by the service does not allow for automation
Still finding it hard to see how you can implement service desk automation?
A common issue in a service desk is that techs select the ticket they want to work on. So although the techs have a queue, or multiple queues to work on – unless the service desk is so quiet that there’s only one ticket in the queue, the tech can still choose the ticket they prefer.
Automating the ticket flow ensures the user can’t pick a ticket. Instead, each ticket is allocated to them automatically, one at a time, based on the priority and urgency.
And here are a couple of ways automation can help customers resolve their own issues without even calling the service desk (providing the software allows it).
A very common ticket is for a password reset. Typically, the user has forgotten their password, and they need a new one immediately.
It’s not uncommon for this to happen at say, 7 pm on a Saturday night. So why not automate it? Let the user (or their supervisor) create a ticket that will reset their password, SMS it to them and log a ticket, recording the event. Simple, right?
Another common one is for print jobs stuck in a print queue. Again, this is a common one outside of business hours. How cool would it be if they could create a ticket and have the system automatically restart the print service for them – even when they are working at home – or in a hotel on the other side of the country?
I think we can call that uber-cool. And yes, it is possible – with ServiceTree!
When we were developing ServiceTree I was adamant that the product name would be more than just a name. I felt the name needed to have a relationship with the DNA of the product and everything it stood for. It wasn’t just MSP software – it was much more than that.
In the early development stages, ServiceTree was known as Project Leonard – named after one of the characters of the hit Sitcom – Big Bang Theory. For those that don’t know me, I love the show – and many have said I have a lot in common with Sheldon. I sometimes question if that’s a good thing or not…
The systems we’d developed at our company, This Solution, were always named after other characters – such as Sheldon – which was our original information repository. We also have Penny – but more about Penny in a future post.
I had the idea early on that the word ‘Service’ should make up part of the name, as the product is all about service delivery. Traditional MSP software – that’s every other system on the market right now – is little more than a management tool; it lacks the critical service delivery element.
I personally believe ServiceTree is the only tool to ensure that QoSD (Quality of Service Delivery) is achieved in an IT support business. This is unprecedented.
I played with many ideas, but one stuck in the back of my mind from the beginning – ServiceTree. The more I thought about the name the more I realized that it was perfect for the product.
The roots of a tree are strong, deep and hidden – yet they make the tree withstand the elements for hundreds of years. Similarly, the architecture and the design that makes ServiceTree such a powerful tool is never seen by the user.
It’s all in the Decision Trees
Decisions trees form a key element of ServiceTree. While the similarity with the product’s name is obvious, so too is its role in the way ServiceTree works.
The trunk of the tree is the core that holds all the elements of the tree together. Likewise, the decision trees in ServiceTree are what every technician uses to work on support tickets.
The branches of a tree are the links between the leaves and the trunk – giving the overall shape of the tree. In ServiceTree we see our activity queues giving us this same connection – automatically feeding the tickets into groups based on the activities that need to be completed.
Then there’s the final element – the leaves. There are hundreds, if not thousands of them. They’re what fill the tree with life and provides its shape.
The job tickets are the lifeline of every IT support business. The more active tickets a support team has, the more hustle and energy there is in the team.
Looking at it this way, we couldn’t possibly have named ServiceTree anything else. It really is the best MSP software out there today.
I remember the day, a few years ago, when I was thinking to myself, “There has to be a better way to manage tickets!”
At that time we were using a ticketing system called CSR, which we’d developed for our own internal use. And the issue wasn’t that it was no good – after all we’d created CSR because there was nothing in the market that could handle our requirements.
But I believed we could do better.
Before we started developing ServiceTree, we researched the market comprehensively – hoping we’d find a helpdesk automation tool that could take us to the next level. We shouted into the void and all we heard back were crickets… Everything we found was designed around old platforms, or worse, old ideologies.
Also, my belief is that a ticketing system must be built around the requirements of the technicians – after all, they’re at the coalface of every successful ITSP, making stuff happen.
I spent many days at cafés and other vertical businesses, looking at how they managed customer orders. Although a cafe serves food (and an ITSP serves technology) – there are underlying similarities.
The customer wants to be served quickly – and their order delivered correctly and as efficiently as possible.
While both a cafe and an IT support team needs to balance many different (and often competing) elements to ensure they’re serving the customers as efficiently and effectively as possible, they also need to profitable.
I also spent time analyzing QSR – quick service (fast food) restaurants – and how they’ve adapted to technology. What I was able to clearly identify was that the only way an ITSP system could ensure tickets were done in the right order – was to build the system so that technicians didn’t have to pick which ticket they should work on next.
This was the key to the design, and what is now built into the core of our helpdesk automation system, ServiceTree. We call it Open Next™.
The Sunday that Changed Everything
I recall sitting at my desk at 8 am on a Sunday, tinkering with this idea and playing with the numbers; trying to figure out what felt like a simple thing but really wasn’t. I was so absorbed in it – number crunching and reworking the formulas that when I next noticed the clock, it was 7 pm!
But I’d hit the right note. I’d devised a set of formulas that would deliver the right ticket to the right tech at the right time. It was a Eureka moment – the purest expression of helpdesk automation!
Once Open Next™ was fine-tuned, I felt we had discovered the holy grail of service delivery for ITSPs. The new techs we hired who were used to the standard ticketing systems said: “This so simple, it’s awesome!”
The positive feedback we received from everyone associated with it encouraged us to file a patent and finally open the doors and offer it to others, too.
As I write this we have clocked around 39,000 tickets already; all of them triaged using Open Next™ logic. Over the course of a year, we saw a paradigm shift from managing and dispatching tickets to efficiently managing teams. We had blazed a completely new trail.