Mario Guisado If I have CSAT as my metric for the organization, that's not necessarily actionable for my agents. You have to look at what are the things that drive customer satisfaction, and what behaviors do the agents on the team have to model in order to bring that.
Jen Weaver Hi there support leaders, and welcome to episode 12 of Live Chat with Jen Weaver. I'm Jen Weaver, and as a customer leader I know that your support data has got to work for you.
I'm really excited about this episode because it comes from a listener question. Being data-driven takes time, and with everything that's going on with managing a team it can be really hard to know where to start, or how to get that data dashboard out of the graveyard of unfinished projects.
In this episode, Mario Guisado, director of client support at Global Relay, shares a simple, repeatable framework for turning support data into strategic influence without needing a background in analytics. Mario is a seasoned support leader who has scaled global teams and built high-impact reporting strategies at companies like xMatters and Everbridge. He's the person executive teams call when they need support to tell a clearer, stronger story, and he stepped up to answer this question.
He'll walk us through how to pick one or two keystone metrics that actually make a difference, what to test before you build a dashboard, and the biggest traps that waste your time and undermine your story. If you've ever thought "I know data matters, but I don't have time to figure this out," this episode will save you hours and help you make your case for support.
As always, this episode is sponsored by Supportman, which links Intercom to Slack and sends over QA data so you don't have to go digging. Let's get started.
So Mario, why don't you just start by telling me how you landed in data?
Mario I think I landed in data because I needed to tell stories. As a leader in the support world, sometimes we have to express what we mean to other parts of our organization in a language that they speak.
So as part of my role leading in support, I think it's really important to have a good data background, and being able to express your ideas in a format that others will understand. That could be folks in engineering, or folks in product, or folks in finance, and you're trying to drive some kind of initiative or change.
That's how I got into it. And I'll share that it wasn't always my focus. I was like, oh no, reports, I have to do a report. But then I realized what the power of a report and a good use of data means to getting goals moved forward.
Jen The process that you are going to talk with us about today is actually requested by an audience member, and it's all about using data to tell a story. Would you just introduce that concept to me?
Mario As we talked about a little bit earlier, it's important to find ways of communicating. In an organization, usually support isn't an island unto itself — there's all sorts of pressures, and it's very important to me to find ways to tell your story.
The concept I use is, I like looking for keystones. This is where your metrics come in. I say, okay, what is my keystone? What are the two, maybe three things that describe my team and describe success? They're very high level.
And the idea is I'm going to build my metrics around those stories. So if I want to convey that my organization is really focused on efficiency, then I'm going to look for a keystone that's around efficiency, and then I'm going to build my dashboard to support that story. If maybe you're an organization that really likes satisfaction, or ease, then I'm going to build the metrics that support those things.
So that when I'm talking to my peers in the organization, I can say, here's our keystone and here's how we're doing against it — rather than what we often fall into, which is, we have tons of metrics available to us in support and we just show all of them randomly. Or we show a few of them and don't have any connection to what we're actually trying to say.
So first thing is find the story you want to tell. What's your keystone? What's that flag you're going to put on the hill?
Jen Okay. So your step one is to take into consideration which teams I need to communicate with, what kind of story they're going to resonate with, what the company's metrics are — and then plug into those, but also tune them out a little.
Mario Yeah, find the ones that tell the story in a good way. And you have to define good for yourself, but in a way that you think will make sense.
I see there are two types of metrics. The ones you're going to show out to the organization — those are the ones that you're going to be sharing with the product team, with the marketing team, with the senior leadership team. And then you have the ones that you're using to facilitate the growth of your team internally. They may be completely different.
The ones that you're using internally might be more performance-based. You might want to be able to see how your agents are approaching issues and does that make a difference. So you want to be a little bit more tactical in how you're measuring your internal team, versus how you're conveying the more strategic message out to your organization.
There's a lot of interplay, and I wish there was a book to say "here is how you do it." But I think you just have to gain some experience and figure out what stories need to be told.
Jen And so if I have CSAT as my metric for the organization, that's not necessarily actionable for my agents. They can't say, well, today I'm just going to have good CSAT.
Mario Exactly. You have to look at what are the things that drive customer satisfaction, and what behaviors do the agents on the team have to model in order to bring that.
Jen Can you give us some examples?
Mario One of the ones that I like, and I think you can coach against it, is looking at tone.
If you've had a support interaction, one of the things that I always notice is if I ask a question and it doesn't look like the person on the other side read my question, and they answer with something that is in their script or playbook or area of expertise, or something they picked up on —
Jen So frustrating.
Mario It's very frustrating. We may be great, we may solve that issue in three minutes and get a gold star for solving it, but I still have a somewhat dissatisfied customer.
So looking at how people are doing that first interaction. Did you match their language? Did you really understand what they were asking? And if you didn't understand, did you clarify, or did you just go with your own idea? And then having coaching conversations around those to help build that interaction, especially the first one.
This is really important in B2C, when you're talking to people that you don't necessarily talk to regularly. And in B2B it has a good tie-in, because that's where you get to learn who your customer is — in B2B you're talking to the same people over and over again most of the time, especially in the software world. So are you building that relationship? Do you know that this particular person who opens these cases all the time likes to interact in this particular way?
What we're trying to do is measure some of those intangibles. You could put some metrics around tone if you have a tool that helps you do that.
Some stuff like, how many back-and-forths are we doing? Are we doing a good efficient pull of information? Are we asking the right questions so that we don't go back and forth for a week? Are we doing our very best to get the information we need so we can go and work on the issue, or that we understand what the customer needs so that we can go and resolve it? Things like that I look at internally.
Jen What are some nuts and bolts ways that you would measure tone, or "are we answering the right question," in your help desk? Where would you keep those numbers?
Mario Tone, I think it's really about the one-on-one and the connection with your leaders, whether it's a supervisor or a team lead.
What I really encourage folks to do is find the time to do a session — it could be once a month — where you're going through each other's cases, and you're doing it from a coaching standpoint. You're saying, okay, let's look at these, let's look at what you're doing. And not in a "we're going to catch you at something bad," not "we're going to look for ways to reprimand you," but in a way where we're looking for ways to make sure that you're capturing tone, to make your job as a support agent easier.
So to me, unless you're going to throw some software at it that understands tone — some of this new AI stuff, which is cool — the people component is really important there. And that's where it's good to have good team leads and supervisors and managers who understand that and want to help the agents grow and develop. Or maybe you have a senior agent who's really good at it and can help others and mentor.
Another one, especially if you're looking at CSAT, is the answer time delta. In chat, if you have a chat channel, waiting a minute or two for that next response is an eternity for a customer.
Jen Sitting there tapping your fingers.
Mario No fun. So looking at making sure that one, we're not overloading the agent so that they can get back to customers — but we're making sure that they're building the breaks right into what they're doing so that they can get back to the customer. Sometimes it's just a touchpoint: still here, working on it, be right with you. I think that message is sometimes better than silence. Often better than silence.
So maybe a metric that you're looking at is that interval time between chats. You can also look at the average length of an interaction — by that I mean how many times are we going back and forth. On average, how often is my organization doing 10 to 12 to 15 to 30 back-and-forths with the customer? And is that because it's a difficult issue that we have to go back and forth for? Or is it because we're being a little bit inefficient, or we're not understanding, or we're not asking the right clarifying questions, or the customer isn't understanding what we want, and we're not changing the tone of our conversation, or we're not changing the channel?
Often in my organizations we have the option to say, we're working through a ticket or a chat, and we're not connecting — let me call you. Changing that channel. So we're looking for those opportunities in our metrics.
Internally I think it's really important to look at some of those things to help us build that experience. Now I'm mostly focused on CSAT and ease. But it's really important — when you're saying CSAT's sitting at 98%, here are the pillars that support that CSAT, and here's how we're doing, and here's how we're improving.
The big part is making sure the pillars that you choose are ones that you can improve on, or ones that you can actually action.
Jen Sure, you might be able to choose a pillar that's important and interesting to the rest of the company, but can you do anything with it? Can you inch it forward? If not, then it's probably not a good pillar.
What's your best guidance for determining — if I'm say a new support leader, I don't necessarily know what I will be able to influence. Do you have tips on that?
Mario I say test it. Test it and measure it for a little bit and try some things and see if you're actually making a change. See if the tweaks you do are reflected in the metrics you're measuring.
What I suggest, especially if you're just starting to build metrics into the stories you're telling internally: start very light. Don't start aggressively. Tell one or two stories, and then evolve it as you go.
Let's talk about CSAT again. If you say what is going to drive CSAT is answer time — cool, let's go look at answer time and let's see if we're actually driving CSAT by changing answer time. Are we making a positive change?
And you can even do that kind of almost organically. You don't necessarily even have to do anything — you can just watch it for a little while and see what your answer time's doing, and then track it against your CSAT. Is there a change there, and is the change congruent to what answer time's doing?
Answer time is one that you can kind of manipulate, but there might be others that you can't.
Jen So you're basically asking, is my reporting actually showing the picture I want it to show — and then just tossing things out if they're not working.
Would you communicate to your leadership that this is a probationary period for my data, essentially?
Mario Yes. I did this with a knowledge center. We were trying to move from a lot of one-to-one personal conversations into utilizing knowledge. And the hardest part of a knowledge center is saying, is it having an impact? You don't know. You can ask "was this a helpful article or not," but —
So what we started doing was, I said okay, the first thing we're going to measure is just visits to the site. At the end of the day I don't care why — are they coming to the site, is the message there? So for the first six months that's what we reported on. Our visits are going up. And I did this through Google Analytics.
Then we said, okay, we're bumping up visits, people are coming to the site, we don't know why they're coming, they're just coming. Then we started looking at sessions — are people coming back over and over again? Visits are one thing, they came to the site. I love sessions. Are they coming back?
And I articulated this to the senior leadership team saying, this is what we're going to do over the next year. After we've sat in a certain place on visits, now we're going to look at sessions, which means they're coming back. Then we're going to look at individual articles and what are they coming back for.
So the story I told is, we're going to get people to use the site, we're going to get them to come back, and now we're going to know what they're coming for.
And the irony of this is that I never set that against tickets.
Jen Really?
Mario It's not about ticket deflection necessarily. Often it isn't. Often the customer is coming more educated. Maybe they're using it for other purposes — and that's when you start looking at the articles and you're saying, oh well, a lot of people are trying to learn how to do things. So maybe we need to look at education more, and the tickets stay the same.
But what I found, especially with knowledge, when you treat it that way, is that at some point you don't necessarily need to go back to the well as much for staff, because the knowledge becomes ingrained in what customers do. They have confidence. So as your product grows you may not need to grow your support team as much.
I never promise reduction in staff based on knowledge. What I do say is, if we do this well, we may not need to grow as fast — and that's the financial hook for doing it. Sometimes that falls on deaf ears, but I certainly give it a shot, because I think that's in service of your team. That's the best way of approaching it.
Because I don't really want to build an environment where people think, I'm going to get replaced by this article I just wrote. No — I want you to get harder questions, because the article took care of the easy ones. And by then I know that you will be taking longer to answer these harder questions, because you're not answering the same "how do I change my password" over and over again.
Jen To me as a support specialist, that's a win.
Just to recap the steps of your process that we've just talked about: defining keystone metrics, and then choosing which metrics you're going to support that story with — metrics that are both more strategic for the outer team, and more tactical for how you're actually going to help your agents iterate. So that's step two, your metrics. And then step three, evaluating: does this really do what you want it to do?
So where do we go from there?
Mario From there — and I think most people find this backwards — but then build your dashboard.
Jen Okay. So until then you've just been looking at data.
Mario You've just been looking at data. And I'm not saying this is a 12-month project, I'm saying that you're doing this in a few weeks.
Jen You're not necessarily going to say — because nobody's going to have enough patience to say "I'm looking at the data, I'll give you a dashboard in a year."
Mario Right, and this is where building in that flexibility for yourself matters.
So then build your dashboard. What I did at one company was, because we had a lot of metrics, I just started telling the story of a ticket. So tickets coming in — what we were looking at was, what was that intake like, how quickly do we respond to it? How many P1s did we have, how many P2s? And then I looked at how many interactions we were having back and forth while the ticket was alive. And then we looked at the closure of it, and how long it was taking for us to close it, from the time it was opened.
So at each of those key points — this is the life cycle of a ticket, just to get an understanding of that, and then building improvements against that life cycle.
Jen Are you aggregating into an average ticket when you do that, or are you talking about a specific single ticket?
Mario It's an aggregate of tickets. You're looking at your overall volume there.
Let's take a ticket category that I've defined for my standard deviation — the standard deviation in the middle is the P3 ticket. What is my intake for that? By intake I mean how long is it between the time that the customer opened the ticket to the time that we responded and have a real person working on it and we're gathering data. Is that 5 minutes? Is that 3 hours? Is that 6 days? And are those reasonable? Are those where we want to be? And how does that compare to the P2s and the P4s?
One of the things you might find out is that you're spending a lot of time on P1s and the P3s are getting left. Yeah, we have to deal with those P1s — okay, let's dig into that.
And when you're sharing that organizationally, then you're saying, okay, we've got a little bit of a culture of P1. Is there a customer that — because we've been slow in support — thinks I have to make everything a P1? Or is it a product that maybe is hard to use, maybe there's a lot of anxiety around it, maybe there are some trust issues? There's something going on that customers are doubling down on the P1.
Jen In this example, the customer is able to mark their ticket as a priority one, and so we're trusting them to do that. But maybe they feel like that's the only way that they can get quick help. Or there really are P1s, and there's a challenge that we have to highlight to the product team.
Mario And say, hey, we've got a lot of issues coming in because of this particular feature — because we're measuring all that, we have that ability. What's going on there? Let's collaborate, let's build a bug tracker, let's do something, because we've identified this through our metrics.
That's the beauty of intake, because all of that stuff I can tie back to CSAT.
Jen And that prevalence of priority one tickets, like you said, is data that the product team needs. Maybe that indicates there are changes in the product that need to happen, because if a lot of people are genuinely having emergencies then you can work with the product team to break that down into — okay, are there themes here on what they're reaching out about?
Have you found it useful to get data from the product team about how they divide up your product into features, and then mapping your data to that?
Mario I think it's really important for support teams to have a tight connection with the product team, and understand what the direction of the product is, where we're going in the future. Understanding that roadmap.
I know often there's a bit of a blocker between product and support, because sometimes the roles are very different, they don't see eye to eye. But I think trying to find ways to build commonalities is really important, because when you have a support team and a product team that work together, you've got some magic there. Those are the products I like to use best, where it's obvious that they're really in sync.
And one thing I tell my support people — this is a little bit of an aside — is we're not going to get everything they want. There is a roadmap, and you may see something that comes up and the customer wants something to happen, but it's just not in our roadmap. We have to be able to accept that, while telling a good story to the product team and speaking their language. Sometimes their language is different than the one we speak.
So understanding that, and through those dashboards trying to convey that — because you want to use the dashboards to manage change, to see a trend over time. Are we going in the right direction?
Jen That's a good moment to talk about dashboards and your experience. Can you save us some time and headaches? What are your takeaways after having done this for a while?
Mario My takeaways from dashboards: your first place to look is what is your tool providing you from a metric standpoint. If you're just starting to bring in a metrics program, try to find things that are already being reported so that you don't have to build custom reports.
Jen What are some examples of tools that you've used?
Mario I've used primarily Intercom, I've used Zendesk of course, and Salesforce — the help desk metrics that come in there.
Zendesk reporting sometimes is challenging for people, especially if you're not familiar with it. So before you jump into that world, or if you're in Salesforce, before you jump into Service Cloud and "how do I create reports" — let's see what's there. Let's see if I can use those, if I'm starting a good dashboard program. And take those, and maybe you're building it in the tool, or maybe you're pulling those things out into a PDF or a spreadsheet. You choose your path.
That's relatively easy, because you're going to be doing this monthly or weekly — hopefully you're not doing it hourly.
I always like to start with, what does my tool give me without customization? Navigate to that dashboard section and just see what that tool suggests that I work on. Start there, and that's a good place for your initial dashboard.
So you've defined what you want to look at, you've defined your keystones, you've tested it a little bit, you understand what your reporting is actually giving you. And then you say, okay, I have these in my dashboard. Most times any piece of good software will have those basic things already built in for you — use those to start.
And then you can go back between the two steps. You're going through a loop where you're saying, this is what my dashboard's saying, I'm testing it, I'm verifying that it's telling the story I want to tell, and then I'm going back and evolving throughout that.
Also, as you're going through that dashboard, leave some room for continuity. Because if I'm constantly changing my dashboard, my audience isn't tying it together. So you want to build set points — if you want to change your dashboard, if you want to change the data you're looking at, maybe you're doing that quarterly. Or I used to use year end as the time to change the focus, especially if it was a bigger one. You're doing that next year, this is what we're doing, you announce it, you share it, you talk to people about it — hopefully you've been talking to them already — and that's the time when you make change.
It is a little bit frustrating for folks who are not in support if you're constantly changing the metrics on them because you found something cool that's new. Maybe you sell those internally, maybe just as part of your test, and then bring them in at a specific time, so that you're not throwing your audience. Because if a CEO is looking at your dashboard and they can't connect dots, you're going to get a lot of questions.
Jen So you wouldn't share a screenshot of your dashboard to your executive team. You would create something that connects the dots a little.
Mario I try and do that, I try and tell that story. I think it's fine to share — there are organizations that have a dashboard for the CEO and a dashboard for engineering leaders. I think those are really good when you've had a session with them and they understand what you're measuring.
If you just throw a dashboard out there — you're not trying to hide things, but you may get questions that don't land, because they're not asking the right question, because they don't understand where the data is coming from. This is where you are the storyteller.
Jen And that goes back to what you said earlier about minimizing what you focus on. So that you're not trying to gather all the metrics that ever exist — you're deciding very strategically, this is my keystone, these are the pillars that support my keystone.
And you don't want to then just have somebody come in and say, well, what about that over there? I noticed this number was red in the report, what is that about? And if it's not in your keystones, you have to kind of play it off, and then it doesn't seem genuine any more. It weakens your position.
Mario Yeah, that makes sense.
Jen That draws us into your next step, which is avoiding pitfalls. Any other things that you can do to set yourself up for success?
Mario I think that's the big one, you tied it in.
One of the things that I try and do is get support into QBRs. I try and get the support team — whether it's me or another leader in the organization that's in support — to go to this QBR and get five minutes, ten minutes, to make sure that support reports are living in the QBR slides.
Jen That's wonderful, because you're getting to tell the story, you're getting to share how it connects to the other teams.
Mario There's danger there too, because if you're not sure what you're showing and you start getting a lot of questions and you're not prepared with the answers, then all of a sudden that's backfired.
So that's one of the pitfalls. It's nice to be there in the conversation, but you have to be really sure about what you're talking about. Make sure you understand what the data is — mostly understanding where it's coming from. Whatever you choose, make sure you understand how it's being manipulated, what levers you're pulling to change it, and where that data is coming from, what it's actually measuring. If you understand those things, you can talk to them.
Jen If you understand what's moving, you can talk to leadership. But until then, maybe you continue to refine until you're ready.
Mario Exactly. And the other area — I've done both of these, where your support team has their own dashboards and they can look at their metrics. Some folks in support love that.
I don't like when the comparison starts happening between agents and they're doing it themselves. I think that could turn a little bit toxic if you don't have the right kind of environment in your support team.
I like having leaders having access to those dashboards, and you can talk to them. Again, they're not used as penalty points. They're used as areas for improvement, or for highlighting somebody who's doing something amazing — and are they willing to mentor? This is where you find your stars. You could find your stars through those metrics.
And that's why I'm saying separate your strategic stuff that you're telling outside and your internal stuff. A pitfall is saying, hey, we're going to set up a dashboard that has everybody's names on it and everybody's performance associated with it, and we're going to share that with the whole team. Maybe you have an environment where that's great and people are really open to it, but I caution against doing that to a team that's maybe not ready for it.
Jen Your final step, step six, re-evaluating.
Mario That comes down to — I think the story around the knowledge center is a good one. When I wrote this, that's what I was thinking of.
We were going through a set of steps, making sure we were measuring the thing, going through that journey, telling that story of usage. And then at some point we said, okay, we got where we wanted to go — or we got as far as we think we can go. Maybe it's not where we wanted to go, but it's stagnant for six months now, no growth of usage. So maybe we're at a good place, or maybe something's missing.
That's when you evaluate and say, okay, what's my next measure? For the knowledge center we said, okay cool, we're good, now we're going to do this thing called a knowledge ratio, where we're looking at how many visits or views versus tickets. And we're saying, okay, where is that sitting, and is that number now changing?
So you're re-evaluating how you're expressing the metric. It's not just views now — now it's views against support tickets, and you want to have a 20-to-1 ratio. Twenty views in your support site for every ticket opened. If you have more views for every ticket opened, maybe that's a signal of success.
So initially I'm just looking at the raw numbers, and now I'm re-evaluating and using another type of metric to hone in on what's more representative of the experience that we're trying to give, or more representative of our goals.
Jen And putting that metric next to another metric to get a ratio is a great way to do that, because it gives it context. For example, if you were to say tickets per paying customer — that raw ticket number doesn't tell the same story.
Mario Yes. It's like per capita data on countries is different than just single numbers.
Exactly. Because software — I'm talking to the software world, but just about everything — isn't stagnant. It doesn't stay the same, it's always evolving. And if you've been in any organization for a long time, you realize that where you were five years ago isn't where you are now. So the metrics you were using five years ago might not be representative of you. That's where you're re-evaluating.
I always suggest that when you're doing that, you have a plan, and state your intent well ahead of time. It's hard to explain a re-evaluation and a change if you just did it. Going to these QBRs and saying, by the way, next fiscal we are going to start measuring this, and this metric is going to go away, and this is why. And saying the same thing to your team, and making sure they understand why all of a sudden we're changing what we're measuring.
Jen And so behind the scenes, you may have been tracking this new measurement for two or three months as if it were your new metric. So you've stress tested it, and you're pretty sure two or three months from now you're not going to have to roll that back.
Mario Exactly. Or if you have to stick with it, you think, I can live with this one.
It's the other thing — it's okay to make mistakes. I think we often want to be perfect and show growth in every metric. Well, maybe that one didn't pan out, and then you just plan change. Maybe you thought you had a way of moving it and you don't. That's why it's important to look at it first, play with it, understand it, stick to the basics when you're starting out, and then get more complicated.
And then don't overwhelm people with numbers as well. They have to make a little bit of sense. I've had dashboards — and I'm guilty of it — of having a dashboard that has 80 data points. Makes perfect sense to me, because I live with it, but doesn't make sense to somebody else who's looking at it for the first time, or looks at it casually. So making sure you're tailoring how you're showing that information, and then allowing space for questions.
Jen How do you pick which five metrics of the 80 you're going to share?
Mario One of the things I've always done — it's level dependent, but I have access to the CEO — I say, hey, can we just sit down? What's important to you?
Jen Like you said, if you're going to share a dashboard with an exec, then you have a meeting with them first.
Mario Say what's important to you, and they might say this and this. And say, okay, well, I can't measure this, but I can give you this. Does that work? Cool. And okay, we're going to create the dashboard, or we're going to give you a PDF every once in a while that you can look at, and then if you have questions we'll revisit that. And if I need to change that, I'll tell you, and we can talk about it, we can re-evaluate.
Doing that with your leadership team is really important. And doing that with your team is also important — making sure that you're asking questions, because it's not just about what I want to say, it's also about what we want to say, and we want to have involvement in that.
I find often, especially, support agents are disconnected from the metrics. They don't understand them, and they don't understand why we're doing it and why it's important, and why I keep asking about the back and forth. Because a support agent is going to tell me, well, it's because that's how long it took for me to resolve the thing. That's why. What else do you want to know?
Jen Also, you're the linchpin between the executive team, the leadership, and the rest of the company, and those specialists. So it's your role to make that data work both ways. Make those connections.
Mario That's how we look at what's important, and also what really supports what you're trying to do. So you have to kind of merge those. That's where I think there's an art in leadership, where you're understanding what folks need and you're trying to tell those stories through those metrics.
And I think they can have amazing power in bringing the voice of support forward and making sure it has a seat at that table, which I think a lot of support people sometimes yearn for.
Jen Absolutely.
Mario And also, when you get it, you've got to do something with it.
Jen Hopefully this podcast has made people feel more capable of doing that, which I love. I really appreciate you showing up and bringing your expertise. Thank you so much.
Mario Thank you, I really appreciate your time. This is fun.
Jen A big thanks to Mario for stepping up to answer a listener question. And another big thank you to our sponsor, Supportman, which connects Intercom to Slack and uses AI to give agents feedback and surface problems in real time.
If you're ready to put this framework into practice, remember the steps. Step one, pick your keystone metrics. Two, identify supporting data. Three, pressure test your story. Four, build a shareable format. Five, watch for common pitfalls. And six, iterate as you go.
Your data doesn't have to be perfect. It just has to tell the right story.
If you found this helpful, don't miss future episodes — we have a whole series on data coming up. Subscribe to our email newsletter or follow along on LinkedIn, the links are in the show notes. Thanks for being here, and I'll see you next time.