Good morning. Thank you all for joining the Pegasystems session at our Growth Stock conference. I'm Pat McIlwee, and I'm a research analyst in the software group at William Blair, as a part of which I cover Pega. I'm required to inform you that a complete list of disclosures and potential conflicts of interest are available at our website at williamblair.com. Today, we're thrilled to have the Pega team back at our conference, including COO and CFO Ken Stillwell, as well as Peter Welburn, who leads the IR team here in the audience. Welcome to Chicago, Ken. You mentioned to me that Pega hasn't done a fireside or a roadshow in Chicago in a few years now, so it's great to have you here. I think especially timely given that we're just ahead of your investor session and PegaWorld next week.
For investors here who are not familiar with Pega, can you just start us off by giving them an overview of the company solutions and why the Pega platform is particularly interesting today?
Sure. Thanks for having us. It's actually been a while since I've been in Chicago in general, so it's good to get back.
Good time to be here.
Yeah. Yeah, it is. That's true. June is a good month. If you think about in large organizations, they have, and when I think of large, I think of banks, insurance companies, healthcare companies, governments, where you have either a B2C business model or you're supporting constituent management like in the public sector. There is a number of use cases to support those consumers, those customers, those constituents. Things like healthcare claims, managing credit card approvals, loan originations, onboarding, change of address. There is just a series of actions that need to be really structured and managed consistently. Sometimes because it is regulated, like managing a credit card dispute and how Visa or Mastercard requires the banks to manage those disputes or other things that might be more driven because it is the internal control processes of the organization to do it a certain way.
When you have those deterministic workflows, work that needs to be done exactly the same way through a series of steps and stages, and be able to know on the front end and know on the back end that you actually executed that work. That is typically called enterprise workflow. Pega is the leader in enterprise workflow. Sometimes the solutions are more horizontal. They look like onboarding that might be very similar across different verticals. Sometimes they are very specific to an industry or a vertical, like Know Your Customer in banking.
We have been helping clients for more than 40 years doing essentially an alternative to either writing their own application or trying to buy a commercial off-the-shelf solution and try to make it good enough to meet the. We have kind of functioned as this low-code platform where you do not have to write code, but you can get the level of specificity and configuration that you need for your use cases.
Okay. That is great. To kind of build on that, more than three quarters of your revenue comes from highly regulated industries like you touched on. Can you talk about why those customers rely on Pega? Is it that trust that you have built over 40+ years, the security, the services component? What is the secret sauce?
We tend to sit in this kind of convergence of a number of different factors. One, the scale and the volume of transactions. Not many systems are able to manage what could be billions of interactions in the course of a year, in that scale and multiple, kind of instantaneously having multiple threads of transactions. There's one is like a scale differentiation. The other one is that what I talked about being highly configurable. Now, highly configurable does not translate into customized, although some clients do like to build customization around Pega. It's really just around the ability to configure a set of work and to be able to iterate and change the nature of that work over time. There's very few vendors that actually have enterprise workflow that allow you to do that. Another dimension of that is the level of security that we have.
Security meaning not just native to the platform, but we have over 100 different industry certifications. Everything from PCI to HIPAA, to FedRAMP, to IRAP to ISO 27001. In any country, in any vertical, we help our clients support their third-party certification requirements that sometimes are because they're regulated. Other times, it's just the nature of the business that they're in. Another dimension is the ability to really drive the very robust structure of the work and be able to separate the work. We have something called a case, which is not only do we have the actual workflow, but we have the ability to contextualize each incident or each activity in a way that is unique, but also related to other incidents that look like that. Many of our competitors manage that just in a database.
They do indexing, and they have rows and columns, and it really prevents the ability to understand deeper associations and relationships around the metadata that is associated with each individual transaction. People typically buy us for the combination of all of that. That really, everything that I just said really fits tightly with enterprise needs. Large companies have scale transactions, regulatory matters, consistency, repeatability, and the ability to manage as the business changes.
Okay. Yeah. That's great. In your overview, you said the word deterministic. I'd like to ask you to kind of elaborate on that because I think it's still not completely understood in the investor community what exactly Pega does. It's providing secure, reliable, deterministic workflows. That work for an enterprise every time. Then what foundational models like Claude do, providing more probabilistic calculations, where there's overlap, where there's a distinction, and kind of where there's a harmony between the two.
Sure. I'll start by saying there are two types of work or two types of, I'll use the word workflow, but two types of processes. One type is probabilistic, generative, where you would expect there to be an error rate. The error rate, you might want it to be 1% or half a percent or 10%, but you would expect it to not execute exactly the same every time, because it's going to use the data that it has. Even when given all the exact same variables, there is a slight risk that the probabilistic model will pick, if left with two equal choices, may pick one one time and one another. That's just the way the models are built. There's nothing incorrect or erroneous about that. They're built to be inaccurate. They're built to try to get it close enough.
Then there's deterministic, which is really not focused primarily on the outcome, it's focused on the process. How is it that you will go through the work? Good example of a probabilistic action or a deterministic action. Probabilistic would be if you come to a website of a large credit card company and they want to speculate exactly what rendering of a picture or a call to action or an offer they give you, that would be probabilistic. They're not going to get it 100% right. They might see that you're coming in from the Midwest and that you're over 50 years old and you have a family. They might show a picture of a family sitting under a tree in a corn field because they feel like that might be the most relevant.
They might have that completely wrong because you're from France and just happened to move to the Midwest, and actually that picture doesn't resonate at all with you. That's not a problem. That just means they got it slightly wrong. Then there's a probabilistic workflow. I'm going to approve a loan, and I have to follow all the state guidelines, discriminatory lending guidelines, credit guidelines, wholesale lenders, whether it's FHA or VA. Very structured, and you cannot get it wrong. Might an underwriter make a decision at a stage in that workflow that could be wrong? Yes. That's where the judgment fits. That's where the probabilistic fits with the deterministic. The structure of how you process that loan must be the same every time. Really.
Sorry to correct you.
Yep.
Deterministic. That is a deterministic-
Sorry. Deterministic. Sorry. I want to-
I just didn't want to be misleading.
Yeah, sorry.
You started that off probabilistic.
Yeah, sorry. Probabilistic is where you can have an error rate and you're making a best guess. Deterministic is where you decide the work that is done on the front end. In a deterministic workflow, you will have probabilistic AI that's used as well. The example would be that underwriting decision. In the underwriting step in that workflow, there may be some judgment. You might look at loan-to-value , you might look at things in there. Someone might have to make a human call on that. You could make an AI call on that. You realize that maybe you give a loan to someone that maybe you shouldn't have because maybe there was a credit risk you couldn't anticipate. That doesn't undermine the process of which you went through to approve that loan. There wasn't an intentional discrimination against a borrower.
In consumer industries, as you might imagine, there is a high bias to protect the consumer. Then if you go across the world in different countries, there's a increased bias around protecting GDPR in Europe. Protecting sovereign information, not sharing information outside. There's so many rules and regulations across consumer industries, that it's very important that you understand where does a workflow need to be deterministic and where can a workflow actually be probabilistic.
When it's probabilistic, I think that's where AI can play a role.
Mm-hmm. Okay.
Yeah.
Very helpful. Thank you. I think it's an important distinction.
Yeah
To call out. Just given this is a generalist conference by nature, can you touch on the pricing model? I think that's been a big concern across the software sector at large recently, and Pega's pricing model is a little unique. Can you just kind of clarify?
I'm going to go back about 10 or 15 years because we changed our pricing model, had no relation to AI or any of the things that are going on now. What Pega does is it takes what otherwise were human activities that would be managed manually across maybe a structured set of workflow steps, and we automated that into a system. When we automated that into a system, what we would do with our clients is we would build efficiency so that if they had 10 people that might've been needed to manage a certain body of work, they might only need five. In a licensing model that's a user model, that's kind of counterintuitive. That we would go out, help a client take their headcount down by 50%, and we would then get 50% of the revenue associated with that.
We did have a licensing model that was a user-based model 20, 30 years ago, and some of our contracts still do have licensing components that are user-based. We made a big shift to move to what we call a case. A case is a unit of measure in Pega. Think of a case as a piece of work. We license based on the pieces of work. A piece of work could be a dispute on a credit card, a loan origination, the number of clients that are onboarded, the different measures, the number of card replacements that you might have for lost credit cards. That unit of measure of a case is how we license. We feel like the more that the system automates work, the more cases that it does, the more that Pega should receive compensation because we're automating and driving efficiency.
You might call that a usage model.
Essentially a case is a use of the technology. In an AI world that's become now much more obvious. We have 75-plus % of our contracts that are exclusively case-based, and the ones that aren't, that have users there, typically purpose clause driven. They're like you can use it for this purpose and this number of users and cases. We typically have both. We were ahead of that challenge, but not because we saw AI coming. It was more around just our value proposition made more sense to charge based on usage. The analogy I use is if you were using AWS for your cloud, AWS would never charge you based on the number of employees you have. They would charge you based on the number of CPU, the CPU storage, processing, et cetera, and that's very analogous to Pega.
Okay. Very clear. Thank you for that.
Yep.
I think, whether or not it's completely misled, there's a fear of disruption associated with some of this automation technology.
right now. When I've spoken to customers of you and your peers alike, it seems like they are leaning more into these trusted platforms more than they're trying to move away from them. Right? Can you talk about just how those customer conversations look when you're talking to enterprise-grade customers that are looking to roll out AI automation at scale?
Maybe a few thoughts on that. One is when AI really started to get more visibility, maybe in the kind of November, December, maybe even January time period, there was a lot of confusion, even with our customers. To be honest with you, I think there's still quite a bit of confusion with investors. There was confusion with our customers around this concept of deterministic versus probabilistic work. Originally it was, there's this AI thing and what can AI do? We should try to experiment and see. I think that carried into the investors thinking, "Well, why couldn't AI just get rid of all of these SaaS companies, all this technology?" I think that was kind of the first wave, which I think has largely been settled down now. Certainly with customers, where I think they're not confused.
They know that 80% of the applications that they have are deterministic, and they're not going to use an agent to go execute that work. There's probably 20% or so that you probably don't even need a software application and an agent or some type of a prompt could actually execute what you need to. I think they're honing in on that. The next step of that was, well, okay, so I'm not going to displace it. I still need a software product, but could I just write my own? Could I actually use now The model started to say, "Well, we can help you write code." There were tools like Cursor, that would help you be kind of almost like a development harness to be able to help you drive using the models to write code, which we do at Pega.
We're not fully rolled out on that, but we're in that journey as well. That kind of takes you back to, well, why would you want to write your own application? In some cases, you write your own application because there isn't something you can buy, to be honest with you. It's just your use case is unique enough. You write your own application because what you could buy isn't quite the perfect fit, or it's just too costly to buy versus you just actually writing it yourself. I think there's definitely going to be applications where the companies decide, "I can actually build my own, and it's going to be faster, cheaper, easier to support." You get into the bucket of why would they try? Many of our clients, I've heard this conversation over and over again where there's a couple dimensions.
One, error rate is one. When you have a situation where you cannot have error rate, there's no such thing as like I'll accept a 1% error, is where the system that you're building is highly complex, it's going to manage a lot of scale, and may be subject to regulatory or control processes. You run into that risk of, is it better for me to build my own ERP system, or should I buy an ERP system that actually I know is hardened to be able to support all those controls? I think when I say that example, most investors would even say, "Yeah, that's kind of ridiculous that someone would go try to build their own ERP system." There are a lot of enterprise systems that have the same level of sophistication and discipline that you would see in some of the ERP modules.
I think that's one of these decisions that companies will make. One of the biggest challenges that our clients are seeing with the AI models is, and I'll get it to the last one, which is cost, but the middle one is the level of imperfection that you get. For example, I'll give you an example. This morning, I was finishing up one of my investor meetings, and Peter, our investor relations vice president, pulls up a screen. The article was from TipRanks, which is basically like a Essentially it's Benzinga of TipRanks. The title said, "Pegasystems stock retreats based on comments made by COO and CFO." We read the article and it said Ken Stillwell made comments at the William Blair fireside chat that caused the stock to go down.
That was 3 hours before I'm sitting here, and that was an actual article that went out. We called them, and they took the article down, but this happens all the time. Right. This is called AI slop. Right. It's out there. Nobody knows if it's right. Nobody knows if it's real. Enterprise company That's just funny that that happened today, but it happens all the time. We have to constantly be watching because the information that gets out. You're an enterprise company. You're Bank of America. You're William Blair. How important is it that you don't actually let AI decide that when you're trying to make a bill pay on your bank account, that it decides you've paid that vendor too much, so pay a different one? How do you catch that? How do you control that?
These are the types of decisions that companies are making. Do I really want to go try to build my own? By the way, for those of you that are not aware, you should ask around on this. AI models now build code that is 50 times faster than a human's ability to review the code, which means we have no idea what it's writing. When we write it at Pega, we have no idea. What you have to do is you have to throttle how much you can. You have to look at the code, run other models to test it, run test models, and hopefully, you actually can know. That never happened before. In the whole world of coding, you never had a situation where one person could write code faster than someone could actually review it.
These are really big challenges that our clients are trying to figure out.
To shift gears to kind of the upshot of AI and how you're leveraging it within the platform. Blueprint, it has been kind of revolutionary for you guys. It's been incredible to see how that tool has helped your go-to-market motion.
Yeah.
It's taken your sales cycles down materially. Can you just talk the audience through what that has meant for you and what that is?
Prior to AI for Pega, if we wanted to work with a client, we typically had to go through a very manual, and quite frankly, very human-intensive discovery session on the front end. That typically involved whiteboard sessions, operational walkthroughs, lots of collaboration, trying to get people physically together, and then quite frankly, realizing that that took cycles to be able to really figure out what do we want the re-envisioning of an application to be? If we're trying to move something or trying to build something new, there was almost like a village that would have to build the view of it, and unfortunately, that could take quite a bit of time. What that meant was slower ramp for sales people, harder to get pipeline deals in, early-stage pipe moved slower.
These were all challenges that quite frankly, we just accepted as part of our business for decades. What Pega Blueprint is is what we did was we took the AI models and we built on top of it all the knowledge of Pega. Specific knowledge of Pega. All the workflow history. How does a workflow work? What are the use cases? What are the personas? What are the typical integration points? That in an actual agentic interface, you could chat with this application and build your workflow. Now the workflow that you build in that is not necessarily going to be one that you click a button and go right into production because these are enterprise companies. It gets you so far down the path compared to what we had to do in before AI.
It's been a massive revolution for us in terms of how fast you can get from concept to a design where you're actually looking at the application. At the end of Blueprint, you can click preview, and it shows you a working application. What we're announcing, or, well, I guess we've already kind of leaked this out, but we're talking about a PegaWorld next week. Next week is our user conference. We're going to talk about the next phase of that, which is the Blueprint experience goes into finishing the build of the application. Something we're calling Infinity Studio, which is essentially keeping that whole agentic experience till the point where you can actually go live and into production.
We know right now that that has taken 50% of the actual time and engineering effort to just get to the point where you could decide what you're going to build. What we want to really do is make this as agentic and as automated as we can to get to application to go live. That's what Blueprint's done, and that's how we're extending Blueprint into the build phase.
Okay. Yeah, that's great. Can you just talk about, a lot of large enterprises are still running mission-critical systems on these legacy applications. Can you talk about what the implications of this technology are in terms of your ability to go and address that opportunity in the enterprise?
I don't know what the percentage is, I've heard different percentages. Anywhere as low as 10% and as high as 25%, which is the percentage of applications that have actually been modernized in large enterprise. I've heard Amazon talks about between 8%-10% of applications have been modernized. I've seen more aggressive ones in the 20%-25%. Whatever you believe the number is, it certainly is nowhere near 50%, there's a lot of work to do in terms of getting these typically homegrown systems running on ancient infrastructure into a more modern world. Whether that be on cloud, public cloud, like Pega Cloud, or whether that be managed on a virtual private cloud.
What Blueprint does for us, which is just massive, is it allows us to go after new logos and new workflows in a much more aggressive way because the upfront selling process, the upfront solution process is so much faster. If you think about in the previous world before Blueprint, if we wanted to target a new organization, the first thing we had to do was hire a salesperson that would target that. The next thing we did was train the salesperson for three to eight months to get them certified on Pega. They would start calling the company. Remember the whiteboarding session example? That might be a six to nine-month pipeline building. We had salespeople that we would hire, they might not build pipe till their second year of working there. That's if they followed the path. Now we can hire a salesperson.
They don't need to be certified on Pega. All they need to know is how to get to pega.com/blueprint. That's the extent of what they need to know. Blueprint is right there. They can engage with a client in a first meeting. The other thing is with new logos, if you think about a company that knows Pega, like Bank of America, I'll use that example because they're a large, many decade client of ours. We don't go into Bank of America and say, "Let me tell you what Pega does." They already know. If we go into a brand new client, they don't know what Pega does. We're going to go into that brand new client. Blueprint is an easy way to show it, say, "Let's walk through one of your problems." Onboarding a client, managing a dispute. You pick whatever that vertical might be.
It just makes the whole conversation. You're immediately going in to a demo that's very specific around the customer use case. The level of confidence that gives our sales teams, how fast we can ramp our sales teams, how quickly we can attack new logos, these are all brand new things for us.
You can correct me if I'm wrong, you guys have actually quantified your sales cycle might have been 12 months before on average. It's been cut in half.
Yeah.
Like last quarter, you highlighted some deals that went live in what, 90 days?
We had one that went live in 42 days.
42.
Which may seem like 42 days for not knowing enterprise software, I may say, "Well, that's still a month and a half." To take an enterprise application and actually go from whatever they had before into a working application inside of a quarter is nearly unheard of in enterprise. We've had a handful of those in the past two quarters.
Yeah. Pretty impactful.
Yeah.
Okay. We can get more into the financials in the breakout, just one. There was some noise in the first quarter on the ACV growth. There was some noise around the license revenue-
Yeah
the renewal timing, a little disruption within your federal pipeline. How should investors be thinking about current ACV growth versus the growth that you expect over the next few quarters?
In our business, much of our growth comes on the backs of a renewal cycle. If a client has a renewal event, typically that's when our ACV is our equivalent of ARR. When our ACV increases, a customer typically makes that commitment based on the usage or systems that went live in the previous year. We're tied to renewal cycles. In 2025, our renewal cycle was not back-end loaded. In fact, actually, there were more compelling events in the first quarter. Last year meaning 2025. In 2026 when we guided, we had exactly the opposite. We have more compelling events in the back end of the year and not as many in the first half of the year. It creates this dynamic of just difficult compares in the first half of the year and easier compares in the second half of the year.
It makes our growth rate kind of bounce around a little bit because we measure a trailing 12 months. That's really what we had talked about. Now, separate from that, in Q1, we had a few kind of isolated incidents that caused our bookings to be slightly lower than even what we would've modeled. We would've modeled about $25 million of net new ACV in the first quarter, and it was about 20. We were at about a $5 million gap. Some of those were some of the government shutdown and changing to the processes that they've had some deals slip a little bit. These are renewals with expansion. These are not deals that we have to win. They're just paperwork situations. We had a couple of those.
We've had a few situations in Q1 that were for various reasons that caused Q1 to be slightly lower than what we had modeled. We had said from the very beginning, and we still feel that way, that first half of the year, tough compare. Back half of the year, easier compare. It will cause some growth gyration through the year.
Mm-hmm. Okay. Got it. There's some more mechanical factors at play than anything necessarily concerning, and you guys still feel pretty good about that mid-teens ACV growth target for-
I think probably the only thing that does concern me, but I don't know how to quantify it because it's not an empirical concern, is supply chain disruption from the Middle East. I still don't know how to measure that risk.
It could be nothing. It could manifest itself into something. I think that's the one that I'm just still kind of not sure how to. We're not in the energy space. I think I'm just more worried about the macro impacts that could happen. Europe has been under a lot of strain with Ukraine. I think with natural resource, with having some shipping delays and certainly running low on inventories for oil and gas. Those are some areas I'm watching. That said, the consumer has held up pretty well.
Okay. Great. I think we're just about at time. We'll wrap it up there. Thank you, Ken, very much for being here.
Awesome. Thank you.
Appreciate everyone coming in, and the breakout will be