Customer success pipeline stages for Supervision

How to create outlook signature

hey everyone thanks for joining me today we're going to talk about how to document customer success processes and how to do it in alignment with best-in-class practices documenting processes for customer success can take a lot of shapes and forms i've worked with a lot of different clients and every time i see the process being documented completely differently but there is a consistent way of doing it and there are some areas that you really need to think about when you document the process so that it becomes sticky it gets adopted and it becomes a really good process you want to do that even before you know you put it in a system so that the process can actually be followed in a consistent manner across all your customer success managers and so i invited pedro candelas who is the senior customer success operations manager at a company called elastic in british columbia and the reason i invited him is not only because he's a customer success operations manager but he's been doing that for seven years and before that he has a really interesting background he actually worked for a number of different industries as an industrial engineer he's been doing that for 14 years in different industries so if there's anybody who knows how to document processes and how to optimize them that's pedro pedro welcome to the show thanks for having me stay tuned we'll be right back with examples workflow charts specific templates that you can implement in your own organization and by the end of this discussion with pedro you're going to be armed with lots of tips and tactical advice that you can take to your own organization and improve your customer success operations [Music] so before we start this tell me a little bit about yourself where are you from like originally yeah so i'm originally from mexico from a town called mexicali which is in the north of mexico two hours east drive from san diego but now i'm currently in vancouver i've been in vancouver for the last four years a little bit over four years i came here with a company that brought me and decided to sponsor me i was a customer support manager when i moved here i was working remote for the same company i actually did a value stream mapping so my boss asked me like can you run this because i'm an industrial engineer so i run a value stream mapping and then while i was here like he liked what i did and he's like oh do you like it you want to stay so get all your documentation ready and yeah and here i am pedro before we dive into what you've done and like this whole amazing project that you've done and all these outcomes you know i've been working with a lot of companies and every time i ask for process documentation i see something else since you're coming from industrial engineering background in your opinion from your experience what is process documentation and what is best practices around that person's documentation is having a place where you can access the processes that affect your day-to-day there's two big mistakes that all the companies do it's either over document or under documents it's a little bit of an art to figure out where how much documentation you have to have startups in general they tend not to have a lot of documentation there's a few documentation here is rarely standardized every department has their own way to document processes and on the other hand bigger corporations they suffer from over documenting so they want to have every single detail and that's a problem in the long run if you are facing audits like if you have a stock compliance or an iso compliance audit like if you over document it when the auditor comes and they will see like oh you have to do exact these five steps by this person that you probably put the name of that person is no longer there since you get a finding you have to be in that place where you have your processes documented but then there has to be a little ambiguity that allows you to be flexible because then your organization will become too rigid as i said some of the best practices is keeping the documents simple and concise have a document control plan in place meaning someone who takes ownership of the of the documentation to keep it standard to keep it in the format to keep control of persons you have to keep different documentation for every different process don't try to have like a master document where they have all the processes in one single document because it also brings another type of challenges about covering the entire organization at once as i said like you should not try to document yeah the company white processes in one single document the other thing is that you have to make them available for everyone so like a single repository or either a google drive where you have access to that documentation a wiki whatever you want to use but it has to be available for everyone so everyone can go on access to that documentation you have to make sure that it complies to whatever certification you're applying if you're interested in going there you are a subcompliant or an iso or maybe a supplier or a vendor or a buyer requires you to be certified by their standards like you have to make sure that your documentation is complying to the requirements and then the least important is uh you have to create a process for creating processes so you have to document your process of documenting processes because if you don't start with that process then everything will fall apart i think it's one of the most important things that you have to have process for creating processes okay so do you have an example can you show how you documented the process for documentation if you liked what you've heard so far that's awesome more coming in a second here but in the meantime i want you to click that like button so that youtube knows that this is great content and you can start sharing it with others so to document the process there's a very easy steps to do that so one is defining the process and its scope so you need to be very precise of which document or which process you want to document you can't be too open and too wide we're documenting standard operating procedures so we're not documenting how the company operates we're just documenting okay i need to create a cta so what's the process creating a cta and what's called a cscta that is for risk management we define the process and the scope second step is uh you have to organize the steps so what i typically do is i walk the process so i sit with someone or or if i'm the expert i'll just run through the process and document or see the steps that i have to do to get to there then i have to see if my interactions or my process touches any other people in the team so i have to also address who's involved with my process and then sometimes of course there's exceptions so you have to add or note if there's any exceptions in the process there's always exceptions so you'll probably have some to add notes on that and then you have to have also very important part of engineering is control points or validations what happens at this point when you're writing the process you need to figure out at what point if something's going wrong they will allow you to notice that something's going wrong or not so you have to include those and then at the end like basically just run that process to make sure that what you documented in the the document that you created is actually gonna deliver what it's meant to what i typically do is i just give it to someone like can you do this process on your own without help if that person is able to achieve that goal of whatever the process was meant creating a cta then i considered that's a well documented process so it's always good that if you have a second person who checks what you documented to make sure that it makes sense that the wording is correct process is actually telling you what to do that you are achieving what is expected to achieve i wanted to say i really like step number five add control points i think it's not just adding control points for having somebody review your own process documentation but also making sure that as you create the process i mean you can document the process as is but usually when we look to optimize the process we add control points to the process we're documenting because i think that's really normally the fail point does that make sense yeah it makes sense typically it's something that we all overlook and i've seen many documentations or many process documentation where like the control points are not included and if you don't have those control points then you're not really setting yourself for success or you're not setting that process for success because something that doesn't have control points it's going to end up being uncontrolled it's kind of like a engineering jargon word kind of like we know that if something's not being taken under control it's gonna end up like being completely different process because people will find shortcuts they will just go around them so yeah if you don't have control points you're not setting up the process for success do you have an example of a process you recently documented where you had some control points so we can kind of illustrate that to the audience before we continue don't forget subscribe to our youtube channel and smash that notification button so that you don't miss out on any new videos so when you look at this what would you have changes this is a process where you would campaign into your customer base let's say you have 30 50 100 customers as a csm and you're doing some sort of like a proactive outreach to teach them about a new feature or new module that you think they might be interested in so start call the customer if they answer you discuss the campaign topic with a customer using the talk track call script if they're interested then you give it to the sales team send the thank you perform a follow-up right like all this stuff what would you have changed in terms of everything you've discussed before well something that's missing here is like the interactions with the other teams like this seems to be like is the same person doing everything so one of the things is the for instance if you're going to discuss it with cells you need to highlight that process and that should be transferable to when you move it to a document that you have to describe what happens and what you're expecting from that interaction with that third party that you're working with as we just discussed earlier the control points i don't think there's a control point here yeah like you're you're not validating if the process actually worked it's just considering that that's the the end like yeah you finalize it and that's it you're not including that part of the of the process it's good like as i said everything has a potential for improvement so like for instance if you want to improve this process then you will have to add like time frames when this has to happen kind of like moving into like a value stream meaning how many interactions you do a day how often where are your bottlenecks and that will help you in the long run improve the process as a general way to document the process it's good but it requires a little more to make process to be part of a documentation okay so let me see if i can recap from a workflow standpoint you would have added also like oh i'll show an example so this one at least has the difference between a csm and a sales person the csm does all these things and then what do they expect from the sales person so you could see kind of like maybe like a better example of the difference between the activities of the csm versus the sales person exactly you have to show those interactions and of course there's different ways to visualize it or swim lanes is perfect i'll say it's like the most common one sometimes just noting the owner color coding works as well but yeah like showing where it moves from one department to the other like process because not all the processes will be within just one which is one department especially customer success processes you touch sales you touch renewal steam if you have you touch support you can't really show that you're doing everything because you're actually interacting with other teams so it's important to highlight where all those other teams are part of the process and these are just the workflow charts so in addition to workflow charts i think what you're saying is that we actually need to document the entire process what are the different things that you have and do you have an example of a process that you documented or at least the template that you typically use just to break down the different elements of what you would recommend any customer success operations manager to use when they're thinking about documenting a process so that they have all the pieces in place so this is standard operating procedure template i recently created for the company i work for it's very standard you'll find something similar almost everywhere if you google you don't have to be very creative there's a lot of things already created for us so you don't have to spend a lot of time inventing the wheel so sop basically standard operating procedure name how you're gonna call that process you have to have an effectivity date when that date becomes becomes effective you have to keep revision control meaning when was the last revision done and then a number you can use 1.0 one point x or ace or whatever you decide and then the authors and this is important because if you need to review it's important to have who created that document because you you will also have a person to ask why or how it's documented and that's something that is very common that we over look in tech because everything is like on goal sheets or whatever and then you never record the who create a document you just save the document the folder and then just leave it there and then you really don't know unless you go through the settings of the document to see who created that document sometimes that person is no longer there so it's important to have a whole created document then you keep a version control doesn't have to be very sophisticated just you start with the initial release like the first time you create it and then every single change that you do to the document will add you will let anything that happened like if you change maybe you change the roles or you change there was an update on the ui they were using so you need to add the new screenshots or or something like that like you will have to document then typically you have a brewers you will have either your manager or your peers to approve it just to make sure that it complies to the documents to the whole structure then you have to describe a purpose you have to describe what's the purpose of the process and what's the background meaning we are documenting this process because this and that happened in the past and we're trying to prevent that from happening again or we or people are not doing this so we are preventing for people not doing it anymore so you have to add a purpose a scope as i said what and whom are flies could be the process it could be team members and this is something you should be a little bit ambiguous don't put pedro needs to do this just leave it like oh the csm role it's responsible off that's important because you don't want to change the document every time there's someone who leaves the company or they win the lottery and then they just stop working for you you don't want to change the documents every single time prerequisites you have to add any information that is proceeding to the procedure so maybe you need to have information from other sources you need to check some other processes to be aware of or you need to check logs or something like that like it's important that you highlight those so that when the person starts doing the process they know exactly what they will need it's like like the part list of when you're building or putting together an ikea furniture you need to know what's there responsibilities this is important because here you will highlight where or who sorry is the person who's actually responsible of executing the process and as i said don't put names just make it as like the role like the csm is responsible of creating a cta and then the cells just sdr is responsible of replying to you be very very ambitious don't put names because then you will have to change yeah that's a common mistake i think it's really important that you brought it up yeah i've seen it multiple times and i've been through iso audits where like there were names of internal people who were like long gone from the company and then you got a finding and it's an easy fix but no one wants to have a finding and what about the procedure that's just a box there is there best practices on how you describe the procedure says include a process flow chart and then step by step where do you highlight the timeline like it doesn't look like you have a format to make sure that you describe the step by step in the detail that you discussed so procedures are very flexible the process of documenting the procedure is what is to be documented but it depends on the on the style of the company some companies have very robust documentation so like the most obvious thing is just describing step by step the process and then you add the flow chart as a support of because people will sometimes understand better with closure some people understand by instructions so you just have to go in a linear way of how to do things of that process so for instance if we're using a csm tool and you need to create cta you don't have to go deep to like open let's say open gain side and click on home and then go to the cockpit you don't have to be that specific but you can say like once you're in the cockpit click on the plus button to create a new cta and then you describe the steps of what you have to fill in in that in that cta and then what about templates that you use how about a business process versus a system process if you have like a business process how do you do a qbr or how do you reach out for a customer when there's an escalation do you typically also include links to email templates what are your best practices in order to scale that operation you always have to add references to what everything that you're documenting we have this other field here where all the related processes related policies and supporting documentation that needs to be connected to this document so yeah everything has to be included here and try not to document the templates within the procedure because if there's a change in the template you have to change the procedure as well so try to keep them apart have a different control process for the templates it could also be under document control so you have a proper control of all your templates for emails for version control of all your templates and then just reference the procedure for that general template don't document the templates in the process that's great okay so once you done documenting the process who do you show it to and who do you get the buy-in to actually use the process in my case or the cs world i'll typically work with the directors and some smes within the organization so like i create a process i'll validate with a select group of csms or like the ones we're going to use it at the end and then just make sure that what i describe is capturing everything that needs to be done and wording as you know many of us are english a second language so sometimes wording needs to be proof yeah so we work with them and then finally typically the director or the person who's overseeing the team is the one who approves the process what happens after it approves you take the document do you put it in a library or do you just put it in in your customer success software we put it in the library and it could be either a google drive or it could be a more sophisticated document control tool what do you use pedro we use wiki which is a wiki okay you convert this into an html page correct we convert this into an html page and we have it on a wiki same format just a wiki so everyone has access the csm team has access to the wiki the version control is also a little bit tight to the person who uploaded it so we have that tracking as well and yeah that we use we just wiki just so you know clients that i worked with if they're a google shop i typically recommend using google sites as your wiki so you don't have to buy a new tool and if you're a microsoft shop the two most used tools that i have seen are sharepoint and confluence oh yeah i work with all three i'll say it depends on the organization confluence has worked in companies where are very heavy into using jira because there's like that world at least in my experience when there's not that heavy in like agile front i'll say i'll prefer google sites because everyone is in goal sites so i have no preference they'll work similar they all deliver the same features basically yeah i have the same impression okay so once you've published it on your wiki page like i've seen a lot of companies document a process or optimizing it but then the process never gets adopted in your most successful newly published processes what do you think made some of them stickier than others like what are the things that you've done the team has done the manager has done or the way you documented it what do you think what's your like main takeaways on what makes a process sticky i feel like when if it's a full change it makes them stickier when it's just a tweak to the process it typically it's harder in terms of change management to adopt it because they're it's more prone to for mistakes because if it's let's say all the step all the process is exactly the same and there's one last thing that change it's harder for csms or persons humans to be aware of that change or change habits or change habits correctly but some of the things that i've been exploring on doing is how you make it harder to stay on the previous process how you sunset or remove the previous process and how you don't make it available or not unavailable that's something that i've been exploring and it's been working i don't have a much experience so far so i can say oh yeah this is the way to go but i've been trying to sunset the processes that we're replacing they just make it harder for them to go through that other process well i feel like this conversation was really great for anybody in customer success operations that wants to have a consistent approach to documenting processes and like step number one make a standard of operations nsop template in place and it's something that works for you find a place where you can document or push or publish all of these processes and then follow the steps you suggested earlier in in the videos for each process how do you work on it until it gets published yeah and then i guess like not last but it's important that we do process for engineering i call it so how you improve that process and i think that might be like a next video because i think that there's so much to cover just on how do you even document an existing one let alone like all the approaches on how to optimize it and i would like to invite you to do another video with me just on taking a horrible process that doesn't work constantly generates issues and how do you approach step-by-step the optimization including like you said a big challenge how do you make people change their behavior to kind of like touch on how do you sunset the old process just to make sure that there is a success and maybe we can walk through an example of how you know you approach that at your own previous companies all right everyone if you enjoyed this video give it a like stay tuned and subscribe to this youtube channel so when the next video with pedro comes up around how to optimize processes you're gonna get that notification and that's it for today pedro you've been absolutely fantastic i really enjoyed getting to know you and learning from you on how to document processes for customer success operations thank you so much [Music] you