Phone Automation for Bulk E-commerce Listing Across Devices

Why One Phone Is the Wrong Unit of Work

If you list products for a living, the listing task itself is rarely the hard part. You already know how to fill in a title and a price. The difficulty is that a catalog has hundreds of items, and a single phone turns that into hours of tapping that cannot be parallelised.

So teams add phones. Then a new problem appears: the phones drift out of sync. One is logged out, one has a stale app version, one is sitting on a confirmation dialog somebody left open. You end up walking between devices, unsure which one you already handled.

Bulk e-commerce listing fixes this by treating the routine as a template and the phones as a fleet. One description, many devices, one place to check the outcome.

Keep the scope in mind too. Bulk e-commerce listing here means your own products: publishing new SKUs, refreshing prices and descriptions, and keeping several phones working the same catalog instead of one. What makes the setup worth the effort is that it removes duplication, not judgement. You still decide what is listed, at what price, with which photos. The fleet only handles the repetition.

Onboarding a Fleet, One Device at a Time

Nothing about batch work is special until onboarding is done properly. Do it in order.

1. Install the workstation on the computer that will stay on, following the installation selection page. It runs locally, with no server required.
2. Connect each phone by USB or wireless, depending on the platform, and confirm it appears in the device list.
3. Scan and onboard it so the workstation can use it.
4. Set an alias that says what the device is for, such as shop-a-01, rather than leaving a serial number.
5. Assign a group, which is the step most people skip and later regret. The devices guide covers scanning, aliasing and grouping in detail.

Device stage	What it unlocks
Connected but not scanned	Visible only, not usable in tasks
Scanned and onboarded	Can be selected in the conversation entry
Aliased	You can tell devices apart in a list of ten
Grouped	Can receive a batch dispatch as part of a set
Offline	Visible in the list, still not runnable

Why Grouping Is the Whole Game

A group is the unit you dispatch to. Without groups, every batch task means manually ticking phones in a list, and a single mistake sends a production listing to the wrong device.

Name groups around the work, not the hardware. Something like shop-a-android, shop-b-ios, or test-run is instantly readable. If you also drive phones from an AI assistant over MCP, the query tools can return your devices and groups, so list_devices_by_groups answers “what is in the shop-a group right now” without opening the app. Note that MCP is read-only for device and workflow information: scanning, dispatching and executing happen inside iEasyRun, in the conversation or workflow entry.

The _ungrouped bucket is where new devices land by default. Treat it as a staging area, not a place to run from.

Offline Devices Cannot Run

This is the single most common reason a batch task underdelivers. An offline device can be seen but not run. It will appear in the list, and the task simply will not execute on it.

The practical consequences:

• A dispatch to eight phones may complete on six, and the other two are not failures of the workflow, they are devices that were not reachable.
• A phone that drops mid-run leaves a partly finished listing, which is why execution history is worth reading per device rather than per batch.
• Before blaming the workflow, confirm the device shows as online.

Make a habit of checking device status before a large dispatch. It is faster than diagnosing a phantom bug afterwards.

Building the Listing Routine Once

With devices ready, build the work. Use the conversation entry to describe the listing in plain words the first time, choosing an online phone you can see. If the requirement is clear, the direct conversation mode runs it. If the steps are vague, the AI refining mode talks them through with you before anything executes.

Then save it in the workflow library. The canvas gives you a visual layout to arrange and validate steps, and AI workflow collaboration can generate or modify steps when the catalog changes. Where a button is awkward to match by text, add an image template so the step can find it on screen.

Dispatch method	Use it when
Conversation entry	One-off listing, or exploring a new routine
Workflow on a group	The routine is stable and repeats across phones
Scheduled task	The work should run at a fixed time without you
Test run on a single phone	Before sending anything to a whole group

Dispatching, Tracking Progress, and Getting Started

Dispatch the saved workflow to the group you prepared. From there, the question is not “did it work” but “which device did not”.

That answer lives in execution history. For each run you can see the result and any error. Read it per device: one phone may have finished cleanly while another stopped on a category picker, which usually means a screen element changed and an image template needs recapturing.

When repeated work should happen at a set time, add a scheduled task. Scheduling is local, so the computer has to stay on, and each target phone has to be online, or able to reconnect when the time arrives. If you retype the same task description often, store it once as a prompt.

Onboard one phone, build one listing workflow, and dispatch it to a group of one. When that run is clean, alias and group your remaining devices and send the same routine to all of them. Then read execution history and fix whatever hesitated.

iEasyRun is free phone automation software for Android, iOS and HarmonyOS that runs locally on your own computer, with no server and no feature paywall. Download it, onboard a couple of devices, and see how far one listing routine can travel.