software

Managed Services Metrics Service Managers Should Focus On

Your managed services helpdesk team is very busy. There are several service desk metrics that can help measure your performance. Here are some metrics that a service manager should be focusing on.

Simple Service Desk Metrics

Open vs Close

The easiest service desk metrics to focus on is the number of tickets open versus number of tickets closed. If there are 200 support tickets opened in a day you should be closing at least 200 tickets a day. This is a simple measure of your closure rate. If you aren’t closing more tickets than you’re closing, you will end up with a backlog. A backlog of tickets will lead to longer resolution time on tickets which will lead to unhappy clients and stressed out support staff.

Mature Service Desk Metrics

Service Level Agreements (SLA)

Once your service desk reaches a certain level of maturity and is able to close more tickets than are opened in a day, the team can move on to more advanced service metrics. Service level agreements (SLA) ensure that when a support ticket is opened, it is acknowledged, started, and resolved in a set period of time. An SLA will ensure that not only is the simple volume of tickets being managed, but the priority of the tickets is being managed as well. Since not all tickets carry the same urgency, it’s important to be able to juggle a little and close the high priority requests fast. I did a very detailed blog post previously about managing SLAs [here].

Performance Management (Advanced metrics)

Tickets Per Tech

Once the team metrics are in place, you can start to focus on individual contribution. How many tickets should the support techs be closing? This can vary a lot from person to person, but having an expectation of output from each team member can be invaluable. Tier 1 support staff, in general, should be able to close 10-20 tickets a day. Tier 2 slightly lower at 5-10 and Tier 3 maybe 5 a day. Whatever the number is, just simply having an agreement between the team member and the service manager is important. This allows for a measure of the output from each team member against a target. If there is a slip in actual output, the manager can work with the staff member to determine why. It can also allow the manager to increase the team performance by setting higher output targets with the team.

Client Satisfaction (CSAT)

One of the key risks to increasing a helpdesk staff members output is it can often lead to low-quality closes. In order to hit a certain number, the helpdesk staff will simply close tickets without checking with the user to ensure they are satisfied with the resolution. When you’re smaller you can review each ticket to ensure the staff is following the support policy and contacting the user to make sure they are satisfied, but this approach doesn’t scale well. Using customer satisfaction (CSAT) as a team metric as well as an individual metric is a great way to protect the clients from quick-closes. Having CSAT scoring available to measure individual technicians metric is really useful as well. If you’re using Connectwise or Autotask surveys you’re likely not getting the amount of feedback that makes this a useful metric. Instead, use SimpleSat. SimpleSat makes it crazy simple for the client to give you quick feedback on every ticket that gets worked on. Plus the data is collected in a beautiful dashboard for easy review or team and individual staff members.

Simplesat Connectwise Survey Dashboard

Simplesat Connectwise Survey Dashboard

So if you’re just getting started with MSP helpdesk metrics or you’re already a mature operator, make sure you are using CSAT to measure and manage your customers feedback about the quality of the service your team is delivering. Simplesat has a free 30-day trial to get you started and if you tell them that you heard about Simplesat from Evolved, they will give you 15% the posted website price.

 

Header image thanks to Infocash on Flickr.

Technical Debt Creating Risk?

At a recent meetup for Tech Vancouver, a speaker was presenting on the idea of technical debt. Technical debt is the act of sacrificing quality for speed or convenience.  For coders, this means that certain parts of the code are not as clean or stable as they should be. Hence, you are indebted to that shortcut with both risk and the commitment to revisit it later. The implications for this practice and risks will become more severe in the future.
Agility Problem?
Agile methodology is a progressive form of code development and tends to support these practices as well. Agile development helps to break down the work into more manageable chunks. The issue is that these chunks are intended to be iterative. There is no assumption that the work product would be 100% on the first or even the second pass. The software will have numerous iterations before it is even close to considered complete. This removes the burden of perfection and time issues on the delivery of a viable product but also increases the risk for errors. Agile is not a bad practice it is very common. However, it does require more strict quality control.
Patch, Patch, Patch
With the connected world, patching is a given. In the early days before the wide reach of the internet, you couldn't ship a piece of software that was faulty. There were no effective means of patching that software if there was an issue with the quality or reliability of the code. A poorly released product could mean a failed product or even a failed company as a result. This is still a risk, but the bar to what is acceptable in a release seems to be much lower than before.
Forever Beta
Beta release of a product used to be done with a select group of customers to ensure bugs were caught before the release and also that the features worked in the way that suited the users. Presently the role of a beta release seems to have expanded. Beta releases act as a wide release to capture many of the issues that should arguably be fettered out in quality control. There is an old ideology in IT that you never adopt version one of a product. Let others test it out, let the software company fix the major bugs in an x.1 release, then you can adopt the release. Some software seems to be in a perpetual state of beta where nothing is ever complete. If there are no patches being released, there are new features, that will then need to be patched. In some cases, this reality is driven from the marketing department. Delivery dates for a product or a release are set well in advance. All efforts are made to hit that date even if it means in some cases that an inferior product is the result. After all, we can just patch it right? 
Risks exposed
One of the arguments for open source development is that you can't hide bad code. Everyone can read, review, comment, and correct issues. The argument is that the risks are lower since the code has already been vetted. Therefore, the code should be fewer errors and vulnerabilities. In private sector development, the idea of public code is not practical. So how will this problem be managed in the future? With the rise of cybercrime, the need for lower risk software is rising. In a recent interview with Lachlan Turner of Arcinfosec, we talked about the growing risk of cyber terrorism. Losing your data to encryption is a serious problem for a business, but losing control of pressure in a gas pipeline could be catastrophic. We may see more legislation to ensure some standards are in place with code. For example, standards guide for code implementation when dealing with high-value assets. No one should assume that these controls would eliminate risk, but certain standards for software are a likely progression from manufacturing practices that ensure our physical products do no harm. The future is a connected world where everything is hackable. The exposure of physical risk will become a more prevalent issue as software plays a more visible role in our physical worlds, beyond the digital world.