How to Configure Multi-Store Order Auto-Assignment Rules: Four-Tier Priority and Exception Fallback Setup

A team operates 4 stores across Shopee, Lazada, TikTok Shop, and an independent site. On a peak-sale day at 14:02, a 3-item order hit 'no valid assignment' within the 10-minute inventory sync window. Manual intervention was too late, and the timeout cancellation directly triggered platform penalties. The issue is not 'slow order routing' but that the rules do not define 'what to do when an order cannot be assigned.' The complete configuration for multi-store order auto-assignment rules is a four-tier priority decision tree plus an exception fallback chain, and the prerequisite of account and environment isolation must be in place first. Refer tomulti-account environment isolationfour-layer self-check standard.

How to Rank the Four Priority Tiers: From Time Window to Price Tier

The first tier is the time window. Once an order enters the assignment pool, the default claim window is 30 minutes; upon timeout, the order is automatically released back to the pool. On peak-sale days, compress this to 15 minutes and link it to the automatic window-extension mechanism in the fallback chain discussed later. The second tier is the geographic warehouse: match the buyer's shipping address to the nearest fulfillment warehouse with available stock, with a distance threshold set at 200 km or 48-hour delivery coverage; when Shopee Malaysia and TikTok Shop Malaysia share the same warehouse, this tier hits directly. The third tier is the inventory threshold—it is not 'assign if there is any stock' but rather 'assign only when available stock ≥ safety buffer (default 5 units)'; SKUs below the buffer enter a waiting pool to prevent overselling caused by sync delays. The field mapping and trigger logic for this inventory sync process can be cross-checked againstthe 4-layer troubleshooting approach for multi-store inventory sync failureslayer by layer for verification. The fourth tier is the price tier: when the same SKU has a price gap across stores (independent site $29.9 vs Lazada $27.5), routing prioritizes assignment to the store within the price-differential threshold.

At the logistics sorting station, a four-compartment tray is arranged by priority, with a hand placing a label into the second compartment. — The four priority layers are matched sequentially: time window → geographic warehouse → inventory threshold → price tier. Processing stops at the first hit.

Price is uniformly applied as a routing constraint: how cross-store price differences for the same SKU trigger rerouting.

The method for unified multi-store price management is not batch price updates in the backend, but embedding the price gap as a fourth-layer routing constraint within the allocation logic. Specifically: the system pulls each store's selling price for the same SKU every 30 minutes and calculates the price-gap ratio (max − min) / min. If the price-gap ratio ≤ 8%, normal routing applies; > 8% and < 15%: orders are merged to the lowest-price store and tagged "cross-store merge"; > 15%: automatic allocation is paused and the order is pushed to the manual pricing queue. This is consistent with Lazada Multi-Store Price and Promotion Conflict Handlingthe logic of "sorting by irreversibility"—first ensure orders are not lost, then adjust prices for alignment, so that price-change approvals do not block the order allocation pipeline.

Exception fallback chain: three-tier safety net when all four layers miss.

Automatic window expansion.Trigger condition: no store hit within the default window. Action: expand the window to 60 minutes and notify the on-duty operations team simultaneously. If still no hit after expansion, proceed to the next level.
Manual claim queue.Trigger condition: no hit after the 60-minute window expansion. Action: the order enters a shared claim panel, sorted by "person who most recently handled this store takes priority." On-duty staff must claim the order within 5 minutes; otherwise, it automatically slides to the next level on timeout.
Merge to the nearest in-stock store.Trigger condition: Level 2 exceeds 15 minutes with no claimant. Action: the system reassigns the order to the nearest store with stock for the same SKU, marks it as "System Merge," and triggers inventory deduction at that store. The original store does not need to process a return.

The main conveyor indicator light turns amber, and operations staff switch to the secondary manual claim station to process stranded orders. — After the primary rule fails, orders slide down the fallback chain into the manual claim queue; on timeout, they are merged into the nearest store with available stock.

Before go-live, validate using a replay of the last 30 days of historical orders.

Pull all shipped and cancelled orders from the last 30 days and replay them one by one against the four-layer rules. Pass criteria: automatic assignment hit rate ≥ 92%, and Level 3 fallback proportion among the remaining orders ≤ 2%. If the hit rate falls below 85%, prioritize checking whether the third-layer buffer is too strict.
Isolate the order subset for "mega-sale days ± 3 days" and "inventory buffer below 5 units" to validate the backup-pool timeout rate. A timeout rate > 10% indicates the buffer needs to be lowered to 3 units; < 3% means keep it as-is.
Simulate historical scenarios with a price gap > 15% to verify the trigger sequence between rerouting and the manual queue, with a focus on identifying the race-condition window where the price gap reverses after routing. This validation workflow sharesthe multi-store order-creation → inventory → fulfillment processand directly reuses the five minimum handover fields within it, with no need to build a separate data table.

The first 7 days after configuration is the observation period, during which the three-category proportions of "Auto-assigned / Manual Intervention / System Merge" are pulled daily. For additional rules on claim and SLA chain in Shopee multi-store scenarios, refer toShopee Multi-Store Fulfillment Rules During Mega-Sale Order Surges, and cross-validate against the fallback chain in this section.

FAQ

Can four-tier priority and three-level fallback be configured in a single rule table?

Yes, but it is recommended to split them into two tables: a 'Primary Rule Table + Degradation Triggers' setup. The primary table stores the four-tier thresholds and decision order; the degradation table stores the three-level trigger conditions and timeout values. Both tables share the same SKU and store primary key, so updating one won't leave the other out of sync.

Different platforms have different inventory sync frequencies (Shopee 10 minutes, Lazada 15 minutes). How do you unify the third-level buffer?

Set the buffer based on the shortest sync cycle (10 minutes). For platforms with longer cycles, add 'sync interval × daily average flow rate of that SKU' to the buffer. For example, if Lazada averages 4 units per day, the buffer increases from 5 to 5 + 15×4/60 ≈ 5.5, rounded to 6 units.

Independent stores have no platform inventory lock. How does the third level make the determination?

Independent stores use soft locking: virtual inventory is deducted at order creation and automatically released if payment is not completed within 15 minutes. The buffer threshold is the same as platform stores, but the release trigger changes from 'payment success' to a dual condition of 'creation + timeout,' so prolonged occupation won't block routing to other stores.

After falling back to Level 3 consolidation, does the original store need to go through a return process?

No. Level 3 is reassignment, not return: the order never completed an allocation action at the original store—only the routing target changed. The original store's inventory remains unchanged, and no return or inventory release is triggered.