PagerDuty, Inc. (PD) Earnings Call Transcript & Summary

Thanks for joining us. We have Jen Tejada, CEO of PagerDuty; and Howard Wilson, CFO of PagerDuty with us today. Feel free to ask any questions in the platform on the left side of your screen and we'll be -- we'll work those in to our conversation. So Jen and Howard, so glad you could join us today. Welcome.

Thank you, Kingsley.

Thank you, Kingsley. Great to be here.

Great. So let me just start with -- just, I guess, broadly, should we think about DevOps trend, what developers typically do and what IT typically do. It's been -- the gap has been closing. And developers are taking more ownership of running and maintaining the apps that they build. So -- but if you compare that trend today to maybe 4, 5 years ago, what have you seen in terms of increasing momentum or just how do you see that trend develop?

Well, I think even a decade ago, our founders bet that DevOps was going to become mainstream. When I joined PagerDuty nearly 5 years ago, it was still early. Most of our business was coming from early adopters, the tech community and companies that were already really either native digital companies, native cloud companies or relying heavily on the cloud. And a lot of development teams were still relying on operations teams to manage their services and production. And what's really been interesting is the developer community has become so influential in business as businesses have digitized. They sort of went from being the folks kind of behind the scenes and on the back end to really architecting, designing and owning the end-user experience, the brand experience, making sure that transactions close, that business actually can run the way we expect it to run. And as that's happened, I think the developer communities had more influence across the organization, influence on how things get done, how work gets done, the culture of the way work gets done. If you think about our app ecosystem, when I joined the business, I think we had less than 200 technology integrations in our API-based platform, and now we have over 500. And most of those are initially built or required or requested by the developer community. So we've really seen this transition to technology leadership coming from the developer community, but really, they're those -- they are the people that are driving digital business. And the pandemic, frankly, has accelerated that. And one of the trends that I see is, if you look at leadership within a technology organization, historically, CIOs might have come from program management backgrounds, big consulting backgrounds, they had run PMOs. Now you're seeing large traditional enterprises hiring very technical leaders to drive their digital businesses and even drive some of their revenue-generating businesses.

Yes. That's a great overview. You mentioned the 200 integrations are now moved to 500. And there's certainly a lot of internal development that went into that, but it sounds like the market, in some ways, is coming towards you, and that's what your partners and customers are naturally gravitating towards PagerDuty. So I guess is that what you're seeing? And then it's -- what are some of the drivers that make PagerDuty sort of like a platform to be a partner with and what your use case is?

Well, I think when you are innovating and sort of designing in a category, it often takes the market time to catch up with you. And that has been the case precisely when you think about our first sort of category, which was on-call automation. To this day, that business is still growing very well and rarely are we ripping and replacing something. It is almost entirely a greenfield opportunity where we often replace phone trees and Whatsapp channels and more traditional spreadsheets, et cetera. So you're -- we're still early in the evolution of developers and engineering teams embracing on-call engineering, which is a really big part of DevOps transformation. But I think the pandemic really accelerated how important it is to automate the work of distributed teams to be able to orchestrate work across different cross functional teams. And that, I think, is, to your point, kind of brought the market faster towards PagerDuty in our first act. If you think about what we've built on top of our initial DevOps offering, really a modern incident response offering. And more recently, digital operations management. We can now, using software, detect any mission-critical unstructured, unpredictable issuer opportunity in the business. We can intelligently orchestrate that across cross-functional teams. We automate more and more of that work. And with the acquisition of Rundeck, we're automating increasingly the resolution in what we call safe self-healing. And it's allowed us to go after new use cases, right? And a lot of those new use cases, to your point, don't come from us building them internally. They come from some clever person inside an organization that says, "Hey, I actually have a hard time closing legal contracts at the end of the quarter because I have to go around through 17 different business units. Can PagerDuty, help me manage that?" Well, yes, it can. We see many SecOps and DevSecOps teams using PagerDuty for threat management and security response, incident response. We see people in marketing and finance using PagerDuty for things we never dreamt of. So you can expect to see us continue to build a very intuitive product and interface that allows our customers to imagine ways to use PagerDuty that don't require us to vertically build out every one of those solutions. And that's why the integration platform is so important.

Right. But yes, that's amazing. And that you mentioned just the greenfield opportunity here, phone trees, Whatsapp. But yes, I think greenfield is -- that term has turned around a lot, but it's really true about PagerDuty. But so for a customer that's sort of adopting PagerDuty in that way, may be helpful to hear a little bit more about what other tools they might be using at that stage of their technology adoption life cycle, not necessarily what PagerDuty would be doing? And then what -- how are they viewing that type of purchase? Like what are the metrics they're using? Is it ROI or is it really just that the product is just sort of delightful at that point and they think that it's something that they need to have?

Well, I think it sort of starts with a practitioner, a developer that knows they have responsibility for a service, and they don't want to be caught flat footed. They don't want to hear that there's a problem with their service from a customer on Twitter, from their boss. And by the way, this is how these things happen, right? And so it's about being proactive and having kind of eyes and ears on what everything that could possibly go well or wrong with the service you're responsible for. And then I think users realize that they don't have control of their own destiny. Their service relies on a number of other services and other dependencies that are very hard for them to have visibility to. And so that's where products like Event Intelligence and our service dependency solutions have become really important because when you ship something you're shipping it into the wild. You don't necessarily know how it's going to go and whether the things that -- the services that it relies on is going to work the way they're supposed to. But I think that when you think about ROI, one of the things that makes PagerDuty so sticky is that we see, in all of our customers, significant improvements in mean time to acknowledge, how long it takes a team to realize they have an issue, and mean time to resolve, how long does it take to get back to a green light status, right, how long does it take to actually resolve the issue and reduce risk to the business. And increasingly, we've built products and services that help teams shift from being reactive, just responding faster and better to being proactive? How do I prevent an issue from actually impacting my end customer, my end user? How do I prevent events from storming to become big incidents? And that has an enormous amount of business value associated with it because a minute of disruption in an organization that has any kind of e-commerce capability can cost between $300,000 and $500,000, right? So seconds and minutes really count. And this is the platform that was built based on microseconds and seconds. Not a command and control kind of sequential ticketing system that you could take weeks or months to solve something. So speed really matters in these environments.

And I think just to add, Kingsley, sometimes the evolution that we see is people have instrumented their environments. They've put in various APM management tools, either with some synthetic monitoring or some real time monitoring. They have to put in place lock management products. And all of those are giving off lots of signals. But none of those orchestrate work, right? And then on the other side, people have put in place ticketing systems with the view that these are going to help them manage the work. But there's nothing that really connects them together, right, or connects them within real time. And so ultimately evolution that we see is a company are drowning in the information that they're receiving from all the instrumentation that they've done, and they have no suitable vehicle to be able to actually assemble or mobilize teams in real time. And so when they start using PagerDuty, we fill what's essentially a really large void for them and very rapidly help them to get control of that workflow and help them manage that workflow that's critical to them delivering their customer experience.

Right. Yes. That's perfect. I had other questions. But now, Howard, you made me think of specific ones. So whether it's a log management provider or APM and you have ticketing as well, it's -- the value of PagerDuty has always been the Swiss-like independent platform. So one would -- I'd like to hear more about how you see that -- the benefits of that develop over time and the market recognizing that? And then two would be, do you see any benefits to a platform being like integrated into -- or your kind of offering being integrated into larger platform, maybe you've seen other companies acquire. But it's not clear that there's a product benefit as much as a cost benefit. So just give us your thoughts.

Well, I -- a couple of thoughts. One, I think being central and neutral through our API ecosystem has enabled us to provide a service for customers that consumes all of the signals that are coming in because, to your point, like a logging tool will recognize certain issues, and it will send alerts to one team, whereas the APM tool might be sending alerts on the same issue to another team. And then you've got an infrastructure monitoring tool or a network monitoring tool that's sending another set of alerts to a different team. You've got 6, 7 teams working on what they think are maybe 20 or 30 different issues. They all might be events that are colluding to become 1 major zero-day or sub 1 incident, right? And only PagerDuty has the visibility to consolidate and correlate all of that, but then also action it. And I think that's where the value has been really meaningful. We often help other platforms -- help customers get more benefit from their platforms because we close the loop on the work, right? It's one thing to get the signal, it's another thing to get some analytics. But now somebody has to go do something or some machine has to go do something. But you've got to get -- you've got to close that loop. And that, I think, is the role that PagerDuty is playing. And I would say that we're growing healthily. It's an efficient business. We think the market is still very early, a large TAM, $25 billion large TAM, if you just look at incident response, and a much broader TAM if you start to look at these digital operations use cases across the business. And so we just continue to be focused on growing our digital operations platform and making sure that we can deliver value to our growing customers. And a big part of that has been our move towards enterprise. And I think the success that we've had in enterprise on our own but still appealing to the developer, the user in an early stage tech company. So if you think about it, there aren't many companies out there that serve nearly 60 of the Fortune 100 and the largest financial services companies in the world, the largest retailers in the world and, at the same time, appeal to the most innovative developers in the earliest start-ups, right? And that's something that's going to continue to be important to us because that's where our acquisition starts, it starts with the practitioner.

Right. Yes. I mean -- and you're right that a significant reason why we've ended up with so many tools per organization is just the sort of the siloed buying centers or organizational structures. So -- but I guess not even just about the technology of PagerDuty. But do you feel that you're better positioned to connect those or appeal to those different buying centers or like types of users than maybe any individual platform might be?

Yes. I think our product and its design is more ubiquitous than some other products. It's quite easy to use. You can move from a trial into a production environment in a matter of minutes. As a new user, you can readily integrate to the services and the other tools that you want to leverage information from et cetera which makes it easy for a non technology user to apply and add. Just recently, one of our employees was telling me that she was -- she's figured out a way to connect PagerDuty to all of the vaccine websites and get an alert when a vaccine may be available in her local area, right? And this kind of hacking, PagerDuty, we hear about all the time. Developers who connect PagerDuty, they're smokers, so they can take a nap while their brisket is smoking. It sounds silly, but it's that easy. It's consumer-grade application. And I think that's one of the things that makes us very different than some of the APM players. We also -- a lot of our customers say with PagerDuty, I don't need as many APM tools, or I don't need as many monitoring tools because I can kind of bring all of that together in one view using or Event Intelligence solution. And equally, you don't need central teams that are just staring at glass in a NOC, a network operations center, anymore. PagerDuty is your automated sort of network operations center in the cloud.

Right. Yes. And then the piece there too that it's kind of tangential, but it's not in the sense that you have a customer service product today. In the past, you've appealed to that user without having a formal product. So does that also enable you to better tie in these different sections of the business than maybe a traditional observability platform might?

100%. And again, kind of that philosophy around open integration and working readily with the other platforms and tools that our customers already use is what made it easy for customer success teams to start leveraging PagerDuty. The problem they had before PagerDuty was there was an issue -- they were getting an onslaught of inbound customer input that something wasn't working the way it's supposed to and be blind, be in a platform that doesn't give them any visibility to what's going on and have a difficult time engaging with engineering and IT teams on PagerDuty, that brings all of these platforms together. So without context switching, a customer service agent can be working in their environment and get real-time updates on what's actually going on with the product or service that's impacting the end customer experience, right? It makes them much more efficient and much more able to inform and solve problems for their end users in that regard.

Great. And then back to the TAM. I mean, since you mentioned the $25 billion and if you think of it more broadly, the $100 billion, I guess, if you could just maybe for the layman or just like a brief overview of what that kind of entails? Or if you were to kind of expand above $25 billion, what the most likely pockets would be to move up to $30 billion or $40 billion?

Howard, you want to take that one?

Yes, sure. So the way we thought about the $25 billion TAM is really by looking at the set of users, both developers, of which we estimated roughly 22 million IT and security users, which was, again, I think, about 21 million. And then the customer service users, which were another 44 million. So a total of 85 million users. And we estimated that based on essentially the incident response offering that we have today. And so that was essentially the way that we did the math to get to the $25 billion. When we look at the broader opportunity, though, which is really what we've become, the digital operations management company, which is really about being able to go after that market that's proactive, that's predictive, that's about being able to close the loop from early detection before a customer even knows there's a problem to being able to fix the problem through safe self-healing. That's essentially what that $100 billion TAM gives us access to.

That makes sense. I guess, for those that may not know that market as well. Are there -- like what would be some other types of platforms or maybe even companies that would -- you'd start to -- would encompass digital operations that might not fall into the $25 billion? [indiscernible]

So I think the one -- sure. I think the ones that we're sort of seeing those are around AIOps, where that's an area that we've invested in ourselves with our Event Intelligence solution, which, in our case, is a solution around putting action into AIOps and not simply being able to produce data and useful insights. It's about putting action into it. So we think that's an important element of that. The other element of it is really around automation and how do you use automation to not just drive the incident response process, but how do you use it to drive other workflows that will be essential to managing the digital environment. And then to a lesser extent, it's really the broader picture around how do you drive process improvement across your infrastructure more broadly.

Okay. Yes. That makes perfect sense. I mean, you mentioned automation. It seems like that's a good segue into relatively recent acquisition of Rundeck. As an example of more automation and just sort of you could become closer to resolving the full life cycle of an incident by changing the actual code. So is that the right way to think about that acquisition? And is this just a trend that you would like to continue over time? You may be muted, Jen.

Yes. One of the great things -- there's a leaf blower next to me. I never had this problem when I was doing these -- in your conference centers, et cetera. But one of the things -- one of the great things about our digital ecosystem is it gives us visibility to what customers are looking for and what are some of the challenges that they have. And we've started to see a lot of interest in an early integration that we had with Rundeck, really around their traditional runbook automation process. And one of the things we like about that runbook automation is it applies to a number of use cases beyond DevOps, but it's really useful when it comes to incident response. It takes a lot of the risk out of running a self-healing script. And at the same time, it creates a lot of efficiency and benefit because you're taking tried and true scripts in runbooks and applying them to similar problems. So this is a really, I think, strategic fit between our platform and Rundeck. We also really loved that they started with open source, and they have a product that sits behind the firewall because we often have hybrid customers that have sort of 1 foot in the cloud and 1 foot still in on-prem infrastructure environment. And so Rundeck gives us an opportunity to support central IT teams in that regard. And then the last thing that I would say is, culturally, they're just a great fit. I mean, these are people that have been very involved in the DevOps movement from early, early days, really understand the challenges associated with DevOps, IT and hybrid ops teams. And so there's -- they've just fit nicely into kind of our ongoing strategy. And again, like you sort of see that, we identified that opportunity through customer usage through that very diverse ecosystem that we have in place. So that creates opportunities for us long-term across, I'm sure, other categories.

Sorry, just to add to that, to show you how real this can be, one customer explained to me a situation that they had. This is a global customer complex infrastructure, and they've been using PagerDuty for many years. And they're using pieces of PagerDuty that helps them actually narrow down to a particular set of issues. And what they found is that there were set of issues that could be well identified and they always had the same set of actions that they would perform to begin with. So as soon the things happened, a human would look at it, a human would go and do those actions. With the Rundeck integration, what they now do is under those set of circumstances, basically, the PagerDuty platform speaks to Rundeck. They run their set of actions immediately. The Rundeck automation can check that it gets a positive signal and then closes it out. If there isn't a positive signal, it runs a diagnostic. And so the responder then has so much more rich information to look at when they solve the problem. So we've actually replaced a whole lot of human efforts just in that cycle and a lot of time. So that kind of gives you a view of how these 2 work together so good.

No, it does. That's a -- that's very helpful. And I think that -- I imagine that there's many things that could be improved with simple automation like that, that you just described. I was interested, and you mentioned just some of the use cases outside of DevOps, if -- or what those might be or just the benefits that you're speaking to?

I mean I think the easiest way to think about it is any type of work that is mission-critical and time-sensitive but unpredictable or unstructured. So when people think of incidents, they think about emergencies, you can think of all kinds of sort of timely issues across the business that sort of fit into that definition. Security is, I think, one of the most obvious and one where we've had a lot of success despite not having a specific security based product. And what we see happen is security operations teams or DevSecOps teams already trust PagerDuty to give them a high fidelity signal in the moments that matter, get it to the right people about a false positive. When you think about how time-sensitive breaches, data leaks are, you can imagine why that would -- why PagerDuty would make sense in the context of security. But then when you think about resolving a security incident or stopping the leakage in a security environment, you need cross-functional support from lots of different teams and teams that go beyond your technology teams with maybe the risk management, PR, et cetera. So that's an example where a use case can start within a technical environment, but then move to other parts of the business because it becomes more like a crisis management situation. And we saw a number of customers use us for crisis management early in the pandemic. We've seen customers use us for staffing, like getting frontline workers staffed urgently because of a surge in demand for something. And we've seen some really -- like inspiring use cases. We have a customer that uses us that manages corneal transplants, and they use PagerDuty to run the entire workflow across organizations from the detection of an available organ all the way through to the transplant in a new recipient. And that's a process that is very time-sensitive because the organ will not maintain its viability beyond a few days. So that's one of those examples where the developer team was already using PagerDuty, and they were trying to solve this problem of how they manage this cross-company work to bring all these teams together in service of getting organ from donor to recipient. And a developer team said, "Hey, you should try this platform, PagerDuty, worked for this." So that's often how use cases grow inside the organization. It starts in the developer community but another problem comes up and the developer team may share what's working for them and so on and so forth.

Yes, that makes sense. A while ago, you mentioned one of the attractive parts of Rundeck is that it gets behind the firewall? And just inevitably, you have customers at 1 foot in 1 foot out. Is that a -- is that -- are you beginning to work with more of those customers as you've kind of focused more or had success selling just like larger platform sale or has that been relatively stable?

Now most of our large enterprise customers have some orientation that is on-prem and some orientation that is in the cloud. They're not native cloud companies. They -- often what we see is the application development team adopts cloud first and PagerDuty starts there, but then the more traditional IT infrastructure team who has largely on-prem infrastructure environment leverages PagerDuty as well. We certainly see that in industries that have been around for a while, like financial services, et cetera, that are digitizing. We also see it in retail. We see it in travel and hospitality too. So that's actually pretty common. And I think one of the things that have made PagerDuty an early leader in enterprise was the fact that our product is flexible. It is easy to deploy. The time to value is actually phenomenal. I mean they think IDC did a study this year with our enterprise customers and determined that our return on investment is, I think, almost 800% over a 3-year period with a payback in 2 months. I mean, it's very hard to find another SaaS platform that can deliver those numbers. And it's because you don't require huge systems integrators and huge processes to deploy this kind of usage, and it does help you advance the culture, the DevOps culture within your organization quickly.

Yes, it doesn't. It -- you described perfectly well why the product can get into organization so quickly and expand so quickly, especially on the number of users. So -- but you've made a lot of progress in terms of just percent of ARR in terms of digital operations bundles as well. So I guess, what are the some of the improving trends that are allowing you to just expand on your large existing user base today?

I'll take a crack at this, and then Howard may want to add to this. I mean, I think Event Intelligence is just -- has so much applicability to the problems that our customers see around the proliferation of complexity and the signals that are coming to them as they've moved from more central IT environments to more distributed computing environments. So that's number one. And number two, I think that increasingly, our customers are looking for a handful of platforms that they can rely on, that they can partner with over the future. And there's a lot of belief in our vision and our road map because we do what we say we're going to do. I think if you look at recently, the kind of uptake that we've seen in digital operations. It used to be that our customers would buy on call first, then buy modern incident response than buy Event Intelligence. And now we're more frequently seeing them really understand the benefit of having the event management solution and the orchestration solution together at one time. And I think our sales team has matured in their ability to articulate the problems that we solve. We're seeing even in the mid-market, more transformative deals than we used to see in the past. And the last thing that I would say is the pandemic has helped people really understand what our platform does and how well it works. Because when you have to send all your employees home and basically become a digital company overnight, suddenly you're dealing with distributed teams, PagerDuty didn't skip a beat. And in fact, with traffic, network traffic and event traffic increasing on our platform to the tune of 130%. We actually saw our customers' mean time to respond improved by 15%. So the platform itself does work really well under pressure. And I think that's why it's become essentially essential infrastructure in most of our customers.

Yes. And I think what I would add to that is customers are having to deal with we often talk about these tailwinds, digital acceleration, cloud migration or cloud adoption and DevOps transformation as being tailwinds for us as a company. And what we have seen is that people have recognized there's a maturity model that you can follow. But really, you want to try and get through that maturity model as quickly as you can. And so when we look at our digital operations plan, what it does is it enables and empowers customers to move really quickly to a higher level of digital maturity. So to give you one example, we know from studies that about 80% of disruption in technology environment is because of change, right? And with our digital operations plan, we have the capability for people to be able to see change events within the context so that they can actually identify whether there's actually been a change issue that has resulted in the problem, which means they can respond really quickly. We also see that, that often in these complex environments, the relationship between services is critical to understand like how do I have this business service and what are the technical services related to it so that I can understand the impact or the blast rate is of it. So the service, the penalty features that you get within our digital operations plan helps you actually understand your environment more clearly and gives you richer context so you can respond. So these -- there's just a few of these very powerful features that I think of why the digital operations plan has gained so much traction because it's helping these companies solve very real problems in a very complex world.

Yes. That's excellent. Just a bit on the -- just the efficiency of the platform, you've always had very strong gross margins. And I think you've wouldn't have even minded to give up a few points in terms of accelerating growth but they remained in the high 80s. So I guess, if you could just provide some color for investors on the efficiencies and how that's going to be durable profitability?

Yes. So for us, our target range for gross margin that we've set for ourselves is between 84% and 86%. As you point out, Kingsley, we've actually been above 86% in the last quarter, we were 87%. And that helped us also think about opportunities to invest as we go forward. And we're starting to make some of those incremental investments now. But what contributes to high gross margins. So there are a number of things. The one is, first of all, we have a very cleverly constructed infrastructure. The way in which PagerDuty is being built in the cloud, cloud native. We've been built in a way where we've got really strong engineering that's efficient that helps us to optimize our use of cloud service providers, not give up on redundancy or any of those elements but do it in a really smart way. So we optimize our spend on our infrastructure because of the way in which we've been architected. We also follow a very programmatic approach to customer support and success so that's helped us to be efficient in terms of as we've grown to over 13,700 customers that we're able to sort of delineate the right kinds of service that we would provide. And then our own DevOps approach to production, where we live and breathe DevOps, means that we are able to drive efficiency into how we're very proactively redeploying code every day. We're responding to issues every day, and our customers aren't even aware of it, right? So our very own approach to that is certainly helping drive those gross margins.

That's a great review. We touched on some of the changes or how -- what's enabled you to move to a higher percent of ARR from the digital operations. There's, I think, some simplifying of the bundles. But just curious some broad insights or things that you've learned over the past 3 years in terms of what customers are receptive to, whether that's on a product basis or just even something like making your customer service product as well. So...

I think customers are really receptive to simplicity. It sounds like such an obvious statement. But as you go from a single tool to a multi-product to a platform and you're adding new features all the time, you're adding new capabilities, you're continuing to improve your infrastructure environment, you're building out an API-based ecosystem, you can -- if you're not careful, build a very complex environment. And we've always had a very high bar for usability because our users, our practitioners are in our product when things aren't going well and the wall clock is ticking in a meaningful way. And they may be responsible for something that is business critical, mission-critical, customer critical, et cetera. So it does create a really high bar around simplicity in the usability, the user experience of the product no matter how much robustness we put behind it. And increasingly, that sees us looking at how do we make sure that our practitioners can discover new features and new product within the product as opposed needing a salesperson or a demo to get there. So I think one of the things we do very well is despite innovating significantly at scale and bringing a lot of new features to bear in the product each quarter and each year, we're still keeping the user environment very simple. We also still acquire the vast majority of our customers through e-commerce. So again, it is a viral kind of land and expand motion. The demand is demand-driven by the market. And I still think this market is very, very early, even for our first product, much less the broader platform. And so I think those things continue to be important to us. Like we are a growth company. We believe we're a durable and sustainable growth company, and we're a product-led company. So even though we've managed to effectively scale an enterprise sales force and continue to do bigger, more strategic deals, our focus is still very much front and center on the customer experience with the product itself.

Okay. Just maybe probably the last area we'll be able to touch on is, you talk about customer experience. And we've talked about the relationship with the IT users or the devs. How -- with something like the Zendesk integration or just, I guess, the customer service offering in general, how would that touch point with that type of user compare to an IT or a dev, not necessarily own any customer relationship but just exposure so?

I think I'll take a crack at this and Howard has a lot of passion around the customer service use case. So I may have him jump in too. But I would say that number one is that it has to be easy for a user under time pressure to get the information they need and execute the work that needs to be done without too much context switching. And so instead of thinking about customer ownership, we think about how do you make the workflow super easy. And one way to think about integration is it's the gateway to workflow, right? And it's this everything that we do is about making all of our integrations easily interoperable for the user with the user in mind. So a customer service agent, as I mentioned before, should be able to leverage all the benefits of PagerDuty without leaving their Zendesk environment. And likewise, anything that they do in Zendesk is going to auto populate into PagerDuty. So that record is there for the developer team who may be responsible for taking next steps post that incident, right? Another example of this is where we've integrated change management into the PagerDuty platform because most -- we know that 80% of incidents usually initiate with the change. But oftentimes, it's not obvious when you're trying to resolve an issue on the fly. And so being able to understand when deploys have gone, what's happened historically from a change perspective and likewise, push information into the next change is really important in continuous development environments, continuous deployment environments, which is what everybody is working towards right now.

Yes. And I think the one comment I would say, when we think about the customer service use case, to Jen's point, it's really about trying to make it easy for people, providing them with as much context as possible. And that sounds simple. But for people who's sitting with a customer service agent, often the context that they have is limited. When you put PagerDuty together with a product like Zendesk, you suddenly have very far richer context around what's actually happening in that environment. What you're also able to do is you're providing a mechanism to collaborate with other people who often not within the frame that you would typically see within a customer support management tool, right? So now all of a sudden, you have the whole environment potentially open to you. In terms of people who you can bring into to resolve an issue or provide you with access to be able to find the right expert at the right time. So that's how these -- there's the power that comes out of putting those 2 together. It's not just the benefit you get from a depth perspective, but it's a far richer context for the customer service user and that ability to engage your organization, not just your team.

Yes. And then it seems like if you're spanning devs and customer service, maybe there's that idea that you can move into that third area of IT. And also, I'm sure many can resonate with being told that they can't see their information. That's just why they need to transfer them. So yes, like in context it's a problem. But thanks, again. This has been great. Jen and Howard, thanks for joining us. I think we're running up on time.

Well, a pleasure to be here. Thank you for having us.

Yes. Thanks, Kingsley. We've enjoyed being here.