Saaspocalypse Now

For my sins, I have joined the “AI not kill SaaS” debate. I am motivating this with the Salesforce stock chart, which went off 30% in the recent “Saaspocalypse.” Charts for Thomson Reuters, Service Now, and Atlassian look about the same.

By 2030, more than 60 percent of software economics could flow through agentic systems rather than legacy SaaS seats.

So, why are people debating an accomplished fact? Because of a faulty thesis. This thesis (which I have actually read, not naming names) is that someone can vibe code a new Salesforce. This is a strawman. That’s not the thesis that wiped out $300 billion of market cap.

Someone probably could vibe code a new Salesforce app, but – that’s obviously not the same as killing Salesforce, the company, nor SaaS in general.

The thesis, according to Satya Nadella, is that business logic will come to reside in AI agents, leaving SaaS systems as mere databases. According to Goldman Sachs, by 2030, more than 60 percent of software usage could flow through agentic systems rather than legacy SaaS seats.

The fact that a single, well-prompted AI agent can now do the job of five or ten “seats” does not bode well for the old framework.

The more recent stock tankage in February – that 16% gap down in Thomson Reuters – is attributable to Claude Cowork, coupled with that day’s release of a prompt that does legal contract review. Yes, one single prompt. Again, it’s not feature coding – it’s the pricing model.

Consider Salesforce, for example. Each literal headset-wearing agent needs a “seat license.” With Claude Cowork, no human agent would ever interact directly with Salesforce. Robots talk to Salesforce, with 10X efficiency, and only escalate to humans when they have to.

As Phil Rosen puts it, “the fact that a single, well-prompted AI agent can now do the job of five or ten seats does not bode well for the old framework.”

None of this says that SaaS is dead, exactly. What it says is that SaaS vendors need to reinvent themselves – something legacy “growth to value” companies have historically failed to do.

Agent Support for Menu Selling

As a software guy, I am always surprised to find F&I trainers doing generic menu training without attention to the specific menu system used in the dealership. There is some generic advice, which I covered in Best Practices for Menu Selling, but then your client’s next question is going to be: “How do I do that on Darwin?” Or Maxim. Or Tekion.

Controlling the menu means you control what products are on it, and how they’re presented.

Familiarity with the given menu system is even more important when you represent a provider or agent. Now, you’re not only training how to sell product, but to sell your product. As I told my boss at Safe-Guard, “you can put a gun to the guy’s head but if your product isn’t on the menu, he’s not selling it.”

And we have seen exactly this. “We don’t sell your coverage because it’s a lease deal.” Because it’s preowned. Because it’s highline. By “we,” I mean Safe-Guard’s ace menu trainer, Michele McMinn, and the menu support team we put together. Double your penetration with this one weird trick…

The easiest way to do this is to pay for the dealer’s menu system. Then, your trainers only have to be experts in one system, and you have a hotline to their tech support department.

Controlling the menu means you control what products are on it, and how they’re presented. If your dealer base is too diverse for that, then you will have to develop F&I trainers who are expert in all of them.

Setting Up the Menu Support Team

You also have to make sure your products are compatible with certain standards used by PEN and the menu-system community. If this is news to you, you’re not alone. Even in the year 2025, I still find providers and agents who think their product is a piece of paper.

Just because the art department added a checkbox for “Rebate” or “Sagittarius,” doesn’t mean that checkbox is going anywhere unless you know a little something about the PEN interface standards. Here’s what a good menu support team looks like:

  • Trainers who are rated on more than one menu system, in addition to generic F&I training.
  • Dedicated support, so the trainers can reach someone while they’re in the dealership. This is key. The menu support desk also looks for recurring issues and develops a knowledge base.
  • Tech people who can run tools like Postman and XML Spy and, ideally, get involved with coding on your menu-system API (the interface that PEN uses).

At Safe-Guard, I went so far as to hire a Product Manager to own the API and to liaise with PEN and the menu-system community.

Designing menu-friendly products starts at the very beginning, when the coverage product manager meets with my product manager. Let’s say you want to offer Tire, Key, and Dent on the same form. Do you want all seven possible combinations? What about the “cosmetic” upcharge?

It’s not enough to have the right boxes on the form. You need to think about how the product will flow through PEN, and how it will look on Darwin. And Maxim. And Tekion.

It’s not enough to have the right boxes on the form. You need to think about how it will look on Darwin.

You can see how this is a team effort. If your product is making the menu choke, support needs to run that issue back to the programmers. If your trainer isn’t rated on that menu, she shouldn’t be in that store.

By the way, you should keep track of which DMS, which menu, and which sales process is used in each store. Keep track of those, along with the training sessions, after-action reports, and your (rapidly improving) penetration scores.

When Michele and I started playing this game at a high level, we discovered we were competing with JM&A. That was it. Everyone else was unarmed.