On the third day of the mega sale, the same SKU was listed at 79 CNY on TikTok Shop, 69 CNY on the Shopify standalone store, and converted to 85 CNY on Lazada Malaysia. A buyer screenshotted the price gap and posted it on social media. Customer support logged into each store's admin panel one by one to adjust prices, taking over forty minutes to align all three. The issue isn't a lack of headcount—it's the absence of a single shared rule source. Every price change forces a person to recalculate procurement cost, platform fees, and stacked promotions from scratch; switch to a different person and you get a different number. If you run 2 or more stores simultaneously with daily orders exceeding a hundred, manual per-store price changes are already one of the highest hidden costs in your operations.
Three Failure Points That Manual Per-Store Price Changes Cannot Cover
- Cost accounting relies on memory.Procurement prices were updated last week, but the floor-price coefficients across three stores were not synchronized. The Lazada store is still running promotions based on outdated costs.
- Stacked promotions have no cap.After stacking Lazada's spend-threshold discounts, platform coupons, and store coupons across three layers, the actual selling price fell below the cost line—yet no one had calculated in advance how far the total discount could stack.
- No audit trail for price changes.Who made the change, from what to what, and what triggered it—all you can do is dig through chat logs, and when disputes arise, no one can make it clear.
These three failure points all point to the same thing: the decision logic lives in everyone's head and has never been turned into executable rule fields. The fix is not "add another person to watch prices"—it is encoding the judgment as rules that the system executes.
What each of the three rule layers specifies: accounting, execution, exceptions
Break pricing into three rule chains. Each layer solves one problem, and layers are connected through SKU primary key and channel ID.
Accounting Layer (Setting the Cost Floor)
Required fields: SKU purchase price, platform commission rate, allocated logistics cost, channel coefficient (e.g., TikTok Shop coefficient 1.0, Shopify coefficient 1.15). Output formula: minimum selling price for this SKU on this channel = (purchase price + allocated logistics cost) ÷ (1 − commission rate) × channel coefficient. This layer does one thing only: calculate the "do not go below" threshold. It does not handle promotional decisions.
Execution Layer (Per-Store Pricing Formulas)
Required fields: accounting-layer floor price, promotional stacking cap (e.g., Lazada discount + coupon total discount must not exceed 35%), effective time window. Outputs the actual selling price for each store; the system automatically verifies whether the price falls below the accounting-layer floor—if it does, the order is intercepted and an alert is pushed. For the specific values of Lazada promotional stacking caps and conflict handling, refer toMulti-Site Pricing and Promotional Cadencethe processing order in the article.
Exception Layer (Conflicts and Unauthorized Actions)
Required fields: trigger rule ID, operator, original value, new value. Unauthorized price changes are automatically intercepted with a notification pushed; when two rules are triggered simultaneously, the higher priority takes effect, and the lower-priority rule is marked as "overridden" rather than deleted.
What to Do When Two Rules Are Triggered Simultaneously: Conflict Resolution Order and Price-Change Audit Trail
The most common "rule clash" in practice: a promotional rule says "all items at 8-tenths of price," while the accounting-layer floor says "this SKU must not go below 72 CNY." The handling principle is ranked by degree of irreversibility — inventory already deducted > price already changed > tag only. Once inventory is deducted, it cannot be automatically rolled back; a price change can be rolled back; a tag can be cleared at any time. In a conflict, preserve the outcome of the higher-irreversibility rule first, and mark the lower-irreversibility rule as "overridden."
This conflict-resolution order is especially prevalent in Shopee multi-store mega-sale scenarios. If you are building order-routing logic for a mega sale, you can cross-referencehow to use rules to reduce missed shipments when mega-sale orders surgethe two chains — claim and inventory — within it.
When to Switch to Rule-Driven Automation and When to Stay Manual
The threshold is concrete: total SKUs below 100 and ≤ 2 stores — a formula-driven shared spreadsheet with manual maintenance is sufficient; the build cost of a rules engine exceeds the time it would save. Once SKUs reach 200+, stores are ≥ 3, and daily orders exceed 100, the error rate of manual maintenance begins to outweigh the maintenance cost of rules, and that's when you move the calculation layer and execution layer into the system. Don't build the full three-layer stack up front — get the calculation layer running first (a shared cost sheet with a channel coefficient column), bring the execution layer in next, and add the exception layer only when you're genuinely blocked by "rules conflicting." For the cutover cadence, refer tothe phased tasks for multi-store operations from single-store to multi-store, to avoid deploying a 6-store toolset when you only have 2 stores.
If you're already usinga unified multi-platform management workspacefor orders and inventory, the rules engine can plug directly into the same set of fields — no need to spin up a separate system.
FAQ
Does rule-driven pricing mean all stores must charge the same price?
No. The calculation layer shares a common cost floor, but the execution layer isolates by channel coefficient, so different platforms can target different gross margins. "Unified" means a single source of rules, not a single price figure.
Rule conflicts spike in frequency during promotions — should you temporarily disable the exception layer?
No. Promotions are precisely when the exception layer should be in full effect — stack caps, floor interception, and audit logging are all running. The correct approach is to tighten stack caps before the promotion to reduce conflict triggers, not to remove your last line of defense.
Should rules live in a spreadsheet or in an ERP/workspace — how do you choose?
If you have 500 or fewer SKUs and a team of 3 or fewer, a shared spreadsheet with formulas will do—set channel coefficients and stacking caps up as dropdown options. If SKUs exceed 500 or you run across more than 3 platforms, use the rule module in a workbench or lightweight ERP to avoid version conflicts caused by multiple people editing the spreadsheet simultaneously.
