Signature AI ·Multi-Carrier Management

Multi-Carrier Intelligence

The AI allocation engine behind every shipment assignment.

✦  ~21% reduction in cost-per-delivery at scale quick-commerce operations

The problem it solves

Every shipper above a million parcels a year ends up with the same stack: a contract binder of 20+ carriers, an ops lead who knows which carrier is quietly under-performing this week, a finance team that finds out six weeks later, and a rate-card spreadsheet that nobody has touched since the last RFQ. When an order drops into the system, the allocation logic is usually a combination of rules written years ago, one overworked dispatcher, and a fallback to the cheapest-on-paper option. That fallback is not the cheapest in practice — it is the cheapest until the carrier misses its SLA, triggers a chargeback, and burns through the cost advantage three times over.

The result is a well-known leak: 18-25% of every shipper’s carrier spend is misallocated. Not because the contracts are bad — because the allocation is stuck in rules, not in intelligence. Carrier performance changes weekly. Capacity changes hourly. Allocation logic changes once a year. And the ops lead holding the whole thing together in her head is the single biggest KVP (key-value-person) risk in the freight organisation. When she is on leave, allocation quality visibly drops; when she leaves the company, the operation spends six months rebuilding the same mental model from scratch.

What it is

Multi-Carrier Intelligence is Shipsy’s real-time allocation engine that scores every shipment against every eligible carrier and picks the assignment that balances SLA, cost, capacity, and performance — not the one that matches a static rule. It runs under Astra as the carrier-selection layer and under the multi-carrier orchestration product as the execution layer.

What makes it different: the scoring function is not a weighted checklist. It is a learned model that updates with every delivery outcome — every on-time, every breach, every refusal, every chargeback — and re-prices each carrier on every route, every weight band, every service type, every hour of the day. Allocation that used to run once per order now runs live, on the current state of the network. It is new-age in a specific, measurable sense: it does for carrier allocation what dynamic ad-bidding did for media buying — real-time scoring, real-time execution, continuous learning.

Under the hood it combines a real-time carrier-capacity registry, a performance scorecard that updates per shipment, a contract-enforcement layer, and 240+ pre-built carrier integrations. Failover happens in single-digit seconds when a carrier API goes dark. The engine is vertical-ready across quick-commerce, D2C e-commerce, B2B express, pharma, and cross-border freight — each with a tuned weight profile out of the box.

Core capabilities

Capability What it does
Composite scoring function Every allocation candidate is scored on four dimensions — SLA match, landed cost, available capacity, observed performance — weighted per customer, per lane, per service type. Weights are configurable and auditable.
Live performance scorecard Every completed shipment updates the carrier’s rolling scorecard. Breaches are weighted by recency and by the shipper’s own priority. A carrier that was #1 on Monday can be #4 by Thursday if its performance slips.
240+ carrier integrations Pre-built integrations with global (DHL, FedEx, UPS, Aramex), regional (Delhivery, J&T, Pos Malaysia), quick-commerce (Borzo, Dunzo, Porter), and niche LSPs. New carriers onboard in 2-4 weeks with a standard adapter.
Contract enforcement Rate cards, fuel surcharges, zone skips, accessorial rules, and minimum-volume commitments live in a single contract registry. Every allocation honours the contract; every deviation is flagged to Nexa for audit.
Real-time failover A carrier API timeout or a 4xx response triggers automatic re-allocation within 3 seconds to the next-best carrier. The customer never sees the failure; the dispatcher sees a single audit line.
Volume-commitment management Tracks contracted monthly volumes per carrier. Allocates in a way that fulfils commitments without over-serving — protects the shipper from rebates they will not earn.
Hybrid own-fleet + 3PL logic Scores own-fleet capacity against 3PL capacity on the same axis. If the in-house fleet is 70%+ utilised and the marginal 3PL cost is lower than the marginal own-cost, the engine routes to 3PL — and vice versa.
Pincode-level eligibility Every carrier’s service map is maintained at the pincode / zip level with service-type granularity (COD, reverse, fragile, reefer). A carrier that lost coverage in 12 pincodes last week is excluded from those pincodes this week.
Dynamic pricing awareness For spot-pricing carriers and quick-commerce orchestration, the engine pulls live rates at allocation time rather than relying on stale rate cards.
Carrier dispute feed Delivery exceptions, chargebacks, and POD discrepancies flow back into the scorecard and into Vera for settlement reasoning.
Simulation and rate-shopping Shippers can simulate allocation outcomes across historical shipments under new contract terms — “what would last quarter have cost if we gave Carrier X 30% more volume?”
Configurable business rules on top Customer-specific rules (Amazon orders must go to Carrier A; Dubai deliveries must use a 4PM cutoff) layer on top of the learned scoring. Rules are first-class, not a workaround.

How it works

The engine separates the allocation decision (live, millisecond-scale) from the scoring model (updated in near-real-time from the performance feedback loop) from the contract and eligibility layer (authoritative, change-controlled). An allocation request hits the decision layer, which asks the scoring model for candidate ranks, filters against the contract layer, and commits the assignment to the carrier API. The loop closes when the shipment status — on-time, breached, refused — flows back into the scoring model.

This separation is what lets the engine run change safely at enterprise scale. The contract layer is ground truth and is edited under change control. The scoring model is continuously learning but bounded by versioning. The decision layer is deterministic once the model version is pinned. A shipper can audit any past allocation by replaying the exact inputs and getting the exact output — which is the compliance-team table stakes no rule-based allocator has ever met.

graph TB A[Order / shipment intent] --> B[Multi-Carrier Decision Layer] C[Contract + rate registry] --> B D[Eligibility map - pincode x service] --> B E[Scoring model - SLA, cost, capacity, perf] --> B F[Live capacity registry] --> E G[Rolling performance scorecard] --> E B --> H[Carrier API - 240+ integrations] H --> I[Shipment execution] I --> J[Status + outcome feedback] J --> G J --> K[Nexa settlement + Vera disputes]

On the execution side, every allocation runs through a fast path that typically settles in under 400ms end-to-end, with a resilient failover path that handles carrier API outages without exposing them to the shipper. The sequence below captures a typical fast-path allocation and the rare failover case in one flow.

Two aspects of the architecture matter operationally. First, the decision layer is stateless per request — which means a node can fail mid-allocation and another node picks it up without a retry penalty. Second, the scoring model is versioned, so a shipper who wants to roll back a scoring update can pin allocation to the previous version for any lane or customer segment without a full rollback. Combined, this lets the engine run with 99.99% availability across peak-hour allocation volumes that sometimes exceed 500 orders per second.

sequenceDiagram participant Order participant MCI as Multi-Carrier Engine participant Scorer participant Contract participant Carrier Order->>MCI: Shipment intent MCI->>Contract: Eligible carriers + rate cards MCI->>Scorer: Rank candidates now Scorer-->>MCI: Ordered list with scores MCI->>Carrier: Book with top-ranked carrier alt Carrier API fails Carrier-->>MCI: Timeout / 4xx MCI->>Carrier: Book with next-best in <3s else Success Carrier-->>MCI: Tracking ID + ETA end MCI-->>Order: Assigned + tracking

Proven outcomes

Customer type & scale Outcome
One of Asia’s largest quick-commerce arms, 5M+ orders/month, 200+ dark stores ~21% reduction in cost-per-delivery via hybrid own-fleet + 3PL orchestration; sub-20-minute promise held as carrier capacity fluctuated hourly
Global parcel leader, 65+ countries, 18,000+ drivers 18% reduction in cross-border allocation cost; 2-4 week carrier onboarding using the standard adapter framework
MENA retail conglomerate, multi-brand sports, health, lifestyle 14% reduction in last-mile allocation cost across 80+ markets; unified scorecard replaced six fragmented carrier reviews
Leading ANZ parcel operator, AUD 200-250M annual revenue 35% reduction in failed deliveries via carrier-aware allocation + performance-weighted scoring

Integrations

  • Carriers: 240+ pre-built — DHL, FedEx, UPS, Aramex, Delhivery, BlueDart, J&T, Pos Malaysia, Yamato, Australia Post, Posti, Correos, DPD, GLS, DPDgroup, IndiGo cargo API, regional LSPs across MENA, SEA, LATAM, EU
  • Quick-commerce 3PLs: Borzo, Dunzo, Porter, Loggi, Rappi Cargo, Pandago
  • ERP and order sources: SAP, Oracle, Salesforce Commerce Cloud, Shopify, Magento, WooCommerce, custom OMS via REST
  • WMS: Manhattan, Blue Yonder, Oracle WMS, Körber, native Shipsy WMS
  • Financial reconciliation: Handoff to Nexa for invoice reconciliation and rate enforcement; Vera for dispute handling
  • Data platforms: Snowflake, Databricks, BigQuery for historical allocation analytics and contract simulation

Deployment

Phase 1 — Discovery (weeks 1-2). Carrier inventory, contract audit, rate-card ingestion, baseline allocation analysis against the last 90 days of shipments. Identify top leakage patterns and define the target scorecard weights with the shipper’s ops and finance leads.

Phase 2 — Configuration (weeks 3-4). Contract registry loaded, eligibility map validated per lane and service type, scoring weights tuned, carrier APIs connected using pre-built adapters (typically 60-80% of the carriers are pre-integrated).

Phase 3 — Pilot (weeks 4-6). Shadow mode — live allocation decisions compared against the current production allocator, with no change in carrier assignment. Shipper reviews side-by-side on 100% of real orders for 2-3 weeks. Exit criteria: 10%+ projected savings and ops-team sign-off on explainability.

Phase 4 — Scale (weeks 6-10). Cut-over by lane or by customer segment. Governance: a weekly carrier-performance review in the first 60 days, monthly thereafter. Contract-enforcement deltas flow to finance. Most enterprises go live in 8-12 weeks; savings typically visible within the first 30 days of cut-over.

Security & compliance

  • SOC 2 Type II, ISO 27001, GDPR-compliant data handling
  • Contract registry is change-controlled — every rate-card edit has an owner, a timestamp, and a diff
  • Every allocation decision is auditable: which carriers were considered, what each scored, why the winner won, which rule (if any) overrode the model
  • Three-tier confidence scoring on scoring outputs — low-confidence allocations (new carriers, new lanes) trigger human-in-the-loop approval for the first N shipments
  • PII is not used in the scoring model; only anonymised shipment features
  • 21 CFR Part 11 and GDP / GMP-aware for pharma-regulated lanes

Case study callouts

One of Asia’s largest quick-commerce arms · 5M+ orders/month

Shifted allocation from a static “own-fleet first” rule to hybrid dynamic orchestration across own-fleet and 3PLs. Cost-per-delivery dropped ~21% while the sub-20-minute customer promise held through peak hours. The scoring model re-prices every 3PL every 15 minutes against live capacity.

Read the full case study

Global parcel leader · 65+ countries · 18,000+ drivers

Replaced region-specific allocation systems with a single engine spanning 65+ country operations. 18% reduction in cross-border allocation cost, and the 2-4 week carrier-onboarding adapter cut new-market launches by an average of six weeks.

Read the full case study

Leading ANZ parcel operator · AUD 200-250M revenue

Performance-weighted allocation — paired with driver-level performance data — dropped failed deliveries by 35% and allowed the operator to renegotiate three carrier contracts on verifiable performance data rather than gut feel.

Read the full case study

Frequently Asked Questions

How long does deployment typically take?

Most customers go live in 8-12 weeks with a shadow-mode pilot in weeks 4-6. Savings are usually visible within 30 days of cut-over.

How many carriers can you integrate with?

240+ are pre-built. New carriers onboard in 2-4 weeks using a standard adapter framework, regardless of whether the carrier has a REST, SOAP, EDI, or file-based interface.

How does the scoring model handle a new carrier with no history?

New carriers start with a contract-only score — SLA commitments + rate-card pricing + capacity — and a cold-start prior set from similar carriers in similar lanes. They accumulate a real performance scorecard over the first 500-1,000 shipments; until then, they are weighted conservatively.

Can we keep our existing carrier rules?

Yes. Customer-specific rules ("Amazon orders must go to Carrier A", "Dubai deliveries use 4PM cutoff") layer on top of the learned scoring as first-class constraints. Rules are authored in a UI, version-controlled, and auditable.

How does it integrate with our finance and settlement flow?

Every allocation emits a contract-enforcement record that flows directly into [Nexa](/brochures/nexa-settlement-agent) for invoice reconciliation, and any outcome discrepancy flows into [Vera](/brochures/vera-dispute-resolution-agent) for dispute handling. Finance sees leakage at the shipment level, not the end-of-month invoice level.

Can we simulate a contract renegotiation before we sign?

Yes. The simulation layer replays the last 90 days of shipments under proposed contract terms and produces projected cost, SLA, and volume outcomes per carrier. Used frequently during RFQ cycles.

How does failover work when a carrier goes down?

If a carrier API returns a timeout or a 4xx, the engine re-allocates to the next-best carrier within 3 seconds. Dispatchers see a single audit line; customers see no disruption. Repeated failures within a time window auto-throttle the carrier's allocations until health recovers.

How does it work with own fleet?

Own fleet is a carrier in the engine, with its own scorecard, capacity registry, and cost function. The engine routes to own fleet when own fleet wins on the composite score — not because of a hard-wired rule. This is how quick-commerce operators get 15-25% landed-cost reductions on hybrid fleets.

How does it interact with the rest of the Shipsy stack?

It sits between [Astra](/brochures/astra-planning-agent) (which decides the plan) and [Atlas](/brochures/atlas-autonomous-control-tower) (which monitors execution). Every allocation feeds [Nexa](/brochures/nexa-settlement-agent) for invoice reconciliation and [Vera](/brochures/vera-dispute-resolution-agent) for carrier disputes. The full loop — plan, allocate, execute, settle, dispute — runs as an autonomous flow with human-in-the-loop gates only where policy demands them.

Can we deploy it lane-by-lane rather than all-at-once?

Yes, and most customers do. Typical rollout is by lane family (e.g. metro same-day, cross-border express, B2B trunk) and by customer segment (top-tier first). This keeps risk containable and makes savings attribution clean for finance.

How is it different from a TMS's built-in carrier allocation?

TMS allocation is rule-based, updated on a manual cadence, and blind to live carrier performance. Multi-Carrier Intelligence is scoring-based, updated continuously from outcomes, and always current. It can run as the carrier-selection brain under an existing TMS or as part of Shipsy's full [multi-carrier platform](/products/multi-carrier).