127: Support’s Relationship to Product with Craig Stoss

Charlotte Ward  0:13  

Welcome to Episode 127 of the customer support leaders podcast. I’m Charlotte Ward. This week we’re talking about supports relationship to the product team. So stay tuned for five leaders talking about that very topic. I’d like to welcome back to the podcast this week, Craig Stoss, Craig, it’s lovely to have you back and we are talking about supports relationship to product.

Craig Stoss  0:43  

Yeah, thanks for having me. Sure.

Charlotte Ward  0:46  

So what what do you think of this relationship, then it is it? Is it a situation where product or product is created, and it’s thrown over the fence. And support is expected to deal with it?

Craig Stoss  0:59  

I mean, I think that’s how a lot of companies operate. But I don’t think that’s how it should, right i think if you’re going to try to drive a real customer centric product and a product that is very supportable, very easy to use a, you know, a desirable user experience, you have to have more of a symbiotic relationship between products.

Charlotte Ward  1:21  

What do you think that looks like them? Can Can you describe to me what you mean by symbiotic.

Craig Stoss  1:26  

So it starts with support getting their own house order. And by that I mean through the through the gathering of customer tickets and customer feedback, making sure that the right knowledge base articles are created, maybe the right guidance videos are created, understanding where the trip points are in your product. And just getting that that kind of data set ready in that knowledge ready to share. Once you have that, you can go to product and say, okay, we need to build a tool, a product that the customers can use, effectively, and be able to support those customers in line when they’re actually working in real time. And that might mean, for example, embedding support articles through your product, or using a third party tool to embed walkthroughs, or videos or knowledge content directly in your app. It could mean embedding chat for support inside your app directly if they you know if it suits it, the but the idea is that you work with product to make sure that the tool is easily supported, and that the customer who’s using your tool can get support easily through it. And once that piece is done, once the tool is set up for support, to to function and the customer to gain that support, the next step is that support can then feed in important product data back into the product organisation to improve the overall offering. And that’s what I mean by synbiotic is that product can improve based on support feedback and support data as well support can improve because the product is set up to be supported.

Charlotte Ward  3:02  

Right, so it becomes a kind of positively reinforced circle, right, it’s a positive positive spiral,

Craig Stoss  3:09  

it’s absolutely like if the customer has an easier way to send feedback into into your company and typically through a front door like support or success, then that makes it easier to then improve the product because you have the data in real time you have that feedback that voice of customer feedback

Charlotte Ward  3:27  

and you can be really reactive Can’t you with some of that data and as your as your customers interact with your product even beyond just giving them a portal to support and support information and more contextual information and, and education with in product you can do quite a lot. If your product team is set up for it, you can do quite a lot with matching your support data to how your customers are using the product try so you can spot trends in that kind of data as well if you’re able to track actions with the product.

Craig Stoss  4:02  

Absolutely be you know, I think that when you release new features, especially in the SAS world, the feedback is almost instantaneous. The you know, you’ll see us spiking in case loads and you’ll see you’ll see customers getting into your chats or coming through your knowledge base looking for details on something if your knowledge base is embedded correctly. Those those things happen pretty instantaneously in in the SAS world. Now your tools might have to be set up to collect that and I think that’s where things like ticket tagging and you know AI natural language processing come in and there’s a several good tools that overlay a SaaS product and that allows you to measure different clicks and flows of customers. So if you’re expecting a customer to go you know, click a button a button B and A button see what you discover. They’re clicking a B and D for some reason. disproportional to what you would expect, then you can start to say, well, maybe there’s a user experience problem, maybe the UI isn’t intuitive. Maybe maybe the the workflow itself doesn’t make sense. We misunderstood the customer’s desires. But those are all things that the product needs to be set up for to then reinforce that loop, as you said earlier, and that spiral of, of getting that feedback in real time into product.

Charlotte Ward  5:26  

Mm hmm. And it does rely on the correct tooling. I mean, and I’m not fully in full transparency here, I currently I’m employed by a company that that it does a great deal in this area of pulling data from multiple sources. And I think this, this relationship between product and support is one that it’s just ripe to be data mined in that sense, and, and probably some from some other customer touch points with the organisation as well. But But nothing you said there. I mean, tagging, I think is a really huge part of this. And I think if you set up a, a well thought through tagging taxonomy in your support tool, I think that’s just a big way to make it into eating all of these conversations around product and, and supports relationship to product, isn’t that?

Craig Stoss  6:18  

Absolutely. And it’s one reason why what I think that, you know, many customers approach tagging from some sort of, almost like a preset list, you know, here are the 10, high level features of the product, fewer of them, maybe each have four or five sub features. I don’t think that’s really the way to go. Because I don’t think that tells you enough information to make educated decisions. And a previous company, I implemented a process where we had five categories of tags, and those weren’t set, they were free form text, which would, you know, does have its own problems, as far as you know, no duplication or spelling errors or things like that. And I admit that, but having those five categories with things like what object is being worked on, was it? You know, what was the action? Was it edit? Was it a Was it a? Was it a create? What, what page specifically, within the application was it on? There were there were these five categories, and we agreed as a team that the standard that would be QA, when we did their ticket QA was that you had to have at least one tag from at least three categories. And and that was a way of being able to go to go to a development team, go to a product team and say, listen, we know that on page, you know, this page, the, you know, the widget page, the creates have a high level of ticket load. And we don’t know necessarily why we have to dig into that data to tell you, but we can tell you an action and a location, as opposed to maybe that high level feature that is pre set in stone, and maybe not directly, directly related to the problem itself.

Charlotte Ward  7:54  

That’s amazing. I’m gonna think about whether I can make that work in house. Right now. We’re about to embark on that huge tagging audit right now. And I think it’s probably a good place to start. It just even if you don’t tie platforms together, just having that level, and being able to have that type of conversation is really powerful with product. And I’m going to go and have a look at that.

Craig Stoss  8:17  

What I mean, I hope you do, and I’m happy to talk more about it when you do. But the I think you hit on something there. It’s it’s a conversation with product, right? I think, again, one of your first comments was about throwing, you know, the product over the wall to support it. And, and that’s really just a bad way to work. You know, there has to be constant communication, you know, support arguably talks to the customer more frequently than any other team. And if they even if they don’t talk to the customer than any other team, they have probably more data about the customer in real time than any other team. And I would argue as a product organisation, you should be clamouring for that data, you should be actually influencing what your tags look like you should be influencing how that that data is presented, whether it’s in some sort of weird pie chart or some sort of textual background. And you should be part probably paying for part of the budget for your natural language processors because they aid the product team just as much as the support team. It’s that type of thing that I really do believe that if you have the right leaders in place and the right customer centric policies in place, then then you can actually really improve both your product and service in a as you set a spiral in a never ending loop. Because it’s self fulfilling.

Charlotte Ward  9:39  

That’s it for today. Go to customersupportleaders.com/127 for the show notes and I’ll see you next time.