Nobody could point to the double invitation as a mistake. One person had invited that creator in September and left a note. The other searched the pool in November, saw the name, and sent a fresh invitation. The note sat on a record that no single TikTok Shop sub account owned, so in practice it belonged to nobody.
This is for sellers running two to five TikTok Shop stores with three to eight people. The stores are distinct enough to have their own products. The team is small enough that everyone shares one login, because sharing one login was faster on the day it was set up.
That setup works until it does not. When it stops, the symptom never looks like a permissions problem. It looks like a duplicate message, a wrong commission rate, or a number in a review meeting that two people remember differently.
Everyone can see everything, so nobody owns anything
A shared login feels collaborative. In practice it removes the one piece of information a small team runs on: who did this. Not for blame. For continuity.
Consider a simple case. Someone set a commission rate at eighteen percent. That person is out for a week. Now the answer to “why is this one at eighteen percent” is somewhere in a chat log.
The cost shows up in reviews. Three people look at the same dashboard, and each of them can change anything on it. So nobody prepares for the meeting. Nobody knows which numbers are theirs to explain. The meeting becomes a reconstruction instead of a decision.
Then there is a quieter cost that only appears with multiple stores. Once one login covers all three shops, every list is merged in practice. A creator who fits the home goods store gets invited by the beauty team. The message does not match anything they posted, so they do not reply.
Nobody did anything wrong. The boundary between the stores existed in the seller’s head and nowhere in the system.
What actually leaks when one login covers three stores
So it helps to name the four things that leak. They fail in different ways, and different settings fix them.
The first is contact history. Invitations, replies and notes belong to whichever store sent them. But a merged login shows them as one pile. So the second invitation to the same creator looks like a first.
The second is numbers. Revenue, creator performance and sample spend are per store. A total across three stores is arithmetically correct and operationally useless. It cannot answer which store is being run well.
The third is sample budget. Samples are the line item most likely to be spent by whoever is closest to the problem. With a shared login there is no per-store ceiling to spend against.
The fourth is the record of who changed what. This is the one that cannot be reconstructed later. So it is the one worth fixing first.
What a sub account changes in daily work
A sub account is a login for one person that sees a defined slice of the account. The definition is the whole product. So the interesting question is not whether the slice exists, but where its edges sit.
| Role | Should see | Should not see |
|---|---|---|
| Owner or founder | All stores, all creators, all spend | Nothing withheld; this is the account the others hang from |
| Store operator | Own store’s creators, samples, invitations, performance | Sibling stores’ creator lists and sample spend |
| Outreach specialist | Assigned creators, message history, reply status | Commission structure and margin figures |
| Content or creative | Posted videos, briefs, product assets | Creator contact details and negotiation history |
That table is deliberately conservative on the operator row. Giving a store operator visibility into a sibling store is the most common mistake. It feels generous, and it recreates the merged-list problem one level down.
Why draw the lines this precisely? Not because of trust. It is because a screen showing four things instead of forty is a screen someone actually reads. Access design and attention design turn out to be the same problem at this team size.
Where DAMI puts the boundary
DAMI runs sub accounts under a main account. Each sub account is scoped to the stores and the work it is responsible for. The point is not that the setting exists. It is what becomes visible once it does.
The operator opens the workspace and sees their store’s creators, their invitations, their samples, their numbers. No filter step. That single change removes the most expensive habit in a multi-store team, which is re-deriving context at the start of every session.
But above that, the team overview answers the question the owner actually has. That question is not “what is the total.” It is “which store is behind this week.” Because every figure arrives already attributed to a store and a person, the comparison is available without anyone assembling it.
And the assignment side matters as much as the visibility side. When creators are assigned to a person inside DAMI, the invite goes out under that person’s scope. So the record shows who owns the relationship, not which shared login was used. That is what turns the September note into something the November search can find.
There is a second effect that shows up after a month. Outreach specialists work faster when their screen has only their list on it. The improvement is not subtle. Most reported gains from scoped access come from this, not from any feature.
One honest limit. A TikTok Shop sub account organizes responsibility. It does not create it. If two people are both told they own the same store, the system will faithfully show both of them everything, and the confusion survives. A boundary only helps when someone decided where it goes.
The second limit is that narrow scopes cost coordination. A creator who should move from one store to another needs someone with wider access to move them. In a four-person team that conversation happens in the same room anyway. So scoping is worth it for stores that are genuinely separate, and unnecessary overhead for a team really running one store with three job titles.
For teams whose stores genuinely share customers, three stores pitching the same creator is the failure this setting prevents. And one shared creator pool across stores is the model that makes sharing work instead of colliding.
Where the main account, the sub accounts and the per-store numbers are set up from one place, the DAMI workspace is where the boundary is drawn.
FAQ
How many TikTok Shop sub accounts does a small team need?
One per person who logs in, not one per role. Shared logins are the problem being solved, so recreating them one level down defeats the exercise. Three people running three stores is three sub accounts, even if two of them do similar work.
Can a sub account see another store’s numbers?
It should not, and the default should be no. Cross-store visibility is the specific leak that produces duplicate invitations and merged averages. Both are harder to unwind than to prevent. If someone genuinely needs a cross-store view, widen the scope deliberately. Do not skip the setting.
Does scoping slow the team down?
Less than the alternative. The coordination cost is one conversation when a creator moves between stores. The cost of not scoping is every person re-reading every record to work out what is theirs, every week, forever. A tiktok shop sub account is the cheaper of the two arrangements once the team passes three people.
