 Hey all, welcome to the Thursday Functional group update. This is the support functional group update. I'm the Matos from the support land team I am gonna full screen and we'll dive in if you have anything that you throw in chat I'll dress it at the end. So let's go ahead and get started here All right, so diving right in let's jump into the highlights We have one offer out right now for an APAC service Geez support engineer and I'm really really really excited about that. So that's really awesome and we have two more Support engineers in the late-stage pipeline. So that's really great We'll go from there and we're looking to bring them on as well and we have two other Positions approved so we want to hire at least two more This is gonna help with load and help us grow this team so that we can support our customers better and faster We've made some new processes to improve response time, which I'll dive into a little bit later I want to give a shout out to the support team because we've been doing a great job of getting documentation updated inside of Support just what we do internally as well as for get lab the product as well as our Initiatives in helping each other learn and grow. We've been averaging one parent session a day this quarter at least one Which has been phenomenal Go ahead did somebody pop in All right, cool, I'm gonna keep going I can't see you all because I'm full screen. So if anything's crazy I'm just shout out But otherwise we'll keep it moving So we get to the thangs section and these are a couple things that I want to talk about Things that are on supports mind and I know for a factor on salesmind are breaching tickets We'll talk about that. We'll take a quick minute to talk about okay ours. We have a new concept services support Here's a link to an Issue where I want to talk about our plan to maintain get host We need to figure out what needs to be done and prioritizing and making sure that there's alignment there So we know how we're gonna make sure that get host is the best it can be The other piece here that's really exciting is we're working on a new flow here for trials This has been a long time coming. So that's very exciting There's a work in progress and our that should be wrapped up later today And I will announce that on the sales call on Monday to clarify with sales on how to get support for trials The last thing that we'll talk about is some confusing product stories that we have from Customers who've tried get lab and ran into some issues. So Every support call I like to show the backlog right now. It's pretty flat. We're trending ever so slightly down Which is good. We've tamed it. We've gotten our handle on it. That's good Things that might make this go crazy 10. Oh, that's what our minds are. That's where we're at That's what we're thinking about when we release 10. Oh Depending on what happens in 10. Oh, this could go out of control. So we're just trying to do everything we can to prepare for that This table I normally show as well. This has been really important to our process. We've been used Sure that support and by that I mean that we're not creating debt and you could see any green Means that we were at least 100% efficient if it's red that means we created debt I've added a new column here which is really helpful because You cannot compare week over week as a percentage because each week has a different value actually so the last new column tickets gives us an absolute value of Actually, how much of the backlog we've made if it was red We've added to the backlog or if it's green that we've taken from the backlog So these are very important things to see for example, I'm going to highlight right now week 26 With 86 tickets were added to the backlog. That's going to be relevant later as we dive in Now we get to the hard thing. This is you know, value I get lavish transparency we need to be transparent about what we're delivering and This is specifically breaching tickets and what that means is in support We have tickets that come in every email that comes into support gets converted into a ticket a ticket gets an SLA clock a service level agreement clock that clock is depending on their plan Where they've submitted the if they're a comm user or things like that, which we adjust their SLA So across all of our SLAs premium regular every SLA in Q1 We had a 75% SLA achievement Obviously, we want this number to be a hundred percent in Q2. We hit 78% so far in Q3. We're at 70% Looking at these numbers. It looks like oh my gosh Q3 We're doing really bad, but I want to show more of the picture here that makes it really important On our premium support page where we talk about when you buy support what you get we Advertise this 12-hour window that we will support you from 8 a.m To 8 p.m. Eastern Standard Time, which is a 12-hour window and in Q1 We were using that 12-hour window in Q2. We were using that 12-hour window and right at the end of Q2 We are trying to get to 24 or 5 advertised coverage a few support calls ago Functional group updates. I talked about this and on our effort to getting there. We've bumped up our Business hours to 20 hours so that means that the clock is running For eight more hours a day and that means we have 60% more coverage on the board We're saying okay. We want to be responsible for 60% more and we only had an 8% drop So we're doing better than we were before in the sense that we have more time that we're covering But we need to get we need to get this to 100 and how do we get there? So those things are on our brain and I'm going to talk about some ideas here So the old flow that we used was very simple. It was in computer science terms You would call it a FIFO first in first out We would sort by breach clock by the SLA clock Which would determine whatever one is going to happen next or if it has already breached that is where we go But we started looking at that and I want to give a shout out to Colin on the support team because he came up with this Great idea. We made this new flow and it's a lot more Complex and the decision tree here is more difficult But the way that we're doing it is in this order Effectively, we're focusing on premium customers that are about to breach first We don't want to make more of a mess So one we focus there then we focus our attention on any premium customers who we may have missed their SLA We've already missed it. So now we need to clean that up Then we do the same for our enterprise edition customers and then we do the same for any enterprise edition Customers that may have already breached this lets us make sure that we don't by focusing on Before what would happen is if somebody breached we work on them and then while we're working on them Someone else may have breached which is going to affect the numbers So and I want to take a step back to be really really really clear here. I've done support for a long time and It's really easy to game support numbers I want to say that I want to own that and that is not what we're going to do at get lab That's not what I want to do ever. That's nothing, you know We could build a script right now that if a ticket is going to breach within 10 minutes a robot replies and we'll never breach and to me That is the antithesis of good support that is not what I want us to be doing that is not how I want us to be thinking about this This is an important number and an important metric, but good Accurate support for our customers is the number one priority and then we go fast So I want to make that clear So I have some graphs here and the thing we really want to focus on are the last two weeks The last this week the column that we see there week 32 We've already seen a huge uptick from where we were with this new process So that's really exciting and I expect this to rise week over week because we're focusing on Making less mess and cleaning it up faster this next graph is incredibly important because You can see this huge spike and you're gonna say what happened there if we look week 26 What happened on week 26? That was the week that we released get lab version 9.3 and when we released get lab version 9.3 we had 86 tickets going to debt because we had over a hundred more tickets Over the average were created that week. Somebody is unmuted. So check your mic. I hear you typing So I want to emphasize to the team I've been asked in a couple of meetings a couple of times. What can we do to help support? How do how can we get developers to come in and help we need to get our releases? 100% if we have any flubs with our releases if they are not as smooth as possible This is what happens. We get backlog Then we go into debt and then we have to work out of our breached tickets and you can see over the past six weeks We've drastically dropped week over week push that down. We've gotten faster and faster and worked through the debt So this shows that you know, we are able to Move through but at any moment Our risks are releases a new release If if there's anything wrong with that release, it's going to blow us out of the water So and that's going to be helped as we hire more to give us more coverage But I just want to keep that in mind. This is the best graph to show that to the team When a release gets a mess We get backlogged our breach everything starts to breach Then, you know, we fail and we need to recover from that And this last graph shows um, again focusing on the last two weeks. This is our premium sla metric Just for premium customers their first reply time and their next reply time We've seen a huge uptick there and that's very very exciting And if you're wondering about week 19 why it was like at 100 and dropped That's because the way that slas were applied. I do not believe was correct around week 19 So it's that data is inaccurate. We've adjusted it and this is and this is what we see So I'm sure there'll be questions about that. We'll dive into that in a little bit But I want to move on to this idea of services support Right now we're testing our documentation and working everything we can to document our processes All across support so that we can scale for example this week Cindy and I in a parent session figured out how get host backups work Before that there was no documentation. It was trapped in Drew's brain So we figured it out. We've written that Drew's reviewed that that's great. We now have documentation on how that works That's in preparation for this new Group that we're building here focused on services support What's happening right now is We have a really great support team really smart with a lot of technical knowledge And we are focusing our time Three of us at this moment myself Arihan and Cindy are focusing our time with get lab.com issues and get host issues And these can range from help my account is broken to I purchase something and I'm not sure what I got and I'm not sure what broke And these are problems that require a smart person to solve someone who is Detail oriented and smart, but they do not need to have deep linux internals knowledge So we are spending our time solving these problems when we could be diving deep with customer problems With their instances and getting bugs fixed faster. So the focus here Is on get lab.com and get host and building processes that are going to Enable that support. I know that there are a ton of people that can do this Services-based support that do not have the deep linux internal skills that they need to do What a support engineer does right now They could learn that where there's plenty of room to grow at get lab and build support process and build tooling to make that Experience as fast as possible. So I'm very excited about that That means that going forward as we develop out this team There will be an ee support group that will focus on paying ee On-premises customers and those customers, you know, we're going to dive in and you need technical knowledge You need to understand linux. You need to understand all the crazy stuff that get lab gets deployed on So in that we're looking to hire about three services support members By the end of the year and until we do that and as we do that we will fill the role We will act as services support to help Get that process in order get those things set up and build that function out That's going to help us because every time that we're able to hire a services support staff member That means that one of our support engineers is going to be able to then focus on ee support Which means that we've grown our ee team by one, which hopefully means we're going to go faster and and Just crush. So that's really exciting. So I want to take a second to Talk about our okrs our goals for the quarter. We have three We want to log every time that we need console access on gitlab.com and how we can avoid that So I have an issue here that you can check out And we we right now The way that we do it is anytime we reach out on slack. We have that captured in zendesk So we need to just transfer that data to issues So aria hunt cindy and I are going to be working on that making sure that that's clear and getting those issues created Reducing time to solve this right now is at risk is failing because we have a ton of breaching tickets We need to get those down. We're working through that. You saw us moving Through that and we're getting better there and our new processes should help I think we may be able to make this up by the end of the quarter But I think it's going to be hard to do So we may not reach that but on our way to reaching that we may have found better processes that help our team And we also want to use service desk for security related issues instead of zendesk And I have things set up and I want to test that later this week. So that's exciting To dog food our product. This is a good time to take a step back and say If you're a lead or if you work on a team Take a moment and think about the processes that you're using to solve your problems This past month for us. We evaluated a bunch of things that were not working change them and solve immediate results Is there a chance right now that you're using a process on your team that worked but is not the right process right now There was a great article on the intercom blog They were interviewing the director of support at slack and she talked about the fact that at slack their support process changed Changes about every nine months because their problem set changes Which is we're embodying here and I'm wondering if that applies to you and your team. So keep that in mind There might be a process that you're using that just doesn't work anymore. How can you change it? So in that vein there's a process in support that doesn't work and we are figuring out how to change it This is around social engineering. So I'm going to share a really quick story with you all Um Spoiler alert. I've been socially engineered not at GitLab, but at a prior job and I'll explain what that is if you've never experienced that or know What that is? Effectively what happened was I was working in support customer called in and said, hey, you know, I need to change the information on my account This is the information I have. I need to update this email address Which is a benign ask They verified all of the things that we asked for they knew the address on the account the email address that was currently there They knew the billing address They had the credit card information Which was what we used as the process at that time at that company and I said, all right, sounds great I changed their email address on file and thought nothing of it made a note that they called in and changed their email address And about an hour later, we got a call in from somebody that said hey Um Actually a disgruntled employee of mine Who we are firing just called in to change all of the information on the account How can we regain access? and They then the disgruntled employee changed all of the data on the account so that this person who was actually the rightful owner Could not authenticate because we would ask the questions. Well, what's the address on the account? What's this? What's that? They went in and changed it all and at that moment You know, I was socially engineered I gave someone access to something that they shouldn't have And there was no way to confirm the rightful owner So we had to figure out how to how to debunk that and ultimately With other people in the team's help we were able to do that But at get lab right now we have these scenarios where customers are are saying hey I can't access my account or I need this or can you tell me the email address associated with this account? And we really need to figure out for com How we're going to proceed with this to avoid socially engineered attacks things like that I have two customers in the queue right now that i'm working with trying to figure out how we can authenticate them To verify that they have access or that they should have access So that's something that I want to keep in mind and that's something that we are working on And that brings us to this idea right now that we have a ton of products and In this past month, I've seen two instances where confused customers were very confused We had one where a get host user had a problem They really wanted our attention. So they wanted to get by support to get a four-hour sla and get emergency-based support Um, but they ended up purchasing a dot-com silver support plan which gives them four-hour support for com So that that didn't really work. Ultimately. I saw it. We fixed that we did it But that wasn't right And then we had a dot-com user Who needed support and they wanted to get faster support. They ended up purchasing a one license e license To try and get support from us faster And that was not that they should have purchased a silver plan So this brings us to this idea of right now our product matrix. You can have get host with One of four active plans one of four legacy plans You can also have runners and you can also potentially have c e e s or e e p You can have get lab com with four plan types You can also have on-premises with a legacy plan and e e s and e e p and potentially going forward e e p Or excuse me e e ultimate So right now we have a ton of offerings, which is great But when it comes to support, it's not a hundred percent clear to our customers Where and how what you get when and how, you know, that's exactly that sentence was confusing That's how it feels and I want to just emphasize that I made an issue here I'm sure there are other customers that are in this boat that have purchased the wrong thing And right now we do not know and when they go to get support and we find out that it's wrong We're going to fix it. Um, but that's going to lead to friction So this is something that we want to think about as a company. How can we streamline this and make this clearer? Because people are buying things which are good. They're trying to get access to support But they end up buying wrong thing which is bad So we want to think about that if you have any ideas or it can help pop in that issue and and would love to hear So We get to our needs section We need to fill a mia Our us team we're potentially going to have two offers going out, which is great or excuse me our america's team We're looking for one more an apac That is potentially going to be filled our a mia team right now is two members We want to get that up to four So that's something that if you know anyone in a mia if you have any ideas on how we can get traction in a mia We'd love to hear it. Um, I want to propose, you know, a german entity Maybe that we can tap into the berlin market or things like that Because I think that there are people we're just not able to capture them and i'm not sure why But we absolutely need a mia support. That is our hugest weak point right now Sales if you're working in sales Please please please go to your accounts Verify their support level. This is what we're using in zendesk to make sure they get the right sla We have a couple of customers that have Interesting products custom agreements and things like that That that may have been legacy or something that we've converted them in some way And if that's not reflected appropriately in sales force, it will not be reflected appropriately in zendesk I saw an instance of that happen this past week because I knew the customer I was able to give them the appropriate support But if I don't recognize the customer, they will not get the appropriate support So check sales force dc make sure that that's correct I also want to say a sentence here that it's not my favorite thing in the world, but I think it's important Support has been really helpful. We've been doing everything we can to help every department But as you see we're not hitting our sla targets and that's something that is huge and we need to So if anyone in support says no To an ask that you have from them It's probably because of breaching tickets and we need to focus on that And I've made it clear to the support team that that is our number one priority Make sure that our house is in order before we go and help other teams and help out with other processes We need to that's what we're being measured on and we need to make sure that we're hitting them The other last thing just as a reiteration We want to make sure that customers know what they have what they get with what they've purchased And also the other products that we offer because maybe something else is a better fit I think that that's really important to Reiterate so lastly give a shout out to everyone here Collin came up with the idea of not making more of a mess for ourselves and building a different queue It's a little bit more complex, but it's working. So I'm happy about that Adam has been working on a tool called omnibus vagrant, which has been insanely Helpful to increase our speed and debugging problems and collins also been working on support bot and got us some new views there I also want to give a shout out to stan He jumped in a pairing session with chen j did a jump a ton of great stuff and they developed and fixed some things there So I was really happy and I appreciate that stan was willing to jump in and help us there And I want to give a shout out to sales. You all have been great in understanding that We are not achieving what we want to achieve We are not as fast as we want to be right now, but we're working through it Thank you for being understanding as we're working through that new hires are going to help We're building new processes Etc. So I'll open the floor to questions. I'll take a look at the chat I got 24 in there. So I'm kind of kind of scared to see what I got, but let's see what we got going on here So um shout out to chen j for the docs Should we treat git host customers separately from ee? So yeah, simon. So what happens right now? Git host customers come into our services support side and they do get treated separately from ee Unless they have an ee subscription And if they do then they land on the ee side because they have an ee subscription. Uh, so that is Um, that's how that gets handled molly asks. Where do ee trials come into play? I'm assuming that's coming in with the breach tickets and things like that That's something that we're we are going to figure out this week when I finished that mr What sla we want to give to trials? Obviously, we want to give them what they would expect if they had support But in the scope of actually supporting our customers who've paid us And supporting people who might pay us there's a tough balance there. So we need to figure that out And that's something that we need to Focus on but we're building a new flow, which is going to help us get better data as to what is the volume of trials So that will help and then we'll be able to see how much pain trials may be causing us Then we have um someone the git lab moderator says can you clarify Our premium support commitment 24 7 not 27 So premium support right now is a four hour sla and that sla is based on business hours And business hours right now are 27 So they technically have a 27 uh sla and it does not or excuse me 25 sla But our premium customers also have access to Emergency, um, they have access to that So they can trigger um an emergency at any time So if they trigger an emergency will respond within 30 minutes So any normal premium ticket and i'm Sorry that my camera is busted right now, but any normal ticket Will land in a 25 view If they have an emergency it will page the on call and will give them a response in 30 minutes So that's something there. So toon says what are the consequences? And I know I pronounced your name wrong. Uh, what are the consequences of when a ticket reaches? We are sad. We've failed a customer. Uh, it messes up our metrics. Um, The consequences are we've failed, you know, and they've waited longer than we've said they should wait to get a response Depending on the nature of the ticket It might mean that they're extra frustrated or sometimes for example We've had some tickets that breach where they said, okay, thanks And that we've had so many other tickets in front of that one that by the time we got to that one Just saying thank you to the customer We were we breached and so that's what we're trying to also get a handle on making sure that Simple cases where we should not have any breach happen that we're handling. Uh, so that's that's one of the things there. Um Who is user gitlab? We think it's larry. Um Then we have Victor has uh, talks about social engineering. Uh, so that's something that we we talked about in there Um, and that's something that we're trying to grow. Thanks for your support everyone talking about, uh, trying to Support us in improving. So I just want to open the floor if there's any last questions if anybody has any last Hey, wait, this is this is victor. Um, so you talk about, uh, love just Evolving your process all the time So are you doing things like, um updating FAQ sending, you know, people to different pages for support? Like what what are the steps you are doing? Just at a high level or examples that you can share with us that that have been effective Sure, and and in our sense a lot of our process has been just How do we handle the influx of tickets? And in that vein that's where a lot of our process focus has been but other things we've done there have been just Making sure that our internal flow documentation is correct, which we didn't have, you know Like I said as of two days ago No one besides drew knew how gitlab or git host backups worked You know, so making sure that that's documented clear and spreading that knowledge As well as that we've been doing Yep, we'll end the call. We've been doing some stuff where the Making sure documentation in gitlab docs is up to date. So I'll end that call victor. We'll talk more about this later Thank you everyone for joining. Have fun on the team call. See you soon. Bye