A crash course in Support Excellence (SX)

Let me quickly dive deep into the Support Operations topic. Actually, it's not going to be only Support Operations, I'm going to expand on the Support Excellence term and give you a bit more sense of why it's called in this kind of weird way. 

First things first, let me just quickly introduce myself. My name is Oleg. I'm working in customer experience field since 2008. I started to run the department eight years later since I started my career journey. Lately, since 2019, I started also the advisor practice, which I'm currently holding on. Also, I just started my career at Microsoft and that was a really huge foundation for my whole career. Later on, I switched to cybersecurity. I also worked in several hosting companies, and even tried game development, which was very fun, and we can talk about this as well. 

But my latest journey was Miro. I joined when the company was about 100 people, I quit when it was 1,200 people. Recently, they raised $400 million Series C round and $17 billion valuation. Yeah, that was quite a rollercoaster. The Support Excellence topic would be specifically about Miro. This was the team that I founded back in the day. Originally, I joined as the Head of Customer Support. Then last year at Miro, I built from scratch the Support Excellence.

So what it's all about; the Support Excellence team was a team of the program managers, so we manage different projects on the ongoing basis and we focused on all their non-customer-facing work for the customer support team. We used to call it Support for Support. We try to empower them and to do our best to help them to be successful. And so, as I started building this team, we divided it under three pillars, operations, enablement and content. In a second, I will dig deeper in each of those. But that's actually the reason why we decided to call it as Support Excellence to give a broader perspective on their scope of work. Also, a part of this decision was that we already had People Excellence team and we thought it sounds cool.

As for the mission, as you can imagine, the Customer Support team exists to delight the customers and make them successful to ensure that they have all the needed support when they have trouble or maybe when they need to have answering some questions. And so, as you scale, you have the operational stuff going more and more, especially I experienced that when we started to have one more managerial level behind me. As the Head of Support, I was focusing more on the people related things like scaling the team, building their cross functional partnership, finding the right caliber. All of these kinds of things they prevent you from being very hands-on on the operation side of things.

Support Excellence's ultimate goal is to make sure that our Support team just prosper. Therefore, we take care of all the operational side of things. The final goal is just to ensure that Support team has all the needed information, all the needed tools, all the needed infrastructure to not just even thinking about them, they just need to have all the needed setup to make the customers happy. That's why we decided to call ourselves Support for Support.

So to give you a bit more sense about the exact pillars, we decided to have it just because it's easier to digest and understand what you're doing and how to present it in a better way and it worked quite well in terms of aligning our pillars with other departments for instance like sales enablement or product operations. It was like similar language that we use to have across the organization.

My definition of operations, and definitely operations can stand for different things, and especially it's getting weird and tricky when whole parts of the companies can be named as operations consists of either customer support, success, marketing, whatever. But when I'm talking about the operations and excellence in particular, I mean first of all, the function that helps core function. By core function, I mean functions like sales, success, marketing, product, etc. And so here within their support ops, we took care of the processes, their tools and systems, data and analytics, and all their cross-functional collaboration.

As for the enablement, we were working on onboarding the first two or three months that newcomers felt within the company. Also, we designed the post-onboarding experience because once you hit your trial period and may be successful to their full-time contract, your learning experience never ends and it can be different for the people who spent, let's say, six months in the company or two years in the company, and we still need to nurture them to make them successful. And hence, we also were working on learning and development. These can go both in soft skills, hard skills, the hard development, these kinds of things. We were also handling the product and non-product enablement. We were working very closely together with product marketing, with product operations just to ensure that the product, their Support team has all the needed knowledge by hand.

The last but not least was called Support content. This was an interesting hybrid between internal and external content. First of all, we were handling the Help Center content, the knowledge base that was and is still available for Miro customers. We were also designing the internal content and internal libraries just to ensure that their Support agents they have all their knowledge by hand. We also were working very closely with other teams in terms of cross-channel content. By this, I mean spreading the content over multiple resources, whether it's mailouts, blog, academy, anything that can help us to spread the content and prevent the ticket creation for the Support team. The last but not least, we also were working on their so-called self-service knowledge. This means that we were working cross functionally with different teams regarding the in-app help touchpoints where you can find the help within the product or where you can expand from the existing features to the Help Center or maybe when we're talking about designing the learning experience for the customers when we're trying to automate it through the bots.

If we're talking about enablement and content, I think they might sound similar, but the differentiation that we used is that the enablement is more about designing the learning experience, for instance, what kind of books we're going to have on the learning journey, but the content was about what kind of information we're going to have in those books. So they were working very closely and sometimes interchanging each other because we were a small team and we were wearing lots of hats.

While it might sound great on paper, I think it's very good to dig deeper into very specific projects that we took over. I hope this will give you a bit more sense of what actually we did at Miro. For the Support Operations, and those by the way just from one quarter. Those are real projects that we handled. Obviously within the year, we handled way more. But I hope that one by one you will see specific distinguishing between the type of the projects.

The ops projects were very undertaking. For instance, we were designing the ticket labeling and the distribution of the tickets. This is just a cornerstone project that we handled just to ensure that we have the right automation in place, the right routing of the tickets in place, we collected all the needed information beforehand and therefore, we also were able to eventually build the executive dashboards and dashboards for the Support agents and the team leads so they have clear and clean data by hand. We were working with the analytics team very closely to actually pull the needed data and design the needed data so also it can be helpful.

One of the biggest things in customer support is actually how you design the contact experience. For instance, what kind of contact channels do you have, whether it's emails or chats or phone calls. Since at Miro we used heavily the email support, we used the interface for the customers so they can submit the tickets, which was called contact form. Actually, building the contact form with all these categories is quite a big process. Because on top of that, you're building the whole complex infrastructure of how you're going to route those tickets, how you're going to assign those tickets, what kind of information you're going to have before you actually get in touch with your customers and these kinds of things.

So one of the things that we were doing is actually hiding the contact form behind the login, and this was very opposite things because we struggled because as a Miro customer, you were able to submit a ticket even though you are not logged in and hence we missed the time for identifying those users. For instance, you are creating the ticket from your personal email, but you are using it for Miro for their work email, and then we're just struggling with all those preset SLAs, preset rules, how we're going to support the customers. And also, we're just trying to figure out, okay, what is your login, what are your credentials, like how we can identify you. This project was heavily based on solving this pain.

I was also working very heavily on building the headcount model for the Support team. When you're scaling in this fast environment, especially after the COVID, you just really need to think twice and build a robust model for different scenarios, whether you're going to continue the growth or maybe the growth caused by COVID will be just not that fast and this kind of thing. I also worked together with the analytics team on this piece as well.

Apart from just headcount model, as a support team, you need to think about your workforce management in general, for instance, how you're going to support your customers 24/7 within different regions when you have so many holidays in every jurisdiction and you also have weekdays. All of this stuff is just very complex and you need to also think in advance and actually use some tools just to make sure that we can manage it in the right way.

And of course, we were working on tools a lot. Our main sandbox is Zendesk and so we were doing lots of stuff regarding integrating with Salesforce, with JIRA, also Success tools like Gainsight and so it's like just because you can have some challenges there. Also, with data restriction, it can sometimes be a very tricky thing to build custom-made integrations like that. Of course, talking about the cross functional collaboration, we needed to be very hand in hand with sales and success but also, we were designing the frameworks with product and marketing and all of those were very different. Of course, the very opposite thing about the process automation, we used existing marketplace for Zendesk. We also used Tray.io. We used Zapier. We also had a very tight collaboration with the Business Systems team, so they sometimes designed customized solutions for us as well.

As for the Support enablement, as I've mentioned, the core and cornerstone thing for the enablement is the onboarding experience. We used Miro as a product and Miro boards for this reason, together with Macrium and Zeplin. The combination of those tools was the foundation for the onboarding from the digital perspective. We were firsthand designing this kind of experience and eventually automating the recurring tasks where it's possible. We also were doing the buddy system and we also needed to enable both their People managers, their buddies to ensure that they actually know what to do, they actually understand how to support the newcomers on the team. Just because of the fact that People team was handling their overall global onboarding, we also needed to ensure that we have seamless experience for the newcomers so they are not going to go either confused or maybe they are not doing the similar tasks from both teams that were provided to them by their onboarding experience.

As I mentioned earlier, your learning experience never ends and so we were designing the ever-boarding experience for two years in advance, like how your learning experience is going to change when you hit one year at the company, or maybe how you're going to see your progress when you're getting more senior and you also need to have enablement for, let's say, spreading your knowledge over the new hires. Those kinds of things were also very important.

Talking about very specific day to day activities, for instance as soon as we decided to go with phone support, we also needed to enable the team on like how you're going to actually do that. Because before that, we had only the email support. Another interesting thing was more outside of the company because we started to emerge in their partnership and also, we've seen that some of our partners, they want to do the first line support for our company. So we also were trying to share the needed knowledge for them so we can deflect the tickets through their enablement.

Obviously, when we're talking about long-term engagement of the employees, we need to have some career development in place. And so, we were also handing their framework for the overall career development apart from the resources that were provided from the People team let's say performance reviews, etc. One quite interesting project that I did was the so-called talent pool, which means that when you're in the Support, obviously you're in the center of the organization, you collaborate with everyone. So eventually, you can go in any direction through your career, whether it's product engineering, sales, or whatever. We were trying to understand, together with the People team, how we can build those systems where people have clear understanding of how they can progress outside of the Support department.

As for the content, obviously we're talking about both internal and external content, and Help Center was leaving even before I joined the company, but you really need to take care of these and nurture on the ongoing basis. So we were creating a lot of new content and we were trying to actualize it every quarter every month. For instance, we are experimenting with restructuring, we tried to see if we can add more used case kind of content rather than just how-to or troubleshooting things. Also, we developed a completely new framework on working with the user feedback that we had from the existing customers. Of course, it also goes hand by hand with the verification process for the Help Center articles like how you're going to ensure that your articles are up to date, and sometimes it can be also tricky when you have couple of hundreds of those articles.

Regarding the Help Center, we also worked with the customization. This was more like cross functional and we were acting as customers for our engineering department where they helped us to ensure that the Help Center is very convenient, pretty and also goes hand by hand with our overall brand style. As I've already mentioned, we tried to spread the related content through other teams. For instance, we had quite close collaboration with marketing team because they had managed all the mailouts. Also, we were working with the marketing ops and we tried to seed our plans everywhere as we could for instance, within the mailouts or within some specific words in the blog. The goal was just to ensure that the customers are enabled on a very skilled way.

We also were working together with the product team on designing the Learning Center. Learning Center is the guide and the set of knowledge that is available right within the product. We were working closely based on the feedback that we hear from the customers.

Other than that, we also worked heavily on Guru. If you didn't hear about this tool, I highly recommend it because it's very handy in terms of the knowledge that you can get right here and right now through the browser extension. And so, we worked on both the content for the Support team, so they have all the knowledge by hand and also for the rest of the go-to market and organization so they are not bombarding their Support team with similar questions over and over again.

Obviously, we also worked on their template library, which is called Macro in the Support world. It was like collaboration with the ops, so we build the content and try to build automation in place so their Support team also speeds up the whole handling time of the tickets. And of course, we were handling the very detailed guides for the Support team, mostly through Miro because it's a very visual platform. As you can see, right now I'm using Miro as well for the presentation and it was very convenient as well.

So obviously, we love metrics. What I can say about this is, first of all, we're talking about lagging indicators, like customer satisfaction is just like a North Star metric for any support team. We also were trying to measure the employee satisfaction because the Support team was our customer and we tried to ensure that they're happy with our performance and they really value our work.

You can also talk about things like first-time resolution because as soon as you think about just customer support in general, we're talking about the combination of quality and the speed of their responses, whether it's phone support or the email support. But the first-time resolution it's about very highly correlated to the satisfaction because if you can handle it within one touch, then you're going to be more successful in comparison with an ongoing conversation for many months.

As I already touched base on this, we were handling their ticket deflection, which is measured by the contact rate so it's the comparison between the users that you have. In our case, we used monthly active users because Miro is a software as a service product and we tried to measure and compare it within specific categories of the users with the tickets that we're actually receiving.

We also can talk about the SLA compliance. By this, I mean the specific time that we agreed on for specific types of the tickets and our success regarding holding this promise to the customers. Within those, you can talk about first reply time and next reply time. If you can eventually improve those, then of course you're going to succeed with the SLA compliance.

Resolution time is very handy as well, especially when we're talking about the collaboration with engineering of product organizations, because sometimes you can have very long resolution times when the bugs are not going to get fixed and this is clearly a good signal for the engineering ops to ensure that we somehow need to either streamline the process of bug solving, or we just need to agree on some specific rules that we're not going to solve some bugs because we need to conquer the market.

One of the biggest drivers for the success for the Support I would say is average handling time. As soon as you can shorten these specific metrics, then probably you're going to be more successful both in the customer satisfaction field and also in terms of their productivity and also their cost efficiency.

That's briefly it. I've tried to give you a high-level understanding of what kind of function I had a chance to build and also what kind of challenges we worked on. Obviously, I can't give you a more sense of specific practices or frameworks that we use because I can talk hours and hours about that. But I'm more than open to continue our conversation, either through LinkedIn or the email chains. So happy to collaborate with you and happy to share my knowledge. Thank you for having me again.