Order exceptions, split shipments, inventory that doesn't line up, returns and replacements. An agent works the exception queue in your order systems and stops only on the ones that need a decision.
Every percentage point of orders that fall out — a carrier that won't validate the address, a warehouse that shows stock the shop floor can't find, a return that arrives without an RMA — is a fixed fraction of a growing number, worked by a team that grows in steps. Peak season is when the queue is longest and the people are fewest, and it's also when a mishandled order costs the most.
A held order in Shopify or your OMS, a failed webhook, a row in an exception table, a carrier notification. The order, the customer's history and the policy that governs this case are retrieved at the step.
Validate the address with the carrier, check stock across locations, read the shipment status, look up what happened the last two times this customer had a problem. Where it needs to compute — allocation, proration, a refund total — it runs Python in an isolated sandbox.
Corrects the address and releases the order, splits the shipment, opens the replacement, issues the credit under your ceiling. A judgment call — a high-value order, a customer already compensated twice, stock that doesn't reconcile — is held rather than forced through.
The ops owner gets the order, what's wrong, what it checked and what it would do, on Slack. One line back and it executes. A malformed record fails on its own instead of taking the run down with it.
Collection Pipelines map the agent across the exception queue as one run per record. A row that fails takes itself down and nothing else, and each run carries its own history, latency and cost.
The same agent can reply on the channel the customer used — email, chat, WhatsApp — so an order held for an address problem becomes a question to the customer rather than a silent delay. That's a permission, not a default.
Status, notes, replacement orders and credits are written to the order system, not to a side database that someone has to reconcile later.
When it isn't sure
Most exception handling is mechanical and safe to hand over. What isn't: the second replacement to the same customer, the order large enough to matter, the case where the policy and the situation genuinely disagree. Those go to the ops owner with everything it checked already attached, so the decision takes a line rather than twenty minutes of tab-switching.
Ceilings per action on credits, replacements and anything that ships without payment
Held records route by ownership, with the full check history attached
Timeouts and a fallback ladder, so an order doesn't sit through peak waiting on one person
Connect a system once for the whole organization and every agent can use it from then on — with credentials held at the org and referenced by name, never pasted into a prompt.
Slack
GitHub
Jira
Google Drive
Salesforce
MongoDB
Notion
Linear
Grafana
Discord
Google Chat
Confluence
PostgreSQL
HubSpot
Airtable
Shopify
Stripe
Datadog
Sentry
GCP
BigQuery
Slack
GitHub
Jira
Google Drive
Salesforce
MongoDB
Notion
Linear
Grafana
Discord
Google Chat
Confluence
PostgreSQL
HubSpot
Airtable
Shopify
Stripe
Datadog
Sentry
GCP
BigQuery
Google Calendar
Gmail
Mixpanel
Monday
MySQL
SAP
Zendesk
Zoho CRM
Google Maps
Google Ads
Coralogix
Telegram
Apollo
Mailchimp
Calendly
Redis
Supabase
GCP Logging
gVisor
Loops
Typeform
Google Calendar
Gmail
Mixpanel
Monday
MySQL
SAP
Zendesk
Zoho CRM
Google Maps
Google Ads
Coralogix
Telegram
Apollo
Mailchimp
Calendly
Redis
Supabase
GCP Logging
gVisor
Loops
Typeform
Don't see yours? Import tools from any MCP server or request an integration.
Mostly about peak, and about what it's allowed to give away.
Can it handle peak volume?
Runs are isolated per record and execute concurrently, so the queue is bounded by your connected systems' rate limits rather than by how many people are rostered. Cost per run is visible per record, which is the number you want before peak rather than after.
Will it issue refunds and replacements on its own?
Under the ceiling you set, and only for the actions you enable. Above it, the order is held and routed. Teams typically start with corrections and address fixes automatic and anything that costs money gated.
Does it talk to the customer directly?
Only if you turn that on. It's the same agent and the same conversation history the support agent uses, so an order exception that needs a customer answer doesn't become a second ticket.
What about our custom OMS?
Import your own REST endpoints from an OpenAPI spec, or query the database directly when there isn't an API. A custom system is a normal case here, not an exception.
Compliance & Vendor Review
Vendor files, document completeness, KYC checks — with a human signature where the rule says a human signs.
Finance Operations
Matches the PO, checks the terms against the contract, clears what reconciles and flags what doesn't.
Front Office
Support, success, onboarding — the work with a customer waiting on it.