Last year a friend who sells home goods across borders was the only person on his team, with fourteen accounts spread across North America, Europe, and South-East Asia.
He described his day like this. He gets up at seven and posts for Europe and North America first, because it is evening there. At midday he posts for South-East Asia. In the evening he does another North America round. Before bed he checks whether anything was missed.
Fourteen accounts, three rounds a day, about twenty minutes a round. Those sixty minutes are manageable. What he dreaded was the hours in between, when he could not do anything else because he was waiting for a time.
I asked why he did not line up the publish times and the content in advance. He said he had tried making a list, and after the list was written he still had to go and post each one himself.
The list records what to post. Who does the posting is still open.
Time zones, and one phone per account
Compared with domestic accounts, overseas accounts add two things.
The first is the time zone. Your day does not line up with the hours when the target market is active. Eight in the evening at home is your rest time, and it is afternoon for users in Europe and North America. Midday in South-East Asia can be morning in the Middle East. Work the publish time backwards from the target market’s active hours.
The second is that the markets are spread out. A dozen domestic accounts can be pushed on one rhythm, because user habits are similar. North America, Europe, and South-East Asia differ in active hours, in what the content should be, and in the platform, so each market needs its own rhythm.
Stack those two together and scheduling becomes a question of how to lay out one timeline.
Keep one account on one phone. Logging three accounts onto one phone and rotating them has a high cost when you switch to the wrong account. A device that logs in and out of several accounts in a short window also fails to look like a normal user.
Write the alias as market plus account name, such as US-home, DE-home, and SEA-home. One look tells you which market it serves and what the content direction is.
Group by market: North America in one group, Europe in another, South-East Asia in a third.
After those three are done, the relationship between account and device is fixed. Later scheduling, dispatch, and troubleshooting do not have to map them again. How to set an alias and how to group devices is covered in the devices documentation.

Turn local time into your time
Three steps. Calculate them, and write the result down.
First, decide which market this account serves. Among fourteen accounts, which one covers North America and which one covers Europe should already be clear.
Second, look up the hours when users in that market are active. They usually fall in the local evening. The exact hour depends on the content type, and the platform’s own history is a usable reference.
Third, convert that hour into the time zone where you are. This is the step that goes wrong most often. Write the result into the table. Working it out again each time is where the mistakes come from.
Add two columns to the table:
| Account | Market | Local active hours | China time |
|---|---|---|---|
| US-home | US Eastern | 20:00 | 09:00 |
| DE-home | Central Europe | 19:00 | 01:00 |
| SEA-home | Singapore | 21:00 | 21:00 |
Nine in the evening in Singapore is also nine in the evening in China, because the zones are close. Seven in the evening in Central Europe is one in the morning in China. Schedule that row by feel and it is easy to get it wrong.
When you set up the flow, read the last column directly.
Lay a dozen accounts onto one day
Stagger inside the group first. Accounts in the same market, such as the five in North America, should not all publish at 09:00. Offset them by ten or fifteen minutes. The pattern looks less like one person operating in bulk, and when something breaks you know immediately which account it was.
Then lay the groups onto one timeline. Draw the North America, Europe, and South-East Asia windows across a single day and you will see some hours packed tight, such as five posts at nine in the morning, and some hours completely empty.
Split the packed hours further. The empty hours can hold content that depends less on hitting a particular moment.
Only after the overlay can you see which hours of the day are packed and which are empty. When you post one account at a time by hand, that axis stays invisible.
One flow per market
Once the schedule is set, configure workflows by market: one for North America, one for Europe, one for South-East Asia.
Fourteen accounts come out as three flows, one per market. Accounts in the same market share the posting actions: the same app, the same entry, the same fields. The only differences are the content and the time, and both of those are parameters.
Configuring by market keeps the maintenance smaller. When the North America interface changes, you edit one flow and the five accounts follow.
Content travels as parameters, passed in row by row from the table. One row means this account publishes this content at this time on this day. The flow only carries it out.

After the schedule is in place, the daily work left is checking.
Pick a fixed time, open execution history, and read it by device group:
- Whichever group shows failures clustered together, check that group first
- If a device keeps going offline, check the device and the cable before you touch the flow
- If one account fails every time, that is the account’s own state
Failures often show up as a group. Devices on the same hub drop together. Accounts in the same market fail together. Read them one account at a time and those patterns stay hidden.
When you change time zone, the table moves with you
When the time zone you are in changes, the whole timeline has to shift with it. A business trip and a move to another city are both this case.
Write the times into the table. Editing the table is simpler than editing the flow, and after the edit you can see at a glance how far every account has to move.
Anything that looks like a one-time decision, and in practice changes again and again, belongs in the table.
This setup fixes structure and timing: accounts mapped to devices, publish times calculated from the target market, and the flow running when the time arrives.
Content and strategy stay with you: what each market should publish, which account deserves more effort, and when an account should be stopped. Those are operating calls.
Hand the schedule over and use the time you get back on the content. One person can keep fourteen accounts going because the timetables and the mappings no longer have to be remembered.
The home-goods friend now spends an hour on the weekend updating the content table. On weekdays the table runs, and he checks execution history once in the afternoon. The publish times for fourteen accounts went from three windows he had to sit through to one timeline that runs on its own. His line was: the accounts used to set my hours, and now I set the accounts’ times.
If you are a small team managing several overseas accounts, connect the devices from the install selection page first. The first job is getting the aliases and the groups right. Everything after that is built on that mapping.
Frequently asked questions
- What makes overseas accounts harder than domestic ones?
- Two things. Time zones, because the target market active window does not line up with your day, so publish times have to be worked out backwards. And natural dispersion, because accounts differ by zone and language, so they cannot all run on one rhythm the way domestic accounts can.
- How do I calculate a publish time?
- Three steps: decide which market the account serves, find when users there are active, then convert that moment into your own time zone. What you get is the value to put into the schedule.
- How should a dozen accounts be spread across devices?
- One phone per account, aliased as market plus account name, for example US-home. Group by market: North America in one group, Europe in another. That fixes the relationship between account and device so you never re-derive it.
- How do I lay out one day across all of them?
- Group by market and stagger inside each group, then overlay the groups onto a single timeline. You will usually find some windows crammed and others empty, and that is the point of doing it.
- Why not fire every account on the same minute?
- Two reasons. It does not look like ordinary activity, and when something breaks you cannot tell whether one account is at fault or the flow itself. Offsetting by ten or fifteen minutes costs almost nothing.
- Time zone arithmetic is easy to get wrong. Is there another way?
- Write the converted time into your content table rather than estimating each time. One column holds the target market active window, another holds the corresponding time where you are, and the flow reads the second column.
- What if I travel or change city?
- The whole timeline shifts, because your own zone changed. Which is another reason to keep the times in a table: editing a table is far easier than editing flows, and it shows you at a glance how far everything needs to move.
- How do I find which account broke?
- Execution History records the target device and error for every task. Read it by device group. Whichever group shows clustered failures is the one to investigate, and that usually points straight at the device, the network or the flow.
Fix the mapping first
One account per phone, then work the times back from each market
Software is completely free and runs on your own computer.