Most commerce teams can point to automation they already have. Order confirmation emails. Abandoned-cart reminders. A tracking message after the carrier scan.
That work matters. It is also the work the platform was designed to do.
The work that still consumes the day sits somewhere else. An order is flagged and waits in a shared inbox. Inventory is low, and someone checks a report. A B2B order needs credit or price approval, and the context is explained in email. A customer changes an address in one system and not in the others. The warehouse has shipped, but the site still says processing. A return is received, and finance, inventory, and the customer are updated in three separate steps. Commerce and ERP are matched by a person at close.
The automation gap is not a shortage of tools. It is the work that lives between systems.
Table Stakes Are Not an Operating Model
A confirmation email fires inside one application. An exception does not.
Exceptions, replenishment, approvals, account updates, fulfillment status, returns, quotes, and reconciliation all require a fact to leave the system that first knew it and arrive in the system that must act. When that path is missing, people become the integration layer. They export, paste, chase, and re-enter.
That is why so many "automation programs" stall after the obvious notifications are done. The remaining work looks messy because it is messy. It was never designed as a workflow. It accumulated as a set of workarounds that keep the business running.
AI readiness is usually an integration problem when the event cannot move. This article is about what should happen after the event can move: who owns the work, what is allowed to be automatic, and where a person still has to decide.
A Progression, Not a Leap to Agents
The useful sequence is not "add AI to the inbox."
It starts with a manual workflow: a person notices, decides, and updates systems by hand.
It becomes deterministic, rules-based automation when the work is structured enough to encode: if the order is held for address failure, route it here; if on-hand falls below a threshold and lead time is known, raise a replenishment signal; if the discount is within policy, release the order.
It becomes intelligent automation when classification or prioritization can be inferred from patterns without inventing a new policy: which exceptions are urgent, which returns are routine, which invoices match within tolerance.
It becomes AI-assisted when a person still owns the decision, but the system prepares the context: the account, the inventory, the prior quotes, the rule that triggered the hold.
It becomes governed agentic execution only when the organization can state, in advance, what an agent may do, what it must escalate, and how the action will be logged. That is not a chatbot on the same broken path. It is a bounded actor inside a designed workflow.
Skip a step and the later step inherits the mess. An agent with access to an undocumented process will either stop, guess, or hard-code the workaround.
Microsoft's Cloud Supply Chain team published a version of this lesson from its own operations: it mapped and simplified six end-to-end workflows and built a shared data foundation before deploying agents. The point was not the agent count. It was the order of work — lean the process, then automate.
Use Deterministic Automation for Deterministic Work
Not every workflow needs AI. Many of the most valuable ones must not use it as the primary control.
If inventory drops below a defined threshold, that is a rule. If a B2B order exceeds a credit limit, that is a rule. If a tracking event should update the customer, that is a rule. If commerce and ERP totals match within a stated tolerance, that is a rule.
Rules are not unsophisticated. They are how a business makes repeatable work reliable, auditable, and cheap to run. Replacing a working rule with a model that "decides" the same thing adds cost and opacity without improving the outcome.
Intelligence belongs where judgment, context, or prioritization is actually required. Which short-ship is commercially dangerous. Which exception should jump the queue. Which return needs inspection rather than restock. Which quote is a reorder in disguise. Which discrepancy is noise.
The Arizon point of view is simple: use deterministic automation for deterministic work. Introduce intelligence where judgment, context, prioritization, or exception handling genuinely requires it.
Do not automate a broken process merely because software can now converse with it. If the replenishment number is folklore, if approval authority is unclear, or if "the way we do returns" exists only in one person's head, the next investment is to simplify and document. Automation will otherwise scale the folklore.
Where the Gap Usually Sits
The examples are ordinary. That is the point.
Order exceptions — fraud flags, short stock, payment holds, address failures — pile up because they are treated as a mailbox rather than a classified queue with an owner and a time limit.
Replenishment still depends on a weekly export or a buyer who "knows when we usually order."
Approvals still require someone to find the right person and restate the case.
Customer and account updates still fail to travel from CRM to commerce to ERP, so service sees a different credit status than the site.
Fulfillment status still has to be copied from the WMS or the 3PL.
Returns still break into disconnected steps: authorization, receipt, quality, restock, refund.
Invoicing and reconciliation still consume finance because the same sale is a different object in two systems.
Quote workflows still leave inquiry to invoice in email, even when the catalog is online.
Inventory plans still stall for the reason described in demand forecasting: a recommendation that cannot trigger a purchase order is a report.
Each of these is a candidate for automation. None of them is automatically a candidate for an agent.
What to Automate First
Start with the handoff that already has a clear trigger, a known owner, and a defined good outcome. Make the event travel. Encode the rule. Leave a visible exception path.
Then ask where a person is still adding judgment rather than re-entering data. That is the first place assistance or intelligence may be warranted.
If the process cannot be drawn, it cannot be automated honestly. If it can be drawn and the work is deterministic, a rule will outperform a model. If it can be drawn and the work is judgment, a person should remain accountable — with better context than an inbox.
Replatforming the storefront does not close this gap. Connecting systems does not close it either, unless someone designs the work that should happen when the data arrives.
The operating improvement is in the space between applications: fewer people carrying facts from one system to another, and more of their time spent on the exceptions that actually require a human.