00:00 Hello, my customers success friends, e-read e-zits here for yet another episode of CSM Practice podcast where have amazing people coming in to talk about what they do.
00:13 And I don't think I've ever had a podcast episode inviting a CS ops manager to showcase what the hell is this functional about?
00:24 What do they do? How do they measure success? Lessons learn. I mean, we today got Ben Crafting, who's been doing CSOs for quite some time to tell us what works and what doesn't, too, and kind of lessons learned.
00:36 So I'm super excited about this session today. Hey Ben, thanks for joining our show today. And thank you so much for taking the time.
00:45 It's been very thoughtful to do the prep for this interview today. Thanks, great to be here. What type of professions should one hire from into their CSOPS team if they do want to hire people that don't have CSOPS experience per se?
01:00 When you look at resumes, what are you kind of like the jobs that you're hoping to have found there for you to join your team?
01:07 You see a lot of variety, especially now, as CSOPS is becoming prevalent across different industries. Analyst roles where you might have been doing testing, where you might have been doing some sort of product work around an enhancement requirements and then validation with stakeholders.
01:27 And then the outcomes that you're able to reach with those things are some of the behavioral skills and behavioral questions are probably ask of those candidates.
01:36 I think the idea of working with ambiguity, seeking out the detail, and those roles, you can see it in financial analyst roles as well.
01:46 That could also potentially be an area where someone could make a good transition, looking at a lot of financial data, where you might be building financial reports from the spirit data sources, that would give you the skills to also look at the problems being presented.
02:02 And then also being able to apply problem-solving, new, unfamiliar concepts. Having that curiosity, hey, I don't necessarily understand what we might be talking about.
02:16 But I googled it, I watched 10 YouTube videos. That tenacity that desire to learn is also going to be one of the most desired skills I would look for.
02:27 And I think, again, it's especially helpful if you have a lower maturity product, lower maturity organization, you will see your teams aim to rely on that far more.
02:36 Very interesting career path for yourself today, you work at CRB. Tell me a little bit about what type of clients those CRB has that your customer success managers work with and then who are your clients?
02:49 So CRB is a thin tech bank and we work with partners to enable financial solutions for their platforms. So that might be payments, it might be lending, and then enabling those platforms, which you might experience through an app, you might experience through a website to connect the value that they offer
03:06 you to your financial instruments bank accounts credit cards, etc. We mostly interact with the customers that own those platforms, and their team supporting the financial integrations on those platforms.
03:18 We have a relationship management team across our products and those teams are working day to day with their peers and counterparts in both technology and on the financial side with our partners.
03:31 And then my team is working with those relationship managers interacting with our partners to support them with the outcomes that they need to solve problems for our partners.
03:42 So, they are on the receiving end of a lot of the requests that come in, ensuring that we reach outcomes that are beneficial for our customers and address their needs, and then providing feedback holistically across the whole set of question inquiries needs gaps that come up to help us be a better organization
03:59 with both our product and also how we work together cross function. Don't per se have CSMs, you call them relationship managers.
04:07 They work with the business lead as well as the technical lead at the client side, which is typically a financial institution.
04:14 And I feel like the product is a set of tools together, make up a solution to a business lead that the client has.
04:23 And your value prop is that you can architect the right solution and customize it to the financial institute's needs, versus selling a specific product with a finite set of features.
04:36 Would that be a true statement? Correct. So we do consultative selling. A lot of our solutions may be a combination of different things.
04:45 Those things are, they might be lending products, they might be credit card products, and they might be deposit accounts or payment rails.
04:54 Those things can all be connected in different ways, so that you can solve the specific business problem on your platform that your end customers need.
05:03 The partner manager of the relationship manager is actually bringing in as many resources as he needs internally. They might have solution architect or whatever that they work in in a pod whenever a request is being received.
05:16 But from what I understood, your team has a big part and collecting these requests and working with product to enable the product.
05:26 So what you do when you start working across the different customers in different products is you start to see the themes of either customer requests that perhaps those things are data aggregation, data analysis that could be self-service surface in a different way with a product or offering that brings
05:48 those things together. You also start to see, hey, how could these requests be product enabled? If these items were surfaced or felt taught in a way or walked through within the product, would customers need to reach out and have these requests in the meantime, then how do you get those requests internally
06:12 back to product, get them prioritized and put them back log for grooming, so that they become a reality. That's one aspect that we work with.
06:20 Also, the analytics all across the organization, where are the trends in our requests and why? So, how do you then see those proactive, again, in front of them, so that you can now have a quantitative discussion with your relationship?
06:34 Hey, we see this many of this. This many of this probably means that this many people are working out. This means this many people need it.
06:41 This now allows us to say, even using back of a napkin math. What is the dollar impact of this? What is the value that it has to offer if we address it?
06:50 And then how will we make it a reality in when? Becomes the open question that you can ask the product teams.
06:57 And then it's also where you're the connection between the relationship management side of the success side in the field. Hey, we've heard you.
07:04 And here's what we're doing. And here's how it is going to fit into our roadmap. We talk a lot about how CS should be working with product and this isn't an interesting angle of saying, you what CS ops should be the function that consolidates or repetitive requests, but then you said there's other types
07:24 of requests that you find even more productive to collect and share with product. What was that? Like the epiphany moment that you had after doing a bunch of repetitive request collections.
07:35 Where I see a lot of peers and like a lot of approaches to this challenge start is that there's a need to have a team that only focuses on repetitive that because those can be documented you can provide somebody with a document and say here this is playbook followed this one this happens and we can count
07:56 how many of these things happen because we're anticipating them, we've defined them, and they fit them all. That model has the assumption that you can define the universe if what's going to happen.
08:07 How often it's going to happen, you can't staff that either because you're staffing for an unknown amount of requests, potentially, that you then don't know if they're going to come through.
08:18 Truth in the matter is, unless your product is very standardized, your requests won't be standardized, because the context of them is always going to be slightly different, most likely, and you're also going to need to be able to understand how the question is being asking context.
08:36 Like, how does it actually apply to the customer's use case? And that's where the relationship between a CSOM scheme and the relationship management team allows this to have a wider variety of apps.
08:49 In that now, it's about the context. Hey, I know they asked for X. But it's not just X, it's also X and how X fits into the bigger picture of this other thing that they're in the middle of, which is connected to this.
09:03 So can we put those things together for them? That's where the package comes in versus just, I think we've all worked with teams where our customer support teams, or you kind of call centers and you ask for something, and there's kind of scripted responses, how it's very defined by a QRC, or something
09:22 that just gives a definite outcome, it may not meet the context of your ask. So, going beyond that to add more value, and then also to allow the conversations between the relationship managers or the success managers and the clients, to focus on the real business needs, focus on the outcome, and remove
09:42 that tension for, hey, I've asked five times about this, maybe I keep providing more details to try to get to the bottom of it and the success person and the scale team is asking me for clarification still.
09:59 Now what you do is you close that gap and you make one source of ownership between the relationship manager and the client where the refinement is going on behind the scenes.
10:08 So that whole multiple contacts reaching out to me with questions gets quelled and there's one person working with the client to own the outcome.
10:18 I mentioned that you actually publish metrics on a monthly basis. So, you know, beyond collecting data and like publishing them, what do you focus on in terms of themes to report on?
10:31 And who do you share these reports with? So the themes that we focus on are types of requests. Well, we look at in types of requests break down who are receiving them from what they are for.
10:44 And we also try to get an idea of how long they're taking. Are we staffed at the right capacity to handle these requests?
10:50 And how do we then forecast going forward based on collecting that data? What else can we take on? Because a successful model is going to create more demand for itself.
11:02 So we see that. And we want to be able to anticipate, hey, when people are seeing this working, they're asking us for more work.
11:07 How do we answer that question? And also what do we need from other teams? So by grouping those requests into, hey, this many might be operations related, this many may be data related, this many might just be on the configuration technical side.
11:22 We are starting to see then who we need to work with on to start to either say we need more resources there.
11:29 The other thing we do is create, I should say, a narrative. What's the narrative for those metrics? So the number alone is counting things is not terribly valuable, but hey, we saw 18 of this signifying that the configuration of this API could benefit from this or even more over it's hey, we need to 
11:51 proactively communicate to the field that changes needed or the way of using this is or here's the documentation on how to use it to evade receiving more requests in the future.
12:01 What would be like the main impact of actually not only collecting the requests, seeing the themes, sharing the themes and impacting the way solutions are packaged going forward.
12:12 Do you see this, for example, like a reduction in ad hoc requests? Is there other impact that you're seeing over time since you started doing this?
12:22 A reduction in requests by being able to provide feedback to partners on configuration changes by creating standardized reporting, creating tools that enable self-service.
12:34 This has been a very large input into a partner experience project that we have kicked off. That's going to enable self-service reporting self-service configuration of products so that these things can be surfaced by our partners directly.
12:49 Then we will start to see you that we can keep adding functionality there to address further requests that we start to see as themes Ideally, as we mature, what types of things that we see come across should change.
13:04 And then that gives us new opportunities to add additional functionality via to our portal, our self-service data solutions, or even directly into the product by being more product-led success.
13:15 So I want to emphasize that your the CSOPS organization doesn't handle these requests. You essentially collate them and you're trying to capture themes, create more productivity and optimization around reducing one-off requests.
13:32 Actually, we measured this and we have a 95% rate of being able to fulfill requests ourselves. A large part of our goal is to understand requirements of these requests so that we're able to see the pattern and address them when they come in.
13:49 And also, we can mitigate them the dependencies on other teams and the need for cross-tMS allies. Building that knowledge set so that the resolution does not need to be handled externally has been a large role.
14:04 You feel like it helped reduce the cost to serve a client. In general, the average cost to serve or maybe even increased revenues to some degree.
14:13 I would say it helped us scale. That's what I like to think about from the perspective is that now a relationship manager and RM has time in their day to work with more customers or work with the customers on how that we're going grow on our platform, rather than directly answering some of the questions
14:31 that they were before and having to spend their time researching, getting to the bottom of it and solving problems on their own for the first time.
14:40 Yeah, I think that's the unique unlock of these central teams is that why should a number of relationship measures your field team have to experience solving a problem for the first time every time when there can be a resource that knows how to get the outcome.
14:58 No, almost sounds like you created some predefined success plans or a baseline for a success plan for specific types of requests that seem to be somewhat repetitive from clients.
15:10 Correct. And then the idea to be taking it further, making them either self-service, built into the product itself, or eventually eliminate the need.
15:19 Where did you find was the most efficient way to share those package solution documentations with customer success team? Do you just post it on SharePoint?
15:30 Do you have like a lunch and learn so that they would know a new stuff has happened? The ways we mostly share out information, the new sliders we had mentioned are a big source.
15:40 Then working with our partnership teams, he had directly by having road shows. So we'll kind of do road shows, go to their team meetings, summarize what's new.
15:52 We also publish weekly newsletters in our collaboration tools. Who gets the newsletters? There's two types of newsletters. The summary ones that we create monthly.
16:03 Those newsletters are going to go to the cross functional leaders. So people within product finance. The teams that we're dependent on for outcomes are the groups that we want to communicate regularly with and make sure that they understand the impact of the work we're doing with them as well as any 
16:24 asks and themes. Then within our field team is probably the most compatible term for like most CS practices is where we'll go and weekly and we'll also share in context with other things like what are client stories people should know about, what are new product features, what are changes to the product
16:44 that you need to inform your clients up. We will build that weekly and publish that to the field as well so that they're kept in the loop that way and then we also leverage cadences with each one of the business leaders to emphasize some of the key points that we're seeing as the themes where we need
17:02 to address them and drive an outcome in each business that the session may get business specific. We talked about what it takes to come and see a soft manager.
17:13 We talked about what you guys do, how do you impact the organization and we talked about how frequently do you communicate with cross-functional teams and that the main impact here is to be able to sort of repackage some of the solutions so there's improved operations and productivity and then finally
17:31 we talked about the impact that it has on the organization and we started touching on the type of metrics that you actually keep track of and you said, okay, we keep track of how many requests and it's being reduced.
17:44 So we also do a steep set from our business partners every quarter. So we have quarterly surveys that are available.
17:50 Get feedback on the overall partnership and then look for feedback specifically on how this is serving them. We have the QDU person that are done with our partners to highlight what are the areas that we can improve our partnership on?
18:05 What are also the things that are working well? What is the overall growth or opportunity for growth, the topics we're both interested in on both sides of our partnership.
18:15 And bring these things up there. Sometimes those can be great forms for hey if we're able to get this file more regularly.
18:21 Like we would be better often, you know, that will reduce the needs. It's a very actionable tactical things come out of those sessions as well that these teams are able to put in place.
18:32 And you say partners, you mean your internal partners? Sorry, partner also means customer. In the CSM world, it would be customer.
18:39 So you actually meet with your business customers. Yes, our partnership managers are facilitating that, and we will join them, or we will provide them the information that they need for those meetings.
18:52 The other key measures that we look at, I think we've started to upload to it, which is, how do we look at how many requests we're getting for an individual customer?
18:59 Is it a matter of something very specific to their solution that we need to take a look at is there configuration changes that perhaps they should consider that if we're able to get that change made then it'll be a much better experience for them and a total number of like requests the amount of interactions
19:19 the time it takes to get outcome will go down. So that's another theme that we look for. The other ones are how many knowledge articles are we publishing.
19:27 So how are we growing meaning how many different types of requests are we starting to take on? How do we look at the growth of what this team is able to do in terms of what it's offering the business?
19:37 Hey, we're only able to do like 10 things last quarter. This quarter we can do 20. Like can we do more?
19:42 And then the other thing we can do is show hey with the same number of people we're now able to do this much more quarter over quarter.
19:49 And then hey, if we get one more person here's what we think we could do and start to forecast that out.
19:54 I think we alluded to that. You truck for a CSAT, you track for outputs, like knowledge-based articles, you track for the efficacy of their relationship with internal customers, as well as the external ones, that's a lot of data.
20:09 What kind of tools does your CSOPs team use on our regular basis that you would potentially recommend? So the tools that we use are largely built into our service management platform.
20:20 So a lot of what we're looking at are the built-in tools, wrote them reporting tools within your platforms like send us service now sales force all those service cloud just very standard reporting and then what we have done is created tagging for our requests on our platform.
20:38 So by having the this tagging methodology that we apply we're now able to see the kind of dynamic groupings that we're looking for to track more closely the types of requests because obviously when a cross comes in that note to wherever really going to be a like because of the variety you can get in 
20:55 other written. So that's where the triage level does assign a tagging to tickets, which facilitates the reporting. I just have a confirmation that when we review the data see the impact that we're looking to have.
21:10 So are the request types changing over time? Are they saying the same? If they're staying the same, then what do we need to drive again with our business partners to get the outcome that we're looking for?
21:21 Are those opportunities that we need to actually push maybe product work to automate or the data teams like how those things become repetitive solutions so they're not being done by a human and don't require interaction they're just scheduled and automated.
21:34 If you have to describe the text tack for a CSOPS team, what would that include? Do you have your data source?
21:41 Obviously, what else do you have your transactional platform? Which is probably sadly going to probably start with something like email.
21:49 It's probably a lot of email that we are still working with and then the other thing I'm seeing is your slacks and your teams your messaging platforms are becoming real time platform for the intake of requests and that can be challenging for the relationship management or the customer's success teams
22:03 because the expectation sent or set in those platforms is their instant messaging which implies instant response what I think teams should think about when they're setting those up is how do you build automation into them when a client needs to have something fulfilled, they can automatically use a bot
22:23 to create the request. So, the outcome is a request is created, not a question you had to answer to instantaneous thing necessarily or you create a way of managing expectations for the solution you offer on the platform so that there's guardrails on that and you don't get into a situation of always trying
22:43 to find a solution instantly for something where you might need to have time to track down dependencies and get answers.
22:50 I think that's one of the learnings or one of the themes I see, especially from that, not just our organization that appears that they talk to about the challenges of integrating instant messaging or some sort of messaging directly into your stack, some sort of case management solution, and also knowledge
23:07 management. We have layers of knowledge management going on through document collaboration portals as well as then directly in your case management solution.
23:17 Where do you analyze and do some business intelligence analysis on the data? At this time, we're thankfully able to do a lot of that in our case management solutions.
23:25 Good old Excel that we also rely on. Power beyond it will be notes of low, low, low fancy years. We haven't had to go there yet with today.
23:33 We are starting to build out the next phases that we're looking for. How do we get a more holistic picture?
23:39 Can I merge cases of more of the transactional information and the logging together and what would that look like? How do I look at those themes and start to learn from them?
23:50 And those are things that we are looking at like, Power BI is tabloes. I think the prerequisite for those to be successful that we're trying to navigate first is creating that data architecture model.
24:04 If you put customer in the center of your data architecture model, How does it become a primary key across all those different systems to answer?
24:13 Well, fascinating discussion, Ben. Thank you so much for coming to the show, sharing your expertise and experience and CSOPS, and I'm happy that you could come in and kind of share the perspective of what kind of role should CSOPS play in making sure customers get to their outcomes while reducing cost
24:32 of serve and increasing operations and efficiency so that the customer experience is more elevated. Thanks. It's great to be here.
24:40 Alright and with that if you like this discussion give it a like if you want to see more of this put it in the comments below we'll try to bring you more interesting guests like Ben.
24:49 I'll see you at the next video.