The Most Important Metric in Implementation: NRR

Hello, everybody. Hope everybody has had a great Pulse. Super cool to be the last session here. I appreciate everybody coming.

I'll try to make this as fun and interactive as possible. Let me start out with a quick introduction to who I am, a little bit about my background, where I'm at today, what we're doing, et cetera. So my name's Daniel Levine. I'm the director of professional services at Clutch.

A little about me on the personal side. I've been in SaaS. Mostly startups my entire career. Been in professional services for a little over a decade.

I was at Gainsight 2016 to 2020. So I feel like I've been through a little bit of CS boot camp myself. It's definitely helped give me some lenses to look through professional services and implementation with. On the personal side, I live in the Portland, Oregon area with my wife and two kids, a 9-year-old and an 11-year-old.

A little bit about Clutch. So we are a FinTech. We make software that helps credit unions. So we have two core products that have been out for a couple of years that help increase loans and deposits like checking and savings accounts at credit unions.

By the end of this year, Clutch will have five products in the market, which makes NRR just that much more important for what we're trying to do for our company goals. But I really think it's applicable to most SaaS companies out there. So I bet a whole bunch of you are wondering who invited the PS guy to the CS conference. And we'll get right into that here.

But I present to you my wordiest slide that kind of explains why we're all here, which is I really believe professional services is more than just an implementation. Your success criteria is more than just common metrics like time to value, revenue, margin, et cetera. Those are leading indicators. They're super easy to measure.

That's why everybody does it. But the real success of an implementation, what I believe is the most important phase in the customer lifecycle journey, the real success metric is do your customers renew and expand. So that's truly measured by your NRR. So is your implementation team helping to ensure that your customers renew and adopt?

And if not, how can you shift your mindset? So I'd be interested to see at this CS conference last session of the day, how many folks here are either in professional services or responsible for professional services? OK, all right, handful of you. Good.

I was worried it would be zero. So I'm glad we got some PS folks in here. So I guess for the PS folks, but for the CS folks as well, if you're aware of the OKRs or the KPIs for your professional services team, raise your hand for me if your PS team is measured on time to value, if that's something your company measures. I'd say that's most people.

How about utilization? Even more hands. That's interesting. We got more hands for utilization than time to value.

How about revenue? A lot of hands for revenue. And then lastly, margin. A little bit fewer for margin.

Totally fine. These are all super common metrics, probably the four most common metrics in implementation. And none of these are related to customer success. Maybe a little bit on the time to value side.

But I like to say that I hope to one day become famous for saying, if you want to do a faster implementation, just do a worse job testing. Just skip right through it. So I really don't believe that time to value is directly correlated to customer success. So let me pause real quick and tell a story, because what really helped shape my mind around this was an experience I had at a company a few jobs back.

I was part of an implementation team that I thought was just doing a bang up job. We had great CSAT scores. Implementations finished on time, on budget. Utilization was good, et cetera.

We were hitting all the metrics that I thought we were supposed to be hitting as a professional services team. But the company started to have a problem. We had one year contracts. And when these customers were coming up for renewal, they weren't renewing.

Our renewal rates just weren't what they thought they would be. There was a lot of blame going around the company. Not much of it was focused on implementation. In fact, just about none of it was.

It was around adoption, which was blamed on the CS team. It was around product and what the product was doing. But we took a look on the professional services team and thought about what were we doing. We had these customers for the first four months of their first 12-year contract.

What were we doing to help with that renewal? And what we uncovered and how we kind of shifted our implementation methodology and our success metrics ultimately informs this slide deck and how I think about implementations today. So zooming out for a minute, just at the highest possible level, like we love to talk about outcomes, right? Why are we here at our SaaS companies?

What are we doing? What does our board care about? Highest possible level. They care about valuations.

What drives those valuations? There's really three things in the customer success world. There's recurring revenue. Your valuation is almost certainly a multiple of your recurring revenue.

And then GRR and NRR also play a part into what your company's valuation is. So that's what your board and your C-level care about. So then for us, what are we doing in either customer success or professional services that's driving those things that's going to help that revenue-- or sorry, that's going to help that valuation? So I think when you think about it from that lens, it starts to shift how you think about implementation.

So it's shifting from thinking about implementation on those common metrics that I shared before, common things like did we go live? Was it profitable? Was the customer satisfied? These are just measuring delivery.

They're not measuring outcomes. But the real SaaS success is coming from, did they get value? Are they expanding? Are they renewing?

Those are the things that we really care about. So we want to shift our mindset there and make sure that we're doing the things that are going to lead towards those outcomes. So I think our team should be thinking about what behaviors must exist to make this product indispensable so the customer ultimately wants to renew and expand. I think too many implementations-- speaking for myself as a PS leader-- we're in the weeds.

We're focusing on the granular details. Of course, we are focused on the integrations, the workflow, the technical setup, everything that has to get done. Implementations are a giant project plan. We're supposed to check check boxes.

But at the same time, we can't lose sight of why we're actually here, which is we're influencing the user behavior to use the systems that we're setting up. We need to pay attention to the product and feature adoptions. Stickiness-- I'm going to ask a question on this one. I know we don't have a ton of PS leaders here.

So for the CS folks here, I'll ask you to guess what you think your PS team is doing. Do you know or do you think your PS team knows what your stickiest features are? OK. There were a few yeses, a couple of noes.

I'm guessing a lot of the silent folks are the noes as well. And hey, that's OK, right? We're all here to get better. But I think that's really important.

Your implementation team should know what features you care most about in customer success. That way, they shift their implementation plans around it. They're not passing off projects that haven't fully implemented those sticky features. Change management-- is that a big, big part of your implementation plan?

Planning for not just, OK, the software is ready, the software is tested, and we check the check boxes on the SOW items. But have we really done change management, honestly, throughout the whole project to plan for the teams that are going to be using the software so they properly adopt it? And then executive alignment-- implementation is really smack dab in the middle between your sales team and your CS team. So we're taking care-- assuming your CSMs aren't around during implementation, which is the majority of SaaS companies-- we're taking care of the customers and we're taking care of those executive relationships while they're in that kind of sandwich period.

Are we making sure that we get the right handoff from sales, not just about what's in the SOW, but also about what were the pain points? Why did the customer buy the product? What outcomes are they looking to get out of it, et cetera? And then are we passing that along to the CS team when we do our implementation to CS handoff?

So anyway, so all that informs your handoff here. So your old handoff might have been something project was complete, this was our time to value, et cetera, et cetera. I believe a handoff should include things like your adoption plan, like is your implementation team paying attention to your daily active users, your monthly active users, which features they've implemented or deployed, how sticky those are, et cetera. Paying attention to the expansion opportunities-- you need to know what other products-- if you're an implementation, you need to know what other products exist in your company and how to highlight those expansion opportunities for CS, executive relationships, and then measurable verified outcomes, ROI for the customer.

If you're doing those things, that's not just a warm handoff to CS, but that's teaming the customer up for renewal and expansion. I like to think of it as instead of just the activities, like here's the activities we did during implementation, it's the outcomes. Here's the outcome of the implementation, so the CS team can take it and run with it. As I said before, I truly believe-- biased person on stage here, right-- that implementation is the most important stage in the customer lifecycle journey.

So it's determining your product adoption, keeping that exec alignment, your internal champions, and the perceived value, the ROI of the product. One of the things I like to say-- everybody remembers a bad implementation. You'll get customers that have been customers for two years, five years, et cetera, and they will remind you on all of your EBRs, we had a bad implementation. Some of them recover from it.

Some of them never do. But let's just acknowledge that it's a really important stage in the customer lifecycle journey, and let's try to get it right. Implementation has so much power and influence for how the product is actually adopted and used. It sets the stage for ROI.

I've been a part of good implementations. I've been a part of bad implementations. I've been a part of re-implementations. Sometimes you get that second at bat where the first deployment of your product didn't work out, so you're re-engaged for a second deployment.

It's great to get that second at bat, but you don't always get that. So we need to make sure we get it right the first time. Three questions I'd ask you all to help change your company's mindset around implementations. Does your customer know their success metrics before they go live?

What's actually going to give them value, ROI? What's going to solve the pain points that led to them buying your software? Do you feel like your implementation is handing off momentum? They've been doing a great job setting the customer up for adoption, correct usage of the product, et cetera.

And then for the implementation team, do they own the outcome for the customer? And this is why I say, NRR, it's a very lagging metric. I'm sure every professional services leader would push back and say, I can't be held accountable for something that happens a year from now, or maybe you have three-year contracts or something like that. But it's the North Star we should all be pointing towards.

So do you own the outcome? Do you own that full customer's outcome, or do you own just the implementation? Again, I'm not saying this is an easy switch. I just think it's the mindset shift to, hey, we're just the implementation people here, to we're really teaming this customer up for long-term success and value.

So, Slido poll here for everybody on the Pulse app. I'd love to know one metric-- this as your team, but it should be professional services. One metric you think your professional services or implementation team can own that you think would directly tie to or influence NRR. And I think that's supposed to show up as a word cloud here.

[AUDIO OUT] I'd love to ask-- because there must be a couple of people who have put in time to value there. I'd love to ask somebody who put in time to value. Why do you think-- now, obviously, we don't want slow implementations, right? But I'd love to know for anybody who put in time to value, why do you think that ties directly to NRR?

And I'm not saying you're wrong, like honestly curious. Yes. [INAUDIBLE] [AUDIO OUT] Got it. OK.

So are you on the customer success side of your org? [INAUDIBLE] OK. Got it. I think that makes a lot of sense, right?

Like if you've got 12 months worth of runway, if you're on the customer success side and you've got 12 months worth of runway, you don't want your implementation team taking up six months of that runway for you. So I think that makes a lot of sense. Love the stuff in here around adoption. I think that makes sense, right?

Like your implementation team should absolutely be responsible for adoption. I think that's the least they can do. Product value, yeah. These are great.

Let's switch it back over to the slide deck here. Appreciate everybody participating in this. 29 responses, I feel like that's everybody in the room here. All righty.

So yeah, just recapping what I've been saying here. I really believe implementation is not the finish line. It's just the beginning. It just kind of starts the real journey when the customer starts using the product.

And I hope your professional services and implementation teams view it the same way, that it's really the beginning of the customer journey once they're live on your product. And I firmly believe that the best SaaS companies out there with the best renewal rates, they don't just implement software. They implement customers who last. So with that said, I hope this was helpful, perhaps inspiring.

I appreciate everybody's time. I see we've got a few questions on there. So we can get to those. Well, let's give Daniel a round of applause.

All right. So how do you deal with services teams being handed implementation projects, scope, and budgets that don't include task specific for long-term adoption and growth? PS teams can typically only implement what was scoped in the pre-sale cycle. Yeah.

I think that's a good question. I think some of that depends on how your company sells and prices their software, like if there are different modules that are really good for stickiness that aren't being sold. I think the first thought off the top of my head is that I think I would attack that via strategic discussion at the higher levels of your company of how are we selling software? And what do we need to bundle in, either force a bundle or perhaps not charge for because we know what's going to lead to that customer success?

If you're going to have 75% GRR with product A, but if you bundle it with product B, your GRR jumps to 88% or something like that, I think there's an actual calculation to be made there. I think the other thing you can do is you could potentially get started looking for upsell opportunities during that implementation if you're not able to bundle it, et cetera. So I think those are the two things that come to mind. But I think it merits a strategic discussion at your company about how are you bundling and selling your software if you feel like the key features that are going to lead to that renewal and expansion aren't being included in some of your deals.

Yeah, that makes a lot of sense. What are some best practices that you can share for improving handoffs between the various teams, so sales to PS, PS to CSNs? Yep. So one of the things that I do-- I learned this one at Gainsite-- is for the sales to implementation handoff, we always had a section that listed out the customer pain points.

Why did they come to you? Why did they buy the software, et cetera? So we ask-- in my current company, we ask our sales team that. We throw that information on the kickoff deck.

So their first meeting with the implementation team, there's that continuity of this implementation team knows exactly why I bought the software because we heard it from sales. And then we try to keep that top of mind during the implementation. And then in our project closed deck, we have those same pain points. And then we have sections for how we solve them and what the result is.

So we have between two and four weeks of hypercare at my current company. So the idea is that you've been live for two or four weeks if there was a phase two, it's at least two or four weeks since your last launch. And we've got some measurable outcomes. We know some things that have happened because you're using our software.

We've solved these pain points, et cetera. So that's what we do to create the warm handoff between the sales and implementation team. For implementation to CS, I think it's just meeting and having candid discussions about what are the things that you each care about. So I think for implementation, we want to listen to customer success.

And hear about which features are most sticky. If you don't know that at your company, I think that's a problem. And I think you should all be talking about that. I think you should be trying to hand off green and healthy customers to your CS team.

So that means that if you're not getting the daily active users, the monthly active users that you need, that project should probably stay in implementation a little bit longer. And that's kind of what I'm talking about, deprioritizing the potential profitability of a project because you need to stick around for a little bit longer. But let's not throw them over to the CS side where there's fewer services resources to be able to work with them and tweak the product if they're really not ready. Like, why would you throw over something that's going to be a renewal risk and put that on the CS team?

So I think when you do both of those things on the sales side and on the on the CS side, you're trying to create warm handoffs between both teams and putting the customer experience first. I have a follow up. Yeah. Yeah.

Just for the recording, how did you sell that to executives? Yeah. So I mean, so we did this again. So I don't know if you remember that journey.

It was probably 2017, 2018. But I think it's a deliberate decision about understanding what you think-- what your renewal rates are today and what you think they can be if you invest a little bit more. Honestly, it's just a cold hard numbers game, making up numbers here, right? Like, if your GRR is 80%, but you say if our implementations are better, we think that can take it up to 84%.

What's the dollars that are up for renewal next year? Do you believe that's worth it? And do you believe that's worth sacrificing a few hours of services revenue? And I think when you break it down like that, I think, obviously, there's going to be customers that can eat up endless amount of services hours.

Those customers absolutely exist. But there's other customers that just need that little extra push. And those are the customers that I think are worth investing in all day long. Well, also, I think as part of the project that Danielle talked about, we did a lot of investigation into churn reasons.

So why were customers churning and recording that? And we heard time and time again, we never really implemented. We never really finished onboarding. And that was a big reason.

So we could directly tie churn dollars and percentages to the customer's perception that implementation or onboarding was the reason. So then how do we fix that? We have to fix the process or invest. So that's part of it.

I'll get to the AI question, because I know it's top. But I want to continue on this kind of thread of working between teams. So if someone's working in customer success, and we feel like our services team needs to change their approach, how should CS teams approach services about changing their approach? Well, hopefully you have a friendly services leader that spent some time at Gainsight in the CS community.

But I've heard those people can be rare, few, and far between. But let's say you don't have that. I think you've kind of got to go straight to the top. Like, it's got to be a company-wide initiative to say, we care about our customers.

We care about a renewal rate. And everybody plays a part in that. So I think a simple answer to that one. I would go straight to the top and say, this mandate needs to come from the CEO down, that our professional services margins cannot be forcing us into subpar implementations.

All right. So we'll take a little switch here. So what are some ways that you're using AI or want to use AI to accelerate implementations? Yes.

I knew I wouldn't get out of here without talking about AI. Just on the keywords. VP. [INAUDIBLE] Did I get them all?

Yeah. So we've got two main project roles on our implementation projects where I work. We've got engagement managers, project managers, and then we've got implementation engineers who do the technical configs. So for the engagement managers, we've got Cloud Co-Work.

We've got a Gong MCP, a Salesforce MCP, a Rocket Lane MCP, the Google Drive connector, and the Slack connector. So between all of those things, we can do a couple of key things that were really just painful activities for the engagement manager. Or if not painful, let's just say time consuming. So one of them is meeting action items in recap.

So every single time there's a customer meeting-- or I should say in co-work, there's an hourly job for our engagement managers that's looking through Gong for any calls with the customer that happened. And then it's putting a draft in your Gmail drafts that says, summary, action items, et cetera. Every engagement manager can write up their prompt of what they want that email to look like. But it basically runs every hours.

It's looking for calls that are coming into Gong and writing up meeting summary, action items, next steps, due dates, et cetera. And then we require every single one of our engagement managers through a weekly project update. So between looking at all the calls you had for that project in Gong, the Slack channel for the customer, and your emails, which have all your back and forths with that customer, we can have Claude do a first draft of your weekly project update and have that teed up as well. So if you're an engagement manager, if you just go to your Gmail, click on your drafts.

Throughout the day, you should have emails popping up in there that hopefully are just about ready for you to hit send. And then at the end of the week for those Friday project update posts, those should also be pretty much copy and paste ready to put into Rocket Lane as well. On the implementation engineer side, we've got some BMAT agents-- so that's another acronym, if you're not all familiar with-- that can do configurations of our product that are trained in our database of how to configure our product. And basically, through those BMAT agents, you can just communicate to them through your normal Claude interface and tell them, hey, I want to make this change.

I want to do this, et cetera. And it'll make that change to our customer's configuration file for you. So there's some cool stuff we've been doing with AI. AI is the best.

So what resistance did you face when introducing renewal and expansion metrics into the implementation scorecards versus the traditional implementation metrics? And then how did you overcome that? Yeah, the two barriers-- so that's a great question. The two barriers that I faced were two things.

So one, that's just way too much of a lagging metric. Too many other things are happening. Even if we own the customer for the first six months of a 12-month contract, how can we be held responsible for the other six months? What if the CSM is MIA, et cetera?

But I really think that argument can be flipped around as well. Like, if you're a CSM, you're like, how am I held accountable for renewal rates? I was only here for the last six months of this 12-month contract. So it's like, why not hold everybody accountable and be in it together?

I know that sounds way too happy, and it probably is. But I definitely got pushed back that it was too much of a lagging metric. But I think having that perspective that there's not going to be an us versus them. We're all here for the same reason.

I think that's important. And I do think professional services teams should have part of their variable comp beyond renewals and expansions. I also believe in part of the team that I'm responsible for today, part of our variable comp is also based on sales numbers. Because I want them to understand that sales success is our success.

So I think comping your professional services team and their variable comp based on the two other ends of your customers just gets them to realize that we're really all in this together and working together. And then the other barrier I hit, no surprise, was of course just this is going-- this is basically asking for-- some of this is just a little bit maybe focusing on different things during the implementation. But the writing on the wall is clearly that we're probably spending a few more hours on every implementation to make sure that we do it correctly. And that's a bit of an argument as well.

And I think that's very much the math argument that I was talking about, that these hours are either worth it or they aren't. Again, I always go back to if you want to have a faster implementation, you want to spend less hours on implementation, just don't test it. We're not suggesting that either. So why are we suggesting doing poor jobs and implementation, just to say we hand it off sooner?

That's great. So for this comment, this person's company is launching an implementation manager role, which is a huge advancement for them, because CSMs were originally tasked with that. So what advice can this person share back to that newly created role to begin to shape how the role operates? Yeah.

That's a great question. I think, like, super simple answer, what does a successful customer look like at 12 months? What types of things do you want to see them doing? What metrics do you want them to be hitting with your product, et cetera?

Love that. So you emphasized that a great implementation builds stickiness, executive alignment, and change management, not just go live success. So how do you ensure those durable implementation behaviors happen consistently across the team, rather than only with your most experienced team members? Yeah.

So I think there's a few different ways that you can do it. But I think-- and I've tried a couple of different ways at different companies. But I think the best way to do it is probably just to be able to score every project, the same way that you have dashboards as a CSM of your customers and what features are they using, how many percentage of daily or monthly active users, et cetera. If you can set those up and either have people's variable comp tied to those, or you can say, look, a project simply cannot close until we have x metric, and then hold your teams accountable to get those metrics.

Obviously, if there's some exception, an implementation manager can always raise their hand and say, look, we can't get this customer to do these things. I can't hold on to this project for a year. What do we want to do about it? But I think, generally speaking, I would assume a lot of people in this room are leaders of different functions.

As leaders, we can set the metrics and the rules, guidelines, frameworks for our teams to be operating under. And usually, those are the exception, not the rule. Yes, absolutely. Hopefully.

So if PS surveys, post-project surveys, are positive at Go Live, but then a customer ends up not being successful in the long run, how do you reconcile that? Sorry, which question is that? It ended up at the very bottom. Got switched.

OK. PS surveys are positive at Go Live, not being successful? That's a great question. I mean, I think that goes back to some of what you were saying that we did at Gainsight, is we started asking customers.

So yeah, I mean, I think, obviously, our best case scenario as leaders is that the picture is crystal clear to us based on data. Sometimes it isn't. And when it isn't, I think that's when it requires a little bit more subjectivity and digging into it. Maybe you can get some of that through surveys with open-ended questions.

Maybe you need to be talking with customers a little bit more, talking with your CSM team who is talking with customers. So yeah, I think the first thing I would do is just humbly ask questions to people at the company, as well as the customers, and see why we think that might be. Ask your customers who are churning why they're churning. Well, there was a good question, and then it disappeared.

That's one. What are your best practices for handling sales commitments and then downstream customer expectations that are voiced in onboarding that don't line up with their current product capabilities when sales potentially overpromises? That sounds like a made-up-- Yeah, it sounds like a made-up problem. Customer misunderstood.

Yeah, I mean, this is like the bane of my existence right now. So this is-- Mine too. Yeah, thank you. We should have a drink afterwards.

There will be a reception. Yeah. Yeah, this is really hard. I mean, I was actually-- I was just talking with our CS leader last night about this on Slack.

And the best solution-- I'm hesitating because I don't have a perfect answer here. This just sucks if we're being honest. So what we agreed to do to start off with is at least-- our job is at least to keep the customer warm, let them know we care, let them know these feature requests are in our backlog. While there isn't a CSM, during onboarding, do our best to advocate for them.

And then make sure-- the critical step is make sure those are part of the handoff. If the customer has to re-explain themselves to the CSM, or if the customer has been passed off to the CSM for four months, and they're like, wait, you haven't been keeping track of our request for the past four months? You haven't been harassing product, et cetera? I think that's a problem.

So I think we're just trying to keep the customer as warm as possible. I know that's not a great answer. It's a really difficult problem. How does your implementation group track post-implementation customer health?

I think we have a little bit of an atypical product for this at my current company. But a lot of our metrics are based on loans and deposits that are opened at the credit union. So we have some good analytical dashboards that'll show us how many loans were opened at the credit union over a given day, week, month, et cetera, as well as how many deposit accounts, checking, and savings accounts were opened. We make sure during implementation-- so we have visibility to that once they're on our platform, obviously.

But what we don't have is information on how that was on their previous platform. So one of the things we make sure and do a real customer success activity that we do during our implementation is ask for their before metrics and then log it down. And we do that so we can show them the growth and the change in these once they're live on our platform. Kind of answers that second question.

Sales doesn't get those metrics. You guys are asking for them when you're working with them in the project. We could maybe ask sales. It's just easier for-- I'm sure you all know here, post sales group.

It's just easier to ask the customer ourselves. That's a quick question. We'll finish on this one because I know there was a reception for everyone to get to. So what do you think are the most critical components of a CS and PS relationship during and then post implementation?

I'm going to give maybe like an atypical answer to this. And it comes from my time at Gainsite. It's all about people and relationships. It really is.

I can talk about business outcomes and drawing clear expectations and swim lanes and things like that. I really think a lot of it comes down to relationships and trust. So I have this amazing relationship with our director of sales engineering. He's on the pre-sales side.

And the reason we have such a great relationship is because there's a dividing line between sales and implementation. And I'm willing to go 20 feet over that line to the sales side to say, how can I help? Do you need me to join a call with the prospect? Do you need some collateral and materials to help close this deal, et cetera?

And he's willing to go 20 feet over to the implementation side when there is a question about what was or wasn't in the SOW, what was said pre-sales on a call. He'll join our calls. So the best cross-functional relationships I've ever had with other leaders are ones where we're not having fighting matches over where the line is and who had to step over it and then getting bitter about it. We're just all in this together.

And I know that sounds very happy-go-lucky. But I promise it works. And when you spend time building-- sorry, I feel like I'm lecturing people. When you spend time building relationships and trust with people, you trust that somebody is coming to you with good intentions.

You trust they did their due diligence. And you know that when you're going to have to ask them to cross the line for you to give a helping hand, that they're going to be willing to do it. So yeah, so I mean, again, if you want the swim lanes answer, like create swim lanes and policies and procedures. But I really believe it boils down to people relationships.

Yeah, I like that. Willing to cross the line. That's awesome. We'll finish there.

Thank you, everyone, for coming. Thank you all so much. Please, for all of the sessions you attended, feel free to leave feedback on the session by hitting survey within that session on your agenda. The speakers would love to see that feedback.

And we do have a reception out in the main corridor area. So please go enjoy. Continue to make connections. Continue the conversations on LinkedIn and GameSight community.

And thank you so much. This has been a wonderful pulse. Safe travels home, everyone. Thank you.

Thank you, Emily. [APPLAUSE]