When Shopee's six country sites are launched together, how should accounts be grouped to avoid chaos?

When six country sites are launched together, what usually becomes chaotic first is not sales but the backend: a Thailand site operator clicks ship in the Malaysia store backend, while the Philippines site receives a verification reminder for the Malaysia payment account; when a newcomer takes over, they face around ten accounts and don't know which one can change prices.

The root cause of such incidents is not the absence of grouping, but that the grouping dimensions conflict with one another—group by country, by store type, and by person; any two of them will override the third.

Let's put the conclusion first: when Shopee's six country sites—Malaysia, Thailand, Vietnam, the Philippines, Indonesia, and Singapore—are launched at the same time, don't group by country first; first confirm whether the control variables behind each account are consistent. Only a set of accounts with consistent control variables belongs to the same group; “country” is just one of those variables.

When six country sites are launched together, don't rush to group by country first

The MY group, TH group, and VN group approach is completely sufficient at the stage of “one person manages one country, one country has one store,” because country happens to equal the control variable. The problem arises when stratification begins within the same country: Thailand has both cross-border stores and local stores, and local stores may also be registered under two different licenses, with different fulfillment warehouses and payment entities.

At this point, the “Thailand group” label will cover up these differences. The accounts in the same group have different registration entities, different payment accounts, and different shipping warehouses, but because they are on the same grouping table, daily operations will by default treat them as interchangeable—sharing one browser environment, one set of sub-accounts, and one customer service script.

When a platform determines whether multiple accounts belong to the same entity, it does not look at a single signal, but at the degree of overlap among several layers of variables: network egress, device and browser fingerprint, identity and payment information, and behavioral trajectory (for a breakdown, seeWhen a platform determines that several accounts belong to the same person, what dimensions does it usually look at?). Grouping by country only aligned the site field, while the other layers are still scattered; when you are actually asked to provide supplementary verification, you cannot clearly say which layer overlapped first.

First determine which stage you are in, then decide on the primary grouping axis.

More granular grouping is not always better; team sizes vary, so the primary grouping axis should vary. First find your own row in the table below.

There is only one criterion: if two groups of accounts can be logged into one after another by the same person in the same browser window without anyone finding it strange, then they have not truly been separated; the grouping only exists on the spreadsheet.

Use 'operations unit' as the primary grouping axis, then attach site, store type, fulfillment, and payment collection.

An operations unit refers to a group of accounts with consistent control variables: the same registration entity, the same payment collection channel, the same fulfillment method, the same set of environment configurations, and the same person in charge. It measures the risk radius, not folder hierarchy—an operations unit may be 1 store, or 2–3 local stores in Thailand under the same license.

After the unit is determined, fields such as site, store type, fulfillment warehouse, receiving account, sub-account, and ERP binding are all attached under the unit rather than grouped in parallel. The value of doing this is that any adjustment only changes one level, and new hires only need to know which unit they belong to, without having to memorize all the differences among the six countries' sites.

It should be noted that the difference between local stores and cross-border stores is not in the backend buttons, but in the chain of entity, fulfillment, funds, and multi-store environment (Shopee local stores vs. cross-border stores: nine operational differences). Putting them into the same unit is equivalent to mixing the variables of the two chains together; no matter how the grouping table is maintained afterward, errors will occur.

Grouping table directly applied to six-country sites: how to place 4 types of operating units

The table below is a common form arranged according to "consistent control variables." You can add or remove rows based on your actual licenses and payment collection situation, but do not change the column judgment logic.

The most important thing in the table is the last column. Messy grouping is usually not because the grouping is not granular enough, but because someone, to save effort, puts accounts that 'cannot be mixed' into the same group. The account isolation sequence, product selection, and compliance processes of the local store matrix can be coordinated.Account Isolation in Practice for Shopee Local Store Matrices and Lazada Multi-StoresCompare them together, but the isolation sequence cannot be reversed to accommodate grouping habits.

When cross-border stores and local stores are operated together, the grouping order follows these four steps.

1. First, group by payment collection entity.Who the money belongs to is the anchor point for cross-checking between the platform and the payment institution, and it is also the first layer of clues for multiple stores being attributed to the same controller (for the reason, seeWhat happens when several stores share a single payment receiving account). Accounts with different payment receiving entities, regardless of whether the sites are the same, cannot be placed in the same unit.
2. Then divide by fulfillment method.Local warehouse shipping, 3PL dropshipping, and cross-border SLS are three different chains; their delivery time commitments, return addresses, and customer service scripts are all different. Within the same unit, the fulfillment method must be consistent; otherwise, one incorrectly filled return address becomes an incident for two sites.
3. Then divide by site and store type.Only at this step do country and cross-border/local labels come into play. The preceding two steps have already ensured that the funds and goods within a unit are consistent; country is only used to name the unit.
4. Finally, divide by operations personnel permissions.People are the layer most prone to change, so put them last. Who is responsible for which unit is expressed through sub-account authorization, rather than handing over account passwords together with the environment.

The order cannot be reversed. If you split by person first, a single reassignment will put two payment entities into the same environment; if you split by country first, a single "Thailand" will contain both local stores and cross-border stores at the same time, and every subsequent step will require patching.

One operations unit corresponds to a complete set of configurations: an independent browser environment, proxy exit, sub-account permissions, payment account, and ERP binding.

After grouping, the environment, sub-accounts, and payment collection must all be recorded in the same mapping table.

If a group stays only in a spreadsheet, it will become invalid within three days at most. What really makes a group effective is that each operations unit corresponds to a complete set of configurations, and that this configuration set can be verified.

Specifically, five items need to be put in place: an independent browser Profile (store fingerprint, Cookie, and login state are not shared), the proxy egress bound to that Profile (the same unit can share an egress, but different units should not mix them), the sub-account permission scope for that unit, the receiving account and withdrawal path, and the store binding in the ERP or order-printing system. If any one of the five items crosses units, this group is not clean.

Put this mapping table somewhere the whole team can see it. When a new store goes live, fill in the table before opening the store; this saves far more effort than investigating after the fact. When an operator leaves or changes roles, freeze access according toStore Account and Permission Handover Checklistin the order specified; the mapping table is the most direct basis for verification.

During handover, verify the fixed fields first, then hand over the owner and suffix; changing a fixed field is equivalent to switching groups.

Naming convention: make it clear at a glance to new team members which group an account belongs to.

Naming only needs to convey four things: site, store type, unit number, and owner. The common template is site_store_type_unit_number_serial_owner, for example, TH_LOC_U03_02_Lin means a Thailand local store, unit 3, store 2 in that unit, owner Lin; for cross-border stores, just replace the store type with CB.

The fields that must be fixed are the site code, store type code, and unit number. These three determine ownership—changing them is equivalent to switching groups, and the mapping table must be updated accordingly. Only the owner and the suffix can change. Sequence numbers increment only within the same unit; do not number consecutively across units, otherwise sequence numbers will collide with each other when you expand stores.

The handover card supplements the naming, recording the parts that cannot fit into the name: store ID, registered entity, receiving account, fulfillment method, browser Profile name, proxy exit, sub-account list, ERP binding, and last change date. Go through each item during handover; if any item does not match, stop first—do not keep operating on the assumption that “it should be this one.”

The three boundary conditions most likely to scramble your grouping

• Multiple stores sharing a receiving account.If two stores must share one receiving entity, treat them as the same operations unit and do not split them into two groups; if you really want to split them, split the receiving chain first, then change the grouping table.
• Temporarily reassigning people across groups.Have the temporary operator use a sub-account to enter the target unit; do not hand over your own account password, Profile, or proxy. When the person leaves but the permissions remain, that is the hardest type of group crossover to trace.
• Cramming new sites directly into the old environment when expanding.When opening a new Singapore site or adding a Vietnam local store, create an independent Profile and exit first, then log in for the first time. For accounts that have already logged in through the old environment, do not try to fix it with “I will be careful next time”—reconfigure them as a new unit and record the change date.

Frequently asked questions

Can the six-country sites be opened in the same browser using different tabs?

Whether you can and whether you should are two different things. If the same person logs into accounts from different units one after another, login state, cookies, and local storage accumulate in the same environment, and when a problem occurs you cannot tell which layer overlapped first. Always switch Profiles across units, even if you are just taking a quick look at the backend.

If one operations person is responsible for both Thailand and Vietnam, should the grouping be split by person?

No. Group by control variables. Give the person permissions for however many units they handle, and switch environments when switching. Grouping by person turns staffing changes directly into account reorganization, which costs far more than provisioning an extra Profile.

Can sub-accounts be shared across operating units?

Not recommended. A sub-account is both a login entry point and an attribution marker for operation traces. If one sub-account is attached to two units at the same time, the behavioral traces of the two units will intersect, making it hard later to determine who made a particular price change or inventory change.

For a newly opened Singapore site, which unit should it belong to?

First look at the payment entity and fulfillment method, not at which country it "looks more like." If it uses the cross-border flow and payment collection is consistent with the original cross-border entity, merge it into Unit A and add SG to the naming; if it is a separate entity or has independent payment collection, create a separate unit.

How often should the grouping table and mapping table be updated?

Update by event, not by time: when any of these five types of events occurs—new store launch, payment account change, person-in-charge change, fulfillment warehouse switch, or site expansion with environment switch—make the change on the same day. Routine inspections should only check whether naming and the mapping table are consistent; do not change the structure while you are at it.