Pegasystems Inc. (PEGA) Earnings Call Transcript & Summary

Welcome to Credit Suisse 26th Annual Technology Conference. My name is Fred Lee, and I cover small and mid-cap software companies. And joining me today is Ken Stillwell. He's COO and CFO of Pegasystems. Ken, welcome to the conference. Good to see you.

Thanks, Fred.

It's been a little while. So for the benefit of the audience, I was wondering if you could talk a little bit about Pega in general, how you got -- how the company got its start and the overall vision of the company, and we'll take you from there.

Sure. So if you go back to -- I'll make this quick. So if you go back to the inception of Pega, the reason why Pega was established as a company was this dynamic of the way that applications were built. They were built by writing strings of, like, unintelligible letters and numbers that somehow, the only person that could interpret that would be a computer. And then as you build something, if you ever wanted to change it, you had to go back in and delete lines and add lines and change code, merge different languages. And that became just a very overhead heavy way to build applications, which, interestingly enough, is the way that 50% of applications in the enterprise space are still running or being built now. So what Pega was, was establishing a platform where you could execute certain activities, the way an application would execute them, but doing it in a way that you didn't have to write code, doing it in a way that someone with less technical proficiency could go through and using in today's world, using drag and drop and icons and kind of inserting almost in a visual map, you could create your application workflow. So that's kind of the where we were, where we are. The use cases are almost limitless. If you think about any activity that happens inside a company, anything that is not a one transaction and close, there's a series of steps, things that have to either get reconciled that get quality control that escalate to different parts of the organization. That happens internally. And then when you're dealing with customers, you have the same scenario. So I think that our view, [ yours should I say, ] shouldn't say our because I wasn't part of the founding team. But when the company was founded, the view was maybe we could -- this could be a better way to build applications. Unfortunately, where we sit now is we still have that problem because there's a proliferation of code bases, and there's all kinds of different point solutions. And it's just very clumsy in terms of the way that organizations try to connect these. So Pega helps to solve that problem of a disciplined way to connect applications such that you can very easily change and evolve and future proof, so to speak, where you don't have the write code.

And so can you talk a little bit more about the low-code no-code approach and how that's evolved over time as it relates to business process management and workflow?

Sure. So I think philosophically, when Pega was founded, we believed in this no-code. We were very principled for probably the first 10 or 15 years to say, you should never have to write a line of code again. I don't know that, that's -- in today's world, that's really practical to say no code. But certainly, you can minimize the amount of code and the code that you write. There is intelligent ways to make sure that you can identify anomalies, things that would upgrade problem so that you can -- when you're migrating or when you're moving or evolving an application, they're like -- almost like kind of sensors, places to look, almost like a car tells you your tire pressure is low, like you know somewhere to go to figure out where that problem is. And so the low-code no-code -- I think the low code is really almost generally accepted as a better way to build applications, assuming that the low-code platform has enterprise great applicability. That's kind of the problem that exists in low code. With many of the vendors that are out there talk about low code, but what they really mean is simple. And that's not going to solve a problem for our Credit Suisse or companies of scale because you just -- you have to have a level of maturity, durability, sophistication, kind of auditability that many of the low-code providers don't necessarily have. So that's kind of the absolutely low code is here to stay. It's not going anywhere because it's just a more efficient way and more scalable way to build and manage applications, but you got to be careful because many of the low-code providers are really like one step low code, like let me build a way to capture a vaccination status for COVID, like that's very simple use case. It's not advanced. And quite frankly, it's common, but there's not a lot of value to it because you're not saving a lot of human time.

A lot of the research we've done out in the field and talking to customers and trying to better understand the competitive set have -- the feedback has come back that Pega does a lot of the heavy lifting in the industry, and you're known to do the more complex type of work. Can we talk a little bit about the use cases that are most prominent within Pega and how that's evolved over even in the past 40 years? The company has been around since the early '80s for those out that are less familiar. And just the primary use cases and I guess the heaviest lifting that's involved and what percentage of the total business is kind of in that space versus the lighter weight type stuff.

Yes. So I'm going to maybe reframe your question a little bit to put it into 3 buckets. One bucket is the heavy lift. And one bucket is the very light touch, like high-volume, simple process and one is kind of in the middle, which is not like a build from scratch, but something that would be -- that would almost mirror what you might buy an out-of-the-box application for. So it's a more common use case. The heavy lifting stuff or the really custom stuff maybe is another way to think about that is becoming a smaller and smaller part of our business over the years. When we first started, that's really all we did because we went in and said, hey, you've got this problem. There's no application you can buy. You really have to build it on your own. And if you're going to build it on your own, you should build it using Pega. That was kind of the -- that was like almost the heritage of Pega. Now I think you'd be hard-pressed to say I have this problem and not have 15 vendors go, oh, oh, I can help you, like, so there's definitely a lot more companies that will argue they could help you. Whether or not they can or not is a different story, but they will certainly make a pitch. Back when we started, there just weren't that many that did that. But also, there's so far less examples where companies are trying to build this monolithic huge process engine to be able to solve everything for an organization. They're really stepping into, let's get pieces of it, let's buy best-in-breed for the pieces and let's stitch it together, so it orchestrates. That would be what I would call maybe the next step evolution of what Pega does, which is we will -- we are a process orchestrator, meaning we're not actually designing the ACH processing system for a bank. We're really saying, look, you're going to have an input application where you take information. You're going to have some type of an account management system. You're going to have a clearing health application. And you need to stitch that all together through an orchestration engine. That's where, I would say, in the last 15 to 20 years, a lot of our business was -- or maybe 50% plus of our business was really around that kind of use case. The next evolution of the use case is really where we go into a specific -- I'm not going to -- I'm going to use the point solution to kind of to make the extreme point. Someone is trying to onboard a participant in a healthcare plan. Someone is trying to originate a loan. Someone's trying to process an exception on an American Express card, like those are like more point solution type applications, either in customer service or in kind of a back-office processing application use case. That's where a lot of our growth has come from where we are selling to clients in our core vertical, you might say, well, what are the -- what is -- what are the verticals you're strongest at? Don't think about the vertical. Think about the use case. If it's a B2C use case vertical or B2B2C, like a State Farm would be an example of a B2B2C, there's going to be lots of customers. There's going to be lots of transactions. You're going to have to automate a ton. You're going to have customers coming in for somewhat silly questions that should be self-served and somewhat routine questions, like I need to change my address or I need to add my child on a cell phone plan, things that should not have to take 40 minutes of a customer service rep and the customer shouldn't have to have that experience either. So those are kind of some of the evolution use cases. When we -- if you think about who we competed with in each of those 3 buckets, the first one we typically competed with code, with actual, like, engineers writing code. The second one we competed kind of more with the big process like an IBM, the traditional -- you might put a little bit of Microsoft in there. You might put a little bit of some of the force.com and, like, the real process. And then when you jump to that third example, which is a little bit more like a point solution, you're competing now with Adobe, with Salesforce, with Microsoft, with Guidewire, with Veeva. You're competing with people that have more finished solutions, which is how we've evolved. If you go to the one step further, and say, now let's just sell a really simple packaged app, something that doesn't require a lot of configuration, something that is maybe a one step, it's an open-close type application. We don't sell a lot of those. The reason why I say not a lot and not 0 is because some of our clients use us for those simple use cases. That's typically not why we win the organization. They might use us just because they see some use cases and they say, we already have a COE for Pega. We already know -- let's just use them for kind of almost an initiation ticket, something that comes in as an exception but doesn't know where to go next. That's like almost a routing system. That'll be a more simple use case. But we don't go in trying to sell those. So that's kind of a way to think of the landscape maybe.

Got it. Got it. And so automation solutions have been receiving a lot of attention, specifically because of the cost-cutting environment that most companies were in. And so when we think about your solution, it really does automate processes. And so how do we balance the fact that there could be an incremental uptick in demand from automation solutions with the fact that macro headwinds are manifesting? And I guess what's the latest that you're seeing in North America, Europe and Asia?

So there's -- if you break it down, there's 2 simple use cases that we help clients with. One would be in times of significant growth, we would help them with driving up the lifetime value of a customer through faster and more automated, more intelligent kind of connective tissue to the clients. Client comes to a website. You route them to a place. You try to put a call to action in front of them, try to get them to take the steps that would make them buy more. That would be maybe more in times like a little bit more like marketing automation, right? When times where companies are saying, I'm not looking at necessarily thinking my clients are going to spend more. I want to make sure I don't lose them. I want to make sure they don't spend less. I want to retain the revenue during this more difficult economic time. We have the other value prop, which, quite frankly, is more prominent for us, is a value prop around taking people and time out of activities. And the automation that Fred just mentioned is a key component. The automation is driven by robotic process automation, which is embedded in our platform. It's driven by our [ rules ] engine, which actually creates a real-time decision tree around when this happens -- when x happens, try y or skip y, allows you to take a human out, which, by the way, humans, a lot of times, clients think that [ lives ] really important for us to have a customer service person that gets on and talks really empathetically with the client. It's not. What's important is that the client gets their question answered and moves on with their day, right? And there's -- that's what consumers want. So if a consumer goes somewhere, a human is going to make an error way more often than a robot is. So then the question just is, how do you balance the human nature and the accuracy and the speed? So what we help clients with is get the actual physical person on your -- in your call center to only spend time with a person when they need to and have the system, whether that be on a mobile phone, on a desktop or calling in, be able to almost automate that transaction with the consumer like it's a real person but using a system to do it. And the robotic process automation is a way to do it. AI, our decision engine, is another piece of it because the decision engine isn't just a typical decision engine that work -- if you think about like a lab, you go and do a model, and then you go and you say -- you basically say, here's all the rules. Our decision engine starts with rules but learns from the activity. And it basically updates and integrates the decision -- the actual activity with the decision model. So it'll change the model. It'll say, hey, that is no longer a valid way to interact with the consumer because you keep getting a negative outcome versus, hey, that really was much better than I thought originally. We're going to put a higher level of dependence on what that customer does in that transaction. So what we're doing is we're essentially taking away cost structure of people, and we're actually speeding up the interaction, which lets the consumer feel like that they're not being [ drugged through it, ] you're going to be on hold for 20 minutes, or worse yet, the new trend is, please put your number and I'll call you back when someone's free. That's a horrible customer experience if you look at any of the surveys. Now it's cheaper, right, because you can basically get really good utilization, but the customer hates it. And so what they're going to do is there's a risk that they'll turn. So that's kind of the way that we would lean in on times of less -- kind of less robust economic times.

That makes sense. So the company reported very strong numbers in Q3. I was wondering if you could talk a little bit about your SaaS solution, which you call Pega Cloud, and the uptake there over the past few years, year-to-date, it's been around 70% of new commitments, right? Can we talk about the business transition over the past 5 years? And then as it relates to Pega Cloud, what's driving the bookings momentum behind it?

So when we started our journey to subscription and kind of almost a 1 year later journey to SaaS, and when we started this, we said, look, we're not going to be a perpetual business anymore because clients don't want to buy perpetual. Quite frankly, it doesn't work for us, and it doesn't work for clients. You end up overbuying, and you end up over discounting, and it's really not a good transaction for either side. I think we were probably a little bit late to that, honestly, in terms of where the market was. So we made that move to subscription. What we realized was that our clients were a step ahead of that moving to SaaS. Even though they hadn't even publicly said that, if you go back to a large banking -- a very prominent CEO in the banking industry, I remember a sequence of 4 years where he said, over my dead body, will we go to SaaS. And the next one was, we'll probably do maybe 50-50. And the next one was, I think we're going to do more and more SaaS. And the next one was, we're cloud first. I mean that was over 4 years of like him speaking at -- so like even the leaders of the largest financial institutions didn't really know what was going to happen, right? So we were -- so what we did was we first moved to subscription and then we moved to SaaS. That was like 2018. When we started, we had about $20 million, 2-0 million dollars of Pega Cloud ACV and revenue. Now that number is approaching $0.5 billion from 2018. That isn't clients moving from kind of on-premise to Pega Cloud. That is all net new growth that has happened between 2017, '18 and today. The other thing that's happened is the percentage of our deals -- percentage of new growth that was Pega Cloud, which is our SaaS solution, has been increasing. It's now at 70% of our bookings are Pega Cloud. Whereas 2 years ago, it was kind of stabilized around 50%. If you go back -- when I started 2016, we had about 5% of our bookings for Pega Cloud. So we went from 5% to about 30%, then 50%. Now we're 70%. Do I think it's going to go then to 80%, 90%, 100%? I don't. And the reason why I don't is you're now seeing -- you're seeing very sophisticated buyers understanding, and I think this will become common knowledge, that SaaS doesn't work for every use case. It isn't the cheapest solution. Amazon Web Services and Google Cloud and Azure, great solution when you actually do not know what your capacity is, when you have variable use -- when you actually know exactly what your capacity is, quite frankly, it's more expensive. And I think people understand that. That doesn't minimize the value of it. It's tremendously valuable. We use both GCP and AWS on the back end of Pega Cloud, and they're great partners. But the reality is you cannot force it to be for every single use case. So there are some use cases where people not want to buy SaaS, either because it's not as efficient cost-wise or that they just have such a legacy environment that it's very difficult to run that in a public cloud. And there's also some security concerns even today, especially in Europe, where you can't move data out of country. So there are some scenarios where you have to really think about the cost or the overhead structure to run SaaS. So I think 70% to 75% seems like a reasonable kind of high watermark in terms of Pega Cloud. Would I love for it to go to 100? Fred and I have talked over the years, like absolutely. I wish every one of our deals was SaaS because it would make explaining our financials a lot easier. But I think that clients want to buy what they want to buy, and we have to be careful. The next part of that is, how did that happen? How did you get to 70%? Why is it 70% versus 50% a couple of years ago? I think our knowledge at Pega, our sales team, our product teams, our marketing teams, our clients have just all evolved over the last 5 years. Like we're just smarter. Like we understand how to sell. We understand how to price it. We understand how to explain it. When we first sold Pega Cloud 2017 -- and by the way, I was part of this problem, too. We would explain it as an infrastructure sale. Well, you can buy Pega Cloud. And oh, by the way, we'll give you some servers in the cloud. Like that sounded right at the time. I mean when I say it now, it even sounds idiotic. Well, it sounded right at that time. Well, clients don't want that. Clients want to manage service. They want to know that they're going to buy a capability from you, and you are going to manage it. And all they have to do is have a client go to a URL and enter something, and they can pull information or integrate to the back end. So that's kind of where we are. And I think that we've -- it's taken us a few years to get there, but I think that has been a natural journey for us.

And back to the mix of your business, can you talk about the profitability profile of your term subscription versus your cloud and where the mix is heading to? I think you outlined a little bit of what you would look like at maturity. But the difference in margin profiles and what we can expect?

Sure. So you've got -- think of term license. Client Cloud is accounted for as a term license. You can imagine that's a very high gross margin business because you don't really -- you don't have any infrastructure costs. You do have people cost, support cost. But think about that as being a margin -- a gross margin that's above 90%. So that's kind of one offering. Then you have Pega Cloud. And Pega Cloud gross margin -- in 2016, our gross margin on Pega Cloud was 35%. Why was that? We didn't have scale. And we were really, quite frankly, still learning how to run our application in an AWS environment, so just wasn't insufficient. Then we went to 50%. Then we went to 55%. Then we went to 63%. We'll be 70% this year. We'll be 75% next year. We'll probably get -- be on our way to 80% in the 2024 to '25 time frame. Some of that is operating leverage and scale. Some of that is us and our partners, quite frankly, just building a more technologically efficient platform that runs in SaaS. So if you think about the gross margin profile at kind of a timeless model, client cloud would be in the '90s, and Pega Cloud should be above 80%. If you think just say -- if we moved more to a multi-tenancy model, we should be even higher than that, probably more like 85%. So I think we'll be pretty close to, I wouldn't call it best-in-class at 75%, but I would say at our scale, pretty reasonable gross margin trajectory. And so you might then say, well, since client cloud has 90% gross margin, and Pega Cloud, let's just say, is more in the 75% to 80%, why wouldn't client cloud be a more profitable solution to sell? It is if you just look at the percentage. But if you look at the dollars of gross margin, you look at the velocity of selling, you look at the ability to -- for clients to always stay current, and therefore, buy new and buy -- and get new feature function, et cetera, Pega Cloud long term, even in the intermediate term, is a much more profitable solution for us.

So you mentioned multi-cloud. How do you -- how is Pega's architecture been rewritten and refactored or rebuilt? Was it a brand-new code from bottom up when you launch Pega Cloud? Or was it more of a managed service that you kind of ported over into a private cloud?

So what we had was we -- think of what we had was, we had a more of a monolithic application, and that application was, interestingly enough, by design monolithic. Because if you go back to the '90s, we actually had a bunch of individual components that at the time, the common thinking was you have to stitch all those together. You can't have these micro services. I mean that I can go back and show you an article of late '90s where there was a criticism of the micro services approach saying it's not stable. You want to actually kind of super glue all this stuff together and do an application. And that's actually what we did. Well, when we actually move to Pega Cloud, we realized, well, that's a very inefficient way. You can't update the whole thing. You can't, like, release capability updates. So we basically took the approach of the analogy -- I use is like your house, right? You have a fuse box. We actually have -- it's one house, right, which is Pega, but -- the Pega platform. But individually, there might be 60 different components, and you can shut off or shut on any of them. And it's an automatic shut off, push and update. It doesn't impact any of the other rooms or zones in the house. And quite frankly, client won't even know because the only thing that happens is anything that happens around that zone while you're doing the update, it kind of sits in a queue and waits to process. So you can actually create a single tenant, enterprise create application that can be upgraded continuously, and that's what sits on Pega Cloud. So we didn't actually rewrite any of the code. What we really did was we essentially kind of broke the code chunks up again and made them into micro services, almost similar to what we had in the '90s that was just -- at that time, that was not a modern way to do it. And so that's kind of how we've -- that's helped with our agility and our efficiency on Pega Cloud, as you can imagine, and the interoperability across different clouds.

One more technology question. Are there any offerings or features that your customers are asking for that you don't currently deliver today as some of these new smaller vendors are kind of fitting into these niche players, some of these venture upstarts? I guess I'm sort of curious where there is pull in terms of features.

So I think -- so there's a few areas that are a little bit more hot. Like, for example, the voice AI, right, the dealing with a person talking in different languages and different dialects using different cultural norms for sarcasm, like all these things are trying to translate that into an intelligent way. That's one area. Another one is the kind of the process AI aspect of -- kind of the process extension, the process discovery, the process mining. I'm putting that into a bucket because process mining is not a solution. It is a technique. It is a capability. It's not something you would want to sell stand-alone. And what -- and for us, we view that as you've got the process. Now can you go out and look at places? Can you learn about where it's working, not working? And what might you identify as areas where you can say, hey, this is clearly an opportunity for you to put some of your engineering capacity in the future to be able to build a more robust functional kind of architectural environment. Then there's -- so there's like the voice piece, which is the customer. There's the efficiency of process discovery, process mining and really trying to be smarter about where you -- how you evolve your application. And then there's another dimension, which is generally around integration and sharing of data, sometimes around a customer data platform, sometimes just in general. I think the biggest challenge that I think our clients are seeing is they have all these applications, and they just don't work well together. And so for Pega, a thin way to be able -- and that -- you might think about that as what we call Process Fabric, right, which is a way to create almost a layer, even if it's just a simple view layer that allows you to look into different applications and correlate things between different applications. There may actually be 2 parts of the same process step that you wouldn't otherwise know and helping users be able to identify like what's in their queue and what do they need to focus on and what maybe isn't working well or what do they -- and that's very easy when it's just a simple like, there's a purchase order. I need to approve it. It's a lot more complicated when you have a customer going down different channels around issues that may be related and trying to figure out how to correlate those together. The thing that's most impressive to me is when you're working with a company and you're talking to them about one topic, and they know the interaction you have in other channels. It happens very rarely, but you do see it sometimes where they almost -- and that's typically -- that works typically in, like, a wealth manager world or somewhere where you're really valuable to them as a customer, right? If you're a commoditized customer, people aren't used to, like, knowing everything about what you're doing. Sometimes you even say something, and you're like, well, I already -- thank you for helping me there, but like, I've already changed my address. And they're like, oh, I don't see that updated yet because there's a 1-hour delay. So that's kind of clients want that voice translation in, being able to learn and understand how to evolve their applications and kind of that other one is just the general interoperability between all these applications.

And before I open up for a question, I did want to touch on the Rule of 40 and how you're thinking about the progression and then timing, I guess, over the next few years as you approach greater profitability.

So we said we were going to be a Rule of 40 company when we exited the cloud transition. We originally thought we would exit the cloud transition at the end of 2022. That looks more like kind of the middle of 2023. And I want to clarify one thing. What I talked about was the full 12 months after we exited the transition would be our kind of Rule of 40. Right now, I've anchored on 2024, saying that in 2023, we'll be a Rule of 30 company. In 2024, we'll be a Rule of 40 company. That isn't that different than what I said back in 2017. It's probably off by about 6 months or so because of the faster transition to Pega Cloud. The way we're going to get there is going to likely be different, though, because we thought we might get there with a 25% growth and a 15% margin. I think we're more -- that's more inverted now. And we're probably accepting more of a mid-teens kind of growth, and we're really focused on driving more free cash flow over the coming 24 months to get there.

Okay. I think we have time for one quick question. Maybe we don't. Ken, thank you so much for your time.

Thanks, Fred.

Great to see you.