In a recent Clouded Judgement article, Jamin Ball makes a point worth paying attention to: in the next era of software, the strategic control point may shift from where data is stored to where work gets orchestrated.

His argument about traditional SaaS moats is that it was never purely about data. A CRM is not hard to replace because it stores customer records. It is hard to replace because sales processes, reporting cadences, handoffs, approvals, automations, and management routines have all been built on top of it. The system became sticky because work moved through it. "Data has gravity," he says — but so do workflows.

That reframe matters when thinking about AI implementation inside a business.

The most common mistake I see is companies starting with the tool: "How can we use ChatGPT?" or "Should we build agents?" or "What can we automate?" Those questions are not wrong, but they are usually asked before the more important ones have been answered.

The better starting point is: where does work already break?

  • Where are people manually copying data between systems?
  • Where do approvals stall because the right person is not in the loop?
  • Where does quality depend on someone's institutional knowledge rather than a documented process?
  • Where do handoffs break down at the seam between teams?
  • Where are expensive people spending time on work that does not require their judgment?

These are useful diagnostics because they point to workflows that are already expensive — in time, in management attention, in error rate, or in customer experience. If a workflow is painful now, fixing it produces real leverage. AI may be part of the solution, but the implementation work is still mostly process design: understanding the current state, defining the desired outcome, clarifying ownership, setting quality thresholds, and deciding explicitly which steps need human review.

That last piece often gets skipped. The goal is not to automate everything. The goal is to build a better operating system around a specific piece of work.

In practice, the highest-value opportunities often do not look particularly exciting. Intake routing. Customer follow-up. Internal knowledge retrieval. Proposal generation. Sales research. Support triage. Back-office coordination. These are not glamorous, but they are often where the most time is actually going.

And they compound. Once a team has redesigned one workflow well — with clear ownership, good exception handling, and a defined quality bar — the organizational muscle exists to expand into adjacent workflows. Over time that starts to look less like a collection of automations and more like an operating layer: a consistent way of routing work, applying judgment where it matters, and maintaining context across systems.

For smaller businesses especially, this framing is more useful than "AI transformation." Most do not need a strategy initiative. They need to pick one painful workflow, understand how it actually works today, and build something better around it.

The sequence is straightforward even if the execution is not:

  1. Map the current workflow.
  2. Identify where time, money, or attention is being consumed.
  3. Define what a better version looks like.
  4. Decide what gets automated and what stays human.
  5. Build a small, testable system.
  6. Measure what changed.
  7. Expand from there.

The companies that get real value from AI will not necessarily be the ones with the most tools or the biggest budgets. They will be the ones that understand their own work well enough to redesign it.

Ball's framing about orchestration as the new moat is worth taking seriously. But the path to building that orchestration layer starts with something much more mundane: finding the workflow that already hurts, and figuring out how to make it work better.