 So my name is Scott Massie. I'm the director of customer success at Pantheon Thanks for coming to making customers successful Hope everyone's having a good Drupal con. I'm having an awesome time. Is there anyone here from the Netherlands? Cool so like just a personal aside like the Netherlands was my first stamp on my passport and I don't know if anyone anyone remembers Oily they're still kind of around but I worked for them for about five years So I used to come here all the time for work and stuff. So being back here is Like super nostalgic and I'm staying at the hotel that I stayed at the first time I came to Europe So like when I saw that the angels on stilts like I had to hold back the tears Like I was like a big crybaby like I just want to move here So it's great to be here and it's good to be at this Drupal con has been awesome for me I hope it I hope it's been great for you guys, too so I Worked for Pantheon where website platform run Drupal and WordPress and some other stuff and I've been doing that with them for about two years prior to that. I worked at a Drupal shop in Chicago I ran their support department and then before that I was doing managed services kind of IT support for You know Microsoft and Cisco for small business and enterprise and I was the service manager for for a company there So my background is in support I kind of came into that by being like an IT manager and managing like internal servers and that kind of thing But I made the for a kind of into the web Dev world and the Drupal world When I came over to the dev shop in Chicago, so um That's that's a little bit about me. I I just wanted to sort of gauge who I'm talking to here like who who works at an agency or dev shop of some kind and Then who's like a freelancer starting their own thing? There's if you need to hire a freelancer, there's three of them right there And then is anyone like a product owner or developing a product? Okay, cool. That's something I see more and more especially when I do hiring and I talk to people There's all different reasons people want to work for Pantheon, but one thing that comes up Is that people want to move from web development to some kind of product and so um So mainly I want to talk to agency people and dev shops but I think there's kind of something in there for something in here for everybody and I sort of wanted to explain maybe what customer success is kind of in capital letters and then in lowercase letters as well because it's kind of two different things and Talk about how how we do it and then finally talk about how an agency can implement this sort of customer success centric thinking In their business and I usually what I do when I give sessions because I do it pretty regularly I get really insecure that I'm not delivering value So I overstuff it with like three hours worth of material and I purposely am trying to break that And do less so I want to have some time open for questions at the end and to discuss stuff and maybe learn stuff And we can talk about Like support or whatever you guys are struggling with and maybe I can help you There's a small chance. I could make things a lot worse too. So just keep that in mind So Customer success kind of in capital started with this guy's quote here the CEO of sales force When he said if customer success is not your number one value you have to reevaluate and it was you know he's pretty respected as a thought leader in the sass industry and it was I think it was kind of a wake-up call to The startup world where they had like an engineer who was building stuff built a product And then they added support who was there to kind of put out the fires and then they added sales and marketing But there was not anyone really engaged in the overall success of the client, you know support Is really good at gauging like non-success, you know if they're opening tickets They're probably not being successful and sales is kind of good at At least selling this promise But delivering the promise. I think they began to discover Was not really under anyone's kind of Guidance and so this kind of came out and all this sort of customer-centric focused Philosophy and business models emerged and so like right now what customer success is it's it's sort of small and growing It's a couple meet-ups mostly in the Bay Area in San Francisco where where I live and Some LinkedIn groups of varying levels of activity There's a meet-up that I'm Kind of involved in called customer success in action and we meet and there's also an association that just did Like their first event in London, so it does seem like it's spreading a little bit Into outside of our little bubble literal literal bubble in San Francisco and Then there's some cool blog posts, which I think are of pretty good use for for a lot of people that kind of explain Some things that are kind of sassy, you know kind of customer kind of product-centric like What churn is when you have monthly recurring revenue and why churn is important and things like for things like that but also just talk about running a Business that is more focused on Being even better than proactive, which I'll kind of get to in a minute and then finally there's along with any sort of Market segment there's the products that kind of follow and if anyone's familiar with like market automation tools like Marketo or Pardot or infusion soft or anything like that There's some customer success tools that kind of if you if you have like a SaaS product for example you can plug in all these actions like if you if you have it like a weight loss app and Someone stops putting in their weight after a certain point and doesn't do it for three days You can have like a tool that sends them You know something to motivate them or sends them an email that says hey where where have you gone? So if you've gotten those emails, it's probably from some sort of tool like that And maybe some sort of like customer success tool and so these guys put have put on events and that sort of thing and and What they do is pretty cool. It's not so much what I want to talk about because it's not it's more Sass-related, but they do exist and I think that What they're trying to do is something that an agency can can also do and get some benefit from And then there's a bunch of people with that in the title me included there's about 9,000 people with customer success somewhere in their title and I think it's it's been growing like I see it more Outside the Bay Area and I also see it in industries that are not necessarily start-up related or sass related I see it support kind of having a customer success manager and and I see it in kind of other fields So it does seem like people are at least getting a feel for for what this what this new sort of philosophy is Yeah, but really what what is it like I haven't gotten to that yet and what it is sort of depends on Like there's there's a couple different ways that customer success is organized in In organizations that I've seen there was an event not too long ago Hosted by one of those companies and they just asked like who oversees customer support in your organization and There were basically like three basic answers and like the first one was sales, you know sales overseas customer success and usually in organizations like that it's tied to like upsell and and Renewing contracts and that kind of thing and they're compensated based on that We don't do it that way And I'm kind of glad we don't the second way is that it's under the the the guidance of marketing and that's mainly because you had that that sort of gap between sales and support and Marketing is you know are generally more able to kind of deliver content and and sort of able to create content that might be relevant and so we saw about a third of people are underneath the marketing departments And that's not how we do it either we love marketing, but We don't report to them the way that we do it is very much aligned with how we do support And I think that's pretty common for a technical product and we have a pretty complex product compared You know, we're not checking. We're not recording people's weight, you know We're building up a platform where people can build something that records people's weight, you know Or you know or can build whatever you guys want. Hopefully, you know, you can do that on our platform So with the more complex kind of of products like us it tends to be more of a support function and To be honest when I when I took the role at Pantheon, I wasn't so much interested in doing support anymore Because a lot of organizations that I've worked for Support is sort of this burning pile of tires that use kind of keep in a room and try and contain the misery of The people who have questions and are trying to get help and you you throw an engineer in there and hope that they'll stay in There for a year or two until they burn out and you have to move them somewhere else And and it's not so much in the Drupal world where there's not as much support, but definitely in managed services you know, you're dealing with kind of Emotionally elevated people on the other end of the line all the time and that can sort of wear people down and it's prone to burn out and all that kind of stuff If you've done a lot of customer-facing roles and and I have to even prior to getting into it I'd say most of what I've learned from management, which isn't much I learned from being a bartender where you're dealing with angry irate usually drunk customers and And you also have really good managers. So a lot of how I work with With people today Not so much as bouncing them out of the bar, but regular interactions. I I learned kind of that way and I think there's a lot of similarities there But yeah, so that's kind of The three areas where you tend to find it The way that we look at it in at Pantheon and I think some of the things that I've pilfered from various Sources that I think are important and we hold We hold to be really high values is that Customer success is less about account management and customer management customer management and more about adding value And it's kind of rethinking how you work with your clients and when you contact them and why you're contacting them And you know when you have a sales organization when you have your sales department Who is rightfully meant to be focused on upsell and making sure the contracts are renewed? That's that's good. It's important to the business But it may not necessarily be adding value to the to the customer and the same thing with support that tends to be more reactive. So The the main one of the main goals of our department is doing things that add value to the relationship And that the customer perceives is value another important tenet is that We we don't focus solely on the buyers and decision makers We find that in in our community and I think the same thing applies for for you all when you're working on projects You know the person who signs the contract is one of many players in the whole kind of lifecycle of a sales Flow and and and definitely after the sales like the ongoing lifecycle. It's many more people than just The guy who signed it in fact a lot of times you never hear from the guy who signed it after the initial contract is signed So this puts more emphasis on who the people are that you're really working with and how can you strengthen that relationship by adding value? and then Like support is is essentially kind of a reactive team of people that are Wait to hear for problems and then try and solve them And so one of our goals is moving from reactive to proactive, but even proactive And if you get to proactive you're probably doing pretty well, you know, you're in good shape, but Proactive can also have its own issues in that you are You're liable to have a shotgun approach and if you know for example if you create tons of documentation And only three of them get read That's helpful, but it's not necessarily efficient for an organization to be churning out documentation That's never going to be read by people So really what we try and do is ultimately go past that and deliver relevant information real-time and Then yeah, so putting out fires like this is important for us as our product grows You know when you have a mature product you kind of people kind of know what to expect and Support can kind of do their job, but with us as we grow and we grow constantly and will continue as you know As dribble eight comes out we will change our product to adapt to that, you know as new Technologies come out, you know things like Fastly and you know varnishes a service that didn't exist a couple years ago Come out we work to adapt with them and try and you know We don't try and put that in ourselves or CDNs because we you know can't do it better than Cloudflare or something like that But we try and make the ultimate goal of the customer being successful built into our product So it works smoothly and so to that extent we sort of feel it's important in customer success to be Kind of in the agile sense the voice of the customer because we are talking to you guys more than anybody And I think that anyone in this role even if you're at an agency there's still kind of that responsibility because You're you may not be influencing a product, but you're influencing How you know the verticals you target, you know and the sales you go after and the business process you follow You know and the development process that you follow, you know I think like customer success Has made a big Influence, you know has influenced how we do Continuous integration, you know and that may not be something that support would necessarily handle But it's something that we look at as something that's important to making the customer successful Because the more testing we have the less dashboard bugs there are the less bad experiences you guys have And we think support is one really good proxy for how happy you guys are on our platform so that's sort of what we kind of We kind of keep in the back of our heads when we talk about it And so when we do these onboarding calls when I talk to like a a contract Clients like an enterprise client or a new partner Or a new OEM client what I tell them, you know to sort of you know Compress all this down to one sentence is I want to make sure that you get every bit of value out of the out of Pantheon that you can and I think that you know when you go about your business and you do like with a dev shop When I worked at the dev shop you go through the process so many times that it becomes kind of rote And do you forget that maybe the customer doesn't understand like something simple because you've sort of moved on past that so I think like putting in processes that make sure that the customer is Informed as possible and if there's something that you guys offer or a feature that you guys need like there's someone That's kind of aware of what the value is like the perceived cost is less than the perceived benefit You know that's sort of my definition of what I call value there And then what I promised my team, you know support is my you know, that's why I'm here that's why I took the job at Pantheon and And My my my promise to them is I want to kill support, you know I want them to come in and have nothing to do You know if we do that if we solve all your problems So you never have to open a ticket then I feel like we've done things right and so that's kind of how we position ourselves as like What can we do to be more real time and more proactive than more reactive and That's sort of my internal promise to make life easy for support because it requires technical skills it also requires a lot of soft skills and We do our best to train that but it's something that's kind of innate in people and support people are sort of a Rare gifted unicorn that I treasure and hold real dear to my heart. So I want to make their life happy So this is an example This is kind of an overview of how we have it working in Pantheon. So Starting from the left we have This is our customer success team. It's divided into four five little teams and Of varying maturity some of these were just sort of launching some of them have been around a while But the white circles starting from the left we have onboarding and these are For either enterprise clients or Partners or for OEM clients. We want to make sure that they have close contact This is something like a project manager It basically is a project manager for a limited time who we work one-on-one with the client to make sure that they The stakeholders are up to speed the developers are up to speed that they understand our platform that they know that They have someone that they can talk to and it works pretty well It's something that I basically took from the dev shop that we implemented there This onboarding process and I'll go through that in more depth But we have this onboarding team used to just be me now. It's three of us Four of us now that that kind of take care of that We have our support team which Which is we're training people in the EU. We have a US team in San Francisco and some other remote people That's kind of self-explanatory. They do support We have a training and technical content team And so training we think is really important and so we offer training one-on-one We offer it on-premises. We go to camps and cons and offer training And we do webinars we do monthly webinars for Drupal So if you if you're not familiar with us we try and show off cool stuff like we do more than show the platform We talk about continuous integration and using features and we'll probably do a DA demo not too soon now that we have that working pretty well and We have a couple pretty sharp guys On our team and hired a couple content managers who are responsible for coming up with more content like companies like I don't know Has anyone used like digital oceans documentation to get stuff done in like they have great Documentation and they're well known for that and we sort of hopped on to that Their bandwagon and are trying to come out with new and really cool Documentation and tutorials that help people and finally like the dev community when we go to camps and cons That's that's my department who goes there and talks to technical people Talks to users kind of tells them about you know evangelists and that sort of thing and then finally like I mentioned How we how we influence the product is really important to us So we have an internal team that kind of handles QA handles bug reporting make sure that gets taken care of and also Handles how we get things on to the roadmap and how we sort of build our product So you can see how you know starting from the left we have sort of you know proactive real-time support is reactive technical training is is Proactive developer community is proactive platform reliability is real-time like that's what we're trying to do We're trying to move from reacting to problems to solving them before you guys even know about them. Hopefully Yeah so a short sort of case study of How we used onboarding which is like I said I basically sort of took this from what we did at promet in Chicago when I worked there I kind of want to run through that so a Little bit of background Enterprise for us used to just mean more resources on the back end and an SLA like we would get to your tickets quicker If you opened one what we quickly found out is that customers had much higher Expectations than that for the amount of money that they were paying and they had more complex sites You know we get sites that are imported that have 800 contributed modules, you know They had much tighter timelines where they needed to launch their 800 module site in a month You know and they also had you know more complex use cases and that kind of thing And we realized pretty quickly that this was not going to work like that And so we developed like this onboarding strategy Where we kind of made people go through this, you know We sort of figured out what people needed to know we created a publicly accessible Page of known limitations We created our required reading page that is still up on our website that we curate and We had calls we had calls with stakeholders And this to me is sort of how you design an onboarding process that everyone is Required to go through and is in the contract that you follow you take all of the problems that you've seen in history And you make a list of them and you come up with the solutions to those problems And then you get the people on the phone and you run through each one now They may not remember it But you have covered it and they know where to go if they need help in the future and maybe it'll jog the memory Two years down the road that like hey I think I remember that I can do this or I remember that this page exists somewhere And you go through that process and we do that with stakeholders and what we go over with with the stakeholders Is how to get in touch with us the scope of our support what we like we don't do module development We work with partners we work with you guys to do that We don't fix people's code we have a very clear delineation of what we do and what we don't do So there's no channel conflict like that's that's why we work together with you guys So we explain that to the stakeholder who maybe might not understand that we make sure that that's clear We talk about how to get in touch with us if you need to like support stuff like menial stuff That if you forget about come You know their site goes down They're gonna be calling the salesperson and not know who to talk to so I think like covering those things and having them respond like Like again back to table waiting days like read it write it repeat it was sort of the rule like you point to the menu At what they're ordering you read it back to them and then you write it down Like it's the same kind of thing you get this sort of two-factor Authentication that you guys both agree on on what we're doing here and then like after the stakeholder call We go right into a developer call where we talk about the same thing only for a more technical audience We go over what the what you should know what you should be using what we're gonna be asking you to turn on How you check, you know common debugging tools that kind of thing So by the end of those two calls stakeholders are engaged and they're up to speed And I think anytime you can get stakeholders engaged the more the better, you know It's like the the pig and chicken joke, right like, you know the pig and chicken joke So it's like the the old joke about agile, you know There's a pig and a chicken and the chicken says to the pig You know the farmers been really nice to us. We should we should fix him bacon and eggs And the pig looks at the chicken and he says hmm. It seems like you're involved in this project, but I'm committed So not a great joke, but it's relevant because like the more you can get stakeholders Involved the more they're committed to the project and so getting them on the phone at least once kind of sets the stage that Hey, we need to work together here and I need your help and the more you're involved the more successful It's gonna be so do that with stakeholders. We do that with developers We set up a time frame like every project is supposed to have an end, right? And so we set up an endpoint, you know We set the goal of like it's gonna be the site launch or it's gonna be you know five site launches or something like that And then we set up a time where we meet we either jump on their stand up We try not to get in the way So we either jump on their stand up or we set up our own kind of weekly check-in or bi-monthly or whatever And that kind of keeps us up to speed on what's going on and then we know that developers are apt to not ask for help right away and bang their head against a wall until they're really frustrated and then open a support ticket and we feel like if we're really involved in their business then we can kind of Prevent that from happening and kind of solve problems a little bit quicker and make them a little bit happier So we go through that process Hopefully at the end of that they have a site that's pretty ready to go and then we have a launch check Which is something that also came from working at a dev shop where we had a site audit because we were getting all these sites from clients varying levels of Of performance and so we realized pretty quickly that some of these sites sites just barely stood up on their own You know and so we developed this this Site audit which marketing came in and smartly renamed launch check Lest developers feel like we were going to look at their taxes We came up with this site audit process that initially was a bunch of manual commands and then we worked with With engineering to turn it into it became a contributed module which is still available at site underscore audit and then it became Built into our dashboard so now like if you go to our site you see the same onboarding checklist in any free or You know Professional or any plan you see that launch check in there That's the same stuff We saw and we found that if we went through that list with people and made sure that their site was caching made sure that their Database was you know using an ODB and you know made sure that all those boxes were checked There was a high success rate, you know come launch time So we did that that was part one of the final steps towards launch part two is Low testing and so a lot of people you know We just basically verified that the traffic they expected was going to work and we found that often there are It's throwing errors, you know and that there were things that weren't happening in dev or test That were only happening when they were kind of stressed out a little bit So we build that into that process and I think that's something that every dev shop should do before they launch a site Is just do a quick load test like load impact and load storm and those companies make it crazy simple to do So we would go through that and then the clients would launch We would send them a survey and there's a couple different surveys that are sort of very customer success See there's the customer satisfaction, which is the CSAT up there Which if you've got ever like done something and you've gotten like a one-question survey Which is how would you rate the service that you received? Like that's a CSAT and then the other one is the NPS which is the net promoter score Which is if you've ever gotten a one-question survey, which is how likely are you to recommend our product to others? That's and that's the NPS and those are pretty pretty well known and often Sort of a sort of there's a lot of controversy around how valid they are But they're really good quick one question surveys that Hopefully you can get you know, they're much better than 50 question surveys Let me just say that like if you're gonna send a survey one good question is is maybe a good start And then so we would close out we would officially say we're closing this out We're handing you over to support and then we would we would finally do up would do a 30 60 90 check-in We do that and we look at New Relic. We look at their support tickets this is sort of like our Attempted account management at scale like we we make sure things are going good and we say if you need us Let us know if you decide to build another theme we can spin up this whole process again but otherwise you're in the hands of support and And it's worked pretty well like we're able to we've onboarded several hundred enterprise clients doing this We have three people who are pretty busy doing this all the time and our process gets better because it's the same thing over and over with Little tweaks that we make all the time, but it's pretty much a locked process at this point And this is an example of before and after launch concierge. These are sort of our launch check These are two clients one before onboarding and one after onboarding So the red client is before onboarding and these are the number of support requests that they had and you see that They're first these are the months down on the bottom scale and the number of tickets on the on the y-axis So month-to-month they had sort of a steady line of tickets, you know between four and six tickets So come nine months they still have a fair amount of tickets that they're opening each month You know one or two a week now if you're is anyone in sales here Who would you like come nine months when you're thinking about calling this person up for a renewal Knowing that they have this many tickets. Does this give you like a knot in your throat? Like if they're still having problems so after onboarding this is what it looks like and I wanted to pick someone that had the same Amount of tickets so this is the same amount of tickets but we solved them all and you know most of them in the first three months and Then you look at month four through nine and it's pretty much smooth sailing So, you know salespeople who do you want to talk to red or blue when it comes time to renew, you know So yeah, so that's how you know even if it doesn't solve You know even if we're not solving all their problems We're getting to them faster and we're sort of solving them all in bulk and mass And the pain is kind of over after three months and people will forgive three months of pain You know that sort of you know that that's you know, especially if you say at the beginning Hey, the first three months are going to be really painful But if we do this right it's going to be smooth sailing Here's a chart that I think is you know pretty accurate, you know And so I think like if you set the expectations and meet those expectations pretty closely You're in much better shape than just saying open a ticket when you when you need something so How some suggestions or ideas of how to build a Drupal shop that is focused on customer success So the first thing is know your different clients Like I mentioned there's a lot of actors in the sales lifecycle and the product lifecycle and you know the the amount the customer lifecycle the entire the entire loaf of bread and and I Think what we find and what I found at dev shops Is that the stakeholder is is like I said a pretty small part of that often you have Different people but of similar characteristics, you know You have the middle manager who has been handed this site and usually they have a title like webmaster You know and it's their job to take over this after you finish it, you know, or you have the CTO who is The one who is drilling you on the questions and making sure that All their requirements are met and you have the 11th hour a stakeholder who shows up at the last minute and you know Has a bunch of changes that need to be taken care of that that were never discussed in the 11 months of discovery Prior like trust me. I've been there. I know these people exist Maybe you haven't dealt with them, but I've been lucky enough to deal with these guys so I sort of Get where the get where they're at and know how they can sort of derail the process and so having like like we did at Pantheon we have the same sort of groups of people that we sort of Clustered based on different characteristics and what this helps us with it helps us Come up with relevant processes to work with them successfully because if you send a document a document to a non-technical A non-technical stakeholder or a non-technical buyer and you send the same thing to Like an up-and-coming developer who has been advocating for your shop to come help them Like it's not going to be of the same value to each of them. So a little bit of work to kind of Divide them up into meaningful segments can save you a lot of time And also it makes it clear who you're dealing with through the sales process and also helps you sort of figure out the sales Pipeline better because if you constantly see that you're never talking to the buyer until the very end But the the middle manager slash webmaster is the one who's always advocating for you Then maybe that's the person you should be tailoring your you know your documentation and your tools for Because maybe that's the most important person in the sales process or you know when you talk about renewal It's the most important. It's the person who you're going to be dealing with and you guys know It's like you have to win certain people over and if you win them over You they're your friend for life, but if you don't win them over like they're a constant thorn in your side So I think like understanding that and understanding like the possible roadblocks is really important And I think if you do like a simple version of that and you have like four to six types of people that you work with That's a good start and then You know, I think how you implement this first at a very high level like at the hand wavy philosophy What level really depends on your business model like what we're trying to do here is be more than just a gap between sales and support We want the whole organization to think about the overall customer success And so this means Other things, you know It means the balance between close contact like the onboarding and the audits and that kind of thing and Automation because there's tons of ways to automate that adds value that scales, you know Like I mentioned those two surveys like nice reply if you if you answer if you get a support request for us from If you open a support request for us and we respond back at the bottom of every ticket There's that little survey like what did you think of this on a scale of one to ten? And that's a company called nice reply that you can just add a snippet of code to whatever support desk you use Template and then it adds its own little survey and you can kind of be Consistently kind of asking people how good a job you're doing in support or if you're a project manager same kind of thing Like how is this working for you? Because a lot of times what people say is not how they're feeling, you know, obviously if Eventually you'll start to see their fists clenched and you can kind of get a sense that something's going on But initially people might just be complaining, you know And not necessarily verbalizing it to you and I think this kind of helps as a second check because they might just say, you know what That response really didn't make me happy Let me check on that and I think you know you don't have to respond to every one But if you get a sense that maybe there's someone that is having like to me if I see someone that gets pretty Consistent low scores or a real mixed average like that's someone I want to walk over to and say is everything okay? Like what's going on? Are we having a bad relationship or you guys not working out together? so yeah that and You know Pingdom and things like that are really easy to install and can be installed via You know an API via the command line and having that sort of thing up there is a really easy way for you to kind of see What's going on with sites and be monitoring even if it's not customer-facing Like if you see things are starting to get out of control a notification to you can kind of let you know That it's time to check in on these people and that's a really inexpensive way to kind of monitor down You know past launch what's going on? And then support like I said all I can talk I could talk about support for days But I think that everyone should offer it I think like if it's if it's something that's feasible for you to do offering Drupal support Keeps you sort of in people's heads when it comes time to upgrade to Drupal 8 and that kind of thing But it also keeps you in the loop as far as how things are going I don't know some people have made the executive decision not to do support But I think it's a good thing to do and then kind of lastly I think You know testing and continuous integration are something that is talked about a lot in sessions and things like that But when it comes time to put that into the bid it becomes a little bit Harrier and a little bit more Difficult because it is added time and I think when if a successful organization is one That understands the value of this and understands that it's important to bring that in early in the life cycle And so sales talks about it as a feature You know as a benefit and has the tools to say this saves you money in the long run Because there's less bugs that we have to deal with because of how we we have a great fast continuous deployment process and we use tests So I think that those are sort of for a Drupal shop sort of key things to kind of implement and Then building the team is kind of the most important thing my team is empowered to make decisions My team will give you your money back if they feel like They should you know if they feel like you're getting The short end of the stick they'll give you a refund like I think that's a really important thing to have Have them empowered to do or make decisions about what we should do or escalating problems or things like that Having support team that's just there to put out fires makes for kind of a miserable support team having one that is there to solve the problem sort of empowers them, and I think that that's not necessarily Given or something that people know to do or think about doing And I think you know having people that buy into what you're doing as an organization like you have a company culture I know that the the hiring landscape in the Drupal world is really tough But I think that having a bad egg in there can ruin culture Having people that don't get what you're trying to do if you have you know a specific way you want to do business I think can be really detrimental to a team And then onboarding like covering the high-level stuff I think is important like getting your culture across your values across on that first call with stakeholders and Even earlier in the sales process to let people know what you're about is important Destroying silos is something that sort of came up in DevOps like I think that that's a really important thing to do Like I think project managers should be technical You know I think they should be able to talk to people and understand Drupal to some extent They should be able to explain you know get why it's there that sort of thing I think that you know the customer success manager that role is someone who really should be destroying silos and talking to the product and talking to Engineering and talking to your development team and sort of making in trying to make incremental improvements throughout the process And then finally like what we have what we call it at Pantheon is cakes and it's a really corny acronym for Clarity accuracy execution and empathy which we think is really important in all our interactions So you know we think it's important to give a clear answer We think it's important to give the right answer We think it's important to follow our workflow and our rules and our escalation process and that kind of thing the business processes and Then empathy is the last one. We think it's really important to not sympathize for the customer But understand their position. We know that when developers are going live that go live day They turn into werewolves. We know they're all werewolves on go live day So we try and act as they would in hindsight You know, we try and understand that and take that into account and respond accordingly And then finally like the soft skills part of it I think is really important to me like asking questions at and this is like something that happened has to start at a Managerial level like what is success for your customer like because it's it's not always just a site that launches on time If it doesn't do what they intended to do It's not always a site that launches bug-free if it launches six months late, you know And if it does what they want to do and it launches for double the budget, you know I don't think any of those qualify as success but I think that a site that I site can launch late or not do exactly what they want or Be over budget and still be a success like I think that there's ways to do that And I think a lot of it has to do with how you treat them with the expectations that sales set and then what happens after You know after during the project and that kind of thing And then you know responding to what they said or what they meant, you know We get those kind of tickets all the time where someone says hey I you know we we are a platform for Drupal that doesn't offer SSH access which you know for a lot of developers just Freaks them out and blows their mind And so we have to say we can say no we don't all day long or we can say well What are you trying to do you know and sort of reframing it like that nine times out of ten? We say oh well you don't have to do that or there's another way to do it that we think is better And we can kind of solve their problem without necessarily doing it the exact way that they wanted to or do it in a better way And then creating a connection I think it's really important to be funny to be weird to show your personality like Drupal people are really weird people if You haven't noticed and I think that that you don't have to lose that you know I am so happy that I don't have to wear a suit, you know That like makes me happy every morning that that I exist in this Drupal community Where I don't have to or coming from the managed services world I don't have to wear a Microsoft shirt and carry a black, you know vinyl suitcase like that's awesome And I think that it's important that your personality comes out because I think it's it's important in the whole sort of Relationship that you have fun and that they understand that you're a normal human being and that when the time comes You do say the hard stuff like if they're doing something wrong having the difficult conversations I think is hard for people that we bring on initially, you know, and especially if they're developers They want to please they want to fix the situation, but sometimes Telling the customer. I'm sorry. You're not being reasonable or this is never going to work the way that you want to do it Or you know when I worked in the web development world. I had to explain to people that You don't want your menu items to be PDFs like they wanted every menu item to just open a PDF Because what if people wanted to print it out and like to them it made total sense and like I didn't even know how to explain Like why that was the craziest thing I'd ever heard But I think like saying that and explaining it to them to where you know balancing the line of like oh my god you just said that and That's not the best way to do it and you can print out webpages this way or something like that is really important, but That's an extreme example But I see I saw a lot of websites get built that had functionality that Every developer was sort of holding their nose at but did it anyway because the project manager had promised it And that's what they were expecting and everyone agreed that it was a bad idea But you did it anyway, so I think that does not spell success ultimately for the customer. I Got through this much faster than I thought so That's sort of what I wanted to say. I hope it was a value But yeah, so thanks And I'm happy to answer any questions about anything personal problems whatever what to get your date for the next anniversary Sir so you're talking about moving them to other positions or having them like balancing the Grinding out tickets from other stuff Yeah, I think We sort of set I think it comes from above to a certain extent. We set At least an 80-20 rule like we you know we sort of set a value that we think that they can achieve and we have rough ideas of about how many tickets per week we want them to do and Initially, we set a hard number and we found that there are people that I just Love and think they do a great job and that number is way too high for them like they're gonna they're gonna close 40 tickets a week and I can make them miserable and they'll quit trying to get them to do 50 or I can find other stuff. That's interesting, but I think We're we're a smaller organization than than yours So we sort of have the ability to you know, they're right next to the technical content person So but I will say the funny thing about developers is like I tell them we don't want you working on tickets all the time You know so block off a day where you're doing other stuff and they will continually ignore me They will just keep working on tickets and it's a problem that I should be happy to have But I don't want them grinding themselves into cornmeal, you know So I think like some of it is sort of a managerial decision but I think that there are some tickets that are just not short easy tickets and I think that having working in teams has worked for us where they can hand over tickets or at least You know our ticket structure we try and have people adhere to a process where where it is kind of Where it is What's the word kind of isolated to where if they were out sick someone could pick up the ticket and take off Where they take up where they left off Does that answer? Yeah It's hard Yeah, yeah Yep. Yep. Yeah, and they get ones, you know some we don't do everything right We like please don't think that I am perfect at this like we are you know Some of these teams that I mentioned are one or two people that we're trying to grow and figure out But I think and I don't hold them to it like I know that my team has bad days, you know And I know that there's some customers that like What I tell if there's a customer that's irate then we just let them sit, you know It's if it's a downtime thing. That's a different issue But if they're just irate like there's no sense in me making my staff miserable to deal with someone who's frustrated and Like and that comes from me because my staff is probably much better Like I can calm down situations really well, but I'm also really good at escalating situations So I have to be careful of it myself I think either way we come sometimes you have to escalate it and then come through the other side together But but yeah, it can be tricky But I think like having that constant kind of feedback is important, you know and the average comes out generally good Like everyone has their bad days, but overall You know people want it like they we want to work together, you know Sir sir in that beautiful shirt that handsome man in that attractive shirt Right so in kill support it sort of goes back to like the kill the Buddha quote that the Buddha said like You have to like sort of find your own way And I think like with kill support the goal is to kill the misery that's involved with support more So like that's kind of what I mean by that like support comes in and they can do more proactive stuff Or the or they have the resources to solve the problems that come in like so an example of the sort of the Evolution is you have a problem and I can pick one like say One thing like I don't know if you like the first thing that comes into my head is a WordPress question So like there's no PHP sessions in WordPress. You do everything with cookies. So Because we're on the cloud People have these modules that create text files to store session information on the server because we're on the cloud a File may land here then the next web web request comes in here So there's like a file and like no connection and it's not working So the first step in support is like you react like hey, that's not gonna work You have to figure out something else the second step is we come up with a document stating that's not gonna work So everyone can do it and we can kind of point people at it and make it a little more scalable Then we worked with our product team to come up with a module that fixes it and we just published that to Wp.org and point people to that So then we create kind of the solution so we sort of move upstream and try and solve the problem there So that's one less thing that support has to like you'll never kill support There will always be questions But you can constantly keep trying to improve things for them and I think yeah support is like I think that if it's in Your business model I think there's some really well-known firms that have said we don't do support and that works fine for them But I think it's it's even if your support is limited to we do contributed and security updates I think that's a good start and it's a great way to get new people in like new developers and team members Into Drupal and kind of train them on that kind of stuff Good question. So I sorry. There was a note here to repeat the question Should onboarding be iterative if you constantly or if you're making regular changes to a site and I think yeah It should be I think you should The ultimate goal is to create an onboarding session that is an onboarding process. That's really fast and scalable so because it's not just going to be for that reason it'll be because they the CTO gets replaced and some new guy comes in and he has you know He has no idea what you do or you know, they may want someone else You know some other dev shop that they know and so like having this sort of repetitive process and say oh you have new People let's get them together for a quick onboarding call And if you have people that can do that really quickly like for us Those two calls are a half hour each and they're time boxed at that and and that's because we can't get people on the phone For much longer than that that was the magic number of saying developers 30 minutes like we have we have ordered Chinese food across the country for them So like we're paying for your lunch if you'll just sit down and listen to us, you know and things like that have worked for us It's bribery. It's trickery trick them into learning any other questions Awesome. Well, thanks a lot