About the speaker

Mollie Bodensteiner is the Head of Revenue of Operations at Syncari, the RevOps enablement platform. Mollie held two prior revenue operations positions so she’s experienced the evolution of revenue operations firsthand. She joins the RevAmp podcast to discuss the importance of data in Revenue Operations and how better data enables better decisions.

The Shift Toward Revenue Operations

Mollie: I’ve spent a little over the last 12 years really in the operations technology space, not to age myself. But started my career using Silverpop and Dynamics. And that was right out of college – my first experience with CRM and MAP – I’ve continued to expand on that experience over the years. Worked at Marketo on the professional services team, as well as have done a number of consulting gigs throughout the years. And currently now running revenue operations here at Syncari. So, excited to be here today.

Barry: We’re excited to have you. So, is this your first revenue operations position?

Mollie: No, this is actually my third. So have had the experience on two other revenue operations teams prior to joining Syncari. So it’s been really fun to just watch how revenue operations has evolved over the last, let’s call it, I don’t want to say decade, because I think that’s even too broad of a net, but let’s call it the last five years. You’re seeing a very similar path as marketing operations and sales operations. And now I think companies are starting to see there’s this go-to-market type of opportunity where having those operations teams come together and really working around the customer has such a tremendous impact for the business. So it’s been really fun being a part of this journey.

Barry: Yes, absolutely. And for you, what do you think caused that shift? Is it that people have been talking for marketing ops for too long, so let’s talk about something else, or was there something specific in the macro-environment that caused that shift?

Mollie: One of the things that I think about a lot in this, and if you’re on LinkedIn, there’s always the noise of, should marketing operations report to revenue operations or who reports to revenue operations? And there’s this perception that revenue operations are a sales function. And I think it’s because of the connotation of the word ‘revenue’.

But at the end of the day, what is marketing trying to do? What is CS trying to do? What are all these pieces around operations trying to do? Provide a better experience for the customer that, in turn, drives revenue. So I think taking a step back on that is helpful. I think strong-performing, customer-centric organizations have always had a revenue operations mindset, and they think about things in that way, in terms of how we provide value to the customer and improve our operational muscle while doing it.

And now I think they’ve just added this layer where they’ve put more of a dedicated focus on bringing the team together, and that’s where the notion of the revenue operations team has come into play. But you don’t have to have a body in revenue operations to successfully deliver revenue operations as an organization. So I think that that’s some of that notion.

I think they’re seeing when you have more alignment across those departments, especially when you think about processes, systems, data, tooling, and enablement, you’re knocking some of those silos down. You’re moving that forward in a more concise way. I always laugh because the operations people in the business are, I don’t know, I’m going to call us your superheroes. We’re the dream makers, we’re the getter done-rs, whatever you want to call it. But if you take a step back and look at your business, can you name another department that’s working as cross-functionally as your operations folks? So when you have that synergy and enablement, you’re putting things forth for your business that you might be missing if you didn’t have that.

Barry: Yes, it absolutely makes sense. I like that. The superheroes. We’ll go with that.

Mollie: Yeah. Let me just coin myself that. Sorry.

Data in the RevOps Function

Barry: Yes, perfect. We don’t patent everything on our podcast. So cool. One thing we were discussing right before we pressed the record button was data. Something that seems you’re passionate about, I happened to be passionate about it. I like numbers. I studied finance at university, and I try to use numbers in my marketing the way I think about marketing. So let’s talk about data on this podcast. We’ve never had a podcast that talks mostly about data, so I’m excited about this. So in order to talk about data, maybe it’s important to define what data is for a rev-ops function.

Mollie: I laugh because data’s the backbone of your business. If you can’t measure it, you can’t improve it. You have to have data to be able to measure it. And so, thinking through that, it’s more than just numbers. It’s that story, it’s that journey, it’s bringing together all that critical information about your business, making it actionable, and making it mean something.

Barry: Okay, cool. So data are numbers that can be understood quickly, so those insights can be made from them.

Mollie: Yes. And I don’t know if that’s almost what your metrics are, are the numbers that you can understand and your key performance indicators. Data is that foundation that you’re going to then aggregate together to tell your story.

Barry: Yes. Okay. And I also wanted to hone in on the idea of improvement because you can do things without data, but maybe you can’t improve without data.

Mollie: Yes. And there are so many nuances to this because you can also work off inaccurate data. That’s a whole other subset of this too. So yes, you can still make improvements without actually having data. I’d say if it’s not something you’re measuring, it’s a lot harder to do and make those improvements. And there’s probably some statistical equation that tells you how much of that is luck or not. But then, on the other flip side, you can also have crap data that’s completely inaccurate, stale, or unnecessary and make decisions off of that as well. I think we see that a lot within businesses. And that’s where one of the big things before you even think about what data means to your business, you’ve got to take that step back in terms of what you are trying to measure and what the definition of that is.

The same way you write business requirements when you’re buying a piece of software, you need to write data requirements on how you’re building metrics and KPIs and what you’re trying to measure. I worked at one company and came in and the way the business was quantifying what a customer was. The product’s definition of a customer was different from the go-to-market’s definition of a customer. How do you aggregate that up? And how do you make sure that the business understands when we say a simple word lie customer, what that actually means?

So even just thinking about the common definitions of things that you’re trying to aggregate up to your business. MQL, let’s talk about it. I know you hear MQLs are dead. But as you’re defining, what quantifies an MQL for our business? What is the process that occurs in our customer experience? How does that then translate into the technical process, how it runs through our systems, and then what becomes the output of that is ultimately the metric that we’re pulling, which is the MQL.

And so before you can start trying to put together, this is our output that we’re going to get to. You have to make sure your systems or your processes, both can deliver that as an output. And you’re clear on what that is. Otherwise, you end up with the crap inaccurate data situation, or you run into the fire drill where you’re either writing a bunch of sequels to try to pull things together or living in Excel.

Barry: Right, that makes sense. And then, let’s say you did it correctly. How do you communicate that cross-team? And does it need to be communicated across teams?

Mollie: I think it goes back to the business strategy that you’re portraying. Ultimately, if a KPI and a leading indicator’s MQL, you should be surfacing that to the business, but MQL on its own is not good enough. So say, 50 is a number. You have to be able to quantify that 50 into the scheme of what that means to the business. Is 50 good, is 50 bad? I don’t know. So comparing 50 based on whatever a goal is, based on historical trend, based on the conversion rate to subsequent stages.

I always laugh. When I was running a marketing team, I had my boss say, “You need to be able to generate 200 MQLs.” And I said, “What’s my budget.” And he said, “My budget?” And I said, “Okay, done. I’ll just go buy a list.” You have to give more to it and why it’s important than just the number. And you have to be able to either reverse engineer it back of how it’s going to get to revenue or push it down and understand how it’s going to convert down to revenue. But you’ve got to be able to tie it to ultimately that end game.

But on the flip side of it, you can’t just say you need $10 million in new business without going back and figuring out how you get there. So that data and those metrics become a part of the journey for how you get to measure your output.

Audit Your Tech Stack and Data Dictionary

Barry: Yes, that makes sense. So let’s say someone joins as the first rev-ops person at their company. Where do they start with data? Clearly, data has to be a priority, but where do they start in that world?

Mollie: Yes. So what I’ve found is usually, companies make their first rev-ops hire after they’ve realized they need the help. It’s never a proactive hire because we have everything that we need set up. It’s a reactive hire of, “Help, we don’t know how to use our systems. Help, things are getting too hard.” So good luck to you, first rev-ops hire. I’m rooting for you.

Part of the things that I think about is understanding what your infrastructure is. Map the flow of data between your tools. And it doesn’t have to be some crazy fancy diagram. But you need to understand what your tech stack is. And I always laugh at this because I’ve worked in companies where I come in, and I think I know the tech stack. And then I’m like, “Oh yeah. Wait, what? You got an invoice for this tool that I had no idea existed?” So spend time, if you can’t track the invoices, go to finance, go to IT, they will tell you what you own and what you’re paying for and bring that together.

And do an audit of what tools do we have? What data do they produce? How does that come together? And map that out, understand what’s single direction versus bidirectional, and what’s manual imports and loads.

From there, start to build your data dictionary. You don’t have to have some crazy, fancy data dictionary. Open Excel, build your tabs, get your schema, and understand what’s touching these key attributes? How do they get populated? What source, what’s the frequency? And what actually is your data authority strategy? What wins there? And start to build that dictionary, so you understand where things are happening.

There are twofold on this that I’m going to talk through. When you have to make a change in your systems, let’s say you’re changing a pick list value of leads status. I’m just throwing something out there. Yeah, I know how to change that pick list in Salesforce. Where are all the other places that are probably referenced in your stack? Several. So having a clear dictionary and understanding the sources of information and the downstream is huge.

On the secondary side of that is that you’re not going to be hopefully a RevOps team of one forever. And so when you think about bringing in your additional hires, this is such a strong foundation for scalability and growth, and being able to get somebody in and get them ramped up quickly. And it’s one thing that you’re keeping updated, but it’s such a critical thing to keep updated for your business. It also helps when you start bringing product usage information in and other outside go-to-market sources to be able to take that to your data analytics team and say, “Here’s our go-to-market data dictionary. Should we be joining this with yours?”

Barry: Well, that sounds complicated. How much time does it take to do something like that?

Mollie: It doesn’t have to take tons of time to do this. It’s not something that you need to sit and do, spend two weeks doing. You should be able to put together your general schema of how your data’s flowing. Go in, and you can copy and paste the fields out of these systems. You can export the fields out of these systems. You can see where they’re being used. And you don’t have to say, “Oh yeah, this is on a page layout. This is on this page layout.”

It can be very high level, but you need to make sure you’ve at least got something in place and getting that aligned so that when you go, and you start defining these KPIs with your team, you know, “Hey, this field’s getting updated from these six different sources. What’s our source of truth for this? How do we need to measure this?” And more often than not your six different sources aren’t all talking to each other at the same time.

And what’s your vulnerability to air, because you probably don’t have centralized data management? So you don’t have to make it harder than what it needs to be. That would be my piece because it’s an evolving document. But you need to make sure you’ve got someplace to work off of.

Barry: Yeah. And does it go into a Google Doc or a software? Do they have software for this? Or does there need to be software for this?

Mollie: There is software for this. So like Syncari, we have its directory built within our platform. It’s right there. It’s referenceable. But you don’t need to go buy a tool for this if a spreadsheet works for it. A lot of times, the spreadsheet is the starting point. Don’t go out and buy your own data dictionary tool. You’re probably not there yet.

Decide on Your KPIs

Barry: Right. Okay. Cool. So we’re at the data dictionary. So when you figured out what data you already have, you figured out the data dictionary. Both of these things are living documents, so even if you’re the fifth person in your rev-ops team, these are still important. You’ll just be growing it versus these non-static documents. Then what? What comes next?

Mollie: Yeah. So I think coming in and your organization, if you’ve been brought in, should have KPIs. There should be some sort of north star metrics, things that the business is measuring. You need to spend the time because ultimately those are probably going to come down to the responsibility of revenue operations and finance to bring together for monthly reporting and those pieces. So sitting, going in, and defining what are those metrics that we’re accountable for measuring, what do we have today that we need to maintain? And then what are the new things that we need to also be bringing in?

And getting aligned on what the process for that is when it happens and then what the output becomes from the display. Because obviously there are going to be different metrics that probably the sales team is looking at versus the financial metrics.

So being clearly aligned on this is how we run the month-end. This is when we calculate it, this is what this looks like, and alignment between finance as well is going to be huge for that. Because if the sales team is running numbers before finance has done reconciliation in those things, you’re going to get discrepancies. So sitting and coming up with this is our operating cadence for pulling these numbers. This is what goes into those, and this is how we report back out.

And getting that buy-in and alignment is important. This something like rev-ops might own the architecture and the delivery of the numbers. They shouldn’t own the definition of the numbers. The business should be defining what they need to measure so that you have that built-in.

Barry: So this piece is a lot of communication and finding champions that want to communicate and also finding the people that need to communicate, even if they don’t want to communicate as much. Not to go into any specifics there. But I think we’ve all been there, no matter what your position is.

Mollie: Yeah.

The Relationship Between Finance, Sales, and RevOps

Barry: So you mentioned finance. Can you talk a little bit more about that relationship between finance, sales, and rev ops?

Mollie: Yeah, absolutely. I think there’s such an important synergy between, think revenue operations, just the word revenue. What’s finance ultimately care about and responsible for? And there’s the whole accounting and financial factor of these things, which is very hand-in-hand with what is happening from the sales operations component of things.

Deal desk, processing new deals, payments, all of that management. Generally, those systems are supported by rev-ops, but finance is ultimately a key stakeholder in those pieces as well. So how does the information go from Salesforce or your CRM to your ERP or your payment platform? There has to be a strong relationship between the two teams, a strong definition in alignment, how it’s managed, and what those outputs are. Otherwise, it’s going to become super chaotic.

And how that information comes back. So when a customer makes a payment in Stripe or wherever, we should probably get that in the gain site, so the CS team stops asking them where their payment is. On the flip side, if the payment’s overdue, how do you surface that then back to CS to make sure we’re following up on that experience? There’s such a process and integration component between those types of platforms.

Barry: Yes, that makes a lot of sense. So I’m going to review the steps. So we got into mapping out the data into a data dictionary. Would you title this one communication?

Mollie: Yes, it’s probably alignment.

Barry: Yeah. Okay.

Mollie: This should be a part of the process as you think about people, process, data, and technology. As you’re going through and ramping up your onboarding when you’re outlining those process pieces behind mapping systems and the data you should be having those conversations and getting those things stood up within the finance organization, same with marketing, sales, probably CS, and products at the same time, if you’re a product-driven organization.

Infrastructure in Revenue Operations

Mollie: Yeah. I think at that point, you’re moving it into the infrastructure, building it into the systems, and getting it up and running. You’ve got your pieces in place, and that’s the technology and then the ultimate output. So setting up what that right cadence is for review and delivery and obviously within that, there’s going to be QA, validation, and then continual iteration.

One of the big things that I think we don’t always do a great job at, or maybe I don’t always do a great job at, I shouldn’t speak for us. If you’ve now finished the race, you’ve got something out as an output, what does it mean? So one of the things that I try to challenge myself with is whenever I am putting together numbers and talking through them, I try to bullet out what decisions am I going to make from them? How am I going to act on this data, or who should be taking action on this data?

And so I think that that’s an important piece when I started doing this, as stakeholders would ask for dashboards, “Hey, we need a report on this. We need a report on this. We need a dashboard on that.” Why? Tell me what you’re going to do with this information and how will I know that by spending the time and energy to put this in place for you, it’s providing value?

How am I going to measure my metrics, almost if that makes sense? Because at the end of the day, if you are just looking at it and not using it, what’s the point? So how do you help inform and drive decisions off of it? So I think that becomes your last piece, is it’s not good enough just to stand it up and say, “Hey, we got 50 MQLs.” What does that mean? What are the decisions we’re making off of it? How do we tell the story with that piece of the puzzle?

A Single View of the Customer

Barry: Yeah, that makes a lot of sense. So to review, you document where these resources are coming from, get a data dictionary alignment, then you also need to do the integrations and the implementations and going things. Possibly buy more data, if you see that things are missing, I guess that would come in there. And then making sure that data is used in the right way. And I guess then you create more dashboards from that, or that was part of the integration phase?

Mollie: I think that’s probably part of the integration phase. I think then you iterate. And as your business evolves and grows, more data are going to be necessary. And you’re never going to get all of this stuff done in one sitting. If you sit down and say, “We’re going to pull this all together and make this all work across our entire business.” It’s not going to happen. You’re going to be prioritizing key pieces of the process that you’re trying to scale through and then continue to iterate. Everyone talks about the single view of customer. You want to have that unified customer data set that you have to understand your business and tell that story, but you’re never done with that. It’s never finished. You’re building this foundation that you’re iterating on, and you’re going to continue to evolve on it.

Barry: Yes, it makes sense. So let’s go a few steps. We can talk about data hygiene, and data management. Where do you want to go?

Mollie: I think one of the big things when you think about let’s talk data normalization, data hygiene, and data management first because I think that the average tech B2B SaaS company has 80 different tools. That’s their traditional tech stack, which is terrifying if you sit and think about it. All of those systems generally have customer data in them. How do you normalize that data in a meaningful way and bring that together? And that’s part of where that data dictionary and data authority strategy comes into place.

What are the things that we should make sure of? This is how we bring data together and what makes sense. It’s even simple things. Are we spelling out state, or are we using abbreviations? That’s such a small thing but can cause tremendous disruption downstream in your reporting if it’s not right. No one wants to stand up a report, and you have two different versions of each country.

And so how you put that strategy in place of, here’s how we’re going to normalize the data, this is what our structure is. I’m sure any marketing ops practitioner can empathize with getting a list from a trade show they have different revenue bands, and how do you fit that in your pick list for revenue bands and get that squared away?

Anyone who’s using enrichment tools, they have different outputs that come from these core pieces. So coming up with this is how we are going to take this data and normalize it into our systems is such an important piece of things that I think we tend to overlook because we’re just, “Hey, we got the data.” And then that comes back and bites us when we try to do the analytics because it’s not always structured in a meaningful way.

Data Hygiene in RevOps

Barry: Yes, that makes sense. It reminds me of a story I remember. I’m located in Israel, so I was like, “I’m from the states, United States.” And so I was abbreviating all the states. Because I know, I would say 80, 85%, in one second and 95% if I think about it for 10 seconds. But other people don’t. If you’re a global company, people don’t know the abbreviation states, which makes sense.

But just was, oh, this does impact people, this does change everything. Or this maybe doesn’t even matter what state they are in. We can say a region or a time zone or things like that. So that reminded me of that story when I was just shocked, but yeah, obviously, it’s like that. It’s funny. So we’re at data hygiene. People are cleaning up the data. You mentioned before that there’s also this bad data. Is that part of data hygiene, like misleading data, if you will?

Mollie: Yeah. I think that’s part of it. I think there’s probably twofold of how you get misleading data. There’s one that’s it just isn’t following the right process, and you go back to the process component and how you’re getting the output isn’t right. Whether that’s something in the systems is mis-stamping or mismanaging, or you have bad data, which happens. It’s never 100%.

If you’re looking at your TAM, you’re trying to get your total addressable market, and you don’t have the right qualifying indicators or bucketing, or you have stale data, and you’re counting all these people who no longer work at certain companies anymore. That’s another huge issue with not having accurate data, which is going to hurt forecasting and projections downstream.

Barry: Yep. No, it makes sense. And data management, do we touch on that, or is that a different topic?

Mollie: No, I think that folds into this as part of all of the hygiene, the management, the definition of it. That overarching is probably data management, is having the normalization, having the definition, having the enrichment strategy behind it, and understanding where your source of truth of data comes in. A lot of people will say CRM is my source of truth for data, but it’s like, is it really, is that really your source of truth, or is it a source of truth for pieces of the data? So how do you think through your true source of truth, where that lives, and how you manage that too?

Barry: So if it’s not in Salesforce, where is it usually?

Mollie: Well, and it’s not to say it doesn’t have to be in Salesforce. I just don’t know that Salesforce is the all-encompassing source of truth of data, of all your customer data. Generally, you think about data warehouse might be the source of it or some sort of data management layer where you’re unifying and bringing data together. But Salesforce becomes the actual go-to marketplace where they action off of data, or sales is actioning off of data depending on your business structure.

But you think about storing the lineage of data and the history of data, and that, Salesforce doesn’t do that well. What is it, like an 18-month history? And it only tracks a certain number of fields changing. So that might not be the best long-term true source of truths for getting your underlying changes in data.

Barry: Yes, I didn’t know about the 18-month rule or whatever to call that. Okay, cool. So that’s interesting. And okay, so this is a lot of data,

Mollie: Data’s a tricky topic. There’s a lot that goes into it.

The Relationship Between the RevOps and BI Teams

Barry: So what’s that relationship between revenue operations and the business intelligence team? Is it a siloed relationship? What is it usually, and what should it be? So you can talk about both. And is there a way that they can work together, or they’re just on such different projects that it doesn’t even matter?

Mollie: It depends on the business. So the best relationship that I’ve had with a data analytics and the reporting team is when we both, revenue operations and it was a data analytics team reported up through the COO. We were on the same team. While a lot of their focus was driven based on product usage and that type of framework in those KPIs. There was such a strong synergy between bringing go-to-market information and tying product information together to help find those opportunities for upselling, churn risk, and all of that sweet information that you need to drive the business forward.

When we work together, we will tell a better story to the business because we are working towards common goals. I laugh at this. It’s, when do people work well together? It’s when they’re trying to accomplish the same thing. That just seems like such a simple thing to say.

But even though we’re trying to get different points of the same thing, at the end of the day, we’re trying to provide value to the organization to understand how we could better monetize off of our product information and give that back to go-to-market. So by working together on that, it required both of us to be at the table.

They needed to know about go-to-market data, we needed to know about product data, and we needed to come together and define those important KPIs that we need to surface and when and how we get that back. And then how do we know if it worked or not? So well, I might not be the person standing up all of the data pipelines and doing the data engineering, and they have no idea what’s going on in Salesforce, but we both came together and made it happen.

So I think you need to forge those relationships and figure out what’s important there. One of the big things I’ve learned is there’s a lot of data that can come in from a lot of the product usage things and being purposeful as you’re defining those pieces for go-to-market. We’re launching a free trial motion at Syncari to allow prospects to come in and try the platform.

I could pick every single event off of an event stream based on our tracking. But if I do that, my sales team is going to be like, “Whoa, what’s going on?” And they’re going to like, “The noise.” So being purposeful of what are the right groupings and the right indicators that show the intent and the usage and where somebody might be stuck and building that journey out and aligning the data to that. It goes back to that process piece, which is huge. Otherwise, you’re going to end up with a lot of random data points that people aren’t going to know how to consume and drive off of.

Go-to-Market Data Best Practices

Barry: Yeah. Cool. So data best practices. What are some of the top three data best practices? I think you told us a lot of best practices, but if you had to find your top three. And this could be for someone that already isn’t the first rev-ops person, maybe it’s the third rev-ops person. But what are the top three data best practices?

Mollie: Yeah. So I think one of the first best practices is to ensure you have confidence in your data. I don’t know if that’s a best practice, but that’s going to be my tip and it’s going to encompass a bunch in there. But make sure that you’re spending the time normalizing, standardizing, and de-duping. Duplicates are horrible. Make sure you’re de-duping. Be sure that you have confidence in your data because that’s the first thing that will affect your credibility if you surface something up, you show a number to people, and they say, “Oh, that’s crap.” Then you’ve lost it. So if you’re trying to drive decisions based on data, you have to have the confidence and the data that you’re surfacing. So spend the time, make sure you’re getting it in there.

The next piece of it is to get your value out of the data. So data is an asset to the business, the same way people are an asset to a business. So make sure you’re maximizing the value of it. You’ve got this clean, trusted data, and take it where it needs to go. Get it into the right systems and the hands of the right people where they can drive things forward on. You don’t want to sit on the pot of gold. So make sure you’re getting the right data to the right place at the right time and it’s working for the business. And then the third is thinking through how you architect your pipelines for data and how you think about data through your systems and your tooling.

Be mindful of a lot of tools. It’s one-to-one type sync between each other. You’re buying a lot of point-in-time solutions that are sending point-in-time data. So think about how you bring your data together and unify that data. So you can have more of that, again, confidence in the value because of the aggregation and unification from it. So those would probably be three of my big points.

For people who are coming into this world, don’t be scared by data either. Don’t let it overwhelm you, don’t be intimidated by it. Use it as an asset. Use it for what it is. Also, it’s never going to be perfect. You’re going to try to make it perfect, but no, it’s not always going to be 100% perfect. And be okay with that, but make sure you’re not just letting it fly off the windows.

Barry: Yeah. So it sounds like data could literally be your full-time job. What percentage of a rev-ops person is data? Or it’s something that is not talking about KPIs and going through the KPIs but grading the data?

Mollie: Yeah. The orchestration and the management?

Barry: Yeah.

Mollie: It probably depends on where the company is from the maturity and bringing new tools on and where they’re at. I think you want to get that foundation to spend time on. Once you have good normalization and operating procedures there, you shouldn’t be spending tons of time on the data management. It’s getting it in the foundation first.

But again, I’d say you’re probably spending 10% of your time on data management, and that’s high. I’d probably spend five to 10%, depending on what we’re doing, if there’s a new initiative or thing on data management. But you shouldn’t be spending 50% of your time on data because that tells me that you don’t have the right infrastructure, processes, and plan around it. You’re being reactive. So be proactive in your data management and it makes it a lot easier.

Barry: Yeah. No, absolutely. And that’s another reason not to be scared of data because then it’s only less than 10% of your day.

Mollie: And I would tell you a tip and trick of this is if I notice something weird in the data, so let’s say, we’ll go back to the state and country example. I have a dashboard, every time something weird comes in, I drop it in the dashboard. So I can take one quick look and say, “Is something weird happening? Yes or no.” And have those hygiene guidelines that you’re trying to manage against. So you can catch the outlier again, proactively before it sneaks in reactively.

Barry: So what does that mean, that dashboard? It’s like you could see that there are 58 states, and that’s eight too many? What does that mean?

Mollie: Yeah. Just anything that doesn’t meet sub-criteria in there. So obviously, Syncari is a data unification platform, so I can do more prepend in my normalization, and I can flag things with a review if they don’t meet what my reference table says it should. So if I think about industries. So our enrichment provider throws something in and I’m like, “Oh, I got to figure out where this goes in the scheme of things.” I get it flagged for me. So I can go in and fix it on creation versus retroactively fixing it when we go and do analysis on things.

Barry: Okay, cool. So it’s a validation rule in the beginning.

Mollie: Yes, correct.

Barry: Okay. Cool. Well, Mollie, I learned a lot about data, more than I ever knew I needed to know. I think data is king and super important. You grow through data. By you, I mean RevOps, but also the whole go-to-market team grows through data, and it’s so critical. And I think the good point is that it doesn’t need to be your full-time job. It shouldn’t take over your job. It should be a piece of your revenue operations position, and that piece will help grow the whole company and get a real accurate view of what you’re actually doing and what you can do better. So I thank you for your time, Mollie, for sharing that with our listener, and looking forward to staying in touch.

Mollie: Absolutely. Take care.