Some problems need somebody physically present. A machine that will not boot, a device to be collected from a flat, a part to be fitted. When that happens in a country where you have no staff, you are briefing a technician you have never met, often through a language you do not share.
TL;DR
- Remote hands means paying somebody local to do the physical work. It is cheap compared to shipping a device twice.
- The brief is the whole job. A technician with a vague instruction will do something reasonable and wrong.
- Write the brief as a numbered task list with expected outcomes, and have it translated once per market.
- Decide access and data questions before anybody touches the machine, not during the visit.
- Require photographic evidence at defined points. It is the only verification you have.
- Never let a third party wipe a device on your behalf without a recorded, evidenced process.
When remote hands is the right call
Three situations justify it. A device that cannot be diagnosed remotely because it will not start. A collection from somebody who has left and will not post a laptop. And a physical intervention like a part swap or a drive removal where the alternative is an international shipment.
In each case the comparison is not against doing it yourself, it is against moving the device across a border twice. A local visit costing a modest hourly rate routinely beats two international shipments plus customs plus the delay, particularly on a machine with two years of life left.
It is the wrong call for anything you can solve with remote access, and for anything where the device has no remaining value and should simply be written off and recycled locally.
The brief is the entire job
A technician arriving with a vague instruction will act reasonably on their own judgement, and their judgement is formed by the hundred other jobs they do, not by your asset register. This is how a machine gets reimaged when you wanted the drive preserved.
Write it as a numbered list of tasks, each with a stated outcome, and include explicitly what not to do. The do-not list is more important than the do list, because the default behaviours of a competent technician are exactly the ones that lose you data or void a warranty.
Have the brief translated once, properly, per market. It is one document, it is reused on every visit, and the cost of a misunderstanding is a wasted trip plus a device in an unknown state.
A worked example
A company needed a laptop collected from a departed employee in a country with no local presence. They engaged a local IT firm with a short email brief: collect the device and confirm.
The technician collected it, and being helpful, reset it to factory settings before shipping so that it would arrive ready to reissue. The drive held the only copy of several months of work that had never synced, because the machine had been offline since the person left. Nobody had told the technician not to, and nothing in the brief implied the data mattered.
The brief now runs to eleven numbered lines, including do not power on beyond the boot screen, do not reset, do not remove any component, and photograph the serial number and the screen state before and after. It is translated into three languages and reused on every visit.
What to put in the brief
Checklist:
- The exact device, by serial number and model, with a photograph if you have one.
- The address, the contact, and what to do if nobody is there.
- Numbered tasks, each with the outcome you expect to see.
- An explicit do-not list covering power-on, reset, reimaging, component removal and data handling.
- Required photographic evidence at named points, including the serial and the screen state.
- Packaging and shipping instructions, including who the shipment is addressed to and who is importer of record.
- Who to call if anything differs from the brief, with a number and the hours it is answered.
The last line prevents most improvisation. A technician who has a number to ring will ring it rather than making a judgement call, provided the number is answered in their working hours.
Access, data and the things to settle first
Decide before the visit whether the technician needs to log in at all. Usually they do not, and the safest brief is one where the device never gets past a boot screen in their hands.
Where diagnosis genuinely requires access, use a temporary local account rather than anything with credentials attached, and disable it afterwards. Never hand over a user’s credentials to a third party, and never ask a technician to perform a wipe on your behalf unless you have a documented process with evidence, because a destruction you cannot demonstrate is close to one that did not happen.
Record the engagement against the asset: who attended, when, what they did, and what evidence they returned. That record is what makes the visit auditable later.
Finding and briefing the technician
Options are a local IT services firm, a lifecycle platform that includes field support in its network, or the manufacturer’s authorised service partner if the work is warranty-related. The lifecycle platforms are usually the least administrative effort because the brief and the shipping are handled in one arrangement.
Whichever route, confirm the working language of the person attending rather than of the company you are contracting with. A firm whose account manager writes good English does not guarantee the technician on the doorstep does, and the technician is the one reading your brief.
Ask for the same named technician on repeat visits in a market where you expect several. The second visit with somebody who already understands your brief is substantially faster. Tools that answer this class of question in the requester’s language are covered in our multilingual IT support comparison.
Final thoughts
Remote hands is cheap, effective and almost entirely dependent on the quality of the brief. A technician is being asked to act on your behalf with no context about your fleet, your data or your policies, and any gap in the instruction gets filled with sensible general practice that may be exactly wrong for you.
Write the brief once as numbered tasks with an explicit do-not list, get it translated per market, require photographic evidence at named points, and give the technician a number that is answered. That document is the asset, not the visit.
Frequently asked questions
What is remote hands in an IT context?
Paying somebody local to carry out physical work on a device you cannot reach, such as collecting a laptop from a departed employee, fitting a part, or diagnosing a machine that will not start. The comparison that makes it worthwhile is not against doing the work yourself but against shipping the device across a border twice, which for a machine with remaining life frequently costs more than a local visit plus the delay it avoids. It is the wrong choice for anything solvable with remote access.
What should a remote hands brief contain?
The exact device by serial and model, the address and contact with instructions for a no-show, numbered tasks each with the outcome you expect, and an explicit list of things not to do. Include the photographic evidence you require at named points, packaging and shipping instructions naming the recipient and importer of record, and a phone number that is answered during the technician’s working hours. The do-not list matters more than the task list, because a competent technician’s default behaviours are often the ones that lose data or void cover.
Should the technician be given access to the device?
Usually not, and the safest brief is one where the machine never gets past a boot screen in their hands. Where diagnosis genuinely requires access, create a temporary local account rather than sharing any existing credentials, and disable it as soon as the work is complete. Never hand a user’s credentials to a third party, and record who attended, when and what they did against the asset so the engagement is auditable afterwards.
Can a local technician wipe a device for us?
Only within a documented process that produces evidence, because a data destruction you cannot demonstrate is close to one that did not happen. The practical risk runs the other way too, since a helpful technician may reset a machine on their own initiative to make it ready for reissue, destroying data that never synced because the device had been offline. State explicitly in the brief that no reset, reimage or factory restore is to be performed, and handle destruction yourself once the device is in your custody.
How do we handle the language gap with a local technician?
Get the brief translated once per market rather than relying on improvisation at the door, since it is a single reusable document and a misunderstanding costs you a wasted trip plus a device in an unknown state. Confirm the working language of the person actually attending rather than of the firm you contracted with, because an account manager’s fluent English says nothing about the technician on the doorstep. Where several visits are likely in one market, ask for the same named technician.
What evidence should we require from a visit?
Photographs at defined points rather than a written confirmation, because photographs are the only verification available to somebody who was not present. At minimum capture the serial number, the state of the screen before and after any work, the condition of the device and the packed shipment with its label visible. Specify these in the brief as numbered requirements, and record them against the asset alongside who attended and when.
