Forty minutes after midnight during the major promotion, Store A had three orders with no one handling them—the main account was still in Store B's backend; at the same time, Store B's delay was not because no one was managing it, but because the available inventory for this batch of goods had already been deducted by Store C first, and the warehouse simply could not ship them out.
Both of these are called "something went wrong during the major promotion," but their trigger points are completely different: a missed shipment happens when the order breaks between payment and someone taking responsibility, while a delay happens when the order already has someone responsible for it yet does not complete the handover to shipping within the platform's timeliness. Managing both with a single set of rules will leave both sides half-baked. Below, for each of the three chains—claiming, inventory, and timeliness—we offer one rule that can be implemented the same day and can be reviewed.
Missed shipments and delayed shipments are distinct failure chains, so rules must be set separately
The sole point for determining a missed shipment is: after the order is paid, how long the gap is before it is claimed by a specific person. It is not directly related to order volume or staffing levels—a store with only 20 orders can still miss shipments if the main account does not switch back. Therefore, the rule object for preventing missed shipments is the "claiming action," not the "shipping action."
The decision point for a delay is after claiming: how many hours remain from claiming to handover to shipping, when the shipping label is generated, and when the warehouse picks up the parcel. Its rule objects are the timeliness countdown and inventory availability. Mixing the two chains together most commonly results in all management actions being focused on "urging the warehouse," while orders that truly have no one claiming them are still sitting in the backend, and by the time they are discovered, the shipping deadline has already passed.
In Shopee multi-store management, these two chains are more likely to run into problems than a single store because goods and people are shared across stores. AliExpress store operations, Lazada store operations, and Mercado Libre store operations perform basically the same, and their processes can be borrowed from one another, but thresholds must be set separately for each platform.
Set an order claiming rule for each store instead of relying on people to watch the backend
- Assign by "store + time slot," not by person.Divide the day into three segments: 0:00–8:00, 8:00–18:00, and 18:00–24:00. Assign a primary sub-account for each segment, making clear who owns Store A and who owns Store B. Completion criterion: at any moment you open the schedule, every order can be traced to a single person.
- Set a claim timeout threshold.For example, if unclaimed for 15 minutes, it automatically escalates to the team lead; adjust the threshold based on average order value and customer service response speed—do not copy it blindly. Completion criterion: for three consecutive days, no order stays in the backend beyond the threshold without anyone being notified.
- Tie the claim action to a sub-account; sharing the main account is not allowed.When the main account is shared, claim records fall under the store account, making it impossible to tell who claimed and who missed. Completion criterion: export the claim records, and every row has a specific sub-account ID. For field design of division of labor and handover, refer tothe division-of-labor table and handover checklist sliced by function.
- Write the claim status back to a single table shared by all stores.At least four fields: store, order number, claimer, and claim time. Completion criterion: without looking at any platform backend, just open this table to know how many orders are unclaimed and how many are claimed but not yet shipped.
Inventory and warehouse allocation must be written as hard rules; otherwise, overselling will inevitably turn into delays
Overselling often goes unnoticed in the system; it only surfaces when warehouse staff pick the goods, and by then the order has already entered its delivery deadline countdown.
| Rule type | Trigger condition | Action |
|---|---|---|
| Shared inventory safety threshold | Multiple stores share the same batch of goods, and the sellable quantity of any one store is already approaching the physical inventory of that batch | Lower that store's sellable quantity to a preset safety line, and prioritize the remaining quantity for the store with the shortest shipping time |
| Separate deduction for pre-sale and in-stock | The same SKU has both pre-sale orders and in-stock orders at the same time | In-stock orders take priority in occupying inventory; pre-sale orders are deducted from an independent inventory pool, and borrowing between them is not allowed |
| Cross-store allocation rollback | Deducted but the warehouse cannot actually ship out | Within the agreed rollback time limit (for example, 30 minutes), release the reserved inventory; the order enters an exception pool, where a manual review determines whether to reassign it to another warehouse |
There is a common misconception here: the practice in Wayfair seller operations of using a warehouse's committed sellable quantity cannot be directly carried over to Shopee store inventory. Shopee deducts inventory at the store level, and the physical inventory in a shared warehouse and the store's sellable inventory are not on the same basis. The result is often that both sets of numbers reconcile, but the warehouse simply has no stock. Inventory rules should be consolidated together with orders and messages; for the field design, seePrimary key design for centralizing the three flows of orders, inventory, and messages.
Connect the dispatch deadline countdown to rules, not to human memory
Reminder thresholds must be set separately for each platform. Shopee's shipping deadline basis differs from Lazada, Mercado Libre, and AliExpress in terms of start point and holiday handling; using the same hour count for reminders will result in one side being reminded two hours early while the other side is actually already overdue. There are four variables that need to be configured separately:
- Platform, which determines the start point and basis of the countdown.
- Shipping method, which determines the time difference between shipping label generation and actual pickup.
- Time zone, determines what time “today” ends; holiday postponements must be marked separately.
- Whether it is a presale, determines that this order does not participate in the same-day countdown at all; otherwise it will generate false alarms every day.
“How many hours in advance the warning line is set” should not be based on gut feeling. First measure the actual cycle over three days—the average time from claim to handover—then take the duration of the three slowest orders plus a buffer as the warning line; anything within the warning line is critical.Failure diagnosis line for multi-currency, multi-timezone, and logistics collaborationExplains why thresholds cannot be unified across different platforms.
Before executing rules, first define three boundaries: account, permissions, and logs
Account boundary:Each rule must run in an independent login environment for the corresponding store. If you switch stores in the same browser window and then execute a claim, the attribution of the rule record will follow the environment.
Permissions boundary:Split the three types of actions—assignment rules, timeout threshold changes, and inventory safety line changes—by role; do not let all stores share a main account.
Log boundaries:Every rule modification must be logged—who changed it, what was changed, and when it takes effect.
These three have no exceptions in AliExpress multi-store management, Lazada multi-store management, and Mercado Libre multi-store management; for the specific field list, seeKey settings for login environment, sub-account permissions, and operation logs.
Canary rollout sequence and review criteria for the 7 days before the major promotion
- Run read-only rules first.First turn on claim timeout reminders and SLA countdown reminders, without any automatic actions. Success criteria: reminders accurately hit for two consecutive days, and no shipped orders are falsely reported as overdue.
- Then turn on assignment rules.Enable automatic assignment, but keep a manual reassignment entry point. Success criteria: every reassignment can be traced to a reason, and misassignments do not become the norm.
- Automatic actions go last.Inventory reservation rollback, and exception orders transferred to the exception pool. Criteria for a successful run: at least one real oversell has been handled, and after rollback the order status and inventory quantity are consistent.
For the retrospective, look at only three numbers: the number of unclaimed orders, the number of orders overdue and not handed over for shipping, and the number of rollbacks caused by incorrect rule assignment. Total order volume cannot be used as a basis for rule effectiveness—during major promotions, order volume is naturally higher than usual; if it rises, it only means you should look at the first three numbers. What you use to host the rules first depends on whether you currently use spreadsheets, multiple browser instances, or a unified workbench; for the capability boundaries of the three, seeHow to Choose Between Self-Built Spreadsheets, Multiple Browser Instances, and a Unified Workbench.
Frequently Asked Questions
If I'm only opening two stores, do I still need to write them as rules?
With two stores, you will also have the gap where 'the main account stays at the other store.' The minimal version needs only three rules: who claims it, to whom it escalates when overdue, and which table the status is written to. Just put it in a shared document; there is no need to adopt a tool first.
What should I do if reminders are set but nobody looks at them?
In most cases, the problem is that the reminder has no clear recipient. Push the reminder directly to the sub-account primarily responsible for that time period, and stipulate that if it is not handled after the timeout, the status must be replied in the group. If still nobody looks at it, the reminder frequency is usually too high; start by changing from "one per order" to "one per timeout".
Can different platforms share a single set of time-limit rules?
The process can be shared, but the thresholds cannot. Each platform has different starting points for the shipping deadline, holiday postponement, and logistics method categories; using the same number of hours will inevitably mean urging early in some cases while already overdue in others. Share the template, but leave an independent threshold field for each platform.
When switching stores in the browser, will the rules get mixed up between stores?
If a rule targets "the login session in the current window," it may land on a different store after you switch stores. The way to avoid this is to make the store ID the primary key for the rule and ensure that each store's rules run in that store's own isolated login environment.
The big promotion has already started — is it still possible to add rules now?
Yes, but the order needs to be compressed: first add the two read-only alerts, the claim timeout reminder and the time-limit countdown, which can reduce unclaimed orders the same day. Do not enable auto-assignment or inventory rollback in the middle of the promotion; wait until the first week after this wave ends to do a gradual rollout.
