Appian Corporation (APPN) Earnings Call Transcript & Summary

Why don't we go ahead and get started? First, the boring stuff. Please note that all important disclosures, including personal holding disclosures and Morgan Stanley disclosures, appear on the Morgan Stanley public website at www.morganstanley.com\researchdisclosures or at the registration desk. And with that, I'd like to welcome the Appian management team once again to the conference. We have Co-Founder and CEO, Matt Calkins; and the CFO, Mark Lynch. I think you've joined us almost every single year since you've been public. So it's really, really great to have you back at the conference.

So maybe just to kick off the conversation, let's just start a little high level. When we think about the problems that you're solving for your customers, can you just walk us through 1 or 2 of your favorite customer examples, sort of highlighting the value that you're bringing to your customers and the types of problems that they're solving that they could maybe have done before, pre-Appian?

Yes. Yes. That's right. Can you hear me all right? All right. So Appian is a platform. On Appian, you build applications. And typically, those are applications that don't come out of a box. So our customers are building something mission-critical, something important, a key process that differentiate from their competition. And they want to do it quickly. And they want to be able to change it quickly, which is to say we're offering them low-code. We were the first vendor of low-code to go public as a local vendor, and low-code has been our modus operandi since before the word was even invented. For 10 years now, I've been pursuing an idea with Appian that said, "We want to let people draw an application, draw it like a picture, express yourself in a human fashion to a computer and allow that to become an application." And if you do that, you'll build an application maybe 10x, 20x faster than if you described it in computer terms. Not only is it faster to build, it's also a lot faster to change. You can look at that picture, which is a flowchart. You can modify it. You can see what's inefficient. You can route work differently. It's like writing an application with a mouse instead of writing with a keyboard. The simplicity and the intuitiveness, it's very human, it's very empowering. And the key thing with Appian is that not only can you build an application really easily and efficiently, but that is also a powerful application. And here's where we divide from most of the firms that call themselves low-code. Appian is used not just to build applications easily, but to build powerful applications easily. Appian is used by major financial services institutions, major governmental institutions. I could give you a few examples. Major pharmaceutical institutions, we have -- we do serious mission-critical things for these organizations. That's the difference. Whereas low-code is sometimes seen as a toy, we have put it to very scalable mission-critical use.

Great. And you mentioned -- there's a lot to unpack there. But just in terms of the branding of low-code, a couple of years ago, it was still pretty nascent. And now it's kind of part of the menu of digital transformation, right, 2 years later. To what extent do you think the term, though, actually describes the value proposition of Appian? That's the first question. And then the follow-up to that is in terms of the end users of the platform, who are the users? Like what type of skills do they have? How many of them are out there?

Okay. So that's a lot of questions to follow on my lot of answers the last time. Okay. So does low-code describe our value proposition? Okay. So it certainly does. The world's got a problem. Let me just say, the world's got a problem. We're going to build as many applications in the next 5 years as we built in the last 40, and we're not going to have 8x as many developers in the next 5 years, not even close. So we're going to have to make more out of every developer that we've got, and the way we do this is low-code. I don't know whether it's going to be called low-code or not, but we're going to need a technology to multiply the effectiveness of our developers. There's just no question about it. The demand is so high for applications. We're just absolutely going to need this. So we are working to create that leverage that organizations will demand, but we're doing it in a different way in kind from what other low-code vendors are doing. We're providing a lot of institutions, prebuilt institutions for integrations and for data rendering and for rules. We've got a built-in rules engine, right? We're not saying we're low-code but start from ground -- from the ground floor. We're saying we're low-code and here are a lot of prebuilt institutions that you can manipulate to quickly get to a very efficient, effective application. And probably the most exciting institution of all that we're offering is automation, and we just -- I should let you ask the question instead of answering it before you even ask it.

Continue.

We've recently -- well, okay, let me describe what the situation is in automation. 5 years ago, if you were delegating a job to someone, that someone would be a human, right? We're a workflow company from way back. We delegate work, and every job went to a human. And if it didn't, then it went to a rule, and the rule is just like an instantiation of a human decision made automatically, right? But we were not leveraging alternative factors, but now we are. Now jobs are done by artificial intelligence, and jobs are done by robotic process automation. And the trick in workflow now is to make efficient use of the multiple factors in the workplace. Humans are good at some things. Humans have human judgment, but they're incredibly expensive and slow. Robotic process automation has no judgment whatsoever. It follows a script, but it's incredibly cost-efficient. Artificial intelligence is good, in my opinion, at advisory and quantification and recognition jobs but shouldn't generally be making decisions. So it needs to work in complement with humans. A good teamwork event will involve all of these factors, plus rules, each doing what they are specifically good at. So for example, let's say we have to onboard 1 million pages of new applications for our insurance product, right? We'll send this to the RPA bots first and let them upload everything they can, everything that's totally compliant. Everywhere where the data matches exactly where it should, we'll just put that to the bots. Everything that doesn't work, maybe hand-written things, we'll send that to AI and see if they can decipher the human handwriting. Anything that fails at both steps, we'll send it to people. People will type in what that means. Whatever we get out of AI and people, we route that back to RPA, and the bots will upload it into databases far faster than the humans could have done. That's teamwork. In many cases, now we're seeing teamwork. At S&P, they take in data, financial results, and they process that, those results, with RPA. With AI, they make recommendations about what their notes want to be. And then with humans, they review those recommendations and send out their final product to consumers like all of us. It's a teamwork. And we are, I think, uniquely leveraging or enabling the team of different work factors. We have long experience orchestrating the workflow and delegating to humans and delegating the rules. But now we have also bought an RPA company, and we have strong partnerships with all the RPA leaders. So we're really facilitating that. And at the same time, we ship with some AI applications in Appian at no charge, and we also ship with Google AI. And we are also highly compatible, certified and with prebuilt connectors to other major AI. So our goal here is to offer the low-code consumer, at their fingertips, all the power of automation, including the diversity of workforces and be the platform that harnesses all of that and makes it all available at their fingertips. So that's the goal, and that's the meaning of our recent acquisition.

Right. In terms of just sort of sticking on the end-to-end platform vision, so it seems like what you're saying is that the role that you're going for here is sort of orchestrating that work. And you're going to sort of be the central nervous system in terms of what gets sent out to the bots, what gets sent out to the AI algo, and what gets sent out to like the human. Is that...

That's exactly right. And you mentioned before who are our users, and I didn't get around to answering that. We have 2 batches of users. We have the designers, who work in our environment to create a new orchestration, and then we have the humans, who would do the work that they've been delegated, and that also occurs within our environment. And it runs on every mobile device and it's native. And it facilitates distributed work, but both count as users and both are licensed.

Okay. Last question on just sort of the low-code sales and developers movement as we think about the last couple of years. To what extent has that proliferation, that sort of common knowledge in the market, has helped Appian in terms of sales cycles, acquiring new customers more efficiently or expanding into segments or verticals that you weren't in before?

Yes. That's right. Certainly, we stand to gain from the increased acceptance and recognition of low-code, and of automation for that matter, amongst the enterprises. We have been slowed down traditionally by the nonintuitiveness of our offering. We're in a developing space, and we have a somewhat iconoclastic feature set because we never want to conform to what our market is. So we're always offering something different, and it makes for a difficult explanation. We're looking forward to the time when customers already know they want to buy our industry, and they already know they want to buy from us. That would be a great thing. But in the meantime, we have long sales cycles, and we struggle to simplify our expression so that customers will understand quickly and be able to move forward. We want to tighten the adoption cycle. That's one of the main ways that we can make progress in years ahead. Today, in order to adopt Appian, you've got to figure out what it is. You've got to buy it, and you've got to implement it. All 3 of those segments could be accelerated substantially. We're trying to make a cleaner, simpler and more intuitive message. We're trying to shorten the sales cycle with things like solutions, and we're trying to shorten the implementation cycle. I asked our engineering department to find ways to cut in half the amount of work it takes every 2 years to deploy the same application. So all of this should be shrinking and, thus, the kind of the propagation accelerating.

So just to follow up, it sounds like there's still a little bit ways to go. Who do you think is the force in the market sort of evangelizing this market? Is it Microsoft? Is it...

Well, when you say this market, again, we exist at the crossroads of a few things. And I want to say that they're conversion. I want to say, for example, that the market whereby we plan our work and the market by -- where we do our work are converging. And that's going to be called automation. And it's going to include low-code for the planning and RPA, AI and rules for the doing, and vendor -- sorry, and buyers are going to want to buy that from a single vendor. And we're going to have an advantage for the fact that we're first out there saying we have a unified solution for automation, including low-code, including RPA. I think that's going to be an advantage. But when you say this market, everybody's going to take a slightly different cut of what this market is, and we're trying to preempt and to crystallize the comprehension of our market around what we think it should be for value purposes to the customer and also where we have a unique advantage, which is why we've established this confluence of low-code workflow and RPA/AI.

That makes a ton of sense. There, I want to dive into deeper. But before we get there, let's talk a little bit about the operations of the business. I think one of the key highlights in terms of the metrics that you guys put out on usually at the fourth quarter is sort of the net new subscription customer count. I always wonder like what that number is going to be. And I think it was 85 the first year of your IPO, bumped up a little bit to 87. Went up to 109, right? It was a pretty material acceleration. So what was sort of the ingredients that drove that acceleration in net new subscription customers this year? And if you think about whether it's partners or just greater acceptance of the platform, do you think that can continue to accelerate going forward?

Well, it's -- would you like to answer?

Yes. Let me give a piece of the answer, right? So another factor that we talked about in the earnings call was that partners, net new logo adds, in 2019 were 70% higher than they were in 2018. So obviously, that momentum obviously helped us get those net new subscribers. So we're seeing a lot of good early innings, adoptions of partners, and we're hopeful that it'll continue to -- continue throughout 2020 and beyond.

Well, you said it. I mean the key is partners. The key is that we're using partners for their outreach, for their credibility, for their reputation in places that we haven't hired anybody and for their ability to supply expertise that we would be unable to supply. So riding the partner wave into new logos is the best way to shorten the sales cycle and also to attract a lot of new customers. In fact, I see a little bit of a bifurcation right now where our partner-led deals are seeking new logos, and our internal deals are seeking deeper relationships with the logos that we've already got. And the funny thing is that year after year, I see this bifurcation happening. And still, our dollars per customer stays right on $0.5 million. I don't know which way it's going to go, depending on whether our partner outreach or our deepening is more successful in 2020.

Feels like there's momentum on both sides of that equation. Let's talk a little bit about those partners. So maybe let's just start with the big 3: Accenture, Deloitte, KPMG. Can you give us a sense where each of those partner is in terms of their Appian practices? How much train capacity they have, if you want to use like the baseball analogy, whatever analogy you would like, to sort of stack-rank where each of those are in terms of their maturity and where they're headed with in terms of building their Appian practices?

Yes. Yes, definitely. So we're not going for a lot of partners. We're just looking for quality. And so we've got a few that we're focusing on. And that way also, they're going to be more committed to the quality of deployment, and they're going to keep our reputation high, which is still important to the way we've grown heretofore. We don't want to lose that edge. We're known as the highest-quality deployment, and our analysts recognize that, so we want to keep that reputation. Our top partners, and I largely agree with your list, but I would add to Accenture, PwC in there, and we got a few Indian, a few European. Our small group of top partners, we're asking them to make a commitment: to invest in expertise so that they really understand the product when they do a deployment. And even more importantly, and this is really the key, to invest in building solutions in advance on our platform so that when they meet the client, they're already ready with the fruits of their Appian work. They should show up and say, "You've got a LIBOR contract migration problem? Well, I've already built a LIBOR migration solution using AI on the Appian platform. Let's just plug it in." And they know they're going to encounter 50 or 100 customers with exactly that same problem. Hence, why they're prebuilt. We're encouraging them to make that commitment. We're supporting their development, and we're co-selling with them. This is really the mark of success for us. Amongst our top partners, this is the thing we want, prebuilt go-to-markets, and we've got several. We've got one PwC built that helps pharmaceutical companies coordinate with their own doctors. We've got one on LIBOR that I mentioned. We've got one on GDPR. We've got one on the California privacy law, and others are in process. When we push a partner relationship right now, it's more than just quality and staffing. It's building out a go-to-market and selling it as a solution, which is also Appian's strategy. We're selling our own product as a go-to-market solution as well. I think it's shortened sales cycles. It eliminates competition. It defends our margin, and it's easily extendable. Also, once we get in with a solution, it's easy to be compatible with that in future sales.

Great. Last question on partners. As you think about the international opportunity, who are the partners that you're targeting to help you scale into some of these new geos?

Yes. We have -- well, we're counting on our core partners. They are global, after all. So we don't go for a lot of local partners. There are a few regional specific ones like Atos, for example, in Europe. It's a selection. But for the most part, we're working with global partners, KPMG, Accenture, PwC. That's our cohort.

Let's take a couple of minutes to talk about just sort of the marketplace, the competitive landscape. We touched on it a little bit, but I just wanted to drill in on it for just a little bit. In terms of the overall market, though, what are -- what is the sort of dynamics of this market? Is this a winner-take-all or winner-take-most -market? Is it just a huge TAM that's going to be fragmented among several players? What is your sort of thesis about this market in terms of how market share gets distributed in this space?

All right. I don't think it's a winner-take-all. There's not a standards-forcing function that would cause that outcome nor is there a scale factor and nor is there a, yes, like a customer capture, all right? So no, I don't anticipate that at all. There'll be a fracturing. There'll be a severe fracturing in RPA and the factors of work, which allows the emphasis and the value-add to be on the orchestration. And so we plan to make open relationships with the RPA vendors and then be the orchestrator, be cooperative with all of them and orchestrate. That's our approach to what I expect will be a very fragmented RPA and work execution layer. It's the same for AI, very fragmented. And in terms of our low-code products, it'll be naturally dispersed. There won't be a primary winner there. There'll be plenty to grow into. The TAM is gigantic. And in terms of automation products, I think the ante is pretty high. I think it's good that we're first, and I believe that there'll be some more entrants, but that we shouldn't see that split too many ways. I wouldn't be at all surprised to see some consolidation that gives other automation suites a chance. But right now, we've got a neat position.

You mentioned the TAM. And how do you think about the rise in that TAM? Is it a function of the number of users on the platform? Is it the number of logos? How big do you think...

There's a couple of ways to view it. One is to take all the different areas that we're a leader in, albeit BPM or low-code or whatever, add up all the TAMs of those, and that becomes a pretty sizable number of $35 billion, $36 billion. If you do it bottoms-up, which I think is the best way to do it, it's basically looking at all the target customers that could be using our platform in the different verticals and the average ARR that we're getting from those types of customers, build it up, and it's around $36 billion, too. So either way you look at it, it's fairly sizable. If you looked at the entire market, because you could argue that this entire market is application development, software application development, that's like $179 billion or $170 billion. So it's like -- it's a very big space. It's one of the biggest white spaces, we believe, in all the software. So...

So in terms of framing up the competitive environment, I want to organize it into 3 buckets: IBM and Pega, which have been like kind of incumbent sort of BPM vendors that are trying to build more low-code functionality into their platforms; Salesforce and ServiceNow, which are -- have significant marketplaces in the past as well; and then the cloud guys, Microsoft and who knows what Amazon is going to do. And so in terms of having this discussion before we get there, can you give us a sense of the types of applications, the types of processes, the types of workflows that is best automated in your platform versus somebody else's?

Yes. Yes, definitely. We're aiming to be the platform that you'd want if you were building something scalable, secure, mission-critical that your business differentiation depended on. We've got a long history of building that kind of application, of being the most solid, reliable, scalable choice. We're first in line when it comes to a new security threshold. We were Amazon Web Services' first authority to operate in the whole U.S. government, right? We're a pioneer in this. And we have -- this is a credibility business, too. When you're automating unique applications, it's a career-defining decision, and the safety is important. And our track record is important. So we've established ourselves there. That's also the part of the market I'd far rather be in because as this gets popular, as low-code or automation becomes popular, you'll see lots of entrants, and they're all going to be entering on the simple side without the reputation but low prices, low functionality, simple put-togethers. I wouldn't want to be competing at that end of the market. I think it's great that we've positioned ourselves behind a wall of reputation at the high-end, high-margin part of this business, and that's the kind of application you should build on Appian.

Is there any line of demarcation between sort of internal-facing processes versus customer-facing processes? Or...

Yes, there is. Internal decisions are usually more complex than the decision between an enterprise and its customer. An internal decision probably has more decision-makers, more processes involved, maybe some rules involved. Maybe you need AI to make a recommendation. Maybe you need RPA to load it into 20 databases. The customer doesn't have that. So the customer transaction decision is necessarily limited by the bandwidth of the customer. What you do with that decision could be really complex, but the actual transition between a customer's decision and a company, that's a very simple -- a thin connection. So Appian being a rich tool, we have generally focused on the rich decisions at the middle of the organization and not on the fringe. We may reach to the fringe in order to retrieve information from the customer like a decision or like a change order or something. But then generally, we're used for the more complex behaviors inside an organization.

But having said that, one of the things we offer are prebuilt UIs, which are very modern and basically something that customers will be proud to have customer-saving or customer-facing. So to the extent that our customers want to build those customer-facing applications with those prebuilt UIs, I think we're well suited to do that as well.

Got it. We're flying through this conversation, just realized we have about 5 to 6 minutes left. And I want to give a chance for the audience to ask a question if they'd like. So maybe just to sort of fast forward on a competitive question because I think people want to hear more about the angle around Microsoft Power Apps, and Amazon is reportedly working on AWS for everyone, a low-code play. How do we think about Microsoft Power Apps, the public cloud guys? To what extent do they overlap with what you guys are doing? How should investors sort of think about the potential competitive dynamics here?

All right. We're first in low-code, and we're the most sophisticated. And as new entrants come in, even giant new entrants, even fantastic winning companies like Microsoft and Amazon, they're still going to start at the low end. That's where the main value and the biggest audience is going to be. That's also where their traditions are. And so their entrance is not going to be in direct competition with us, but it will have an effect on us. If Amazon, for example, tried to make its AWS offering more sticky and less enhanced margins by creating a platform as a service similar to what we're offering, I think it would drive a lot of their customers, with some degree of worry, for the price increases to come. They will be driven to a fair broker, a portable technology like ours, compatible with multiple major clouds, to retain their price leverage. So I think that a move by Microsoft or Amazon to claim this ground would drive a lot of customers to the best-of-breed alternative. The -- and that would be us. So I don't regard it entirely with trepidation, but I think it could, in some ways, be a positive development. It would elevate the profile of what we're doing, and it would also drive a lot of business to us.

And so just in terms of the framing, I think what you're saying is that when it comes to like at least the first couple of versions of whatever product comes out from Power Apps or Amazon, they're probably going to focus on sort of the low end of the market. And you guys are skating to where the complexity is going in the business. Let's see if the audience had any questions. Yes, got one right here.

Yes. Thank you. You mentioned that you were using partners to accelerate your customer acquisition. But the names that you mentioned, Accenture and especially the Indian guys, application development, especially the complex application development, is their highest margin business, and you are essentially cannibalizing that. So how does that work?

All right. So first of all, the world does change and tools become more efficient, and they have to keep up. So our edge right now is to work with a few partners and be their secret weapon, be their differentiation against their competitors that they can be more productive. The second thing I'd tell them is Appian is not a one-application proposition. You may be selling one application into the enterprise today, but our goal is to impress the enterprise enough that they decide to standardize on Appian. They're going to write not 1 application but 50 or 100, and this has happened. This happens right amongst our customers typically. And in that case, the partner that brought us in is going to be in the lead for a very long series of projects. And so there's something to be gained with a generational rewrite of the custom side of the enterprise, where just all the tremendous greenfield that comes from building as many applications in the next 5 years as we built in the last 40, there's going to be a tremendous amount of new applications built in this decade. And I will predict that in this decade, most of them will be built with low-code. And so a partner who wants to be with the modern way of developing is going to have to be with a low-code vendor. They regret that it's a little more efficient and, therefore, deploys fewer hours, but they're going to appreciate that they're on the cutting-edge of change. And they absolutely want to move up the value chain. They want to be the one that goes into the C-suite and brings a new idea. They all come to us and ask, "Can you be that idea? Can you be our differentiator?" They don't want to just sell hours, and they know that, that's not a winning business. The margin is declining on that. They need to be the strategic, trusted adviser, who brings not just hours but solutions who adds value at high levels, strategic levels from the organization. I think there's generally a movement to try to fill that, and we are a vehicle for that movement.

Got 2 minutes. I want to hear on pricing a little bit. And in terms of like historically, you guys have priced on a per seat basis, and that's been evolving. And you've been moving to more of a per-app pricing model. Can you talk to us about the progress there? What percentage of the base is or new business is on per-app pricing? And what's sort of the impact in terms of initial deal sizes but then the longer-term opportunity within the customer? What are you driving towards with per-app pricing?

The ideal pricing curve would lock in Appian's permanent price at some point during the relationship rather than prior to the relationship. A customer who buys software today, a new software, a new industry, a new product is buying according to their belief of the value, not their knowledge of the value. And unfortunately, the newer and more speculative your industry seems to be, the lower their belief is. So they -- the lower their price tolerance. Now you know software. We build it in advance, and then people buy it. So I mean, theoretically, we'd be willing to sell it for $1, right? So we don't want to be stuck in a situation where we have to mark down the price well below the actual value because of the risk discount applied by our cautious buyers. The ideal trajectory then would be to sell an application price at the beginning at bargain perhaps, application price that does not set a precedent and then to switch into a per-user price later on once we have the leverage of the customer knowing the value that we can add. So that's what I'm trying to do, to create a marginal cost curve that actually increases over time. It's typically not the case in enterprise software, but that's the intention. And that's why I've emphasized application prices for the first transaction.

What's been the progress so far on that?

It's good, high adoption. They like the discount.

Yes. No, at least greater than 50% [ of lease ] sale. They like it. It minimizes the impedance. It shortens the sales cycle. It gets sort of -- because they can't -- if you do on a per-user basis, the customer knows they're going to be stuck with that pricing for a long time. They're going to grind you, especially when they don't understand the true value of Appian until you go ahead and implement it. They've certainly heard this pitch before, it does all these things, whatever. So you're going to get ground for a while. And the application specifically is like unlimited users, it's going to solve this problem, it's well within your budget. And a lot of times, a ROI's tied to it. You can show an ROI within 1 year, and it's -- boom, it makes it a lot easier.

And you guys are making a bet that they're going to go from app 1 to app 2, 3, 4 and 5.

Yes. And the beauty of that, too, is that per user, you could have multiple applications with the same user. So you only have 1 license. With an application, you get the same user under multiple application licenses. So there's a chance -- I think Matt's background is he's an economist by nature. And so at the end of the day, he feels that you're going to be able to extract more value out of a customer using the app-specific. But remains to be seen, right? A lot of people are used to buying on a per-user basis. As a CFO, I would prefer to buy on a per-user basis so I can model it out. But I've been pleasantly surprised at the adoption of the application-specific licensing. So...

We're selling velocity. We've got the Appian guarantee that says your first application is done in 8 weeks, right? We want to establish efficiency right away because it'll differentiate us from every competitor we've got. The low-code crowd does not move as quickly as we do. Pegasystems, they cannot deploy an application as fast as we can. And so if we establish that efficiency right at the beginning, that's how we're going from 1 app to 50 apps. We make that statement upfront. And by guaranteeing the first deployment in 8 weeks, we've got the client thinking about the Appian value proposition the way we want them to think about it.

Got it. And with that, we're all out of time. It went by fast. Thank you, Mark. Matt and Mark, thank you.

My pleasure.