Fruxon logo
Fruxon
Back Office

An address that won't parse is somebody's afternoon.

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.

Why it gets worse when things go well

Exception volume scales with revenue. The ops team doesn't.

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.

An exception, end to end

What happens to the order that fell out.

It picks the exception up from the order system

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.

It checks against the systems that actually know

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.

It fixes what's fixable and holds what isn't

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 held ones go to the person who owns them

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.

What that needs underneath

Built for a queue that spikes.

One run per order, isolated

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.

It can talk to the customer, if you let it

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.

Writes back where the order lives

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

Goodwill is a decision, not a rule.

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

Systems

Your OMS, your carriers, your inventory, your storefront.

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.

Fulfillment questions, answered plainly

Mostly about peak, and about what it's allowed to give away.

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.

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.

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.

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.

Build the agent. We'll run the rest.