A friend in ecommerce went from three phones to twenty-three over about half a year. Through the first dozen or so he could still manage from memory. Around twenty, things started to slip.
At fifteen he sometimes mixed up which phone belonged to which shop, but it mostly still worked. After twenty, one shop went three days in a row without its tasks, and he only noticed on the fourth day. Two other phones had poor USB contact and dropped offline often. He treated that as a flow problem and spent two weeks looking in the wrong place.
He later rebuilt the device layer: names, groups, and execution history. The changes were small. Missed tasks, and dropouts he had read as flow failures, became less common.
What changes between three phones and twenty
Patience can still cover tapping three times or twenty. With three phones you remember what each one does, which shop it is tied to, and which charging cable is loose. After twenty, those details no longer line up.
Names, groups, and execution history have to stand in for memory. One look at the device name tells you which shop it belongs to, without having to recall it.
When a device is first added, the system assigns a random id. To send a task you have to look up which shop that id is. Ten lookups a day gets tiresome.
An alias takes a few seconds, and it should use the name you already say out loud. Ecommerce uses “Shop A-1,” “Shop A-2,” and “Shop B-3.” Content work uses the account name. The test is whether the name alone tells you what that phone does.
If you buy a batch of the same model at once, you can name them “batch 3-01” through “batch 3-10.” When that batch develops the same fault together, you can tell a batch problem from a problem on one phone.
How to group, and how many phones per dispatch
A group exists so one action covers a set of devices. Group the way you already send tasks: by shop if you run by shop, by platform if you run by platform, by content type if you run by content type.
Grouping by device model does not help. The model has nothing to do with the task you are about to run, and that group will not get used later.
Two levels are enough. The first level is the business, such as “Shop A” and “Shop B.” If you need a finer split, the second level is the content, such as “Shop A short video” and “Shop A image posts.”
How many phones to push at once depends on how heavy the task is. Opening an app to check a status, or taking a screenshot, does not use much bandwidth and does not take long, so the whole set can go at once. Uploading a large file, or running a flow of a dozen steps, means five to ten at a time. Running them all together competes for bandwidth and for the computer, and the total time is not necessarily shorter. After you split them into batches, a failure lines up with one batch and a few phones.
When there are many devices and the cables are long, short USB power makes phones drop offline, and the logs often show no cause. Past a dozen phones, use a USB hub with its own power supply. Connection options are on the installation selection page.
What to do with the phones that fail
One failure out of twenty: note it, let the rest finish, and deal with that phone afterwards. If more than a third fail, stop and look. That pattern usually comes from the flow or the network, not from one broken phone.
After the run, open execution history and read the target device, the status, and the error. Over a stretch of time, failures often cluster on two or three phones. Checking those phones once is less work than hunting for a cause every time something fails.
Once the rules are set, the daily work is about ten minutes. Open the devices page and see whether anything is offline, skim execution history for repeat failures, then send the day’s tasks.
If you would rather not sit and watch, use the schedule page for a check at a fixed time each day. The workstation scans device status and picks out the ones that are offline.
The ecommerce friend filled in the aliases and grouped the phones by shop. Before he starts, he looks at the devices page and at execution history, then dispatches by group. He said the remaining problem is that when a phone goes offline, nobody goes and plugs the cable back in.
With only two or three phones, these rules can wait. If you are moving from a few phones toward a dozen, set the names and groups up now. Filling them in once you are at twenty means a few messy days. The devices page is here.
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.