a16z's latest interview: It's too early to say SaaS is dead; the biggest bottleneck for AI deployment is no longer the model's intelligence.

Faced with extreme market panic over the narrative that “AI will destroy SaaS,” a16z partner Alex Rampell believes this concern stems from a detached, static mindset that is out of touch with reality. Core business processes that are truly embedded in handling real-world situations will not only survive but will also experience explosive cash flow.

On March 6, renowned investment firm a16z and Atlassian CEO Mike engaged in an in-depth discussion about the current market obsession with the “SaaS disaster” narrative.

Participants believe that the current panic is somewhat disconnected from reality. AI is not the end of SaaS but a catalyst for industry segmentation; future software competition will focus not just on model capabilities but also on business logic barriers and pricing psychology battles.

SaaS valuation divergence: Who will go to zero, and who will see cash flow explode?

Currently, public market investors tend to lump all software companies together, but in reality, AI impacts different SaaS categories very differently. Rampell points out that existing SaaS companies can be roughly divided into three types, yet the market does not distinguish their capabilities.

The first type is extremely risky “accounts linked to output” companies, like Zendesk. Rampell says:

“Zendesk is the ‘patient zero’ here. If Zendesk’s customers now use Sierra, Decagon, or opt for self-developed solutions, their required accounts could be zero.”

For this type of company, if they do not shift to result-based pricing and thoroughly change their existing model, “that revenue stream will absolutely go to zero.”

The second type involves core business systems with extremely high barriers, such as Workday. These systems are superficially billed per account, but this is just a “smart pricing strategy.” Their true moat lies in built-in implicit rules and edge cases accumulated over decades. Rampell emphasizes:

“Many software are essentially deterministic rules learned over decades… What if an Indiana employee leaves while on maternity leave? Unless you’ve personally encountered such edge cases, you simply wouldn’t know.”

For these deeply ingrained enterprise systems, AI will not eliminate them—in fact, it will add significant incremental value.

“Truly core business systems, sticky, relied upon, and embedded with all edge cases, will thrive… When this truly happens, future cash flows will grow substantially, which shocks me.”

The third category includes products in an intermediate state, like Adobe. AI era will reduce demand for these products, but the impact is less extreme than Zendesk’s and not as unaffected as Workday’s. The impact is somewhere in between.

Why do customers dislike “pay-per-result and token-based billing”?

As AI becomes more widespread, front-end applications and back-end databases are gradually decoupling, and software pricing models face serious challenges. There is rising advocacy for shifting to “pay-per-consumption (Token/Points)” or “pay-for-results,” but practical implementation faces many hurdles.

Mike sharply points out customer resistance:

“When you talk to customers, you find they really dislike this approach. They are genuinely opposed to star-annotated clauses.”

He explains that traditional cloud storage billing is controllable, but in the world of AI tokens, it’s a black box for customers.

“Customers feel they don’t understand what these tokens or chips you give me actually are… I can cause my customer’s quota to double overnight just by adding a bunch of features like generating great summaries for you. Customers will think I didn’t ask for that.”

Additionally, billing based on results (like cost savings) works well as a sales pitch in the first year, but by the second year, customers see the baseline lowered and find it hard to measure the incremental value AI provides. Therefore, Mike concludes:

“When you talk to customers, they still prefer account-based billing. This might be because they now understand this model better and have been burned by many usage-based billing schemes.”

Vibe Coding cannot replace core processes

The tech community currently popularizes a “replacement theory,” believing that through AI coding (Vibe Coding), companies can write code themselves to replace all traditional SaaS tools. But Mike states this idea is unrealistic.

Mike says the core of knowledge-based enterprises lies in coordinating thousands of input-restricted (e.g., legal, customer approval) and output-restricted (e.g., R&D, creative marketing) processes.

“I personally dislike the term ‘core business system’ because it sounds like a static database… For me, business is a process-based system, not a record-keeping system.”

The real change brought by AI coding is not rewriting a Workday from scratch, but enabling companies to build highly customized applications on top of these foundational giants at very low cost. Mike explains:

“For example, I want a conference room booking app for the Miami team… In the past, I couldn’t afford it… but now I might be able to build it easily. This app uses Workday’s global data and rules at its core.”

This actually makes the underlying SaaS giants “more sticky and valuable in the enterprise market.”

The last ten kilometers of AI implementation: trust design, not model IQ

When exploring future product possibilities, the interview reveals that before AI software can generate revenue in the real world, it must cross an experience gap. Current models far exceed the actual delivered value, with bottlenecks in UI/UX design and human trust mechanisms.

Mike points out that introducing agents into complex business approval flows faces the biggest challenge not in underlying computing power but in eliminating the black-box feeling. If AI instantly handles a dozen emails, users’ instinct is panic, not gratitude.

“Blindly promising ‘I can do anything for you’ will only leave users confused.”

Future software interaction is evolving from “skeuomorphic” to first principles. Take document flow as an example: traditional typing and formatting are being replaced by an AI collaboration mode where “the left is the document entity, the right is the chat window.”

Although changing users’ decades-old habits is challenging, this is not only a paradigm shift in product design but also a necessary path for SaaS companies to turn AI potential into tangible subscription revenue. As Mike states:

“The reality is, not every SaaS company will thrive over the next decade… but for us, this is the best thing that has ever happened in our business.”

Original interview transcript:

Alex: From 1960 to 2022, the entire history of software is about turning filing cabinets into databases. The first example is IBM’s SABRE system developed in 1960 in partnership with American Airlines. It replaced the paper reservation system managed by numerous secretaries stored in safes, digitizing the data into early databases. Keep in mind, in that era, a 10MB hard drive could cost hundreds of millions of dollars. The development of electronic health records is similar; Massachusetts General Hospital developed the earliest system, MUMPS. Likewise, Salesforce and the first CRM company founded in 1987 are essentially turning filing cabinets into databases.

This approach has benefits but didn’t make the world significantly more efficient. Previously, if you needed Eric’s info, you’d have someone retrieve it from the HR filing cabinet. Now, although data is in Workday, you need a Chief Information Security Officer to prevent hacking, and IT staff to configure accounts in single sign-on systems. Efficiency is only evident when collaborating across regions—people can now work together and perform complex joins on databases, which was much harder with paper documents. But fundamentally, from 1960 to 2022, software remains static because filing cabinets cannot think.

What’s happening now in AI is the coolest thing: filing cabinets can do work themselves. For example, QuickBooks can now independently complete certain tasks without relying solely on humans retrieving files from the system, akin to saying goodbye to the 16th-century accounting department digging through archives—very exciting.

Erik: That’s a great entry point. Everyone is now discussing the “SaaS end times” or even “SaaS disaster,” which clearly refers to what’s happening in the public markets. Many have different views on its significance. I’d like to hear how you two interpret this? What exactly is happening? And more importantly, how should we understand all this? Why is everyone so fearful?

Mike: I think the whole world is trying to figure out how to rate or value software businesses during this highly disruptive phase. Everyone has sharp opinions about what the future might look like. Different views paint two extremes: for the entire software industry, certain companies, or categories, it’s either very good or very bad. Undoubtedly, the risk level has increased.

From an investor’s perspective, SaaS used to be a very stable category, but now, with higher risks, people are stepping back to observe. As I often say, investors aren’t necessarily trying to discount all past profits via cash flow models; they’re trying to guess what other investors will do, or betting on how others see the future.

The current panic is somewhat detached from reality. People keep thinking: “If AI can achieve a certain function in two or three years, what does that mean?” I believe this stems from a very static mindset, as if people won’t adapt, the world won’t change, and only AI is changing while everything else remains static. So, it’s interesting: companies like ours still perform well, with three consecutive quarters of strong results. While we’re not defending the entire software industry, we’re very optimistic about our own opportunities, as our data and results show.

Of course, this doesn’t mean we don’t need to adapt. We are rapidly and thoroughly changing how we work, just like in previous years. Many think we can’t change or respond, which is clearly wrong, though there are many strategic uncertainties ahead. The reality is, not every SaaS company will thrive in the next decade. Just as many failed to transition to the cloud from the Windows era, it’s impossible for all 100 SaaS companies to succeed and grow. Some believe software will eventually diminish or become just a revenue stream. But I can say for our company: this is the best thing that has ever happened to us. We operate in a knowledge-based world, with tools to explore and act on knowledge to accomplish tasks clients hire us for. Logically perfect, but we need to prove it in practice during the transition, as market patience is hard to maintain.

Erik: Alex, what about you? How do you react to what’s happening, or how do you interpret it?

Alex: I hope my long-term judgment is correct because what’s happening now is crazy. I tweeted about this a few weeks ago. I’ve observed roughly three types of SaaS companies in the market, but the public market can’t distinguish them. One type’s accounts (seats) are linked to output, occupied by actual system users—like the filing cabinet analogy again.

Before diving deeper, I want to step back and answer your question. Dan Ariely wrote a great book called Predictably Irrational. I used to send this book to all our product managers to help them understand how to charge users. A classic example: imagine being locked out at midnight, calling a locksmith. He arrives in a minute, spends 30 seconds opening the door, and charges you $500. You’d think: “For 90 seconds of work, $500? What a rip-off!” You’d leave a one-star review on Yelp, refuse a tip, or even dispute the charge.

Now imagine another parallel universe: the locksmith takes 9 hours trying to open your door. He goes back to the office for more tools, works until 9:30 am, and finally gets you in. You’d be grateful, tip him $200, and leave a five-star review.

This example shows that people are willing to pay for “ineptitude” to some extent. Many pricing strategies are about psychological fairness. We feel it’s fair to pay more to someone who worked all night, even if they’re incompetent; but we get angry at highly capable competitors charging too much. Logically nonsensical, but emotionally fair.

Think about how SaaS evolved—monthly per-user billing. When offered for free, configuration costs are nearly zero. It’s not about everything, but about fairness. For example, if you have 500 accounts, you pay more than if you have just one, even though the backend mechanisms are similar.

So, I believe SaaS companies can be roughly divided into three categories. The first is those who originally needed accounts (seats) to produce certain outputs but no longer do. Zendesk is the “patient zero” here. If Zendesk’s customers now use Sierra, Decagon, or self-developed solutions, their account (seat) needs could be zero. For Zendesk, this is about the present value of future cash flows. They are at risk because if they only charge per account (seat) for existing products and do nothing to change their code or pricing, their revenue will go to zero. Conversely, if they shift to result-based pricing and abandon the old model, their revenue could triple or quadruple. Still subject to fairness and irrationality, but the path is clear: unless they change, they will go to zero.

The second type charges per account (seat), which feels fair but isn’t tied to results. For example, Workday charges based on the number of employees—say, $X per employee per month. Why? No particular reason, just fairness. But GE’s employees aren’t using Workday to produce results. Workday is good, but it’s about what AI tools can do. For example, HR at GE must review files in Workday and call three companies for background checks—AI could do that, but only if it’s a core business system. The IT sector has fallen 45%, but no one abandons QuickBooks. These two pillars—per account (seat) billing and result-based billing—are just smart pricing strategies.

The third category includes products like Adobe. You might need more or fewer accounts (seats), but the situation isn’t as extreme as Zendesk’s or as disconnected as Workday’s.

Beyond these, there’s a latent undercurrent that AI can write all code. As a senior developer, I find this absurd. I’ll quote David Ricardo’s theory of comparative advantage from 1817: you can farm or weld aluminum, but even these simple examples are not quite right. It’s like I have a comparative advantage in podcasting with you—doing this earns me more, even if I’m more productive than a plumber, I should focus on podcasts.

More importantly, there are hidden edge cases at the foundational level. In theory, I could automate some Workday processes with AI, but what if an Indiana employee leaves while on maternity leave? Unless you’ve experienced it, you wouldn’t know these edge cases. Many software are deterministic rules learned over decades, embedded and not public. You can’t just copy them; you need experience. If a subtask is simple and has no edge cases, AI can handle it.

But I believe truly core, sticky, relied-upon enterprise systems with all edge cases embedded will thrive. They will start to add AI-driven functions, like asking whether background checks or overdue collections are needed. You won’t need to hire humans; your software can do it. When this happens, future cash flows will grow dramatically, which shocks me.

Many public investors can’t distinguish these categories. They’re excited about AI but don’t realize it must be deployed in core business systems. I think now is a fascinating moment to return to first principles in business.

Mike: I personally dislike the term “core business system” because it sounds like a static database—just putting things in and taking things out. Viewing business as a filing cabinet system is very industrial-age, very different from pre-industrial business models.

I understand the term, but it feels like we’re still using floppy disk icons as save buttons. Kids have never seen a floppy disk but still use that icon. I question this because I see business as a process-based system, not a record system.

Everything Alex said is correct: there are processes like background checks. Coordinating a series of processes as cheaply, efficiently, and quickly as possible is the core of knowledge work. In the knowledge economy, I have thousands of employees who come in with their brains and leave with their brains. I have no atomic assets, drills, or steel, not even a filing cabinet. Everything I do is about coordinating those processes, which I think most modern companies do.

How does this relate to Alex’s point? I think it’s spot on. We have different process types—call them input-restricted and output-restricted. For example, customer service at Zendesk is input-restricted: customers ask questions, and how fast you handle them affects efficiency, cost, speed, and quality. If you process 10 times faster, you won’t get 10 times more questions because the number of customers is fixed. The challenge is how to reduce questions or handle them faster. Many processes are input-restricted.

I often cite our legal team: their job isn’t to create legal work but to respond and process it. How many lease agreements, NDAs, or contracts do we have? That’s a fixed volume. I try to do it as efficiently as possible—this is input-restricted with a complete process. But then I face output-restricted work, like creative, marketing, or software development, where in theory I can do unlimited tasks.

My bottleneck is my creativity, or how many things I can think of and how much value I can deliver. That’s where I can improve efficiency and produce more, not just by restricting input scope.

Regarding Indiana’s rules, it’s correct because some processes are constrained by external rules—laws, governance, compliance. For example, in Indiana, I must follow certain procedures for employees. These processes are how I want the business to run and how it must run. The business is essentially a collection of these processes. From a certain perspective, we have record and execution systems. I think most companies don’t operate exactly like that, but that’s how we usually think.

Alex: I agree completely; it’s a great framework. I love how Intuit, like TurboTax, makes all tax rules public—you can download all the rules, which are highly deterministic. You can handle tax filing and messy folders simultaneously. In this case, all rules are transparent, but edge cases being public is quite rare.

Companies are valuable; many knowledge-based companies have assets that go home in elevators every night, but these businesses have core value. For example, does McKinsey still have value after all employees leave? Because it’s a knowledge-based output business, deeply tied to labor, unlike physical products. Still, they might have a secret internal manual on how to operate, hire, fire, and deliver results. I’ve never seen such a manual, and because I haven’t, I can’t copy it. It might have been built and maintained for over a century.

What are the products of non-digital, non-software companies? Their products might be centuries or decades of accumulated knowledge. I love Japan; some ramen shops have been around since 1587, which is impressive. This is a long-term cultural, knowledge, and skill accumulation, including recipes. Making noodles might be simpler with fewer edge cases, but there are extremes—what if you run out of flour? How did they survive the 1623 flour famine? They must have taken measures, and those experiences are stored in secret manuals, not in publicly available ones.

Mike: That’s what makes it so fascinating—it forces us to rethink our business. Is Intuit really just filling out tax laws for you? Or has Intuit mastered understanding tax law to an unparalleled degree? Their core value is helping you process life data, organize your understanding, and ask the right questions. In that sense, Intuit is more like McKinsey. That’s their special skill: asking the right questions to fill out tax forms, not just filling forms.

Now all companies must revisit themselves. Maybe I have 50 processes I thought were unique core secrets, but only 20 are truly core. I now need to carefully consider which processes are genuinely unique and which are not, because we’ve never had to think this way before.

Alex: I see this as a matter of balancing. Whether it’s worth doing yourself depends on whether third-party tools are an unbreakable red line or just an independent variable. Should I now code with Claude Code myself? If a company charges too much for software or risks my business failure, and I can do 99% of what I need in-house, then coding myself makes sense. But if that software costs only a dollar a year, then building it yourself isn’t worthwhile.

Not all record systems are equally valuable. I tend to see record systems as atomic units of a business. For example, a calendar is a time record system; ERP is an inventory record system. You have all these different record systems. I’ve given an example: I have an infrequently visited office in Miami with a conference room booking system like Google Calendar. Would I bother to change that system? Of course, because I only visit once a year—who cares if it’s stable?

Conversely, some systems directly impact my revenue and aren’t expensive. Do I really want to farm my own food just to eat? Using the agricultural metaphor, dining at a restaurant is much cheaper. If I just want a burger, I don’t need to buy a cow and raise it; economies of scale and comparative advantage make restaurant food far cheaper.

Some record systems are more susceptible to impact simply because of high pricing or because their stored content isn’t that valuable. Carta, for example, tracks and manages equity structures for many companies. How often do you check your equity structure? Not very often, but it’s crucial and must not be messed up. So I’d likely keep using Carta because their fees are low, and it’s not a high-frequency product, so it’s not on the list of things to replace.

Mike: I find vibe coding fascinating. As someone in the software world, I feel that in the future, people will just vibe-code to replace all traditional tools. But then I think: if I vibe-code to handle my entire day and run it, that’s terrifying. It still needs some really smart engineers to back it up. First, I have other priorities for them. Second, relying entirely on this approach is currently more disadvantageous than advantageous. But that’s the trend of replacement theory.

Undeniably, we see huge improvements in internal software scalability through AI coding. Most such applications are highly configurable and customizable, and in our case, truly scalable. You can write software snippets that run on the platform across various domains, and many clients do so. But previously, they needed large tech teams to do this.

Now, with vibe code, they can extend and customize applications for specific use cases. For example, I want a conference room booking app for the Miami team, which needs to check Workday and other systems constantly due to local HR policies. In the past, I couldn’t afford internal IT resources for this; now I might build it easily. It uses Workday’s global data and rules at its core but provides a highly customized interface for Miami’s front desk to handle specific tasks. Powerful, but it can’t fully replace humans.

Speaking of poor Workday, I think Aneel is often joked about in these conceptual examples. But it’s actually very powerful—making Workday more sticky and valuable in enterprise markets because you can build all these custom apps on top of it. That’s the power of AI, vibe coding, and creativity: making foundational systems more tailored to specific needs.

But we must carefully balance stability, rule processes, and high customization. For example, openclaw-like apps are tailored for individuals—most builders aren’t software developers but are creating personal apps or tools on Gmail. They still rely on Gmail for reading and managing emails, just building specific solutions for their own needs. Some of these projects might evolve into companies, but most just solve their own problems—very powerful.

Alex: That’s why I’m curious about the fairness of pricing when front-end and back-end are decoupled. Take Salesforce: they charge per license. I think our company has about 600 people, so we probably bought 600 Salesforce licenses. I’ve never logged into Salesforce, but I bet the company paid for me. Yet I sometimes use its outputs because it’s our record system. Not to overuse the term, but it stores all our business relationships, and I’m like part of a relational database table—user ID 422.

Every time I connect with a company, it’s like matching in another database, but we’re only paying for a single underlying database. It’s like living in a world where front-end and back-end are gradually separating. I think Workday has a very clever pricing strategy—powerful and perceived as fair. The more employees you have, the more you pay. Why? Because it’s fair. GE’s profit is obviously higher than a 10-person company, so they should pay more, and it’s still a tiny fraction of their revenue. Its pricing is in the optimal range, and I believe no one objects. They will generate huge AI revenue in the future, but their base pricing feels very fair.

But for these products where front-end and back-end are somewhat separated, I don’t know what a fair pricing model is, nor what future software pricing will look like. Clearly, if no one is willing to buy, everyone writes their own code, and competition disappears, pricing will stay the same. But imagine a future where people build on customized front-ends and read data directly from the underlying database. Since all record systems have a database representing the entire abstraction layer, will these categories face price pressures?

To me, if front-end no longer equals back-end, it becomes more vulnerable and impacted than tightly intertwined systems. For example, QuickBooks is used by small businesses; they don’t have the concept of accounts (seats). Business owners just log in directly, so its front-end is, in a sense, the back-end. Conversely, with Salesforce, you can imagine that although no one will completely abandon it, they might significantly reduce the number of accounts (seats) because the underlying back-end remains essential, but demand for expensive front-ends decreases. They won’t eliminate or change the back-end, only optimize front-end costs.

Mike: I’ve always believed that pricing fairness and customer perception are crucial. People need to understand why they pay and feel that their payment correlates, to some extent, with actual usage. A company with 10,000 employees paying double or more for Workday, with volume discounts, seems fair because they buy more and have more complex needs. They believe it’s fair. The principle seems to be: I’m willing to pay per employee for my HR system.

The core issue is that it’s not just a database; it’s a database plus a set of complex processes. Back in my day, we called this business logic. These business logics are not trivial—why do companies have them? Because they operate as a collection of processes, and managers pursue standardization to some degree of process automation. This allows different teams to work the same way, be managed, understood, and precisely tracked.

Like having a bunch of car factories, wanting to track the total cars crossing in and out. Business logic embedded here is a moat and value. Traditionally, sales processes are huge, and the workflows you set for sales are very valuable. You’d think this is a fair way to pay. But how much do your sales teams need these processes? To what extent do they need them?

I assume Salesforce Sales Cloud has an MCP server that doesn’t directly access the database but involves business processes and rules. The debate now is whether some sales personnel—like in marketing or customer success—need those heavy processes, governance, control, and rules. For example, systems that specify we only provide X service in Japan or Y service in that region, even requiring a dedicated account (seat) for their MCP server. Whether customers see this bundled billing as fair is another open question.

Yes, the challenge is how to price this. I want to tell you that when discussing consumption-based or on-demand pricing, result-based pricing is reasonable in many fields, but I absolutely don’t think it will be the main SaaS pricing model or applicable to all SaaS.

Because when you talk to customers, they really dislike this approach. They are genuinely opposed to star-annotated clauses. It’s unrelated to the value they perceive they’re investing. For example, I use pay-per-log for Splunk; if I double the logs I send, I pay more. I understand this logic, but logging is under my control. I can log more or less. I can tell my team, “Why are you logging so many logs? It’s expensive, and are you really using them?” I control how much data I input. It’s similar to storage in S3 or other services. I can store 1GB or 2GB without issue. The problem is, for me as a customer, these are relatively transferable and controllable.

But many examples of result-based or consumption-based pricing are uncontrollable and non-exchangeable for customers. So in the world of AI tokens and points, it’s very difficult for customers—they don’t understand what these tokens or chips are.

I can get 1GB of storage from AWS and deploy it on Azure, knowing exactly what I’ll pay because the per-GB cost is fixed. But when I have these AI quotas, I don’t know if your quota is the same as others’. Vendors keep adding new features, my users consume them, and my quotas are used up. But I don’t know what they’re doing with those quotas.

It’s not that companies choose to use them; vendors just add features that make the software better, and these improvements seem to happen naturally. I can cause my customer’s quota to double overnight just by adding features like generating summaries. Customers will think I didn’t ask for that.

So I think when discussing result-based usage billing, customers still prefer account (seat) billing because they now understand this model better and have been burned by many usage-based schemes that cause bills to skyrocket, leaving them unable to control costs.

Yes, it takes time to adapt. It will appear in many categories. Our Atlassian business covers many areas—you can call it usage-based pricing or pay-as-you-go. We focus on those where, when customer volume doubles, they get twice the value and pay twice as much, all within their control. Many other pricing models are outside customer control.

The last example of result-based pricing is that these results are also dynamic. For example, in customer service, I save costs. Previously, I spent $20, now I spend $10. That’s a great sales pitch in the first year. But in the second year, the customer says I only spent $10, and I want to spend $5, or you provide no value. The vendor responds that if I exclude them, I’ll spend $20. The customer thinks: “But I only spend $10 now.” So, the ability to save money annually from results is hard to measure, even as I eliminate tedious tasks.

Alex: I think it’s the same from a sales perspective. I’ve founded two payment companies. I admire Workday; I often talk about it with my sales team because they know the external landscape well. They know how much GE makes from it. They say GE has 330,000 employees, and maybe we charge $5 per employee per month—this is what we earn from that account.

If you sell software this way, scaling a sales team is much easier. You know that company will pay us $3 million. When we started, we signed 1,800 companies, and we had no idea how much we’d earn from them. The real driver was Casper, the mattress company. You can’t predict this. You think you’ve landed a big client like Walmart, but initially, progress is slow. Signing Casper was a game-changer.

Workday has this bilateral predictability—predictable for investors and management. You can clearly focus on signing GE, not a 10-person company, because GE is larger. But in the internet world, it’s crazy: Stripe might earn more from a 10-person startup than from GE. That model offers higher predictability.

But result-based or consumption-based pricing, while not inherently bad, makes it exponentially harder to expand sales and marketing if you can’t know how much an account (seat) can earn externally.

Eric: As an entrepreneur, I want to return to one point: in this era, can you share what’s the most prominent way it manifests for you and how it’s changed your business?

Mike: Our view is that we sell collaboration tools that solve human coordination problems. In many fields—service teams, broad business units, HR, finance, software teams—various teams buy different application suites and combinations. Fundamentally, these involve a lot of text-based collaboration. That’s very advantageous for us. What people do is the most important part.

The tech world tends to reshape everything, believing that’s the future. From a medium- to long-term perspective, that’s often correct. But our challenge is that many of our clients still work in traditional ways, with workflows in various apps that aren’t very intelligent. They want to move forward but also need to bring many users along. So when we build AI features, the first thing is to understand what this technology is and how it can help us. Second, we need to build foundational platform components to adapt to rapid technological change.

That’s why we developed AI Gateway, team collaboration maps, and enterprise compliance and control features. You must distinguish these from the specific features you build for clients in particular apps. Where do you put these features? What exactly are they? Many of these exist within existing workflows, helping clients do their work faster, better, more efficiently. These features are often very simple—like that 30-second animation GIF that went viral on the X platform. But they’re very exciting for clients because they can use them immediately, improving their existing workflows. They love it. In the AI world, I think it’s quite simple, and it can bring huge benefits today.

I often tell internal teams that just giving an example in service isn’t enough—you need to leverage their existing workflows, combine new apps, or view new workflows to solve problems. So we must do all that. For example, Jira is a typical case. In our HR and IT service management products, we’re doing ticket summarization. This is something we can do much better than before.

About four or five people handle the same ticket, trying to solve a problem. When the fourth person joins, there are already many attachments and chat logs. Usually, they need 30 minutes to read everything and understand what happened to apply expertise. Summarization isn’t just inputting content into an LLM and getting a summary. Context is very powerful for the model, but the workflow itself hasn’t changed at all. It’s still Alex asking Eric, “Can you help me with this ticket?” Eric has to load all relevant info into his brain. It’s an existing workflow, and we can use LLMs to improve the experience, which clients love and praise. But these features usually don’t have agent-like capabilities.

So, for that service workflow, we need to add agents at various points. Most people are handling a workflow and find that certain steps often cause delays and waste time. Can we make that step faster? That’s a feature we must provide for agents.

We have a great agent framework for the whole team, combined with maps and all your existing context. It’s very simple and affordable. Or you can bring your own agent framework. I think most enterprises will run three to five large agent platforms internally. They might say, “I use Agentforce for this,” or “I use Gemini for that.” Bring that agent, and we’ll integrate it into the workflow. We must be able to do that.

But you’re still entirely within the existing workflow—just executing a new, more efficient task within it. Then you’ll encounter people asking, “What if the service ticket doesn’t exist at all?” So you’re rethinking the entire class of software into new workflows. We must help clients cross this gap because they usually don’t have just one service team—they have hundreds. If they run hundreds of different service desks, they might say, “These 20 will work in a new way,” but they must manage all of them. So we’re trying to connect data from the team collaboration map with this, from the client’s perspective. This is often overlooked—we’re trying to lead them toward a future five years out, but our responsibility is to guide them toward one year, two years, and five years ahead.

Lastly, I want to emphasize that we invest heavily in design. This is always overlooked in any conversation because it involves fundamental design work. Looking back at the mobile internet era, the first apps mostly just ported desktop or web content directly to phones, then evolved new interaction modes and experiences.

It’s not just visual evolution but also how we use these tools. Push notifications—what were they originally for? Pull-to-refresh is a very obvious, simple example; it’s a classic design pattern. The whole process is about how to coordinate mobile and desktop, how to switch back and forth. We face many design challenges. It’s really about helping ordinary users understand the content. They don’t want to dig deep; if AI doesn’t matter to them, they just want the results. They don’t need to understand all the tech details. Our job is to hide those details and deliver the results directly, or make tasks more effective and efficient. In tech, we sometimes obsess over model quality.

Now, saying models are far ahead of actual delivered value is almost a cliché. The unrealized potential is enormous. Part of it is design and experience. How do I give people an infinitely capable chat box, and they just say, “Tell me a joke”? It’s like having unlimited power but being unable to help them leverage it. That’s a big challenge—how to incorporate agents and all their capabilities into workflows and collaboration cycles, enabling humans and agents to work