The Moat Is the Workflow. Systems of Record Will Become Irrelevant.

What people think the moat is: being the system of record. Owning the data.

What the moat actually is: owning the workflow.

For far too long, we’ve confused where information gets stored with why a customer depends on a product. A product becomes hard to replace when the customer builds a working process around it.

How often that process runs matters. A workflow used for an occasional project creates a different level of dependence from one the business relies on every day. That’s the distinction between episodic and continuous use cases.

Some use cases are episodic.

A B2B sales team needs leads for a campaign. They go to a data provider, build a couple of lead lists, export them, and have enough to work through for the next few months. Then they put the product down until they need another list.

The product delivered value. But the workflow ended.

Other use cases are continuous.

Now imagine a platform that keeps finding relevant accounts, identifies the right people, runs outreach, handles responses, and follows up on conversations. A new signal, a buyer’s reply, or an agreed follow-up date triggers the next step.

The workflow keeps running. The customer depends on it to keep that part of the business operating.

That second category is what drives stickiness. Replacing the product means rebuilding the process: reconnecting the tools, recreating the rules, and moving the work already in progress.

That’s the shift I’ve seen, make platforms stickier across companies I’ve worked at: moving from episodic use cases to continuous ones, and owning the complete workflow around them.

AI will supercharge platforms that own these workflows.

They can increasingly gather the context, recommend an action, execute it, record the outcome, and feed what they learn back into the next decision. Agents can help people run the process or take responsibility for the whole thing.

The product keeps doing the work, and each completed loop gives it evidence to improve the next action.

This is the moat: continuous workflows that produce outcomes, learn, and increasingly act autonomously.

Two case studies explain why owning workflows are critical for a software platform: experience management, and the system of intelligence for revenue we’re building at Monaco.

Case Study 1: XM, or experience management

Lot of customers start with research projects.

A team has a question - what drives subscriber churn for product X. It designs a study, finds the right people, collects responses, analyzes them, and presents the findings. The product becomes useful again when the next project starts.

Now move from that episodic use case to continuous customer experience measurement.

Take an airline. The journey starts in the mobile app, continues through the airport and flight, and ends at the destination. Problems can happen anywhere along the way.

Someone tries to book three times, opens a support chat, then calls customer service. A useful system needs to connect those events to the same person and trip.

It also needs to understand what the customer was trying to do. Maybe the app worked, but the customer couldn’t find seats together for their family.

Sometimes that explanation is already in the chat or call transcript. Sometimes a short question in the app helps. A customer might tap a rating or leave a voice note. Someone testing a new booking experience might record their screen and explain what’s confusing.

Continuous measurement doesn’t mean constantly sending surveys. It means using the available signals and asking for missing context when it matters.

But collecting that context was only the beginning.

The full workflow connected context, recommendation, action, outcome, and learning.

The context might suggest that customers booking family trips are abandoning at seat selection. The recommendation could be to make seat availability clearer earlier in the booking process, while routing unresolved customers to support.

Then someone has to act. The app team changes the experience. Support helps the affected customers. The system needs to record which recommendation was made, whether it was followed, and what actually changed.

Now measure the outcome.

Did the customer complete the booking? Did they have to contact support again? Across similar journeys, did abandonment fall after the change? Where possible, test the change against a comparable group so a seasonal shift doesn’t get mistaken for an improvement.

A closed ticket tells you that a task ended. It doesn’t tell you whether the customer’s problem was solved.

Then feed the learning back.

If the change helped a particular type of traveler, use that evidence the next time the same pattern appears. Update which signals trigger a follow-up, which questions get asked, what the system recommends, and which team acts.

In this model, people often did the interpretation and changed the rules. But the full loop was there: the result of one intervention informed the next.

That was what made the product stickier. It had become part of a continuous operating process.

Qualtrics is a useful example of the product depth underneath this: feedback collection, chat and call analysis, integrations, configurable rules, tickets, and follow-up. Its closed-loop tooling connects feedback to assigned work and subsequent measurement.

The full workflow includes coordinating feedback across channels, joining it to the right journey, configuring the analysis, routing work, tracking what happened, and bringing the outcome back into the next decision.

The platform has to support businesses with different tools, customer interactions, approval rules, and exceptions. Their teams need to change the process without commissioning a new software project.

And customer experience is one set of workflows. Market research, brand, and employee experience each bring their own questions, audiences, permissions, and actions. Breadth creates more opportunities to become become entrenched with multiple buying centers in an organization.

Case Study 2: A system of intelligence for revenue

We’re building the same loop at Monaco, as I described in A System of Intelligence for Revenue.

Our re-engagement agent finds promising conversations that went cold and drafts the next move using the existing relationship. If a buyer asked to reconnect after planning, the follow-up should pick up that conversation.

We’re building toward long-running agents that monitor these conversations, recommend or take the next action, wait for a response, and continue. The context and unfinished work have to survive between runs.

Then connect each action to what followed: a reply, a qualified meeting, an opportunity, or revenue. Preserve what the system knew and did at the time so those outcomes can inform future decisions.

That learning should change which accounts get attention, when to follow up, what to say, and when to stop. Replies alone aren’t enough if they never lead to business.

Some agents will enhance existing workflows. Others will run the entire process. In both cases, the loop is the same: context, action, outcome, learning - and that learning feeding the next action.

What makes this defensible?

The moat forms when a platform can run complete, recurring workflows across the customer’s business - and use the outcomes to improve how those workflows run.

A complete workflow requires substantial product depth.

In XM, that means collecting feedback through different channels, connecting it to app events and support conversations, analyzing it, recommending an intervention, getting the right team to act, and measuring what happened.

Each step needs its own capabilities. The integrations need to bring context in, carry actions into other systems, and bring the results back. The customer needs all of those pieces to work together to get one complete unit of value.

What looks like 50 small features is the product depth required to finish the job. A missing piece leaves the customer assembling the rest.

That depth has to work across each business’s variations.

Different companies use different tools, interact with customers through different channels, and have different questions, policies, owners, and approval rules.

The platform has to support those variations through configuration. Teams need to change how the process works without rebuilding the software.

That flexibility is what lets the same platform support more workflows and more teams. Shared capabilities get reused, while each workflow fits the specific job and business.

Every completed loop needs to inform future execution.

Continuous use creates repeated opportunities to connect a decision to its outcome. That becomes valuable when the product uses the evidence to change what happens next.

Which signals should trigger an intervention? What missing context should it collect? Which action worked in this situation? When should it follow up, try something different, or involve a person?

The answers feed back into the questions, recommendations, rules, and agent actions that run the next workflow.

Now the customer depends on a platform configured around how its business operates, running complete jobs continuously, and applying what it learns to the next action.

As the platform takes on more of these workflows, it runs more of the business. Agents can take responsibility for more of the execution because the integrations, business rules, and outcome feedback are already part of the product.

That is the moat: a growing set of complete workflows that produce outcomes, learn, and keep acting.

So what makes software sticky?

1/ Focus on continuous use cases. Find work the business needs to keep doing. Research projects becoming continuous CX measurement is one example. A one-off follow-up becoming an ongoing revenue workflow is another.

2/ Deliver the whole workflow as one unit of value. Take the job through to an outcome. A summary, recommendation, or dashboard may be useful, but it is only a step if the customer still has to assemble the rest.

3/ Fit the way the business operates. Build the integrations and flexibility needed for its tools, channels, rules, and exceptions. Make the process configurable without turning every customer into a custom engineering project.

4/ Make each completed loop inform the next. Capture the context, recommendation, action, and outcome. Feed the learning back into future context and decisions. The next run should benefit from what happened before it.

5/ Give agents responsibility for ongoing work. Let them monitor, act, wait, follow up, and handle routine exceptions within the business’s rules. Expand that responsibility as the product proves it can complete more of the job.

That is where enterprise software is going.

The moat is the set of workflows a business depends on: workflows that produce outcomes, learn from them, and increasingly take the next action autonomously.

Records will still exist. They will be created and updated as the work happens. Customers will choose the product that runs and improves the process.

The system of record is dead. The workflow is the moat.