Redesign First, Automate Second: How CS Leaders Build an AI-Native Team That Retains

[Speaker 3]
Spring, a time of renewal.

[Speaker 1]
Yes, I know it's October, don't worry, this is a flashback. Please continue.

[Speaker 3]
Spring, a time of renewal. The grass greens, the birds return, and somewhere, a homeowner is about to turn on their sprinklers for the first time in months. Meet Kate.

She runs a landscaping business.

[Speaker 1]
That's me. You're probably wondering how I got here. Well, long before B2B SaaS, startups, or AI, I ran a landscaping company.

That's right, I mowed your yard, lawn, garden, got there. Every spring, I'd get the same call dozens of times. My sprinklers are broken.

So I'd grab my clipboard and go check out the controller. Everything looks well, so I head to the front lawn to get a look. Oh my, expected delivery, terrible outcome.

But hey, it's a water feature, not a bug, right? If you work in customer success, you would have closed this ticket while your customer front crawls to check their post. In the end, we didn't buy a single new sprinkler head.

We moved dirt. Nobody posts photos of the dirty work, but it's the part that matters the most. Fast forward to today, new desk, nicer clothes, same phone call.

This time, I'm not checking the controller. Let's go look at the lawn. Today, I'll show you how to get AI to grow retention instead of building a water feature.

Let's dig in. I've watched a lot of CS teams do this. They spend months choosing the best sprinkler heads.

The demo is gorgeous. The pilot gets approved. Rollout happens, and the dashboards tell you everything's fine.

Then a few months in, someone says the AI isn't working. Except it is. It's doing exactly what the work underneath, the grade, told it to do.

Almost nobody spends time on the grade. Why would they? It's not in the vendor demo.

It's not on anyone's roadmap. It doesn't come with a launch date. Frankly, it's just not sexy.

When I looked at the sprinkler controller, every zone was green. It ran on the right schedule, delivered the water that it said it would. The job was done, but the lawn was underwater.

Your AI scoreboard is that controller. We've gotten very good at measuring whether AI, and humans for that matter, is busy. But busy isn't a customer outcome.

If busy secured renewals, we wouldn't all be here together learning how to execute and deliver customer success better. For most of us, if we put the scoreboard next to the retention number and try to draw a straight line between the two, we can't. It's not because the AI isn't working.

It's because nobody designed it to connect to the actual outcome that we measure. A better dashboard won't fix that. It'll just give you a better view of the pond.

What does fix it? It's the work, not the tools. A few minutes ago, I promised to show you how to get AI to grow retention instead of building a water feature.

This is at a high level the how. Three moves in order. First, we change what the work is starting from the desired customer outcome instead of a 2015 workflow that we inherited.

Second, we decide who, or what, executes each step and what triggers the action. And third, we look at how that changes the role of our CSMs and how we measure them moving forward. Each one depends on the one before it.

You can't assign work if you haven't redesigned. You can't redefine a role if you don't know what's left for the human. These are the questions that I want you to sit with.

By the end of the session, we'll have an answer for all three. I'm gonna present these a little out of order, however, because our executors become an important factor in how and what we design. So let's establish who our executors are.

Now, only two of these are newish to our toolkit. We've had people, automation, and digital programs for years. What's changed is how much more we can do with these old three and that we now have two new ones to choose from.

A person is who you want when somebody has to own the call, put their name on something, or sit across from an upset customer. AI can draft the strategy, but it can't be accountable for it. Automation is my sprinkler controller.

It did exactly what it was told on a schedule every single time, and it never once asked whether the lawn was underwater. You own plenty of these already today. It's the alert that is created after usage drops.

Digital used to be the newsletter and email campaign segment, but now with AI behind it, each customer can get something different, something personalized. So it's not just a channel. It's also how the other executors reach your customer.

Now on to the AI layer. One question I get asked all the time is, when to use a skill and when to use an agent? A skill is a work order.

You tell it to read an account's last 90 days, write the briefing, and it does it the same way every time. An agent is your crew lead. You don't hand a work order over.

You say, get this lawn ready for spring, and she'll work out what to do and who does it. In CS, that's asking whether an account is in trouble and letting it decide what to look at, follow what it finds, and tell you when a person needs to step in. A skill is predictable.

An agent is more capable but riskier, and that's why you want to tell it what's off limits, and we'll get deeper into both in a moment. Well, we need to ask two questions for every step in any given motion in the customer journey. Who does it and what starts it?

Let's look at who first. So this is a decision tree that you can use to determine what executor should take an action. You want to start at the top and stop at the first yes.

So let's take one risk signal as an example. Your customer goes dark. They haven't reached out to you in a set number of days.

Maybe for your top accounts, that's 30 days, and long tail, it's 90. If it's your biggest account, that signal goes to a person. Is this a quiet champion?

A lost sponsor? Do you call? Does your exec?

That takes judgment and someone who will be held accountable. So first yes, a human does it. If it's one of your 2,000 smaller accounts, nobody is making that call 2,000 times.

The signal goes into a system, and the system sends each customer the message that fits them. One bought a module that they haven't turned on. Another hasn't logged in since our last release.

Same signal, appropriate action taken, no extra head count required. That's the digital layer. The rest of the list works in the same way.

If fixed rules can do it with nothing to read or write, that's a plain automation. Flag the account, create the task. That can handle anything repeatable.

Everything that needs AI splits into one of two directions. Can you list the steps? If so, that's a skill.

If not, that's an agent. Once you land on an executor, you decide how that message reaches the customer. What channel is it delivered on?

In a meeting? With a human? When the stakes are high or judgment is required?

Or the digital layer when you need to scale with personalization? By the way, if your agent is talking to your customers, that's the digital layer, and I'd want to know exactly what it's saying and who's checking on it and validating the outputs. So that's who.

Who takes the action? Let's look at what started this. In our example, the account went quiet.

So let's look at the what. What starts it? For most CS teams, historically, this has been a person or a calendar.

Somebody notices something when they next look at the account, or it's a monthly check-in or a QBR, or you're 180 days out from renewal and the static playbook kicks in. The trouble is that your customer is not reading your calendar. An account can start drifting the day after your check-in, and you may not notice that until the next one.

By then, the problem is a month old. In my landscaping days, most sprinkler controllers ran on a timer, 5 a.m., on whether it had rained all night or not. A moisture sensor waters when the soil needs it.

Same sprinklers, different trigger, very different lawn. And that's the shift. A signal starts to step when something actually happens.

A ticket escalates. A rule trips, like the account that's gone dark. Or your intelligence layer picks up on a pattern across emails, calls, and tickets that no one person has the time to read.

In fact, as you begin to implement more intelligent triggers and motions, that's one measure that I'd pay attention to, is are we able to increase the average days between first signal and renewal? People and schedules don't go away. They just happen a little bit less often.

A schedule is still fine for internal routine work. What you don't want is those important customer moments waiting on either one of those. And whatever starts a step doesn't decide who does it.

A signal can kick off an action done by a person, a skill, an agent, and so can a schedule. Trigger and executor are two separate choices, and we want to make each one for every step in our motion, and oftentimes for every customer segment as well. So one question I hear often from customers is, what is the difference between a skill and an agent, and when do I use which?

So let's look at two examples. I'll show you a skill that I run myself and an agent that we build for customers. This is a skill I built for myself.

I did put it on a scheduled automation so I don't have to manually call it every time I need it. Instead, every weekday morning, it checks my calendar for tomorrow's customer calls, and by the time I open my inbox, there's a brief for each one already there, giving me time to prepare as well as maintain good customer-facing email hygiene. People ask me, isn't a skill just a saved prompt?

A prompt is what I would yell out to a new crew member from the truck window. Do this now. It works once and only as well as I've explained it that day.

A skill is the work order on a clipboard. The steps are written down in order with what the crew needs to know, what they're allowed to use in terms of equipment. Anybody can pick it up and follow the same steps to the desired outcome.

That's what's on the left, the steps that I wrote down. Check the calendar for customer-facing meetings. Collect the appropriate client data and the meeting using the tools that it can reach.

For me, that's GainSite, Staircase, my calendar, Slack. By the way, the connections between the LLM and the tools that I regularly use run through something called an MCP, or Model Context Protocol. Think of a wall outlet and a lamp.

The power is in the wall. The lamp is perfectly good, but neither does anything until you plug one into the other. So your LLM is the lamp.

GainSite is the wall full of what the AI needs. That MCP is the plug. And it's a standard plug, so it can fit any tool that works with an MCP system.

One difference from this lamp is that that plug carries traffic or data and context in both directions. So the AI asks a question. The system sends the appropriate data and context.

And then the AI is able to make a suggestion or craft a plan, and you can write that back into your system of record. When my skill runs every day, out comes a brief in the same shape every time. Same work order, different long.

The trigger is the schedule. That's the internal routine work that I mentioned that we still have schedules for. It never takes the call for me.

It drafts an email to the customer. It waits in my inbox, and then I decide. The skill prepares, I decide.

Notice what made this a skill. I was able to write down every step before it started. Skills handle repeatable steps that you've already designed.

Let's look at an agent next. So my last slide, the skill ran in a straight line. Same steps, same order, every time.

An agent runs in a loop. Look at the account, decide what it wants to do, do that, check what happened, and go around again. If a skill is a work order, that agent is your crew lead.

You don't hand that crew lead a list of steps. You just hand them the job, and then what they can spend without your approval, and things that they must never do, and then you trust them to figure out the rest. So this slide shows a very simplified version of an agent that we build for customers called Atlas.

Its job is to secure customer renewals, usually within your long tail segment. So when it's triggered by a signal, or because it's a renewal, a calendar event, it assesses the account and the detail that's relevant to the renewal. Then it uses that to formulate a strategy, including identifying who to contact, and what channels of communication that person prefers, call, email, et cetera.

It contacts the customer and continues to follow up until it reaches them. Once it reaches them, it works to close the renewal on its own, or it identifies a point of escalation, and it'll hand it off to the human in the loop to close that last mile. So same general renewal process every time, but not the same moves to get there.

I couldn't always write those steps out in advance because the next step depends on what happened in the last one. That's why it needs guardrails instead of a checklist, a discount that it can't go past, the account that it never touches, contracts that it isn't allowed to write. Hit one of those, or sentiment drops, or a customer asks to downsell, and that's your escalation point.

Now when I want to say, when I said before I want to know who's checking, this is where that matters. Someone needs to own the outcomes of the agent and then regularly check it, not just to fix things, but also to learn and iterate, and everything is up for grabs. The guardrails, the handoff rules, the script, the goal, the tools that it can reach, what accounts that it covers, and when it starts.

Sometimes the fix isn't the agent at all, it's the process, which is that redesign part. Use a skill when you can write the steps. Use an agent when the next step depends on what it finds in the step prior.

This is an example of a champion leaving, and this is how a lot of account risks get handled today or in legacy CS. Some of this made sense when it was built. With no signal feed, a CSM noticing was the signal.

With a monthly meeting, the meeting was the decision process. Nobody designed it to be slow intentionally, they designed it around what we had. But look at what's underneath each step.

No feed, so you find it by luck. A calendar, so it waits for the next meeting. Manual entries, so someone has to go type it in.

One inbox, so it depends on who's in the office. And a QBR cycle, so the recovery waits for the next quarter. Four handoffs between the champion leaving and the customer hearing from us.

Each one depended on somebody's calendar. It's that sprinkler timer, right? It runs whether the lawn needs it or is already a pond, because it was never built to know what the lawn is doing.

And some of these limits go back to 2009. Now we have AI. So what do I see most teams doing?

They layer AI over an existing workflow and call it a day. And to be fair, this does help speed things up, creates more efficiencies. It summarizes the call, so nobody has to re-watch a recording or furiously take notes while you're trying to pay attention in a call.

It summarizes the risk, creates a CTA, drafts the email, prepares the QBR deck. Every step gets faster. But let's look at what happens in between these steps.

The handoffs, the waiting. Did any of that change? The champion still leaves on day one.

We still find out when someone happens to notice. The waiting's still for the monthly review. It still goes out from one inbox, and it still lands at the next QBR.

It's the same four handoffs and same four waits. That's a nicer nozzle with the same timer. So it sprays better, but it's still on a timer.

It's actually unaware of the status of the lawn. This is our earlier slide again. Better sprinkler heads, same old grade.

The scoreboard says we're faster, but the customer experience hasn't changed, so the retention doesn't either. AI speeds up the steps, but it never asks whether this should be the process and what should start it, and that's the question that's usually skipped. So if we look at the legacy workflow, someone noticed something, so they raised it.

So someone created a CTA, so someone sent an email. Each step was designed from the one before it. A proper redesign flips that.

You start with the outcome, and you ask what has to be true one step back at a time? So each step has to earn its place by serving the next one. So the outcome is the customer renews.

What has to be true for that? They need to see the value that we deliver and not from the person who left. So they need to be reached by the right person with the message that fits them.

Someone has to decide who that person is, and that answer is usually already in the account, the people showing up to calls, opening emails, using the product. And before any of that, we have to know that the champion left. So I've tagged each one of these sense, decide, act, deliver.

Almost every step in a workflow is one of these four, and hold on to that, because we'll come back to it shortly. So notice that we haven't mentioned a tool, a CSM, or AI yet. That's on purpose.

We want to decide what must be true first, and then who or what does it comes later. And when you work backward, the champion leaving stops becoming a problem and starts becoming the starting point. That last slide gave us a destination.

This is how we get there. Most teams ask one question when they look at a workflow. What can AI do for this step?

But that's only part of the new picture. I use four questions with CS teams in an AI first motion redesign workshop that I run. I call it gain, and it's the same four questions in order.

Grasp, what can we see now that we couldn't see before in terms of signals? If we skip that, we're just automating a guess. Adapt, what could AI take over completely?

That's, again, the question most teams start and stop with. Innovate, what becomes possible once the old constraints are gone? That's the proactive, personal work that nobody ever has the capacity to do.

And then narrow, what can we stop doing completely? Remember the four weights on the last workflow? Faster steps, same weighting.

Narrow is how we stop speeding up the weight and start removing it. If we skip that, again, we're just doing a quicker version of what shouldn't exist in the first place. So it's these same four questions for every step, every time.

So this is that workflow redesign version. It's the same five steps built backward from that renewal. And count how many of them are automation.

One, route. The CTA still exists because that's how we check whether what we did worked or not, but it creates updates and closes by itself. Everything else is redesigned.

So detect, we don't wait for somebody to notice. The signal does. Decide, the answer is already in the account.

It's the people showing up. Deliver, the message is about value that we deliver to the new person, not a check-in. And the relationship starts long before the QBR, so that stops becoming the rescue.

That's the title of this talk, right? We didn't add AI to the old workflow. We redesigned it.

And the AI tool, the AI took one step that's actually repetitive. The CSM is still in here. We just haven't said where yet.

The sprinkler timer ran at 5 a.m., whether the lawn needed the water or not. This is your moisture sensor. The champion changes, the signal fires, and everything starts that day, not on the next cycle.

So remember the five executors? Here they are in one workflow. Skill and agent are AI by definition.

The little spark indicator means that AI helped with the work or created the content. Look at what starts it. Nobody is designed to detect.

It's the trigger, an AI-detected signal, right? We get an email for a personnel change. We see an email signature title change.

There's a change on LinkedIn. And that's where it's the same step for every account but a different outcome. And after that, the one automation step is our CTA.

The rest is people or the digital layer with a skill or an agent where the work needs reading or deciding. One workflow chained across executors and the chain changes by customer tier. And the tier shouldn't be fixed or static.

I think in our new world, a signal or a pattern can move an account up or down the tier hierarchy as things change. So as you can see, this does sort of break our current model of CSM to account ratios. Ultimately, part of this transformation is that we're reassessing what the role of the CSM looks like and how we measure them.

So for a long time, the math in customer success was a human, a calendar, and a book of accounts. If you wanted to cover more accounts, you added more humans. That was our ceiling.

Every account needed a named person, so we only grew coverage by adding people. And that constraint is now gone. We can have different customers with different kinds of coverage, not the same coverage just spread thinner across those accounts.

Some keep a dedicated person, some move to a pooled model, and some are served by the digital layer with a person coming in where it matters. And so if the coverage model changes, then the role changes with it. Running a pooled team or a bigger enterprise book or the escalation path for a digital layer is a different job than the one most of us were hired or did hire for.

And so eventually, that has to change who we hire. So let's take a look at the CSM role and what specifically is changing. Now, I called this slide the great bifurcation, but really it's just a fancy way for something simple, which is that the CSM role is splitting into two.

I built CS teams at four different companies, and at every one, the job description was the same. Relationship manager, renewal owner, product expert, all in one person. We call it a CSM, but really it was just five jobs stacked on top of each other in a trench coat.

And if we're honest with ourselves, that generalist approach didn't yield the business results that we intended. And so when you shove so many jobs into one role, people get spread thin, so they default to whatever is urgent. That's the support backfill, the tickets, check-in calls with the end users who are easy to reach.

Meanwhile, our decision makers and executive sponsors, the people who actually sign the renewal and hold the budget, hear from us once a year, maybe. Everyone was busy, but again, busy is not the same as moving the business. AI exposed that.

It took the tasks that CSMs were busy with and automated them or made them faster. Notes, summaries, health checks, follow-ups. And when those tasks go away, what's left is the question, what the heck is the job then?

So we have to reinvent the role and prove it out. Prove that CS is not a cost center that keeps customers happy. It's a team that retains and grows revenue.

And as you've seen, you can't do this effectively with a generalist. So we stop asking one person to be everything and we split the role into two distinct buckets, commercial and technical. That goes back to our green scoreboard, right?

The AI was winning, but the retention was flat. Our CSM scoreboard has the same problem. Calls logged, QBRs held, success plans created.

All of that matters or measures how busy we were, not what the customer did or achieved. And that makes sense because the old way, the old role did everything. We counted the activity that we could and we hoped for the best.

Once the role splits, we can finally be specific. A commercial CSM is accountable for what comes of the renewal and the expansion motions. A technical CSM is accountable for whether the customer is actually getting the value from the product.

Different jobs, different scoreboards. Now, I know what some of you are thinking. CSMs don't control everything that impacts retention.

Neither does sales control everything that impacts a deal. That's the game. And ownership changes what a CSM can do with it.

A CSM that owns a revenue number can walk into a product team with real dollars at risk and a business case. That often gets more traction than my customers are complaining. If it's a dedicated book, the number is theirs.

If it's a pooled team, the number is the team's. Decide that up front because individual goals on a shared book are the fastest way to unpool a team. And yes, this does mean comp.

If we score CSMs on outcomes, then we need to pay and incentivize them on the outcomes the way we do with sales, not the activities. Both roles share one new number, and that's how fast a signal turns into action. That becomes our leading metric that will tell us whether AI is changing how we operate or just generating alerts.

As we redefine the role, there's a core set of skills that both of these roles need. Our new CSM measures call for outcomes. To hit them, both roles need the same base.

Start with AI literacy. That's an agent flagging a risk on the account. Can your CSM read it, work out whether it's right, and decide what to do about it?

Not can they use chat GPT, but can they act on the signal? Workflow thinking and supervising digital team members, those are the things that we've been watching kind of in action over the last few slides. The one I'd hire for first is strategic thinking.

AI took the tasks. What's left is the judgment, and that's the part that we never really hired for on purpose. A customer says, I want feature X.

An old CSM logs a request. A strategic CSM asks, what are you actually trying to do? Because half the time there's a better way to do it, or they shouldn't even be doing it at all.

That deflects the request, saves the product team's time, and builds trust all at the same time. Both roles need this, just pointed at different people. Here's the practical move.

Look at your team and assess who's already leaning commercial and who's already leaning technical. Most people have a lean, even in a generalist role. Then ask, who already has the shared core?

Some of it you can train. I think strategic thinking is probably the hardest to teach, which is why it changes the hiring profile. Not just great with customers, but can work with AI.

Let's bring it all together. At the start, I gave you three questions. What should the work be?

Whatever gets the outcome, not what the old steps happen to be. Who or what does each step? Choose the executor on purpose, and let the signal start it, rather than someone's memory or calendar.

What do your CSMs do now? Two roles, scored on what the customer got, not how busy they were. Notice the order.

Redesign, assign, redefine. If you skip to the tools, you've just built a faster version of the old workflow. You'll get the same results faster.

If you want different results, it starts with a decision. What do you do with this on Monday morning? One thing.

If you're a nerd like me, here's your homework. You will get this deck to get a start on it, but this will help you begin the AI transformation of your CS team and operating model. Pick one retention workflow, not a tool or a pilot or a vendor demo.

A workflow where you say, it's complicated when a new hire asks, why does it work this way? Start with the outcome you want, and then work back who and what does each step, and what triggers it. If you can't fill it in, you weren't ready to automate it.

If you can, you already know what to build. So this is again the homework that nobody grades, but it's exactly why things work. Because before you plant anything, you grade the ground.

Which brings me back to the yard lawn garden. Same sprinklers, same pipes. We didn't buy a single thing.

We moved dirt. The sailboat is landlocked, the duck has questions, but the water is finally where it belongs. Grade, pipe, heads.

In our world, redesign the work, assign it to the right executor, and only then bring in the tools. Thank you so much. I'd love to use the rest of the time to answer any questions, but before we do that, just a quick plug.

Our advisory services team loves to work with customers through the CS and AI transformation. So if anything that I talked about today has you interested in working with us, please grab the QR code for our intake form, and I'll follow up with you after I eat and theater my way through London. Questions?

[Speaker 2]
Cool. Thanks, Kate, for such a great session. Yeah, let's jump straight into the questions.

Cool. First up, so if we redesign the way we measure CSM work, how will that look in 12 months? Will there be different KPIs?

[Speaker 1]
Yeah, I think definitely, right? A lot of what we're measuring CSMs on today are those activity measures. What we want to move them to is measuring them on the outcomes.

Now, the outcomes are going to be your lagging indicators, so we still do pay attention and measure those leading indicators or the activities to make sure that we're on track to get to impacting those lagging metrics, but really we want to hold them accountable to things like GRR and NRR because ultimately that's what the business needs to move.

[Speaker 2]
Great. Next up, if AI eliminates steps rather than simply accelerating them, how should we rethink success metrics beyond efficiency and productivity?

[Speaker 1]
Yeah, I mean, again, I think it comes down to what is the human doing that's driving the outcome that we want, not are they doing X number of meetings or X number of QBRs, but how many CSQLs are they opening? What is the close one rate of those CSQLs? We want to make sure that we're making them more efficient and productive, but what matters more is how they fill the time that we've freed up for them by taking away some of those tasks.

[Speaker 2]
Nice. Do you think AM teams will disappear if CSMs run renewals and expansions?

[Speaker 1]
I mean, I think that's going to be a per company decision, right? We may have CSMs delivering CSQLs to your account manager or your cam team, or if you've got the right people in place, you can have them fully own those numbers in that process.

[Speaker 2]
Great. And how do you think QBRs will change in the world of AI for CSMs?

[Speaker 1]
Oh, man, I have a lot of thoughts on this. So I think QBRs have kind of always needed a revamp. Most of the ones that I've experienced throughout my career feel more like a vendor demo pitch, or they feel like you're going in there to prove value.

I personally don't think it's ever great to go into a QBR from a defensive position, right? We should already have the value secured, communicated, the customer aligned to that. In my mind, the QBR is a lever for continuous discovery with the key decision makers and budget holders of the accounts.

I think we all know right now that our goals are changing and shifting. The things that we're focusing on, our pricing models, how we deliver work, like everything is changing. That's true for your customers, too.

And so what becomes gold for you is having that conversation with that customer, getting that into your context and data layer so that the AI can help you craft an update to your success plan or craft a strategy on how do we get the customer from the conversation that we just had and their desired outcomes to on the next QBR, we're reviewing the results of that work, iterating on it together, and then restarting that cycle together. So I think it's not just AI that's forcing that change.

I think we need to force that change on ourselves because it hasn't always been the best thing to do in the way that we've delivered them, but I think AI helps us by keeping that context layer so we can continue the conversation with the customer and continue to grow and build and ideally expand that account.

[Speaker 2]
Yeah, great question. How would you split your CS team into commercial versus technical CSMs?

[Speaker 1]
Yeah, I mean, there's going to be some math there, right, depending on the number of CSMs, the number of accounts that you have, but I think in a practical term, when you're looking at your team, you want to start assessing who has a lean either way, right? Some CSMs are much better at kind of ferreting out expansion opportunities or having those conversations or connecting with customers at the right level of the customer hierarchy, and some CSMs are better with the product, right? They're deep product experts.

They can hop on a call with a customer. The customer says, I want to do X, Y, Z, and they can tell you, here's exactly how you get from point A to point B. So I would do a skills assessment on your team.

I'd also keep in mind that shared core so that you can kind of understand not just where the lean is on one of your CSMs but also where they are on that core skill set, and then you can start to work through how do we upskill them and uplevel them on the areas where there's some deficiency.

[Speaker 2]
Great, and if account management holds the commercial side of the relationship, is the technical role that's left for the CSM?

[Speaker 1]
I mean, listen, I think the technical part is important. So is still the relationship part. So is the judgment part, right?

Those things don't go away. Those are still very important, right? Good with customers, making sure they're happy and successful, that's all still, it's not going to leave the CSM.

So I think both of those roles will attack those just at different levels of the customer hierarchy.

[Speaker 2]
Nice. And when AI agents and humans contribute to the same customer outcome, how are you measuring the individual impacts and determine what's actually driving the improvements?

[Speaker 1]
Yeah, I mean, so typically they're going to, if the AI is trying to achieve an outcome and your human is trying to achieve an outcome, they're probably operating at different customer segmentation, right? Like usually we're going to employ an agent to be autonomous at the long tail layer so we can kind of separate that, right? We've got the long tail segment, the actions that the agent is taking and what are the outcomes, and then we can redefine and iterate that.

And then if we move up that hierarchy chain, the AI is augmenting the human, but the human is taking the action. The AI is going to draft the strategy, the human refines it, owns it, and executes it. So I think there's a way to kind of separate the two.

[Speaker 2]
Nice. I think we can squeeze in one or two more here.

[Speaker 1]
Yeah.

[Speaker 2]
If every customer requires both commercial ownership and technical adoption support, how do you see this model scaling operationally without duplicating resources or fragmenting account ownership?

[Speaker 1]
I mean, so every customer requires, you know, some sort of commercial attention and some sort of technical attention. And so when we talk about scaling the model, again, that's going to kind of come down to what are the different segmentations of our customers and then who is the executor of the action. So we've got a customer lifecycle that's probably fairly similar for every customer.

And then again, as we move up and down that chain, we're kind of pursuing the same outcomes. We're just using a different executor and a different channel. And so I think clearly defining those roles and swim lanes, the outcomes from each, the metrics that we're tracking from both a lagging and a leading framework is kind of how you help separate that and measure on the two distinctions.

[Speaker 2]
Last one here. In the enterprise group for this example, what is the ratio of commercial to technical CSMs? Do they share the same portfolio and how do you ensure they are accountable for the same customer outcomes and workflows?

[Speaker 1]
Yeah, I think, again, I think it'll depend on your company, how many accounts you have, how many CSMs, which ones lean more technical or not. I think I'm really interested in what I call the idea of strike teams, where we have maybe product-specific, especially if you have multiple products in your suite that customers use, have product-specific strike teams that can kind of come in when that action is needed. So at the enterprise level, if we get an adoption signal that requires action, that goes to the appropriate strike team for that product.

They step in, kind of handle that. So they're probably going to have more accounts, but it's more of a come in at a project-based level as opposed to the commercial CSM that probably still has a named account, a named book of accounts.

[Speaker 2]
Right. I think that's about all we've got time for, so thanks again for a great session, Kate. Let's please give Kate one last round of applause.

[Speaker 1]
Thank you all.