FARMHand off phone farm operations without losing work
Give another operator the correct account, approved asset, task state and recovery path, with a complete example of a shift handoff in PhoneFarm.
A useful handoff lets the next operator continue without asking the previous person to reconstruct the work. “The videos are in the folder” is incomplete: the publisher still needs to know which version is approved, which account should receive it, whether anyone has already started and what counts as completion.
In a phone farm, handoff quality becomes a capacity constraint. More phones create more concurrent work, but every uncertain task can consume time across two shifts. A small amount of structure prevents duplicate publication, wrong-account actions and repeated diagnosis.
Divide creative decisions from execution
The same person can write, approve and publish early in a business. When those responsibilities split, make the boundary explicit.
| Responsibility | Decides or delivers | Does not automatically authorize |
|---|---|---|
| Campaign owner | Audience, offer, target accounts and business objective | Publishing an unreviewed asset |
| Creative producer | Script, media, caption and requested variations | Changing the campaign claim |
| Reviewer | Approval of a specific version and destination | Reusing that approval for a later revision |
| Publisher | Correct-account execution and result verification | Rewriting the offer during upload |
| Operations owner | Phone access, task coordination and exceptions | Replacing the account owner's recovery authority |
These are team responsibilities, not PhoneFarm permission settings. Use the actual access controls available to your team. The point is to remove ambiguous decisions from a time-sensitive publishing task, while still allowing creative improvements through a review process.
Package the work around one account-specific task
A publication packet should contain enough information to execute one defined action:
- Campaign and task reference, such as CAM-DESK-01 / PUB-NL-014.
- Account ID, platform and current handle.
- Phone reference and where to open it in PhoneFarm.
- Approved asset version, caption and any platform-specific settings.
- Approval owner and timestamp.
- Intended publication window with a named timezone.
- Current state, last action and final-result location.
- Exception owner and the conditions that require escalation.
Use a link to the asset and approval record instead of copying different files into several chat threads. If the asset changes, make a new version and update the packet. A publisher should not have to choose between two files both called “final.”
The creative brief explains why the piece exists; the publication packet explains exactly what the operator is authorized to do with it.
Use states that describe what actually happened
A practical shared queue can use these states:
| State | Meaning | Next step |
|---|---|---|
| Preparing | Inputs or review are incomplete | Producer or reviewer finishes them |
| Ready | Approved inputs and a usable destination are identified | Publisher may begin |
| In progress | An operator has started the task | Other operators leave it alone |
| Outcome uncertain | An attempt occurred, but publication is not confirmed | Reconcile before another attempt |
| Published | The intended post and destination are verified | Record result and measurement time |
| Blocked | A named condition prevents progress | Assigned owner resolves it |
These are suggested operating states alongside the product's own task statuses. A queued or completed automation attempt should be reconciled with the outcome your workflow requires. In particular, an uncertain task must not silently return to “Ready,” where a new operator could publish it again.
A complete shift-handoff example
Northline Desk has three tasks when Lee ends a shift and Sam takes over. All names and events in this example are fictional.
| Task | Account and phone | Current state | Handoff instruction |
|---|---|---|---|
| PUB-NL-014 | ACC-NL-01 / DEV-NL-01 | Published | Post link verified; collect the planned observation tomorrow |
| PUB-NL-015 | ACC-NL-02 / DEV-NL-02 | Outcome uncertain | Upload was attempted; inspect the profile before any retry |
| PUB-NL-016 | ACC-NL-03 / DEV-NL-03 | Blocked by approval | Asset v2 exists; Maya has not approved the revised price caption |
Sam's first action is not “publish the remaining two.” They open the assigned phone for PUB-NL-015, confirm ACC-NL-02 and inspect the app for the attempted result. If the correct post is visible, Sam records its link and closes the task. If the result remains unclear, Sam preserves the uncertainty and follows the escalation route.
For PUB-NL-016, Sam contacts Maya through the normal approval channel. Finding the file in Videos does not approve its price claim. Once Maya approves the exact version and caption, Sam updates the task and proceeds.
This example separates an operational exception from an editorial dependency. They require different owners and different next actions.
Walk through PhoneFarm in the order the task needs
Before taking over, open Phones, locate the assigned environment and inspect the actual account through live control. Use Videos to locate the intended supported asset where your workflow uses the library. Compare the asset version with the approval packet.
For tasks using Agent or Skills, review the available task/activity information and the last observed result. Avoid submitting an overlapping action while another operator's work is still in progress. Use the product's available controls rather than assuming every requested action supports unattended scheduling.
At the end, return an observable result to the shared queue: the post link, the precise blocking condition or the unresolved question. The dashboard and queue serve different purposes; the dashboard operates the phone, while the queue coordinates the people responsible for the work.
State times so another timezone can act correctly
“Post at 9” is not a usable instruction for a distributed team. Write the date and named timezone, and distinguish the planned window from the actual publication time. A named zone such as America/Los_Angeles accounts for seasonal clock changes; a bare “PST” can be misused for dates when daylight time applies.
For example, September 21, 2026 at 09:00 in Los Angeles is 17:00 in London and 16:00 UTC. That conversion applies to that date, not every week of the year. Let your calendar or timezone-aware tool convert the next date rather than copying a permanent offset.
Assign responsibility for missed windows. Some content can publish later; a time-limited promotion may need fresh approval. The operator should know which case applies before a delay occurs.
Train with a representative task and an exception
Have the incoming operator complete one normal task under observation, then explain what they would do with an account mismatch or uncertain publication. They should be able to locate the correct phone, identify the visible profile, find the approved asset and return the result.
Teach decision boundaries as well as button sequences. An app layout can change; “confirm the account before publishing” remains useful. A checklist that only records clicks may fail as soon as a prompt appears in a different position.
Give creative contributors room to propose improvements, but route material changes through review. The team needs repeatable execution and useful creative judgment, not a process that rewards publishing the wrong version quickly.
Improve handoffs from the exceptions they reveal
Review repeated questions: missing timezone, unclear account mapping, unavailable recovery owner, changed captions or tasks with no final link. Fix the packet field or ownership gap that caused the question.
At fleet scale, track the age of unresolved work and how often tasks cross a shift without an accepted next owner. A queue of old uncertain publications is an operating problem even if most phones are online. Use the weekly review for work outcomes and the monthly audit for persistent ownership or access gaps.