A friend in ecommerce went from three phones to twenty-three in about half a year.
The first fifteen were manageable, even with the occasional mix-up over which phone was which shop. Around twenty it started to slip. One shop stopped receiving its tasks for three days and he only noticed on the fourth. Two more were dropping out repeatedly because of USB port problems, and each time he assumed it was the flow and spent a fortnight checking the wrong thing.
We went back and rebuilt the device layer together. The changes were small, just naming, grouping and reading Execution History, but the whole situation felt different afterwards.
What changes between three phones and twenty
Not the tapping.
With three, you tap three times. With twenty, you tap twenty times. Patience covers that gap.
What actually changes is that your memory stops being enough. With three you know what each phone does, which shop it serves, and which cable is loose. With twenty, that all blurs together.
So the goal of device management is not to operate faster. It is to let rules replace memory. Once the rules exist, you do not need to hold any device detail in your head. One look tells you.
Names matter more than numbers
This is the most underrated piece.
A newly scanned device gets a random identifier, a string of letters and digits. Looking at it tells you nothing. When you want to dispatch a task you have to go and check which shop it belongs to. Once or twice is fine. Ten times a day is annoying.
Filling in an alias takes seconds. Use the words you already use: ShopA-1, ShopA-2, ShopB-3 for ecommerce, account names for content. The test is simple. Does the name alone tell you what this device is for?
Another habit I have seen work well is naming by purchase batch. Ten units bought together become Batch3-01 through Batch3-10. When a whole batch develops the same fault, you can tell immediately whether it is a batch issue or an individual one.
Grouping that actually pays off
Grouping has exactly one purpose: letting a single action cover a set of devices.
So group along the dimension you dispatch on. If you run by shop, group by shop. By platform, group by platform. By content type, group by content type.
Do not group by device model. The model has nothing to do with the tasks you run, and you will find that group never gets used.
A workable layout uses two levels. The first by business, such as Shop A and Shop B. The second, if needed, by content direction, such as Shop A short video and Shop A articles. Two levels are generally enough.
How many devices per dispatch
That depends on how heavy the task is.
Simple tasks, such as opening an app to check a value or taking a screenshot, can go to everything at once. They do not consume much bandwidth or hold a device for long.
Heavy tasks should be batched, such as large uploads or a flow with a dozen steps. My experience is five to ten per batch, for two reasons. Running them together competes for bandwidth and machine resources, so total time is not necessarily shorter. And batching keeps the failure scope small, so you immediately know which batch and which devices went wrong.
One thing easy to overlook is USB power. With many devices and long cables, insufficient power produces dropouts with no obvious cause. Past a dozen devices, use a USB hub with its own power supply. That single change removes a lot of unexplained failures. The install selection page covers connection details.
What to do with the devices that fail
With many devices, failures are normal. The handling is what matters.
My rule is to look at proportion. Twenty devices with one failure means note it, let the rest finish, and deal with that device afterwards. More than a third failing means stop and investigate, because that pattern usually points at the flow or the network rather than any one device.
The other habit is not to diagnose from scratch each time. After a run, skim Execution History, which shows the target device, status and error message for each task. Over a period you will see failures concentrating on two or three devices. Checking those once properly is far more efficient than re-diagnosing every time.
Ten minutes a day
Once the rules exist, daily maintenance is light.
My own routine is three things, ten minutes total. Open the Devices page and check for anything offline. Skim Execution History for repeat failures. Dispatch the day tasks.
If you have many devices and would rather not keep watching, use Schedule to set a daily sweep that scans device status at a fixed time and surfaces anything offline. You do not have to sit there to know which devices need attention.
Back to my ecommerce friend. He aliased everything, grouped by shop, and now starts each day by scanning the device page, skimming Execution History, then dispatching by group. His summary: the problem is no longer remembering anything. It is that nobody goes and plugs the cable back in when a device drops. Which is a different problem entirely.
With two or three phones, none of this applies yet. But if you are moving from a handful towards a dozen, set the names and groups up now. Retrofitting them at twenty costs you a few very confusing days.
Frequently asked questions
- What actually changes between three phones and twenty?
- Not the volume of tapping. With three you can rely on memory for what each one does and which one has a loose cable. Past twenty, memory fails and you need rules that do not depend on it: how devices are named, how they are grouped, how tasks are dispatched, how failures are traced. That is the real difference.
- What makes a good device alias?
- Use the words you already use day to day, not a device identifier. An ecommerce setup might use ShopA-1 and ShopB-3. A content setup might use account names. The test is whether the name alone tells you what that device does. The only cost is a few seconds when filling it in, and it pays back on every dispatch afterwards.
- What should devices be grouped by?
- By business or account, such as Shop A and Shop B, or short video and article. Do not group by device model, because the model has nothing to do with the tasks you run. The entire value of grouping is covering a set of devices in one action, and a wrong grouping throws that away.
- How many devices should one dispatch cover?
- It depends on the weight of the task and your network. Light tasks, such as opening an app to check a value or take a screenshot, can go to everything at once. Heavy tasks, such as uploading large files or running long flows, work better in batches of five to ten. Batching also keeps the failure scope small.
- If a few devices fail, should I stop and fix them immediately?
- Look at the proportion first. One failure out of twenty can be noted and handled later while the rest finish. If more than a third fail, stop and investigate, because that usually points at the flow or the network rather than individual devices. The signal is whether failures are concentrated.
- How do I find which device keeps causing trouble?
- Read Execution History rather than trusting impressions. It shows the target device, status and error message for every task. Over a period the failures usually concentrate on two or three devices. Checking those once thoroughly beats emergency diagnosis every time.
- Do many devices strain the computer?
- The workstation itself is not demanding. The pressure comes from how many tasks run at once and from USB power delivery. With many ports and long cables, insufficient power causes frequent dropouts. For larger setups use a USB hub with its own power supply, which removes a whole category of mystery offline problems.
- How much time does device management take daily?
- Once rules are in place, roughly ten minutes: check the device page for anything offline, skim Execution History for repeat failures, and dispatch the day tasks. The time is really spent in the first day or two setting the rules up. After that it is maintenance.
Get the device layer in order first
Scan them in, name them, group them, then dispatch by group
Software is completely free and runs on your own computer.