Every e-commerce brand with more than one carrier has carrier selection rules. Most of them live in the head of the person who runs the warehouse. This page is about writing them down, in a form that a shipping system can execute and a new hire can read.
Short answer: a carrier selection rule is a sentence of the form "for orders that match these conditions, ship with this carrier and service, unless this exception applies". The conditions come from the order (destination, weight, dimensions, value, promised date, items), the warehouse (which location holds the stock, its cut-off) and the carrier (cost, measured performance, capacity). Good rule sets have a few broad defaults, a short list of specific overrides, and an explicit fallback for when the chosen carrier fails. Bad rule sets have forty rules nobody dares delete.
The inputs a routing decision needs
Before writing rules, list what the system can see at the moment of routing. If an input is missing, the rule that depends on it will silently fall through to the default.
| Input | Where it comes from | Rules it enables |
|---|---|---|
| Destination country, postcode, address type | The order | Domestic vs cross-border, urban vs rural, residential vs business, pickup point vs home |
| Weight and dimensions | Product data, or the packed parcel | Carrier weight bands, oversize handling |
| Order value | The order | Signature, insurance, a premium carrier above a threshold |
| Promised delivery date | Checkout, if a promise was shown | Standard vs express, and whether the promise can still be met |
| Items and categories | Product data | Dangerous goods, temperature, fragile, high-theft categories |
| Warehouse or 3PL holding the stock | Inventory | Which carriers collect from which site, cut-off times |
| Customer's chosen delivery option | Checkout | The option the customer paid for constrains the rule |
| Carrier cost and measured performance | Rate cards and your own scan data | Cheapest-that-can-still-make-the-promise routing |
The last row is the one most setups lack. Without your own on-time and first-attempt data per carrier, every rule is a guess about which carrier is good. How to build that data is in carrier performance metrics.
Twelve rule examples
These are written the way an operator would say them, which is also the way they should be stored. Names are generic; substitute your carriers.
- Domestic default by weight. Orders to Sweden under 2 kg ship with the postal parcel service; 2 kg to 20 kg ship with the parcel carrier; above 20 kg go to the freight carrier.
- Pickup point preference. If the customer chose a pickup point at checkout, ship with the carrier that operates that point, regardless of weight rules.
- Promise-driven upgrade. If the promised delivery date cannot be met by the default service from this warehouse, upgrade to the express service of the same carrier before switching carriers.
- Cross-border by destination. Orders to Germany, the Netherlands and Belgium ship with the carrier whose measured on-time rate to that country was highest last month; recompute monthly.
- Value threshold. Orders above 3,000 SEK require signature on delivery and ship with a carrier that offers it; below that, no signature.
- Cut-off aware routing. Orders placed after the warehouse's 15:00 cut-off are routed as if placed the next working day, and the promise shown reflects that.
- Multi-warehouse. Ship from the warehouse that holds all items and is closest to the destination; if no single warehouse holds all items, ship from the one holding the highest-value item and split the rest only if the customer's option allows it.
- Category constraint. Items flagged as aerosols or batteries ship only with carriers approved for that class, by ground, and never by the express air service.
- Rural surcharge avoidance. Postcodes on the carrier's remote-area list route to the alternative carrier if its price for that postcode is lower and it can still make the promise.
- Failed-delivery follow-up. After a failed delivery attempt, offer the customer redelivery or pickup point collection by message; if no answer in 48 hours, redirect to the nearest pickup point rather than let the parcel return to sender. The customer-facing side of this event is in attempted delivery.
- Carrier failure fallback. If the booking with the chosen carrier fails (API error, service suspended), fall back to the next carrier that can meet the promise, and flag the order for review rather than hold it.
- Peak override. During the declared peak window, cap daily volume per carrier at the agreed capacity and overflow to the second carrier, in order of measured performance.
How to order and maintain rules
Evaluate specific before general. Constraint rules (dangerous goods, customer-chosen option, signature) run first, promise rules second, cost rules last. A cheapest-carrier rule that runs before a dangerous-goods rule ships a battery by air.
Every rule has an owner and a reason. Store the sentence, the person who wrote it, and why. Rules without a reason are the ones nobody deletes.
Review the exceptions, not the rules. Once a month, list the orders that hit the fallback or were routed by hand. Each is either a missing rule or a rule that is wrong.
Recompute performance-based rules on a schedule. Rule 4 above is only true while the data behind it is fresh.
Keep the fallback explicit. "If nothing matches, ship standard with carrier A and flag" is a rule. Silence is not.
Testing a rule set
Take last month's orders and replay them through the rules on paper or in a sandbox. Three numbers matter: how many orders hit the default (should be most), how many hit the fallback (should be very few), and how many would have missed a promise that was actually kept (a rule that is too cautious costs money). Brands that do this usually find two or three rules that never fire and one that fires far too often.
Where static rules stop and agents start
A rule table answers "which carrier" for the conditions it was written for. It does not notice that a carrier's on-time rate in one region dropped last week, that a promise is about to be missed on an order already in transit, or that today's volume will exceed a carrier's capacity by mid-afternoon. Those are decisions a person makes by looking at a dashboard, and they are exactly what an agent can make continuously.
Pango's approach is to let the operator state the policy in plain language ("route to the cheapest carrier that can still make the promised date; if a first attempt fails, message the customer and offer a pickup point") and compile it into a per-merchant workflow that runs on every order and every tracking event. Because Pango runs the outbound routing and the warehouse pick and pack as well as tracking and returns, on one record of the order, the agent acting on a late scan already knows how the parcel was routed and what was promised. That is the difference from a rules screen inside a shipping app, and it is set out in AI agents in e-commerce logistics and on the delivery management page.
The bottom line
Carrier selection rules are your delivery policy made executable. Write them as sentences with owners and reasons, order constraints before promises before cost, keep the fallback explicit, and replay last month's orders through them before trusting them. When the rule table starts growing faster than the business, that is the signal to move the decisions to a system that can act on live performance rather than last quarter's assumptions. The carrier integration checklist covers what to ask a vendor, and a demo shows how the rules above run in Pango.
