In this post we want to provide a status update on Unimus support, share a few improvements that are coming to our support system soon, and also share some analytics and graphs on what our support performance looks like. This will be a longer blog-like post, so let's get the exciting things out of the way first.
- We will be introducing an option for 8/5 Phone Support with per-device licensing, as many of you have asked for this. Up until now, this was only available with the Unlimited licenses.
- A new Support Portal is coming in Q4 this year. This will improve visibility into progress of tickets for you, and allow us to better organize the support process on our end.
- We have created a new position on our team dedicated specifically and fully to support, and hired a new colleague for this. This will take some load off the dev team, and improve the support experience for you at the same time.
A new "8/5 Phone Support" tier for per-device licensing
The per-device license tier always came with 8/5 email support. This is not being changed in any way. However, quite a few of you asked us for the possibility of upgrading to phone support without the need to buy an Unlimited license. We will be introducing this option in Q4 this year (2021). This will come at additional cost (based on the license price), but it is fully optional. This will therefore allow access to phone support even on smaller licenses, without the need to pay the full Unlimited license price.
A new Support Portal
When we started the Open Beta for Unimus back in 2016, support was super easy. A few topics here on the forums every now and then, and maybe a few emails per week. These days the situation is of course very different, as Unimus is now being used by thousands of networks all around the world. We now get around 10-20 support emails daily.
In the last 2 years alone, the amount of new tickets per month has doubled:
With each ticket comes a sizable increase is email volume, as a single ticket usually takes multiple emails and followups to close. We have been keeping up with the ticket queue at a decent rate. From all the tickets opened in the last 2+ years, about 9% remain unclosed.
The unclosed tickets are mostly new feature requests (which we leave in the "Opened" state on purpose), or tickets we specifically left "In progress" as the request is covered by something on our Roadmap, and will be closed once the relevant feature is released.
Up until now, once a ticket is created on our Portal, the rest of the exchange takes place over email. This worked well at smaller scales, but we are now at a point where a better solution is needed. For example, full ticket histories are not available on our Portal, and an email client leaves quite a bit to be desired as a ticket management platform on our end. We are now at a point where a proper user-facing support system is needed. In the coming months, we will be rolling out a new Support Portal for this. This should provide a much better support experience for you, as well as making it easier to continue scaling the support processes on our end as well.
A new dedicated support position
During the first couple of years when ticket inflow was still low, it was mostly me who was responsible for handling support. As the new ticket flow increased, we distributed the support responsibility across the team. We always have (and always will) keep a very technical support - we do not have an "L1" support tier. If you create a ticket, you always talk to someone very technical, or directly to one of our devs. This however meant that up until now, some of our developers' time went into support tickets. This of course had impact on development pace. We are now at a point where opening a position 100% dedicated to support to process (and answer) incoming ticket makes sense. This will lessen the load on our devs, and at the same time make for faster ticket resolution times for you.
Speaking of ticket resolution time, here is how we have been doing on that front historically (in the last 2+ years):
These numbers do require some context, as how these numbers look is directly affected by how we choose to organize our tickets:
- we do not exclude ticket wait time (for example, waiting for a reply from you) from resolution time
- if we are already committed to a particular feature development (feature is in design or development phase already), if a ticket asking for or related to this feature is created, we keep it "In progress" until development is finished
- if the ticket is a feature request for something that is already on the Roadmap, we leave a ticket in the "Opened" state
- if a ticket is a feature request for something not currently planned on the Roadmap, we create a ticket in our backlog, and close the "user" ticket
Around 70% of all tickets get resolved within a week - with more than half of those taking less than a day to resolve. We think this is a decent resolution rate, as this includes time tickets are waiting for replies from customers (you), and often there is some scheduling delay if a remote session (Zoom) is required. There is room for improvement here, and we want to push as many tickets here into the "<1 day" category as possible.
Around 16% of tickets take between 7 and 30 days to resolve. These are mostly tickets that actually require a release to be fixed - either being a bug, or being a minor feature request / behavior adjustment. There are a few tickets here that are long-running non-release related tickets - these are the ones where we would like to improve on the most.
The next category is actually in a similar position - 10% of tickets taking 30-90 days to resolve. Almost all of these tickets are either bugs requiring a release where a release was more than a month away from ticket, or mid-sized feature requests. Finally, there is a 90+ days category. All of these tickets were for major features, so took a significant amount of time to close. For example, the 2.0 development period was 7 months, so if someone had a ticket opened regarding Zones / remote polling / proxying, we would keep the ticket opened until 2.0 was released. Similarly with 2.1 which brought in Backup Filters. We had a number of tickets that were kept "In progress" during the 2.1 development cycle (9 months).
Like mentioned earlier, we now have a new team member fully dedicated to support, and we are quite happy to report we are seeing improvement on the ticketing metrics. Here is a look at how ticket resolution time has changed from the 2+ year average in the last 6 months:
We have increased our "<7 days" resolution rate to 75%, and decreased the number of tickets that stay in an unresolved state for extensive periods due to more frequent releases now that the long development window of 2.1 is over.
If you have gotten to this point - thank you for reading this entire post! We hope this was at least a bit interesting If you have any feedback, or would like to offer some pointers or ideas, we would be glad to hear them!