Speaker 0: I was like, where did everybody go?

Speaker 1: Good morning. Alright. Let’s do…

Speaker 0: You got one more minute.

Speaker 1: It’s hard. My office is right next to the heating and air at our house, so in the summer in the winter, it’s really hot, and in the summer, it’s freezing. So I always have, like, the counter outfits on to what you’d expect.

Speaker 0: I love it. Alright. Well, let’s get started. Hi, everyone. Welcome. My name is Tamara from Sercante. Welcome to the last day of MarDreamin’. It’s been so much fun. We have an excellent session for you today. Understand and protect your System of Record with MH Lines. So if you have any questions at all, feel free to put them in the little Q and A box, in the upper right hand corner. Put them in the chat. We’ll get to them. But without further ado, I will pass it on to our speaker today, MH.

Speaker 1: Thank you so much, and we’re so excited to be here. I don’t know if anyone caught it this morning, but Ariel that I get to work with, got to do a demo as well. So we are beyond excited to get to participate in the system. I do work with a company called Stack Moxie. We do monitoring and observability for complex tech stacks, but that has absolutely no relevance to what I’m talking to you about today. Again, my name is MH Lines, and I spent a good ten years of my career helping build Marketing Operations Centers of Excellence at companies like Microsoft using Marketing Cloud and at IBM Watson Health, different companies like that consulting and helping them build their Centers of Excellence. So that’s where this presentation is coming from today. And again, thank you so much for having me here and for all the sponsors who helped make it possible.

Alright. So what we’re thinking about today is is your team aligned on the Source of Truth for each of your metrics? It’s really important that when you’re thinking about metrics that you’re trying to drive your business around, that you’re aligned which system is reporting it because with a lot of frequency, those things are not the same. So I guess the best place always is to start with the definition. I like to quote Wikipedia because I like this definition best, not because it’s necessarily the most reputable source, but, Wikipedia says that a System of Record is a data management term for information storage system that is the authoritative data source. So, that authoritative data source is what’s really critical. So I want you to think about how does your your team and your company view System of Record? Is there clean clear alignment on what the System of Record for different metrics is? And then the worst part, let’s talk about what happens when there is an alignment. Obviously, when there is alignment, disagreements arise. So your MarTech stack will naturally have difference in reporting numbers even if those same even for the same metrics. So this means that your team doesn’t agree on which one system has the final say, and there’ll be debates about what the true number is and whether or not goals have been met. It’s an incredible waste of time and does nothing to benefit the actual business and what you need to reach alignment.

And so a super common example that I see everywhere is time to follow-up with a lead. So we all know that lead conversion decays the longer it takes to follow-up with a lead. If you ask the average Salesforce Ops Admin, they’re going to say they know that number cold. But what they’ll be meaning when they say that number cold is the time a lead is created in Salesforce and the time it lands with a rep when that rep follows up. Sometimes they even mean the time it lands in a rep’s queue and the time the rep follows up. So if we were trying to report on time to follow-up on the lead and have a good understanding of of that decay, what’s that time that that decay happens, it feels like that’s not the right place to start. We really want to start when that person from their user journey takes the action. They’re filling out a form on a website, and then that clock starts ticking. So should it be the time that a lead is created then in Pardot? Sorry. I’m going to keep saying Pardot because I’m just not good at it. Is it the time that that lead is created, the create date time in Pardot? Is that the System of Record to start that clock? I mean, not really. What if you’re using Unbounce or if you’re using Instapage for your web form fill outs? What if there is a fifteen minute delay there? So, it’s important for us to think about what’s the System of Record for start time, what’s the System of Record for stop time, and then we can come together and say that this is the time to to create a lead.

Alright. So the hardest part here is getting everyone on the same page. So I think the only way you can get everyone on the same page is first to talk about what are the systems. Right? So if you don’t even know what systems exist, how can you define one of those as the System of Record for each metric? I I always start with just a published stack diagram. So if you don’t have a published stack diagram, you can just use any workflow diagramming tool or there are really cool tools out there like MarTech Guru or CabinetM that can help you diagram your tech stack. And next, you need to understand how that data is currently owned and managed. So this one, the the owner, the ultimate admin for this tech stack is our Sales Ops team. This one is our Marketing Ops team. This one is our Web Ops team who is on the engineering team. So just defining who those people are, and who owns that tech stack, a lot of times there isn’t clear ownership even over your tools. And so when a disagreement arises on how to manipulate a field, you don’t even have alignment there.

Next, you need to understand how your Tool of Record is impacting other teams. So this is really an exercise in bringing your tools together. So this isn’t really assess a system on how to define KPIs, but this is kind of that’s going to be where you start. Like, your KPIs should never be about systems. It should always be about a business metric that you’re trying to accelerate. You know, it could be the things that support that. So for us, ours are helping our customers find value in our product. It’s about sales, and it’s about pipeline. So what are the systems that help us track that? Like, another example is pipeline velocity. That one is going to be defined across every system in your funnel. So if you think about other things you could care about, it could be time to contact or follow-up, number of touches. If you think about System of Record issues, if you’re using a Sales tool and LinkedIn and when you’re trying to say, how many touches does it take to follow-up to get a lead to convert? Right? So we want to we want to track that and we want to reduce the number of touches by improving the quality of each touch. So we’re that’s the thing that we’re tracking with our SDR team this this quarter. If you’re using a CRM, Salesforce maybe, and a sales tool on top of it but you’re doing most of your touches through LinkedIn, how are those touches getting tracked back to the System of Record? In that case, it’s going to be a manual convert most of the time. There’s some really cool new tools out there that’ll do it for you but you need to make sure that the System of Record that is counting those touches has every touch included in it.

Alright. So how you’re going to do this is you’re going to bring everyone together to just drive alignment on if these are our KPIs for the quarter, and most teams have nested KPIs underneath them. This is the system that we’re reporting out of, and everyone can understand how that system is updated. Like, latency is a really important part of this. And so here’s just a quick sample agenda. I’m I’m a meeting girl. I know that there’s lots of really great async teams. So you could totally do this by defining something on Confluence, asking for comments via Slack, and then having a publish date where it’s agreed upon. So this could be totally done async. For me, I like to do a meeting. I want to review the map of all the systems. I want to think about our our KPIs and agreeing where those systems live, create a data map that that aligns us on what those systems are, and then schedule a regular cadence to review it. So it’s not a very heavy meeting and I would argue that most people can come to alignment really, really quickly once they realize, oh, shoot. That that number in Salesforce that I’ve been looking at for my time to contact, it really is based on when it started in Salesforce, not when the customer takes action. The other thing that’s hard about this meeting is that you’re going to occasionally have to come to numbers that you agree are manual and so you’re going to have to agree what’s the cadence in which that manual pull is happening that we’re going to test it, maybe you’re going to have to go with a sample or a manual pull and you’re going to have to agree on for our regular cadence to review who owns doing those things manually.

Alright. So let’s get into the System of Record Best Practices. The goal here is to just keep us aligned across the org with as little time spent as possible. One is managing your system. So this is something that I’m I’m really key on is if so so we’ve gone through the tech stack diagram. Right? And we’ve said, this team is managing this system. This team is managing this system. This team is managing this system. And for a lot of our KPIs that really impact our customer across their journey, they’re going to be cross system ownership of the System of Record for our KPIs. So you need if you’re an owner of a system, you need to make sure that you’re managing that system in a way that allows everyone else whose KPIs are impacted by your system just with consistency and communication. One of the biggest ways to do this is just by publishing SLAs, making sure people know that, hey, this is a batch integration between these two systems. It takes eight days. So there’s a delay in our reporting. Or, if you’re managing latency or time to execute, then it’s really critical that you understand it across the system. And then having reporting notifications to those people who are impacted when that System of Record is you’re making changes or they have issues. And then have a clear process for managing outages because if someone else is being impacted and their analytics team are working against those notifications and they don’t know that there was something down, there is so much rework and just stall and just unnecessary headaches that can happen that could totally be cured with just a quick Slack message saying we had the outage, this is what was impacted.

Alright. So this is our Stack Moxie strategic quality model, and you can see, I’m I’m really focusing on kind of the concept of transparency for starters, when we’re talking about how do you manage your stack with quality. So this is all we’re trying to do is communicate with transparency to the other people who are impacted by a System of Record what is happening. So just as we discussed, you start with a diagram of the tech stack partner and then you can move into a published SLAs that, you know, we, this is how long it takes to route to these systems, this is how long we’ll take to notify you of changes if there’s problems. And then publishing those details somewhere, we call it Demand Central but it’s really just an intranet page where everyone can publish those things so everyone knows how to get access to it and everyone knows that this is the field, this is the API name, especially as it impacts a System of Record for core business metrics. Publishing status against that. So again, talking about when something goes down and there’s a problem, how do we create the entire organization from being impacted and the entire organization from spinning? We can just publish status and drop it on that internet page so people can even self-service. Like, it looks like something’s not working. I wonder if something’s wrong with this core system. Just like Salesforce does. Right? You go to the Salesforce publish status page. Before you try and solve and see if something’s wrong in your instance, you want to know if something’s globally wrong. Well you can do the same thing with your Demand Central and your internal team for all of these connected systems. Finally, when something does go wrong that impacted everyone across the organization, I think we’ve all heard the term postmortem, but I think most of us try and keep our postmortems really closed and sit in a room and try and talk about how we could fix it. It’s better if you bring everyone together and they go, you know what? I actually don’t care about this one. Like, you don’t need to notify me on these issues. So you can go back to your little, issues list and saying, yeah, next time let’s not notify the web ops team when there’s a Salesloft problem because it’s creating noise. So that postmortem process isn’t just about what can we do more of, it’s what can we do less of? How can we have these impacts have less of an impact on our organization? And then finally just doing more and more publishing, like just living with complete transparency. If anyone hasn’t seen it, GitLab has the absolute best Demand Central where they just share everything not just with their company internally, but with the world about what are their processes and systems and tools, and they really do an exceptional job of living out in the open.

Okay. So the next best practices that we’re going to talk about are planning your KPIs. So as you’re coming through your annual planning process right now, I guess people might be done with them. We’re in November, aren’t we? Your Internet or maybe you’ll do it on your Demand Central. Planning, defining your KPIs in a glossary that the entire organization can access. So, we’ve sat in a meeting. We’ve put together a PowerPoint that has the KPIs and who’s owning them and things like that. But wouldn’t it be nice to just have someone talk through what this is? Like, have a definition where everyone can go to the definition to drive alignment. And I think in every single one of those definitions and documents like that, you should have a tracking log at the on the back page that says on this date, this person made a change and here’s the change we made and why. So over time, you can see, oh, wow. Bob’s joining the organization and Bob is really on the SiriusDecisions demand unit waterfall. And so he really wants us to follow this, but when you start to look through those track changes document in your glossary of your definitions, you can say we’re not using MQL anymore and here’s why. And so he can be taken on that journey to help make strategic decisions rather than making everyone relive every single definition change to get on board when they join the company because everyone has their own way of doing it. And and half the time when they join the company, they make you want to take go back through that journey again so they can go through it with you. But if you have that really great documentation and they can see the why, it’s really easy to get people on board. In your KPI glossary, another great suggestion is to, publish that live report dashboard where it lives. So if these are your KPIs and this is the frequency that it’s updated and this is the glossary of the things we’re we’re adjusting, you can just have bullet points underneath the glossary that say, this dashboard, this dashboard, this dashboard. So it helps people find them and everything’s interlinked all the time. And finally, again, I just talked about how much I admire what GitLab has done. Make these accessible to everyone in the entire organization so they understand what’s driving you. I can’t think of how many times as a Salesforce or a Marketing Ops Admin, I have to say no, and I can say here are the strategic initiatives I have, here are the new campaigns we’re trying to get out the door. The thing you’ve asked for I totally agree with is important but I’m having a hard time making it list, making it onto the list because of these priorities and it and it makes it very easy to then have conversations with the people who are impacted by your strategic decision making.

Alright. Here’s one of my favorite things to do when I think about these Systems of Record. This is just a Google Sheet. These are actually some metrics that were life changing. And, when I was starting to build this ops core ops function at Microsoft Office, it was net new. All of these systems were net new. There were engineers, there was Dynamics teams, Salesforce Marketing Cloud, and Marketo. And and everything was being built from the ground up. And so we had metrics that were really critical to us, but we just couldn’t track them yet. There was incredible volume. It was pre-launch, and we knew that we didn’t have the tools and the systems in place to be able to track them. So the almost every single metric was at a status of black, which meant we weren’t able to track it yet. And it was an incredible place to start because our goal when we were looking at it was just to get to tracking. Even if everything was red, moving from not being able to track it to being able to track it was an incredible success. And so for the first six months, the incredible people I got to work with and learn from were incredibly patient, because they knew at the scale we were working at, it was just hard enough to get to track and they didn’t want people to bury it. So starting with a goal of getting your tracking in place, and then being able to track those those measurements. And on this document, having a view of the world that takes you back to that glossary and back to the System of Record so you know what you’re tracking against. So if our KPI is we want our lead routing to sales to be under ten minutes, what System of Record are we tracking from? And then we can start to to input the tracking and talk about the successes we have on tracking those core metrics. Another cool thing that we learned pretty quickly is, you want to be able to show where you came from. So if you have yellow, a yellow highlighted field, you can show the previous time period’s status by just putting a ring around it. So this one, sales follow-up, we want to move it we want sales follow-up to happen in less than two hours. Right now, it’s at four hours. We identified this as a problem, and that’s when we realized that there was an incredible delay in, in routing some of the follow-up. So we’re hiring additional project managers for this because we’re taking action on it. We’re moving it from red to yellow. And so this one, even though we’re not meeting our goal and we have a pretty big gap, we’re moving it to yellow because we’re taking action on it. We’ve identified a solution for it. And then red is pretty obvious what that means.

Alright. So the other thing is using data to have the hard conversations. I think every single one of us feels like failures when we see red all over a dashboard. And I want everyone to take a second when they’re dashboarding these things and using data and not feel like red is a failure, red is just a status. So if if you come into a meeting where everyone’s hot and everyone’s mad about there being a bunch of red or, god bless, even a bunch of black where we’re not tracking the things we care about yet. Those conversations feel personal and people don’t make good progress. So I would encourage everyone on these status meetings, and these status meetings can be their own meeting or they can be a subsection of other just KPI meetings. I I would argue that they should be just ops teams members who are coming in looking at these systems because once you get into business value, there’s a whole level of confusion. But if you think about coming into these ops meetings where you’re looking at these statuses, have the hard conversations, have these quick cadences. If you’re doing this right, these meetings are quickly turning into emails or Slack notifications where you are just updating on the status and you’re driving alignment. This shouldn’t be something that’s taking a lot of time but they are critical conversations to get to in order to improve your quality.

Alright. So just an example of two systems of record and one metric. I’m going to go through a couple more of these. Lead, your map has defined as qualified. So if you think, I’m going to skip ahead to the next slide. So if you think about the demand waterfall, there are Sales Accepted Leads (SALs), and then there are all these Marketing Qualified Leads (MQLs). And a lot of times, it feels like it’s the same metric but two Systems of Record. It’s not. There if you have the same exact metric, so if it’s a Marketing Qualified Lead and Sales Accepted Lead just means it’s not being found in Salesforce, feels like you’ve got duplication. This is a metric that is allowing you to diagnose when there is a disagreement between two Systems of Record as systems are making it through your process. So, counting how many MQLs we had and how many SALs we had in that weekly status meeting lets us know that, oh my gosh, something didn’t route through that we thought was a qualified lead that should be routing and you can identify when there’s a problem just in your technology, not necessarily in your business processes. So that’s why you’ll see things on these demand waterfalls where there is something that is accepted before it’s qualified even though it’s just a person opening it up and looking at the screen. So I would encourage you as you’re getting really sophisticated in your operational measurements to make sure you’re keeping those tools and those opportunities to have counts that can talk against each other.

Alright. So I I just want everyone this isn’t something that should be hard. This isn’t something that should be time consuming. This is something that just should be a documentation and agreement exercise because if your System of Record isn’t aligned then your digital life, your KPIs, your metrics, everything your business is trying to align against are going to be debates that are absolutely pointless and useless. So I would argue to protect that System of Record and your System of Record documentation and discussions like your digital life depends on it. Alright, thank you guys. So do we have any questions?

Speaker 0: I gotcha. Alright. We have any Q and A questions. Anything in the chat? Has anything popped up? Let’s see. Alright. No questions so far. Last chance y’all. Get your questions in. Oh, thank you so much. That was that was excellent. I have an, uh, desire to go, like, graph everything now and, like, put everything in a Google Doc, so I appreciate that.

Speaker 1: Well, and if anyone wants, I think for any attendees, we’ll have access to the spreadsheets and get those out. So those are available, and we’ll we’ll happy to send those out as well.

Speaker 0: Awesome. Thank you so much, MH. And, for everyone else, this concludes today’s session. So thank you for joining us. And, again, a very special shout-out to all of our sponsors, for making it happen today. Make sure to pop into their booths to, you know, get a, you know, kind of understand what they’re doing as well. And, yeah, really excited to continue the day with y’all. Have a wonderful one. Talk to you soon.