Securing a Seat at the Table: How to Architect a CS Data Foundation That Earns GTM Influence

Hi, everybody. Who's tired after lunch? Did you guys get full? Yeah.

Well, I hope that my talk is going to be exciting enough for you. If not, I will raise the roof. No. Hi, everybody.

My name is Charlotte LaViolette. I lead the customer success team at Open Prize. I've been there about five years. I focus on building operational framework, how our team actually runs, and how it doesn't run most of the time sometimes when I find the gaps.

What this includes is Gainsight, our CRM, working with cross-functional role workflows. Before this, I spent over a decade as a consultant, working with sales marketing teams, RevOps, product teams. What I have gotten out of that is I've worked in a lot of messy environments, and I'm not excluded from that at all. I found out, and most of the time, it's not necessarily a data problem.

It's a design problem. So I want to start out with where we started when I started out at Open Prize. Oops. This is an evolution.

We're a little bit of a small company, but we started out with Excel sheets, managing all of our accounts in Excel sheets and in notes. It worked. It was manual. We didn't really have visibility across the teams.

Sales kept coming to us about everything, and I was like, "Okay, we need something centralized." So we went to Monday.com. It offered us more structure, more visibility, but it wasn't quite enough for us to do cross-functional workflows with integrated platforms. We still didn't have the Salesforce data from our sales team. So we graduated.

Started working out of Gainsight as a centralized managed system. On paper, looks good. We make progress. What actually happened was we upgraded our tools, but not how we used the data.

So with every step, we offered more and more data, but we didn't design how the data should work, how it should be used. So data, data everywhere, no design in sight. This is a trap. It is a trap.

No design. Data is just sitting there. It's documentation. So I'd like to go into a poll and ask a couple of this question here.

How many of you feel like your CS team is capturing more data than the business actually uses? I was being a little facetious on these answers, so... I'll give you a little time. Ooh, that's interesting.

I might have to come back to that question. I'll dig into that. Okay. All right.

Still going up and down, right? 63% of you need more data. Oh, I have a follow-up question for that later on. We can get into that later, though.

All right. I'm going to skip back into here. All right. So, like a lot of teams, we fell into the same trap of not having a lot of design, but we had a whole bunch of data because the teams were putting everything in Gainsight, capturing everything, but it wasn't very consistent either.

So you implement a system like Gainsight, and in Stik is just to capture everything because you're brand new. When we first started out, we had an implementation process and an onboarding process and best practices, but change management is hard to get people into a different mindset. Right? So you end up with a system full of data that doesn't actually do anything, and our team was looking at valuable information because our CAM team was treating our CSMs as databases when they were actually looking in Gainsight or in Salesforce for that matter.

So it felt like admin work, and nothing was happening with them. Again, big theme here. We were designing how data was captured, not how it was going to be used across systems, across people. This was a turning point.

It is imperative, as your business needs to change, your architecture may not be able to sustain that. Right? You have to change how you do your workflows, change how you're utilizing data. Right?

This is why it's not really, to me, a data problem. It is a design problem. Sorry. Okay.

So we identified three gaps in the CS and the GTM architecture because I had four other forms to deal with to amalgamate all of this data. We stepped back and we looked at, well, is it visible? Well, data existed, but the decisions were not where the decisions were happening. Right?

Second, structure. When the data was there, it wasn't standard enough to use consistently through automated flows. And the third was activation. When the data was visible and structured, it didn't go anywhere.

It was documentation. Okay. So, cool, Charlotte. You've described the problem.

All right. You identified the gaps. So what do you do about it? Well, RIP data hoarding.

We had to shift, right? This is simple in layman's terms. Moving from thinking about data as something to capture to something that we actively drive decisions across the organization. Right?

So it came down to these three things. Filtering out the noise so that the data was consistent and we had a structure of data that mattered to us for these decisions. And then we had to make it--sorry. We had to make sure that they actually did something with it.

So activating those data triggers. Right? Because, again, all you're doing is putting data into GATE site and not doing anything with it. It is documentation.

It's a vanity metric. Hey, look, execs. We put it in. We met our KPI.

That's not something how I want my ICS team to be measured on. Again, this process here, I just keep repeating. It's on repeat. Every initiative that I do, it's on repeat.

It's when your business changes, I go through the same process all over again. All right, so same process broken down into five steps. Right? This is a system that everything mapped back to for me.

If you take one thing from my session, take this. Pick a revenue use case because that's what drives GTE Emotions. Right? The GTM.

Define your set of signals. Standardize them into fields. Assign ownership. And then trigger the action.

Right? And this is really key for us. Getting a seat at the table isn't about visibility. Although visibility does help, it's about becoming a part of how the business makes decisions and being right there with them.

All right. So... Drowning out the noise. Separating the key signals out.

I knew when I started to tackle this problem that I'm one person. I can't look at everything. But what I can do is look at our biggest issues within the company right now. I can pick two life cycle stages, which I did, which was implementation and the renewal.

And start assessing risk patterns, NPS surveys, conversations that we had with churn customers, and the actual customers that were going into expansion. And I had to sit down with our commercial account managers and say, hey, the data is in the gain site. What signals are you looking for? Because every time you have a problem or a disconnect or you're trying to do a renewal, you are creating meetings on all my CS teams, you know, schedules, and you're eating up all their time.

What is not there? What behaves... You know, where's the disconnect? Right?

So I knew I had to create business processes for the CAMs to follow and do change management, which is, I think, is the most difficult thing for most organizations to do. I also had to ask myself, is the data missing for them, or is it not, and is it there? Right? Did the CS team capture everything?

And most of the time, they did. They absolutely did. We just needed to make sure that we focused in on the right things. Our lifecycle, when we first got gain site, we mapped out all the lifecycles, entry and exit criteria, and over the last two years, those things have changed drastically.

So remapping this stuff is part of the process. It's just operations, right? There was data that we got PX, and there was data that PX couldn't give us that was in our product that I had to pull out and was in disparate systems. Now, before I move on, I have another poll question for you guys.

Let's see. Pick up the... This is the last one, by the way. I was trying to keep it simple.

Where does most of your customer insight currently live? Oh, there's more in there. I think there's one of the favorite ones at the bottom. And you can pick as many as you want.

Oh, the poll's closed? Uh-oh. Okay. Okay.

Did you guys giggle in about the last one? Okay, good. I like it. Okay.

Yeah. The depends who you ask is always a big one. Because everybody has different opinions. Different opinion, and marketing has a different opinion, my CSMs, and then the directors have a different opinion.

Okay. Thank you for my experiment. I will laugh at these later. All right.

So I was talking about how my product information was in a different system. And some of the other things were spread out across, and I was having a little bit of trouble orchestrating that data. Well, lucky for me, OpenPRIZE does orchestration. So I use my own platform.

The point of this is that you can use whatever platform or tool that you need to do the orchestration. It is the concept that is important here. Because everything sounds great that I just talked about, but if you can't make it work and you can't connect these systems, you're not going to get to where you need to be. Because, again, the data lives in Gainsight.

Sales lives in the CRM. Sometimes sales messes up their own architecture and you can't make heads or tails of it. Marketing lives somewhere else in the product system. Data is in two different systems in my case.

So we use our own platform to create this orchestration layer. But, again, it is just finding something that you can do. You can do it quickly to create the systems. All right.

So let's talk about some examples here. Risk. Everybody deals with risk with their customers. And before all of this, risk lived in notes, slack, and gut feelings.

Intuition, if you could call it that. So when somebody asked, "Is this account at risk?" It really depended on who you asked. Everybody had different feelings about stuff, and we had some data in there, but we hadn't really defined what risk looks at at all levels. So we determined and did an assessment and said, "Here are risk signals." And then I said, "Okay, great.

So these are defined and these ones are currently consistent." So I created a trigger off of this. So now when those signals show up, it creates an action. Same input from CS. CS is still putting the stuff in there, the same notes, things that they're putting in.

But I am now having a completely different outcome because I've now tied that to a system action to be triggered. This is where CS starts influencing forecasting across the board. I know some people with their CS teams do the renewals. Ours doesn't, so that's our touch and our KPI with our sales team.

All right, another use case because I talked about the expansion. Same model, same model just applied to expansion. Instead of relying on the reps to find the opportunities, we defined the signals for expansion, whether that been how many bots somebody has in their system and how many of those bots are active and how much data are they moving through the systems across that. Those were all expansion triggers for us.

So we tied those to signals and we created opportunities based on those so the sales team can identify that and move forward and have conversations with our customers. So this was making CS a pipeline generation, not just post-sale support and complaint loggers. So this worked for us, it's still working for us. We are still applying this system across other lifecycle stages.

It's an iterative process, but this is how we began. One thing, you can create workflows and come up with these triggers and identify the signals, but if you were at war with where the data lives and who owns the data, then it's like when everybody owns a field, nobody does anything with it, nobody's responsible, accountable. You have to have a race each day basically. And that's what I did with our RevOps team, the CS team, and the marketing ops, and even the product team as well.

Because when we sat down and talked about all this, it was eye-opening about how people were using the different fields and how different they were interpreting those. And I said, "Okay, well, how do we want to use them now? Can we talk about the future here? If you need it for something like this for something else or this, we'll create other fields.

But I'd rather not create more on top of more if we can come to a consensus." So I wanted to eliminate the friction that we were having across the teams and make sure that we all had an understanding. It is eliminating the chaos of field ownership. There's... At my company, they call me the data chaos crawler because I took on this thing, and so I think it's a fun nickname, but I don't know if I really wanted that nickname in the first place.

We didn't... This all became clear because we did an analysis. And creating the structure and the alignment helped us get to a better place. We had the right teams, and we built trust because you knew who to talk to when we had something have to change in the business.

All right. So impact and results. This is where we started to show up at the business level. Our CS team supports...

We have a highly technical product. We support them. We guide them through. We build with them.

We actually build for our customers. But we needed to prove why. And through this process, I helped uplift our CS team. For cross-functional trust, feeding sales information and marketing information.

And adding in measurable inputs into our business design. Because risk improves forecast accuracy. Expansion drives pipeline. And marketing now uses the CS tasks and things that we do.

And they add it into their attribution pipeline so you can see the effect that CS interactions has on opportunities. It's not just sales and marketing. CS actually shows up. 30% of the time.

30% is pretty good for me. Just saying. So what happened here is that we didn't make CS more visible. We made CS unavoidable in the revenue decisions.

And unfortunately, these were the only metrics I was allowed to share. My CEO said no. So the 10 hours fluctuates. But as we add in new processes and make our CS team less...

Doing less admin work and automating things, I expect this to increase. I've unified some systems together so we're all working on the same level. And I have decreased field ownership data chaos. So once these systems started operating consistently, we had measurable outputs.

Not just inside CS workflows, but in how teams worked together. How they moved, the signals moved, and how decisions were being made. But I also got a second job at my work. I think this is a good thing.

This changed my relationship with product. Because I proved with the data decisions and the things that we were doing that my system was working and I could provide product with reliable data to make better decisions about the roadmap. And I got invited to the council. And honestly, I think that CS and product should always stay closely connected.

And a lot of companies don't really operate. They operate really far apart, unfortunately. Product builds the experience, but CSD is the practical reality of implementation every day. We see when customers get stuck with adoption.

When the process breaks down operationally. So the challenge is that most of those insights live in scattered notes, right? Anecdotal conversations. And again, I started structuring all of that for product.

And they started valuing our opinion. And I basically showed the friction at scale with our customers. So it's not just us reacting to customer complaints, filings. We are actually influencing the pipeline.

Just this past year, I got 30 new enhancements in. It was unheard of from my time being here. 30. I impacted the pipeline that much because it was taking all of the feedback we got from our customers.

So if you want more work, follow my system. Okay. So I'll leave you with this. You don't earn a seat at the table by asking for it.

You earn it by building a system that drives data decisions for the business. Okay. I left a lot of time for questions. So let me see here.

And I built you guys a nice diagram. Actually, AI built it. AI built it. That's what I use AI for.

Okay. I think I surprised how fast I went through this. Let's see here. Do we want to put the questions up?

How do I do that? All right. Well, thanks so much, Charlotte. Everyone give her a round of applause.

That was great. All right. So open up your pulse apps and start submitting your questions. It's going to be under the Slido section if you haven't navigated there before.

All right. So we'll start with the first one. Does your cross-functional teams all have access to GainSight or do you push insights into other sources? No.

No, they do not. It depends on which department it is. There are certain leadership is in GainSight. I guess how many say how do I answer this?

So there are certain executives that have access in. They have viewer analytics access. I create dashboards for them in that case. But my RevOps leader does have access.

My product leader does not. But I still serve them up and they have a viewer analytics license because it makes it easy for me just to show the dashboard of things. And then I report out. Could I find a better way to do that?

Absolutely. But currently, not everybody has access. Not everybody has access on the GainSight. So I find other ways of pushing that data out.

All right. And then what was the hardest cross-functional conversation that you had to have? Was it sales, marketing, or RevOps to get the CS data treated as go-to-market critical? And then maybe some tips for all of us who are trying to do that.

Ooh, okay. It was sales. Typical. I don't mean to beat up on my sales VP.

RevOps was the easiest because RevOps leader used to work on the CS team. So when he took over the Salesforce system over, he's been working with me great congruently. And we've been ganging up. It's not the right word.

Being a force for good against our sales VP. The hardest conversation was actually was the risk conversation because we had different ideas about what's risk for CS, what's risk for sales, and what's risk on the marketing side entirely. We still continue to have those conversations, but it is a discussion and it is not a fight. It is about coming to a mutual understanding.

I'm not going to say that my first conversation was the best conversation. I think my third conversation was the better conversation because we came to an understanding. Yeah, yeah. How do you decide which CS engagement signals are meaningful enough to push back into the broader business versus which ones just create the noise?

So that would have to be if it's happened multiple times. So if I have data that proves the use case, like where I've seen that same situation over and over and over again, that's when it gets diagnosed and put in as a signal. Again, not all customers are created equally or anything like that, but there are some consistent patterns. I'm looking for patterns basically.

I will do an analysis myself and look at the data and then I look at it as well. Just to check to see if they're seeing the same things as I am. How did you audit your data chaos and how did you get teams to take responsibility for their own fields? Painfully, very painfully.

I had to start out with one object at a time, basically, and I had to break it down. If you try to look at everything at the same time, it's going to be overwhelming. You basically take bite-sized chunks and then you start building your case. I find that that's the best way.

That's how I operate because then I know I'm taking it piece by piece and I'm not trying to eat the whole entire watermelon. Absolutely. All right. And what do you do when you have trouble getting the data that you need?

It depends on the data. If I know that the data exists somewhere, I use OpenPRIZE to pull it in. I'm wondering if somebody could explain which data you're talking about. If you need data for enrichment, there are plenty of enrichment vendors out there and you can get data filled in on contacts, customers, companies, things like that.

But I always find with rich proprietors that you can't validate the enrichment proprietors data. So that's the hardest part, right? How much do you trust that data vendor? There's that piece and then if I have something that I can pull down into an SFTP and get it into my system, I will do that.

I will do the hard work and then I'll automate that. All right. And how did you structure product feedback from CS to translate into scalable data for product to rely on? So our CS team is very high touch.

Unfortunately, we're still trying to get into long-term and get something a little bit less intense. But because we talk to them, our customers are mostly weekly. We have it all in our call notes in the Zoom integration. And so we're pulling that out basically through AI a little bit and then categorizing that.

We're also putting anything that we hear into GitHub and then we further take that down and say which things are high impact and we build a use case in metrics against and then serve that up to product or at least I do. Yeah. And along those lines, CS and product should be close together where if any, in your opinion, should ops fit in. We really struggle with chasing behind both teams.

We don't know how to get them to agree and come to ops after that. I think that I have a little bit of a I'm ops. I'm also CS. So all of that stuff.

Usually I sit there and I say, what is this fight really about? Sorry, it's a question. It's really about. And I say, how can I help or what difference can I make?

Is it a resourcing issue? Is it a misunderstanding? And I really just sit down there and to diagnose problems because I think like it, though my consulting days have helped me a lot in certain situations and dealing with different parties because I always had to manage change within a group because nobody wants to change what they're doing because my way is the best way always all the time. And it is just communication and communications.

You have to communicate with your customers and internally. You just treat your the groups like customers and it might help you a little bit further in that way. All right. And where did you decide to start with wrangling the data quick wins or something that will be useful for everybody to take home?

I did two quick wins and then I didn't long term project because I needed to see results from to understand if I could get this to work fairly quickly and I was under a little bit of pressure from my VP of customer success. So definitely started with quick wins. I actually I did a survey. I did a survey with my team saying, hey, what's the hardest part of your job?

What do you think? What do you want to fix? And I got a gamut of information back from them. And then I disseminated from there and what I could do in a week and what I could do in three months.

All right. And do you have anyone who's resisting these changes and fight for the noisy data and they think that it still has value? How do you handle that? These are funny questions.

Yes. I find that some of my executives are a little stuck. I would say stuck because we've always done it this way. I'm reliant on that and I look at it for X, Y and Z.

I say, okay, if you're lying for X, Y and Z, what are you doing with that? Are you doing anything with that? No, I just want to see it. Okay.

Can we talk about that a little bit more? Like that's the problem that I run into. I get people who are used to doing it one way and they know it's documented here, but they aren't actually doing anything. And this is about this whole entire thing that this project that I do is to make sure that what we're doing is not just documentation.

We're actually driving change and driving action because I'm like, what are we going to do here? It should do something. It should drive change, drive revenue, drive retention for our CS organization. Yes.

And how did you determine the triggers identifying usage metrics for a product? Slowly but painfully with my product team. So most of them were based on how we structured our renewals and how our sales team sold and what we were supposed to be tracking for our customers. So that's where we started and that's even changed now.

So now I'm working with product to product size the metrics in there so that we don't have to manually calculate it by hand. So really determining the triggers is figuring out what matters mostly for our renewals or if our customers asking us the same questions over and over and over again. We do data quality checks right now on the databases for our customers and so they seem to like that. So we're continuing to do that and we're adding in like some new KPIs for that too as well that are product size instead of custom built.

Yeah, makes sense. And how many products does your CS team use to populate and store the data? Are they all integrated? Believe it or not, we only have one product.

One product is very flexible and so it can do multiple use cases for our customers. So we really only store information about that although we are coming out with a free product here in a little bit in July. So for people to try it out and see if they want to upgrade. All right.

The operational workflow you built, which tools did you use? Did all the stakeholders have access to all of those or was it siloed? I guess I wanted a little more explanation on that one. In Gainsite, you know, you use rule engines but most of the time I was doing rule engines to push stuff out, ingesting it into open prize based of it or having open prize pull it in.

And then doing workflows inside open prize to manipulate and pull in the disparate information to basically use the GSE. GSE ID to track it back down and then using the Salesforce ID because we take the information from Gainsite, pull it in and then sometimes we'll spit it back into Salesforce because it's easier with the API calls because you're allowed to have a lot more API calls with Salesforce. Not all of the stakeholders have access to the flows because they aren't technical enough to work inside open prize. All right.

And then some change management advice. What is your suggestion for encouraging team members to migrate their notes into new systems versus their previous process, old habits, that have worked for them in the past, primarily in a time where people are stretched thin and tiny. How do you get them to do this and how do you get them to do this in a time where your time is limited? I love this question.

I love the KISS methodology. Keep it simple, stupid. I make it so simple for them to do this that it is unavoidable and if they don't do it, I'm like, okay. It's very easy.

So you have to find a way to make it unavoidably easy that they will do it. I found that getting down to having conversation also, it's like, okay, I've made this process for you. If you could let me know how you, you know, try it out, see how it works and then give me some feedback, right? Because then I make it a discussion and then they can actually improve upon the workflow that I've done to make it even easier for them, right?

If it doesn't do this, then I add in that nuance. It is really about just making it as simple as possible and easy for like an easy button. Yeah, I'm sure they appreciate that too. Sometimes.

All right. Once you categorized data along with the dashboards, did you develop CTA playbooks? Oh, yes, I did. Of course I did.

Of course I did. Yes, I did. Now ask me if they were widely adopted. Sometimes.

I would say about 50% right now. But yes, I did develop some CTA playbooks for, I think, like 12 risk patterns. So every time a risk, that one of those risks, a playbook shows up because it's like a guide for them to say, here's what you need to do. Here's who you need to contact.

Here's how we're going to resolve this and de-risk this. We also have risk meetings every two weeks. So where we talk about all the risks with different accounts. All right.

And where did you start in this journey? What was your first step? I was a bumbling toddler when I first got Gainsight. I was like, ooh, it's bright, shiny, hot checks.

Yes. I felt like sales because basically we started out with trying to pull everything that we had in there and then also pulling everything in Salesforce. And then we had to back out of some stuff because we went over our limit just a little bit on our accounts. But I mean, we did have guidance within the implementation team.

It did take us a while to get where we are today because I didn't want to automate everything that we had because then it just becomes noise. And I wanted my team to get comfortable and have good habits in Gainsight. And so that's what we built upon. I wanted habits so they were consistently doing things, working in there because we use SuccessPlant to the max because we do implementations ourselves of building up workflows for our customers inside of it so they can get a handle on it themselves.

All right. And with that, did you inherit the existing Gainsight or did you start it? Oh, no. I started it.

I started it. Again, it was taking one system going from one tool to another, but not changing practices because we are still in our infancy on design. And I wanted to make sure that I didn't build something that couldn't be taken back down or taken a step back down to make sure that it worked for the whole entire team and the sales team. All right.

And we're going to end on the magic question that I think everyone has been asking. I use OpenPrize to clean my data. I'm sorry. That's the answer every single time.

I use OpenPrize to clean up. We had the accounting team needed to move the data, like the address data. They had to go because they were, I think they were in SAP. They had to go from two digits to full name and we had so much data.

So I whipped up a workflow that changed it on a hundred million records and it took me an hour. All right. Great. Well, thank you so much.

Thanks, everyone, for coming. Thank you.