Every organization struggles with balancing user support quality and efficiency. The typical solution is to scale the team up, by hiring more people, and this is absolutely a necessary step… to an extent. However, it's also important to scale efficiently, by giving your new agents and/or engineers the right tools.
Scaling support should be like writing code: you can't just worry about whether it runs properly – you have to make sure that other people (and that can include 'yourself, two years later’) can follow the logic, in case something goes wrong and they need to fix it. One reason for our success is that we’ve made the onboarding and information-sharing process for our support team as seamless as possible. We want to make sure all our new people are qualified right out of the box, and we assume you want that for your new people too.
Support can be a monolith, but at Mux, we like to break it down into microservices, just like other infrastructure in a video streaming/monitoring stack.
Microservices are, as their name implies, a collection of tiny little services that contribute to a larger application or common goal (which is, in this case, high-quality scalable support). Our implementation of support as microservices relies on six components.
In a general sense, we’re a software company providing software as a service. Our product flow is based on logic, yes, but it’s used by Weak And Fallible Humans, who can entroduce irrors. So we try to minimize that, by automating as many procedures as possible.
Just like how Mux uses video compression algorithms to reduce redundant visual information, it can also reduce redundant tasks for our – and your – customer-facing engineers. You could call it ‘task compression’, if you were in marketing. I’m not in marketing.
For example, integrating documentation links for common questions can speed up conversations and improve both customer satisfaction and ticket times – and when you speed up dealing with individual tickets, you speed up dealing with tickets as a whole.
We try to make sure you’ll be able to find applicable information without contacting support. The key to scaling support is keeping your response times low – and to do that, you have to keep your ticket volume low too. While you’re welcome to contact us, we know you probably don’t want to unless you have to… and, let’s be honest, your customers probably feel the same way about you. This is why it’s important to have great documentation, especially when you’ve got a set of APIs whose flow is different from a UI-centric product. The official Mux blog is a pretty good resource, not just for fascinating Mux-related information from people like me, but for the general ins and outs of the web video industry. And we’ve got some plans to provide even more resources in the upcoming months, so you and your customers can use our products without needing direct support.
Our support team has multiple engineers who respond to tickets at different times. This means we need to carefully calibrate our support interactions, so that if six different tickets come in with the same question, six different engineers will provide the same answer.
If you’ve used our Data product, you’ve probably taken a high-level look at your viewers and used that to make your own product- or engineering-based decisions. Our Support decisions are based on high-level data contained in our monthly Support and Insights report, circulated company-wide. This gives each department more granular information about user interactions, so that we have a better idea of what needs improving.
This is a dashboard-style tool that shows all user information on a given ticket – a user's priority, what team/org they belong to, their name, location, time zone, shoe size, eye color, or anything else that might be useful. The app also gives a direct display of the user's /video and /data info without needing manual lookup, reducing time to first response.
A crucial aspect of scaling support is tracking what users are writing in about. This helps us – and (again) you – make decisions that stimulate growth. If we see that users are constantly writing in about Webhooks, for example, we'll be more inclined to create a new Webhooks guide, code example, or blog post.
This might be the hardest metric to track internally on each ticket, which is why we’ve introduced a tagging functionality. Any engineer working on a ticket can Tag it depending on what needs support. This is fine as far as it goes, but it relies on – as I mentioned earlier – Weak And Fallible Humans. Having engineers manually tag conversations each time they answer tickets can create a whole new set of problems.
Fortunately, We can now do automatic tagging based on message content - for instance, all incoming messages with the words "live stream" or "OBS" are automatically tagged "Live Stream".
In conclusion, scaling support is an ongoing process at Mux, where we hope all our customers will also be our fans. The support vibes here won't ever change: you'll always be able to find an engineer to help you with a technical issue, and we'll always have a transparent overview of your needs.