Support Burden
This is one post in a series that outlines some key metrics that best-in-class software vendors tend to focus on when designing the teams, process, and product integrations for distributing their application to customer environments.
Definition
The number of hours your teams spend supporting your customers per on-prem installation per month (support/instance/month).
Detail
-
Tracking support burden over time is an important metric to monitor to ensure you are staffed to handle the support volume your customers require and to scale as you grow.
-
While your overall support burden will grow with the addition of new customers, the amount of support required per instance should decrease - this is what allows you to scale.
Best in Class
1 hour per instance per month.
How to Measure
-
Replicated can help with measuring time spent on end customer calls, however, we won’t have visibility into support issues where Replicated wasn’t engaged.
-
If you are using a support tool or ticketing system, it will likely have reporting that can help calculate the amount of time spent on support within a given period.
-
When you first start off and only have a few production installs, we recommend tracking overall support hours per month. However, as your number of installations grows, it is important to add in the additional factor of number of instances.
-
You can total this metric across all customer-facing teams and also calculate this metric by individual team (i.e. field, support, engineering) or level of support (tier 1, tier 2, etc.).
-
Below is an example graph of tracking this metric over time:
How to Improve
There are two primary paths to reducing support burden. The first is to enable your customers to self-serve, and the other is to reduce mean time to resolution when they do need your direct support.
-
Support Bundles - In the scenario where something doesn’t go as planned, customizing your support bundles through collectors and analyzers enable you to find the source of the issue to resolve it more quickly by eliminating the back and forth and collecting everything at once. Support bundles also allow your customers to debug and self-remediate using the troubleshoot page in the Replicated admin console.
-
Training - if your field and support teams are trained, they will be able to identify and resolve issues in less time. We have Replicated field labs that we recommend everyone go through to get a better understanding on how Replicated works with your application(s). We also have some recommendations for trainings for folks who are new to Kubernetes or are looking for more advanced training.
-
Replicated support training - It is also important that your field and support teams have proper access to the Vendor Portal and your GitHub collab-repo and are familiar with our support paths and processes in the event you need our help. We also have a video on efficiently scaling your customer support process that we recommend your team watches.
-
Documentation - documentation also plays a large part in support burden, both through external facing documentation to enable your customers to self-serve, as well as internal documentation to help your team support your customers. We have an example repository that can be used to start your documentation.
-
Architecture outline - having an outline of your architecture in your GitHub collab-repo readme provides the Replicated support team with context on how your application is set up and allows us to better support you and your customers. Sharing this detail with us helps reduce back and forth on issues and results in a faster resolution.
Related Metrics
- Time to Live - a reduction in time to live will have a significant impact on your support burden as the time your teams spend on helping customers with installs and upgrades decreases.