Carom · There are only bad reasons not to have a good demo

Enterprise software has a credibility problem. It’s a pain to buy—or even to figure out a price—and relies too often on slick salespeople selling to buyers who aren’t users. With a few notable exceptions, the “try a demo” link on a B2B site lands you on a salesperson’s call list, not in a working version of the software you want to buy. For companies selling to small and medium-sized businesses, there are fewer and fewer excuses for hiding their products from prospects—and it’s no longer fair to blame the difficulty of creating a good demo for the lack of one.

This sales-heavy model is not new, of course; it’s been the standard approach for years. Click the “pricing” or “demo” button, and what you get is a link to speak to a salesperson, which if you’re lucky might allow you to see a few screenshots and a ballpark price that’s the start of a protracted negotiation.

There are reasons that model is popular. In the interest of steelmanning the case, here are some reasonable arguments for this anti-self-serve, salesperson-led model, roughly arranged from most to least justifiable:

Consultingware really does require a conversation. If you’re a hospital looking to switch to a new electronic health record, there’s no such thing as a list price, and there’s not really anything to demo; you’re purchasing a platform that will be developed and deployed to your specifications.

Purchasing decisions are complicated, and sellers are experts. Compliance and legal requirements mean employees need certain types of annual training, for example. If that’s all the buyer knows about his or her requirements, companies can usefully shape how they assess the market (though their advice will of course be biased).

Buyers need help navigating their own companies. The larger the enterprise, the more complex the internal procurement process. Companies can help their buyers strategize and sell internally, provide relevant materials to finance teams, and structure a compelling pitch across departments.

Salespeople are expensive, and their time is valuable. The more a company can do at the outset to qualify buyers, the less time they will spend with prospects that are unlikely to convert.

Hiding the list price means you can take most of the pie. If a software sale is really a negotiation between two big companies, and especially when the marginal cost of software is close to zero, companies don’t want to name a price until they can name the highest price they think a buyer will accept.

These are all real reasons the sales-led model is what it is, but only the first is a good reason not to provide a realistic demo of a software product. And all of these conflict with the preferences of buyers, two-thirds of whom would prefer a rep-free experience.

Why high-quality, self-serve demos are so rare

There are two not-so-good reasons companies don’t let buyers demo their software:

For most software, it’s hard to create a demo that reflects real-world usage. To portray a product in the best light, you need to have realistic content, data, scenarios, personas, etc. and the infrastructure to serve them safely. A demo that’s a blank slate, for a product that’s designed to be filled with content, is neither compelling nor informative to a buyer.

Most software is bad, and bad software is harder to sell. That’s just the reality: most products aren’t good. If a potential buyer learns your product is bad before you have a chance to talk to them, explain away its problems, or sell based on charisma or golf outings, you’re toast. It’s better to leave some doubt about whether your software is bad than to show conclusively that it is.

We’ll come back to the second point. But on the first point: the difficulty of creating a realistic demo has changed, and so too should buyers’ expectations. CRM-adjacent tools are a pain to build demos for: to offer a true-to-life glimpse into Carom’s value, we need to create a team of users with different functions and access to information, clients and prospects with evolving needs over time, meetings to address their pain points, tasks to capture work to be done, and comments as colleagues collaborate on that work, and it all should be internally consistent and current.

We’ll talk more in the future about how we built the demo for Carom, which depends heavily on some carefully crafted LLM output. The result is realistic: over 700 messages in 150 threads across twenty narrative arcs that mirror real-world scenarios (a deal stuck in procurement, a lost customer, an outage, a hiring decision) and capture evolving relationships, along with meetings, comments, actual files that fit these simulated conversations, and other artifacts that give a good sense of what it’s like to use Carom day to day.

In the age of LLMs, building good demos isn’t as hard as it used to be. We’re still left with the second reason they’re rare: most software is bad, and...