Charlotte Ward: 0:13
Hello and welcome to episode 104 of the Customer Support Leaders Podcast. I'm Charlotte Ward. This week we have another fireside episode, and this time I talk to Simone Sechi. I'd like to welcome back to the podcast today, Simone Secchi. Simone, it is lovely to have you back. And this week you are joining me for a fireside. And while our listeners can't see this video call that we're recording this conversation on, you are in fact sitting by a very wonderful and welcoming, but albeit virtual background of a fireside. So thank you for bringing a fireside to this conversation. And uh and also you're bringing the topic as well. What would you like to talk about today?
Simone Secci: 1:07
So I thought I will bring up a topic that um has been at the center of my projects and uh and the roadmap of uh the support team um for doodle in the in the last I would say six months, which is support data. And so um I wanted to give an overview of like all the different aspects of uh support data and how they can come in uh handy, like to have difficult conversations and uh how can they be shared and how can they help you plan out different aspects of uh a support team and different aspects uh different operational aspects of a support team.
Charlotte Ward: 1:47
That's awesome. Um I know we've talked a number of times, and you've been on quite a journey with data, haven't you? And it can mean quite a lot of things as a as a as a topic, it's a broad one. I mean, we could be talking everything from setting up your dashboards and figuring out what you can measure to ultimately completely the other end of that scale, um, what you do with that data and who you talk to about that data. So I'm looking forward to this one. I know these are all all aspects of that journey are things that support leaders find challenging in multitudes of ways. So I'm looking forward to seeing where you take us with this one.
Simone Secci: 2:26
Yeah, so um I think not to scare anyone off, but one of the main things I think that you have to set yourself up for when you approach data uh in in support and in from any one of you is learning. So you're going to have along this path. Like I started approaching data in in leadership role back in 2014 when I was commissioned my first KBIs report. And first were highlights, and then I started to bring like very simple KBIs, so like Ticket Solved, and um, you know, uh first response time and things that were easy to find. And and I think back then I was using this and as um insights um with good data. That was like my first approach. It took me a very long time, I gotta say, to familiarize with the the specific language that the the product used, which was for whoever remembers that, you used that in the past, it was like a sort of like uh a customized version of SQL, um which wasn't immediate uh if you weren't familiar with the programming languages or you know, you weren't a technical person per se. Um and then you know, slowly it took me to approach data not just within um you know an ELP center or uh support uh support data, but just starting to look at data from the point of view also of um looking at company um data outside of support and see how related to support data. For example, to understand the return of investment of support, understanding the impact of support on um the annual revenue or monthly revenue. So there is a number of things to understand the connection between what you're doing and what impact it has. Um and it they can be accidental discoveries or the it can be a very um very like voluntary path where like you get somewhere to get to.
Charlotte Ward: 4:36
Sorry, so so do you think you need to know where you're going before you start measuring, or is it a matter of figuring out what you can measure and finding conclusions to draw, or somewhere between the two?
Simone Secci: 4:48
I think you you yeah, you need to you need to understand where you want to go, so what you need and why. And then I think that a data scientist would say that the the problem would be to figure out what the data model is to get those results. So to what like a technical term I became familiar with recently, you have structured data and you have unstructured data. So structured data is anything that can come in a CSP form, for example, it's already tabular. And then you have unstructured data that can simplest example is text. So you have conversations, and and you you have to understand what do I do is like unstructured conversation, right? Because this is a problem, I think, that the um if you're not familiar, you're not a data scientist, you you just became a team lead and you have all these conversations and you know there's a customer sentiment or something that is happening, there's a bug or something, and you want to track it. Um so one very common you know mistake you make in the beginning is just reporting the sentiment. I've seen that there is an issue, and I've seen more or less this many tickets. If you go with that type of attitude towards your leadership, it doesn't mean anything to them. You know, it's an opinion. If you pack that with like concrete data, especially, and I and I found this, you know, uh in this case, like appearances matter, like well presented and visual and easy to digest the visualization of data that makes all the difference in the world. They buy into it, and you you have the, you know, you have the attention of the room at that point.
Charlotte Ward: 6:26
So I I think this is just dressing up your data in a way that makes it seem well-founded and therefore more trustworthy, actually, than just a few numbers on the back of an envelope kind of thing, right?
Simone Secci: 6:40
Absolutely, but also that the fact that it's like you have to always think how can I present this data so that it can be understood if somebody doesn't have the context that I have, right? So nomenclature that you use in support, like text that you use, categories that you use, how can you explain them visually without having to give like a lot of context, putting out the notes, you know, making it like really how can you do that?
Charlotte Ward: 7:08
Yeah, yeah, it's more than just the colours of the graphs you use, it's actually like like sometimes the difference between the type of charts and that kind of thing can make quite a difference in in providing that context that you're talking about, because we might understand quite naturally, you know, a a line kind of trend or something over time, because we have the whole context that's built into, we have the whole backstory of say what a handle time means and how and how the different types of work that our team do affect that handle time and all the other interconnecting pieces that that kind of bubble up around that handle time in terms of other data points or other activities. But if that's all you present, if you just give that line chart to someone in the organization, it could be pretty meaningless, right?
Simone Secci: 7:58
Yeah, it it could be not enough. You know, there's always you have to consider what are the follow-up questions. And you know, obviously for everyone, uh you start with some incomplete data and you hear some follow-up questions, and then you learn, like, okay, when I presented that data that way that that was missing, and I didn't really reach the goal that I wanted to reach, and like I didn't really communicate what was clear in my mind, and then you you go by trial and error and you perfect that um going forward. Um, so to quote some you know, uh concrete examples, I would say, of what the uses that you're gonna have in data, we can break it down um in uh in support in a few aspects. Like we can say that some what we really uh care about is performance data, then we have self-service data about like all our self-service initiatives and help center. Um if you have um if you're using AI, for example, like understanding the impact of that on reducing cost on on your on um the team, the stress that you put on the team. Um and um, you know, then you also have like uh quantitative data in terms of like uh forecasting, for example. So you know, in the in that sense, you you start with everything, I would say, pretty much from tagging, from categorization. Categorization is like the first thing that you have to to um try to nail, which is you know, understanding okay, what categories so what what principles guide the categorization you want to make? So I would say uh three main things understanding uh the impact on reducing the cost for the organization, understanding the impact of uh of a change in the organization, product change, for example, like you have feature requests, or you have feedback negative positive, um marketing campaign, once again, feedback negative positive, and um you know, um so this this this part I would say um is is very important, but uh as well um understanding uh your your performance. So these three things uh one is internal, two are external, if you will. Um start all with the categorization. The right categorization will set you up for successful gathering of of data.
Charlotte Ward: 10:44
Yeah, and I'm trying to understand like practically how I translate that into my categories that I might set up. So are you saying, I mean, obviously it's gonna vary significantly from organization to organization, but yeah, absolutely. But but but are you saying that in your experience you need a very limited number of categories because you really uh the the model you use is is to just try and capture in the categories the influence of that ticket on one of those three areas.
Simone Secci: 11:17
Right. So those are the guiding principles, right? They all come from understanding the customer experience. So you have you know understanding customer experience to do to improve the products, understand the customer experience to reduce the cost, understand the customer experience to improve the quality and consistency of your support interactions. From that, you generate your your large buggets of data, right, for categorization, like what type of issues you deal with, for example. Like it can be very general things, like and they can be common to all support organizations no matter what you do. It can be e-commerce, it can be uh social media, it can be a SaaS company, but you all always have bugs, you will always have feature requests, uh, or feedback more even more general. Um, you know, if you have social media, you have those categories. It can be social media, your your big bucket, like uh Twitter, Facebook, LinkedIn, whatever it is, or it can be broken down by specific uh social media. It doesn't matter, like you know, uh these messages will come in. Most companies have this uh external channels, right? And say you will categorize them like that. Um, you have mobile apps, so that will be another category. It can be mobile apps, or it can be broken down by type of mobile, it can be Android and iOS. So this type, for example, like five this five buckets, no matter what team you will go, you will have this category. Then you will go more granular and start using tags to characterize, for example, a female event, like an outage. Um, you want to be able to track it, or you want to be able to track a specific type of uh critical issue over time, uh, figure out a trend line. So if an issue is an it could happen in some organization that maybe there's an issue that's overlooked a little bit, and you want to prove that there is an impact for that issue, you want to make sure that you have that specific tag, you track that over time, and then you could, for example, go and measure that against um trial conversion. So let's say that this issue affects users. You could see how many users um on a trial, if you are a test company, for example, are affected by this issue, and how many then churn. So churn metrics that you can get from you know your data scientists, or you can get yourself if you have tools like I don't know, Charmogul or uh, you know, game sites, uh, tools of customer success, you know, or or other tools. And your uh support data in your app sending your app sending in your uh app desk, uh you can put those like side by side or compute those together in an external tool can be as easy as like Google spreadsheet and and figure out what the relationship is, for example, and it gives you very interesting data that you uh can present to your uh you know to your leaders and say, hey, I can you can clearly see there's an impact in a correspondence between these two.
Charlotte Ward: 14:30
Yeah, I like that actually that um if you're using those guiding principles for your categories and then really using tags to identify particular issues or activities or like in the in terms of say like the reducing cost guiding principle, for instance, maybe um impacts on cost or or or impacts on efficiency in the team. Um that um it's very easy to draw those lines, isn't it? Because I think I think one thing that it's pretty common in my experience is when people set up their news end desk or or any help desk, they think, right, what are the things we do? Let's just categorize and tag the things we do. So we'll tag the types of work and we might tag some bit or or we'll categorize the types of work. So they might categorize categorize by feature, or they might categorize by um, you know, particular activity that their team does, like uh, you know, support a customer through a particular, you know, a particular type issue type or something. But but doesn't necess but we but we throw all of that in there, all of those categories and tanks, because we think that and also there's it's often not clear what the distinction is between those two levels as well, between categories and tags. So quite often you get end up with a mishmash of activities in categories and then a mishmash of you know, what perhaps really are bigger, bigger types of data in tags, right?
Simone Secci: 16:04
Yeah, what what you know what works is like what the the old uh uh the most effective system for for filing, you know, as as we can learn from our uh old like office habits. So what's successful filing is is in a tree structure. And this is exactly the same thing. You have guiding principle, you have categories, and you have tags. Everything is like, you know, uh in in this tree structure, right? Um if your ephemeral tags and your in your and your large categories aren't the same thing, it gets very confusing. Like you have large categories that have four tickets a month. That's not really useful, you know. Like you want to understand the big picture and then you want to understand the individual events. So I'll mention uh very simple uh thing that you can do. Um very interesting piece of data is um understanding your CSAT by large issues. So what um in what issue are what is the customer sentiment for each category that you have? So you have large categories, you let's say you have different features or different on different products, um which one is creating the most negative sentiment to understand uh where to act. And for example, if you're tragging from a project management perspective, bugs that you're filing in Jira, um, you could see how many digits per bug, how many digits there um sorry, how many bugs per category that is used in your project management system Jira, for example, um for engineering. So those categories are most likely different from the ones you use in support, right? So understanding that data and then that gives you you know a new picture um that like is external from from the data that you have, but you can compare the two and then you see a correspondence within we file this many bugs, people are very upset because this is broken, you know, and you right there you have the correspondence, like of the impact. There's an um, you know, you're not if you want to push your ingenity team to fix or your product team to push the engineering team to fix something, you can back it up with this customer sentiment.
Charlotte Ward: 18:27
You have to be able to quantify it.
Simone Secci: 18:30
Yeah.
Charlotte Ward: 18:32
Yeah, absolutely. So you mentioned at the start of this this data journey. Let's assume we're in Nirvana and we have our categories and our tags sorted. We've got those nailed. Never need to touch them again. We're building data from that. We're built, you know, we're figuring out what um what data points we can extract from that. And I guess the next question I want to ask you is oh, you've touched on some of them there about the relationship between issues in certain buckets and how they relate to bugs, for instance. I would like to I would like to ask you to expand on like some other interesting data points that you might have particular experience with or a love for. Um, but but then let's let's go on the rest of that journey that we talked about at the start of of this conversation, which is like then how you have conversations about that data.
Simone Secci: 19:24
Yeah, so one something that is particularly interest uh interesting for me is because we particularly put a lot of attention on our knowledge base. We have a knowledge base manager that you know uh is the uh as of the digital role, writes the FAUs, uh writes our internal uh knowledge uh base for for the team and for the external teams in in the in the company. Um one thing that I was interested in in uh understanding uh the um def what they call the deflection statistic. So you have in most um you know atlas that I use, you have some basic like up center data, visualization, sometimes you have votes on articles, but it's really hard that we have a clear picture of customer sentiment from those uh you know those uh survey system that you put in place because it's hard to understand like the path of of those users. Like you, for example, uh if you have complex like uh um business models like freemium, for example, you have a mix of like free users and pain users, different uh tiers, like it and it gets all mixed up, it's hard to sort that way. Um so one thing that I did was bring in all this data together on a dashboard, um, on a spreadsheet, and having okay, this is my these are my tickets, the number of tickets that I have, uh, where users ask product information. Then what I did is that with the help of a little bit of JavaScript, I was able to calculate the path to the contact form. So how many times uh as single events users will go to the contact form, find us an automatic suggestion for an article, click on that and not submit a ticket. And I classify those as deflection events, so number of deflection events. Then when we get when it came to artificial intelligence, we have very basic answer boat, nothing fancy. I use more elaborated like uh AI systems in the past. It can work for some people, didn't work in my case, but uh it doesn't matter. You have your deflection through uh your AI, quantify there, and then you have, for example, data like um how many uh article suggestions your agents give uh in tickets. That's a very interesting piece of data, and then you can calculate what's the percentage of those suggestions on the overall volume, and that gives you the percentage of um uh ability to expand the flection on product information tickets specifically. And you have a very complete picture at that point of self-service, one that is much larger than what we started with with visualization and article votes, and you know how many times uh an article was was visualized and things like that, you know.
Charlotte Ward: 22:37
Yeah, yeah. That's I I actually that's really fascinating because I hadn't really thought before about the number of times agents refer in just the text of a response to a document as being a diff potentially a deflected ticket, if only I guess if only there was another way to surface that document earlier in that customer journey, right? But but that's what you're talking about. It's like how you start to draw, extract some of those insights and make use of them like that, right? Um so let's talk about the final part of this journey, then, which is with all of this data, what conversations do you have?
Simone Secci: 23:16
Right. So then it comes to the fact um it comes to the part where you have your data together, you have your performance data sorted, your internal data is okay. Um, but you want to bring out messages, you want the data to be accessible. So then there are some technical issues there. You talk with your data demons, like how do we export and in what format do we export it? What it communicates with. You have an internal data layer, so understanding you want to preserve all this work that you did, all this customization is filtering, and then at the same time, you want this data to be accessible. So um there's a number of things like you want, for example, ticket IDs and user IDs to be um accessible to your customer success team so they can match it with their own tools. So exporting their raw data, um, that is a part and understanding how to do it with your with your with your data science team. Um, there are a few approaches that you're gonna have. You can, you know, if you have the possibility of an engineer to write scripts for that and do it in uh you know um with like more structured formats, CSV or uh or just general like XML export or JSON files, like that, you know, depending on how much they can work with it. Um and then there is some um some like more product-related data that can be useful. So you have all the the customer feedback and you have all the you can break down that feedback by features, by different products, and and depending on the on the company, and centralize that data with you know all the other departments. So then it becomes very powerful because if your findings are confirmed by other departments, then your voice is much louder.
Charlotte Ward: 25:11
It's amplified. And actually, what you're talking about then is not really it's much more sophisticated, isn't it, than just putting your graphs on a slide deck once a month for a for a town hall or whatever. It's it's about keeping that data accessible but live effectively or semi-live, right?
Simone Secci: 25:32
Yeah, exactly. So understand you have your source uh and you know the certain features where it's a lot. Very common all-support team. Uh or there's a certain negative sentiment about a change. Um, you bring that in, for example, through I don't know, um a Xavier connection into uh an endpoint. Um that is you want a tool that is shared by most most teams. So whatever that tool might be, I don't know, confluence, notion. Um, you know, notion is very difficult to customize, but you know, Spacey or Airtable, whatever that is, where you have your product team, your marketing team, your sales team somewhere. Wait, you know, it has to be a common tool to to have more visibility. And then you you sort of like narrow it down by uh let's say what you think are the priorities, the 10 most important things, the 20 most important things, to because a lot of data is very difficult to digest. You know, let's say you have a large volume of tickets, if you bring, I don't know, 3,000 conversations or you try to break them down, it's that unstructured data we talked about in the beginning. Very difficult to figure out what's going on there. That's what once again, categorization is very important there. Um but once you let's say we got you got that down, then if you can match the customer sentiment and the feature request with what it says by other teams, or you can bring a different point of view. Either way, it's a different type of conversation than being an isolated voice.
Charlotte Ward: 27:19
Yeah, yeah, absolutely. So so the this kind of dashboard building relies on you having the right tooling, um, even if it's fairly fairly rudimentary. Um and I I don't um you know, I mean it can sort of be a bunch of Google Sheets and a bit of automation, can't it? Absolutely. Uh if you if you've got the budget, you can go for a more sophisticated tool, dare I say, something like Snowplow, which is my where I happen to uh have state my claim for as a support lead at the moment. Um so you can get pretty sophisticated about this and you can draw data from almost as many data sources as there are available that you can hook hook into with any of those tools that that that uh you know you have access to, you have budget for, you have capability to use, right? Um and and then once you have that data, it becomes a really and you have that tooling, it becomes a really collaborative exercise, I suppose. This this is not a dashboard that you as a support lead are just going to build.
Simone Secci: 28:26
Yeah, exactly. It becomes like a collaborative effort, and then that's where you really give a voice to your team and to your customers ultimately, because in that case we're talking about feature requests. So something that might be overlooked, like you're making sure that it's uh that that voice is uh is heard that that that that feature is that feature request is seen.
Charlotte Ward: 28:47
Yeah, yeah. How much once you have that kind of visibility um to everyone in the organization, how much conversation do you still need to have around that data? Or or can people do you rely on people pretty much to self-discover the the things that you have have put the effort into surfacing there? So so do you rely on a product team to go to the same dashboard that you've carefully crafted and make the same make the decisions you hope they would make based on the data that you have worked so hard to present and and collaborate on?
Simone Secci: 29:21
I think it's important to clarify the goals together. So before you set up like uh any sort of you know, um mechanism we talked about before, with like a sorts and endpoint and an automation in the middle, like uh ask um what their goal is, what their strategy is, um, what the um what the categories are, for example, and see how you can match yours. Very important because like your core categories, you know, the more they match, like uh in the language the other teams speak, the better your your message can be understood. Um so I think this preliminary meetings uh before you know investing a lot of time and technical effort in into building with this this uh dashboards of data being just tailored or being um something more visually compelling, like uh are necessary. And then, you know, um looking for the collaboration of your team, of course, because uh, you know, you're going to rely on them on understanding their business priorities in order to tag correctly, and so that tagging for the team is not just an afterthought where it's like, you know, I'm trying to to get uh to do my my job as as fast and efficiently as I can and like tag a sort of like a hurdle that is in the in the middle of this.
Charlotte Ward: 30:43
Yeah, absolutely. You might as well simplify it for yourself as much as you can at the start by by aligning as much as you can. Otherwise, you're gonna have battles of alignment further down that actually involve battling the data rather than just the concepts.
Simone Secci: 30:58
Yeah. So yeah, the alignment is is fundamental for you. Do not like never expect anyone, never assume anything or expect anyone to know what you know or or or what is apparent to you.
Charlotte Ward: 31:12
Yeah, yeah, absolutely. Um I think this has been a wonderful chat. I I think um we've talked about data on and off in various conversations, recorded and not, um, over the last two, three years, maybe. Um but um one thing that I would like if you if I'm gonna put you on the spot now, just to close out this conversation, is do you have a favorite story around data that you can share? Uh maybe a big data success as a support theme. I appreciate I appreciate I have put you on the spot there.
Simone Secci: 31:49
Yes. Well, because there are there are a few, um, but I'm I'm trying to think of like um something significant. Yeah, well, I I will put something simple uh and uh uh and let's say uh that underlines collaboration and and uh empathy among uh among teams. So um one of um uh my teammates in the in in the tier two uh team that um uh you know that I help with uh like structure their data among other things, um make their strategy, uh came to me with like a request from a product manager to help uh help this person with uh an OKR that they have in order to understand a certain percentage uh in order to guarantee a certain percentage of bugs submitted by our team to be sold. So how do we help this person measure that? Right. And so we're talking about two different tools, uh, and so they're um starting to think, okay, how do I put this tool and this tool, how do I connect them? So you start thinking maybe I don't get uh like uh permissions, and maybe I need to uh get somebody else to help me out with this, how do I do it? I have this piece that piece of data there, but not this, and I have this piece of data there, but not that. Uh so thinking a lot, how do I put them in and I do put them in touch? And then the most effective thing in the end is the simplest thing was like using charts on the Google spreadsheet. This is something I mentioned actually at the beginning of this conversation that um you know, you I had the names of the projects that this person was working at, I had the bugs, and for each bug I had tickets that were um, you know, that were associated with each bug. So we could see the number of bugs submitted by uh project. We we see um because of the way that we set up the data with the team, um when a bug is resolved, we mark the solved as part of like the data, the tabular data that we have on this on the spreadsheet, right? So we get all these columns, we feed this into a chart, and we split this by month. When we have to see the the quarter, well the you know, the the under the let's say the the actual like OKR to see what is the if the key results was successful, we just grab three months of data, we align them on a column, we feed into a chart, and we have that data. It was as simple as that. And we can see what what the percentage of like uh you know solved um bug by uh um by project management category uh was.
Charlotte Ward: 34:47
Yeah, I I like that. I I think that um it's it doesn't always have to be uh automations and and uh you know data data teams necessarily, does it? Because frankly, you know, you're lucky if you've got those tools available, and if you have you should really utilize them. But but sometimes all you've got is a Google Sheet and two tools that don't talk to each other. And if you're willing to put the time in and the effort, you can you can do some quite some quite amazing things just in a single chart, even right.
Simone Secci: 35:20
You have that that uh you know uh the golden circle of like good process and the good data, you put them together, you have a simple solution.
Charlotte Ward: 35:33
Absolutely. Um I think that's a wonderful parting sentiment. I I I don't think you can top that as a closing remark, Simone. So I'm I'm just gonna take this opportunity to say thank you for joining me today. Um, it's been wonderful to hear your data your data insights. Um, and uh thanks again. I look forward to you popping up on the podcast again in the future, which I'm very sure you will. But now thank you.
Simone Secci: 35:59
Always a pleasure.
Charlotte Ward: 36:04
That's it for today. Go to customersupportleaders.com forward slash one zero four for the show notes, and I'll see you next time.