Back office automation is dead. User-facing self-serve is the future.

We've kept our ear to the ground and there's a tsunami coming. Just not the one you expected. SaaS *has* to change or die.

As the bem team talks to more and more people in the market, there’s a topic we inquire about with every executive and board member of public companies/enterprise that comes through our door: what their company will look like 5 years from now and what their board mandates are. We’re building a generational company and that means we need to understand really well what our value is today and how to align our roadmap and vision with the board mandates that will take 3-5 years to make an impact.

The conclusion: the focus today is user-facing software and services. Period. The focus for years was to make internal operations more efficient, and that focus is fading away in favor of very good, consumer-level user-facing products that allow customers to self-serve, even in complex verticals and industries. This is something we’ve talked about with supply chain, logistics, healthcare, and even insurance companies.

This doesn’t mean there won’t be high-value processes reserved to the back office. It just means the back office as we know it today will be much, much thinner 3 years from now than it is today.

Bad news, good news

There’s bad news and good news. I’ll start with the bad. A huge chunk of the SaaS market today has been built to make back-office processes more efficient. This market is slowly disappearing before our eyes and replaced with user-facing self-serve products. This means a significant percentage of the SaaS market will have to re-architect their product to provide better abstractions for their customers’ customers.

User flows are going to change dramatically, too, and so are expectations. The days of “Give us 12 hours to complete X operation and we’ll get back to you” are over, especially in time-sensitive environments. This also means most RPA is dead in the water, because it has been architected with the wrong frame of mind: purely saving OpEx.

This also means most AI companies who’ve followed this frame of mind are entering TAMs with already negative growth, and severe limitations: when your business is to make things more efficient, again, saving OpEx, you introduce a self-limit on your TAM and ACVs.

Business process mining as a concept is also going to disappear in favor of self-serve abstractions. The first companies to change and adapt will be consulting companies. They’re the most flexible, easiest to adapt to market trends, and an abstraction on top of existing technology. We’ve seen this with AI: they’re by far the ones making the most money on AI — to be fair, they’re also not spending much on compute.

The good news: we didn’t have the technology to do this market conversion 3 years ago, but we do now. That’s what AI is for, plain and simple. AI has been for us, philosophically speaking, a new layer of abstraction for humans to interact with automated processes. Where before you had to convince your enterprise customer to use your shiny new React-based form website running on a subpar web experience (good luck, by the way), now you won’t have to: you can just tell them to text you their orders and requests. Where before you had to hire a team in the Philippines *and* build the software for to mechanically-turk the inner workings of your data flows, now you won’t have to do either.

And that’s our bet.

Plain and simple. Our bet is that the “back office” is disappearing, and any automation and enablement we produce, has to be for our customers’ customers. bem is in the business of providing incredible building blocks to create these experiences. We’re also in the business of making the existing operators at these back office processes the architects and supervisors of front office, user-facing flows.

That’s why we don’t build AI agents. We build AI product infrastructure, definable as infrastructure layers, deployable, testable, meant to be inserted right in your production application.

Why we started with data transformation

Because this is where every process and interaction starts. And the status quo is dire. Companies working in mission-critical environments spend millions of dollars manually translating data between systems and other stakeholders.

Rather than building you an agent that will intermittently take chunks of data, or work based off the concept that the current state of a process should be unstructured, we structure everything first, and then automate downstream business logic.

Join us on this bet.