The hardest part of automating a logistics operation is not the standard workflow. It is the 200 exceptions to it, one per customer, most of which live in a rep's head. Customer A needs an appointment at every receiver. Customer B never accepts drop trailers. Customer C requires its PO number on the BOL or the invoice gets short-paid. Customer D wants three people copied on every delay notice, and one of them changed jobs in March.

These instructions are the operation. Miss one and you get a chargeback, a rejected delivery, a short-paid invoice, or a customer who quietly starts routing freight to someone else. And the way most teams store them, in scattered notes, old emails and tribal knowledge, is why they get missed.

Why do customer special instructions get missed?

Special instructions fail for predictable reasons:

• They are stored as prose. "Please make sure drivers call ahead, and liftgate is usually needed for the Denver location" is readable by a person and ambiguous to everyone. Which Denver location? Is "usually" a rule?
• They live in one person's memory. When the account rep is on vacation, the backup does not know that this shipper's accessorials over $150 need approval first.
• They change silently. A customer emails a new requirement in a thread about something else. It gets followed for two weeks, then forgotten.
• They conflict. The shipper's SOP says "no weekend deliveries." This week's order says "deliver Saturday." Someone has to notice.

The cost is rarely one big failure. It is a steady drip of preventable errors, each one small, that accumulate into margin loss and churn.

What does a machine-readable SOP look like?

A machine-readable SOP breaks each instruction into three parts: the field it affects, the condition under which it applies, and the action to take. That structure removes ambiguity and makes each rule checkable.

Here is the same set of instructions, rewritten:

• Acme Foods — Field: Appointment · Condition: All deliveries · Action: Require confirmed appointment before dispatch
• Acme Foods — Field: Equipment · Condition: All loads · Action: No drop trailers; live unload only
• Brightline Supply — Field: BOL reference · Condition: All shipments · Action: PO number and store number must appear on BOL
• Brightline Supply — Field: Accessorial · Condition: Liftgate · Action: Always required for consignees flagged "retail"
• Carter Industrial — Field: Accessorial approval · Condition: Any accessorial over $150 · Action: Hold and request customer approval before accepting
• Carter Industrial — Field: Notifications · Condition: Delay over 2 hours · Action: Email ops contact + CC two named contacts

Customer names above are illustrative.

Written this way, every rule can be checked at order entry: is the field present, does the condition apply, was the action taken? That is the shift from "the rep remembers" to "the system verifies."

How do you capture SOPs you never wrote down?

Most teams do not have a clean SOP document for every customer. The good news is that the instructions already exist, scattered across the email history.

1. Mine past correspondence. Six to twelve months of email with a customer contains nearly every rule they care about, usually in the form of corrections: "As a reminder, we need the PO on the BOL." Each correction is a rule that was broken once.
2. Interview the reps, briefly. Ask each account owner one question per customer: "What goes wrong if a new person handles this account?" The answers are your highest-risk rules.
3. Pull chargeback and short-pay history. Every deduction has a reason code. Recurring reasons map directly to missing rules.
4. Draft rules, then have the customer-facing rep approve them. A rule nobody has signed off on is a guess.

An AI agent can do the first step at scale, reading the email history and proposing structured rules for a person to confirm. That is typically where onboarding an AI agent in its first 14 days spends much of its effort, and it produces something the team has never had: a complete, reviewable list of customer rules. New accounts should start with this structure from day one, captured alongside the credit checks and account setup rather than after the first mistake.

How should an AI agent apply customer SOPs?

An AI agent should apply customer SOPs as structured rules at two points: when an order is entered, and whenever it communicates about that shipment. At order entry it checks every field and condition and fills or flags what is missing; in communication it routes notices to the right contacts in the right format. When an instruction conflicts with the order in front of it, it escalates instead of guessing.

At order entry. When a tender arrives by email, the agent extracts the shipment details and runs them against that customer's rules before anything goes into the TMS. Missing PO number on a customer that requires it? The agent asks for it in the same thread. Retail consignee on a liftgate-required account? The accessorial is added. This is the same capture logic behind AI order entry from email to TMS, extended with per-customer rules.

In communication. Delay notices go to the contacts the customer specified, with the reference numbers they expect, through the channel they prefer, whether that is email, SMS or WhatsApp.

On conflict. When an order says "Saturday delivery" and the SOP says "no weekends," the agent does not pick one. It holds the order and asks a person, with both the instruction and the rule shown side by side. Designing those handoffs is its own discipline, covered in escalation rules for AI agents; the principle is that conflicting instructions are a human decision, every time.

A practical template to start with

For each customer, capture:

• Contacts: who gets tenders, updates, exceptions and invoices, and by which channel
• Documents: required reference numbers on BOL, POD and invoice
• Delivery rules: appointments, hours, equipment, drop vs. live
• Accessorials: always-on, never-accept, and approval thresholds
• Exception handling: what counts as a delay, who is notified, how fast
• Billing rules: invoice format, portal submission, required attachments

Start with your top 20 accounts by volume. They typically represent most of your order flow and most of your SOP risk.

Frequently asked questions

How many rules does a typical customer SOP have? It varies widely. Simple accounts may have a handful; large retail or grocery accounts can have dozens. The number matters less than whether each rule is specific enough to check.

What happens when a customer changes an instruction? The rule should be updated in one place and apply immediately to every new order. An agent that reads customer email can flag likely changes for a person to confirm.

Can an AI agent handle ambiguous instructions? It should not resolve ambiguity on its own. Ambiguous or conflicting instructions should be escalated to a person, and the resolution captured as a clearer rule.

Do we need a new TMS to store structured SOPs? No. The rules can sit alongside your existing TMS or ERP, with the agent applying them before data is written to those systems.

The bottom line

Every customer has rules, and the errors that cost you the most come from rules stored as prose in someone's memory.

Rewrite special instructions as field-condition-action rules, mine them from the email history you already have, apply them at order entry and in every customer message, and escalate every conflict to a person. That is how 200 sets of instructions become something your operation follows every time.

Debales deploys AI agents for order processing and customer communication that apply each shipper's SOPs on every order and escalate conflicts. Book a demo.