Inventory, Order, and Customer Service Permissions: Separation of Duties and Collaboration in AliExpress Multi-Store Management

On the afternoon of the second day of the major promotion, customer service, to appease a buyer waiting for restock, changed the available inventory of a certain SKU in the AliExpress backend from 40 to 80. That night, the SKU sold three more orders on Shopee, leaving only 12 units in stock in the warehouse, and the two stores oversold at the same time. When they later tried to find out who had changed the inventory, they discovered that three people shared the same sub-account, and the logs were all under the same name, making it impossible to trace the person or roll back the change.

This kind of failure is rarely due to "people not being careful"; rather, it's because permissions aren't separated: anyone can change the numbers, and no one has to sign off. Below we address only three things—how to split permissions for each of the three lines: inventory, orders, and customer service; how to hand over in daily operations; and who approves exceptions. Platform differences only affect backend field names and authorization granularity; the mechanism itself is common across AliExpress, Shopee, Lazada, Mercado Libre, and Wayfair.

First determine which permission line the problem lies in: three failure signals

• Inventory counts don't match the physical stock, and the same item oversells in two stores at the same time.Points to inventory permissions: more than one person can change the sellable quantity, or there is no safety stock threshold at all.
• Slow shipping, incorrect address changes, and buyers receiving orders that aren't theirs.Points to order permissions: there is no review checkpoint between order capture and shipment confirmation, and address changes leave no evidence.
• For the same SKU, AliExpress agrees to reship, while Shopee will only refund a coupon.This points to customer service permissions: compensation caps and script guidelines are not unified across stores.

The three lines need to be diagnosed separately. Treating overselling as a customer service problem and adding staff only results in one more person having the opportunity to change inventory.

Permission delegation principle: split by action risk, not by store

Assigning people by store is the default practice for small teams—the operator at Store A is not given permissions for Store B. The problem is that the same role has different permissions at the two stores; to get the work done, people ask colleagues with permissions to perform actions on their behalf, ultimately reverting to shared accounts. A viable approach is to split permissions into six types of actions: view, edit, approve, export, refund, and change price. This is consistent withAccount Isolation, Permission Division, and Data Reviewthe layered order given in it: split actions first, then discuss tools.

The reading is: the further down you go, the shorter the validity period and the greater the need for an audit trail. One person can look at three stores at the same time, but should not simultaneously hold the price-change right and the refund right for three stores.

Inventory permissions: who is responsible for changing inventory, locking inventory, and cross-platform sync

1. Designate a single inventory owner.This role is set up by business line, not by store. For AliExpress multi-store management and other platforms, he alone has the final say on inventory; others have read-only access.
2. Set safety stock thresholds.Below the threshold, you can only lock, not release quantity. Releasing quantity is a separate action that requires approval—not a casual 'change it along the way'.
3. Each change leaves four fields:Who made the change, when, from what to what, and why. A change missing any field is considered invalid and will be reverted during reconciliation on the next shift.
4. Cross-platform sync only synchronizes quantity.Synchronization can be automated, but the responsibility boundary remains unchanged—if synchronization fails, the inventory owner is still responsible for explaining it, and cannot shift the blame to the tool.
5. Reconcile once a day.Align three lines for each store: sellable quantity, in-transit quantity, and actual in-warehouse quantity. If they don't match, lock the store first, then investigate the cause.

Business flows such as orders, inventory, and messages should be centrally consolidated, but login credentials and browser environments must be strictly isolated. Do not mix these two things together,Centrally processing orders, inventory, and messagesis premised on the account assets themselves having already been separated.

Order permissions: red lines for order grabbing, address changes, shipping, and refunds

1. Order grabbing:Anyone can view it; there are no restrictions. Restricting viewing only drives people to copy orders privately, making them even harder to trace.
2. Review:Orders that are high-value, multi-item, from first-time buyers, or have incomplete addresses are automatically flagged red; red-flagged orders do not enter the normal shipping queue.
3. Address changes:Customer service supervisor only. Before any change, you must obtain the buyer's written confirmation within the platform and save a screenshot in the corresponding order notes.
4. Shipping confirmation:Normal orders can be executed by the operations assistant; address change orders, split orders, and reshipments must be final-confirmed by the store manager.
5. Refunds:Store manager level and above. If the amount exceeds the preset limit, or it is the same buyer's second application in the same month, escalate directly; do not repeatedly negotiate at the front line.

The entire order flow has only three red lines: keep evidence for address changes, abnormal orders do not enter the normal queue, and refunds are not closed at the front line.

Customer service permissions: how scripts, compensation, and escalation are tiered

• Front-line customer service:Can reply, can log, can escalate; cannot promise compensation amounts, cannot change inventory, cannot initiate refunds.
• Customer service supervisor:Can issue coupons or provide small compensation within the unified limit, can handle address changes, and can escalate orders to the order owner.
• Store manager:Responsible for refunds, reshipments, cross-store policy rulings, and judgments requiring a global view, such as “the same buyer has complained in all three stores.”
• Parts that must be unified across stores:The script templates, compensation caps, and turnaround commitments for the same SKU are maintained by the store manager in a single table. Shopee store operations and Wayfair seller operations may use different greetings, but the compensation cap for the same SKU cannot differ.

Coordination mechanism: three handoff status fields plus one exception escalation path

Verbal handoffs inevitably lose information in multi-store scenarios because they have no status. Replace them with three fields: Pending, In Progress, and Pending Review. Every task must have an owner and a deadline, and cross-store dashboards should be sorted by status, not by store.

• Pending:Just entered the queue and has not been claimed yet. If it remains unclaimed beyond the agreed duration, it is automatically escalated to the store manager.
• In Progress:Has an owner; clearly note where it is stuck—waiting for the buyer’s reply, waiting for warehouse confirmation, or waiting for approval.
• Pending Review:The action has been completed and is awaiting confirmation from a second person. Three types of actions—inventory changes, address changes, and refunds—must stop at this step.
• Exception escalation:For any action beyond the scope of a role's permissions, the initiator must document the reason and the impact on the store, and it may be executed only after the store manager approves it; the approval record stays with the task, not in the chat history.

This mechanism and the function-based division-of-labor table are the same thing, and can be used in conjunction withHow One Team Manages Multiple Stores: Role Division, Approval Flow, and Handover Checklistto cross-reference the division of labor in it.

Platform Differences Quick Reference: AliExpress, Shopee, Lazada, Mercado Libre, Wayfair

The five platforms differ in their backend fields and authorization granularity, but the types of actions that need to be centralized are almost the same. The table below lists only the criteria for judgment and the centralization targets; the specific authorization items are subject to what is currently displayed in your account backend.

For platforms with coarse granularity, make up for it with process: if the backend does not provide granular permissions, change that action to "must be handled by two people," and write the second person's name into the task status. The real difference between AliExpress multi-store management and Shopee multi-store management is not in the permissions table, but in whether you can stick to this substitute rule.

Beyond permissions: sub-accounts, login environments, and operation logs

Tool selection comes last. If you roll out a unified workspace before sorting out the three layers of credentials, environments, and collaboration, you are just moving the chaos into a more expensive interface; self-built spreadsheets, multiple browser instances, and unified workspaces each suit different stages, and you can choose according toHow to choose between self-built spreadsheets, multiple browser instances, and a unified workspaceUse the three scenario tiers in it to determine which layer to upgrade.