 Right, the time is upon us. I'm gonna go ahead and share my screen. And then if I can get someone in the audience to make sure that my screen shares properly, that'll be great. And we'll go from there, starting the support functional update. I see your screen. All right, awesome. Can you still see my screen? Yep. I still see your screen. Great. Welcome my favorite hooligans to the March, 2017 support functional update. Very excited today to bring some new information to you. Last time when I started the support functional update, we talked about what the support team is, the customers the support team is responsible for interfacing with. But I wanna take a step back and talk about how I view what support is responsible for and the context there. And it all comes down to the word risk. And I think that every business venture is a risk and the product team decides on the risks that we're taking, the things that we're trying to do, where we need to go, where the ball is going. The developers then take and implement that risk. And then the support team is responsible for reducing that risk. Understanding, fixing, clarifying. And we get that information through the customer, but our job is to make sure that product is going forward and we're getting as much information to product as possible so that they can continue to make choices and we reduce risk. So that's something that I want to emphasize that this is the way that I think about the support process, this cycle that happens as we release new versions of GitLab, we are responsible for reducing the risk of GitLab. If we dive in this last, since the last functional update, we've had some great accomplishments that I'd love to share. First, we've hired Adam Mulvaney in APAC. If you haven't said hi to Adam Popover and Slack, he's Adam M, say what's up. He's a wonderful guy. He's ramping up very quickly. It's awesome to see him jumping in and getting things done. Something that took some time that was a cross team effort, everybody involved with scheduling, we have a really clear escalation process right now for bugs and things that support fines. All of the risk that we find, we are now very clearly able to give that to the teams that can fix that. So that's really, really exciting. This was something that was a little bit frustrating as we worked through, trying to understand how to get things fixed. But I'm very, very confident and things have been getting better. So this is awesome. So I want to shout out to the teams there that were involved. We'll be diving in a little bit to relevant data. This is our constant struggle, is getting the most relevant data and getting that out of Zendesk and using the Zendesk tools to get that data for the team. And I'll show some examples of that later. Something else I'm very proud of, an initiative that I started. Every support tech had a four day work week at some point in March. The work we do is absolutely emotional labor. It is absolutely something that can be draining. And I think this is sustainable going forward that every month the support team, every person can have a four day work week at some point. We did, we were crushing. So I'm very proud of my team for being able to do that. And I'm going to try and keep this going. We'll see how it goes. And I think everybody enjoyed their days off. I heard that Chris and Cindy went to Six Flags. So that was exciting to hear as well. The last piece that I'm very excited about, we are developing a tool to help us coordinate with the sales team. We're calling that support middleware. What that does is let us know what support each customer is eligible for so that we can provide that, track that, make sure that we're delivering on that. The first version of that is now functioning. It is tagging all of our premium customers. Jose and Chris are developing version 1.1, which will start making sure that all of our enterprise edition customers have the proper tags. We have some legacy plans, and that's where this comes in with legacy plans. Some of the features are slightly different. And we wanna make sure that we're delivering what we've contractually agreed to. So middleware is gonna help us accomplish that. It's already working on the premium customer level and we're moving that down into EE as well. Last time that I jumped up on this stage when we talked about goals, hashtag goals specifically, we talked about shrinking the backlog. This is support issue number 17 in our tracker if you wanna check it out. And you can see in January 20th, we hit a peak in the backlog of 14,000. As of March 21st, this is about cut in half. Now I'm gonna be very honest with you all. This is a little bit of a vanity metric. And the reason why it's important that we keep pulling things out is we don't know what those 14 that, I'm identifying what those tickets are, what those things are, so that we can make sure that we don't have any hanging chats, if you will, or anything outstanding. So trying to make sure that we can be as efficient as possible. So in that, I've figured out a way to get a more accurate picture of the true support backlog. These are the tickets that our team is actively responsible for, tickets that were created in what we call tier one, tier two, tier three. And you could see that it's been ramping up slightly, slightly and in the last few weeks, we're about to turn a corner and we're about to start minimizing that. And that is this is our graph of risk. This is instances of a customer identifying something that we need to help resolve and bring to product in some way, shape or form. Whether it's documentation updates or an issue in the EE or CE tracker or getting a dev to help us figure out what weird state a client machine is in. The one thing I also wanna note is that about 1,500 of these tickets have a special tag that we've added called pending backlog. These tickets are older than three months old. They were sitting there and they were pending, meaning we reached out to the customer and the customer has not followed back up with us. So it's most likely that their problem is solved or it is no longer a problem, but we have not reduced that risk because the ticket still exists in a pending state. We're gonna periodically be closing chunks of those tickets as we go through. I'm working with our team to go through and make sure that we can close some of those, which is gonna help us get a more accurate picture as we go through. Again, I want to make sure that we know the risks that are on the table so that we can then identify them and move forward. That's the key goal of support. This is one of our OKRs and I reported on this last time. This is a little bit more in depth. This is just tier one, tier two and tier three. Last time when I reported on this, it was all of the tickets in Zendesk. So we were seeing Twitter responses and things like that. And the most interesting piece about this graph, about this data, up is bad. Up means that we are slower, but when I dove in to see why we were slower, what was happening was there were tickets that were from the pending backlog that our team or the customer were closing and these tickets were two or three months old or things like that, very old and that's pushing up the time to resolve. The way that we're combating that in the future is we've set up an automation that will close pending tickets after seven days. So that's gonna start to catch all of that cruft to avoid this from happening in the future. I'm also gonna be setting the tone with the team that if a ticket is open longer than 30 days and it's still relevant, then we're really doing something wrong and we need to figure out what it takes to move that ticket into an issue or whatever it takes to get it moved. So these numbers are gonna be a little wonky again as we saw last time, but I have a little bit more of an accurate picture which is helpful for me and helpful to dive in and see what those tickets are. I'm gonna try and work with this metric to see if there's another couple of ways to slice it, quartiles or something else to help us see and get a better sense of what's happening with time to solve in the last month or so, that kind of thing. One of the other goals of the support team right now, we are a relatively young team. We want to be more self-sufficient and the way that we're starting this is by measuring the amount of times that we reach out and slack. When we ask in questions or we ask in sales or we ask anywhere that is not our team, we're tracking that and we're trying to track that so that we can see insight. This is data from January that shows our top three reasons for reaching out. We're sales related issues, so license renewals or things like that. GitLab.com, things related to repos being messed up or something that needed Rails console access on.com and then the third one from that is Git Host. And if we go a little bit further down, we can see CI and LDAP as well. And this is really great because now going forward into the next quarter, I want the support team to focus on Git Host, LDAP and CI. Those three things are clearly in January where top of our list, data for February I'm still going through. But these are things that were a problem and let's see if there continue to be a problem and this is how we're gonna address them. Another thing that is gonna help the sales team is interested in joining us in Zendesk which is really exciting because that means that there will still be an escalation but there will probably be a lot less friction in getting the data between teams. So that's really exciting. And this is just one way that we want to be faster and more efficient in the ways that we reduce risk. Now, speaking about efficiency, this is kind of the way to think about support as a well-oiled machine. These are the weeks. The created column is number of tickets created in that week. Solved is the number of tickets solved and the ratio is exactly that, the difference. And you can see in the last two weeks, the two weeks prior to this week, we were net positive which means that we created no debt. We resolved at least as much risk as came in which is exactly where we want to be. We want to be at maximum efficiency which is one. And if we go over one then that means we're buying back debt that we had from before. So we need to continually focus on this and this is the metric that I'm working with the team the most on to understand tickets are coming in, are we able to keep up, when, where are they coming in and how do we maintain maximum efficiency. And that's something that's on our brain. So it was really exciting to see in the past two weeks that we hit maximum efficiency. Ticket load was down a little bit but it's still achievable and that's something that we're gonna keep an eye on. I don't have anything to ask for from Greater GitLab. I do wanna shout out some teams though. Things have been really, really great this past month. We've had a lot of help from production, from product, from dev. So please keep making GitLab better. However you know how that helps us and we're gonna do the same. I wanna shout out specifically to the dev team, especially Gabrielle, Douglas, James Lopez. You guys helped us out with some serious issues and jumped into calls as well as Felipe jumped into some interesting customer calls. So that was super helpful. We appreciate that. And lastly, I wanna give a shout out to Beyonce. And if you're wondering why that's relevant, I'm giving a talk next Saturday in Philadelphia. This is my opening slide. This is Beyonce defining Beyonce and why she's important to the support process. It will be live streamed so you can tune in if you are so interested to know and understand why Beyonce is important and relevant to the support process. I am going to stop sharing my screen and take a look at a chat to see if there's any questions. If anybody has anything, we'll go from there. So let's see. Sean McGivern says he's a risk implementer. What else do we have? Yob wants middleware to be renamed Rocket Fuel. Is there a staleness criteria? I think Victor asks, is there a staleness criteria or is it a case by case basis? I assume you're talking about ticket backlog. If that's the case, right now, stale tickets are anything older than about two months as we're considering stale. But going forward, I want that to be as tight as 30 days. We want our cycle. I want to make the cycle as tight as possible and that's gonna help us be more efficient. So I was referring to, you mentioned like some customers don't get back to you. So is there a date before which you close it and you don't care about it or do you look at each individual ticket alone? So in the future, as of two weeks ago and into the future, it will be seven days. After three days of not hearing back from us, we will send an update and say, hey, it's been three days. We haven't heard back. If it's still a problem, reach out. And if we don't hear from you, this ticket will be solved in four days. And then in four days from there, it will solve itself. And that helps us address the backlog mountain, you know, getting higher. Definitely. Thank you. But for the pending backlog that we do have, those 1500 tickets, we are going on a case by case basis just to be a little bit more sensitive just because it was pre that system. So that's where it gets a little bit difficult. And DeVette's answer looks pretty relevant as well. It's awesome. Let's see. Jose asked for, what is the link to the live stream? I'll paste that into general as well. And then Molly says, how do you handle tag EE trial support requests? Arihant says that they are handled the same way. And yes, my understanding is that an EE trial, as long as they are in the system, we will see them as EE. So that's the next iteration of middleware where it's going to automatically do that. But right now, usually the handoff happens. Molly, I see you pass things into support all the time. BDRs are passing things in. And if you pass us a ticket, then we treat it as a customer. So our process right now is treating it as a customer. In the future, it will automatically, it should automatically be tagged as well. So I hope that helps answer your question, Molly. If anyone else has any other questions, happy to answer them. If not, we can call it. All right, let's see. Jim says, how are things going with knowing what level of support a customer has upon ticket creation? And this goes back to middleware, or as Job wants to call it, Job wants to call it rocket fuel. This is the tool. Right now it's tagging just premium customers. And we're auditing that and building reports on that. The next iteration that Jose and Chris are working on, which is targeted to be delivered tomorrow, will tag EE customers. There is a little bit of a wrench there where the EE customers have six or seven different like legacy plans. So that's going to be difficult for us to work our heads around. I'm learning more about the legacy plans and where they subtly differ. So the progress is going, but it's going to take probably at least until mid-April before it is 80% functional where it's getting things. But yeah, progress is incremental and we're moving forward. And I'm very happy with that as we go through. Cool, I don't see any more. If anybody has any, this is your time to speak up. Regis says 60% of the time it will work every time. And that's what we're trying to avoid. We want it to work every time. We want it to work every time, which is proving to be increasingly challenging. If you wanna, if I can wax poetic for a minute, one of the challenges is Zendesk creates organizations, which are companies, creates them by domain name. So we have some EE customers who are using generic things like Gmail and Yahoo. So they are not all part of the same org. So it becomes this very interesting challenge of how do we sync multiple things? It's wild if you wanna learn more, talk to Chris Wilson and Jose about it because it is a fun challenge. But I'm gonna call this one. I haven't seen anything else pop in. And thank you for joining in to support Functional Update and I will see you all on the team call.