The device management model built around centralized MDM and remote troubleshooting works well for the vast majority of device issues. An alert fires, the IT or operations team logs into Moki’s dashboard, diagnoses the problem remotely, pushes a fix or initiates a reboot, and the device is back online in minutes.
But there is a category of device issues that remote management cannot resolve: a device that has been physically knocked off its mount, a power cable that has been unplugged, a screen that is visibly cracked, or a device that is stuck in a state where it needs to be manually restarted before remote access can be re-established. These situations require someone at the location to take a physical action.
In most multi-location businesses, the people at those locations are not IT technicians. They are store managers, shift supervisors, front desk staff, or warehouse leads. Their job is not device management, and they should not be expected to perform technical troubleshooting. But they can be trained to handle a small, well-defined set of physical interventions that dramatically reduce the time between a device problem being identified and it being resolved.
Building that training program, and keeping it simple enough that it actually gets used, is the focus of this guide.
Define What Field Staff Should and Should Not Do
The first principle of any non-technical device support training program is a clear boundary between what field staff are expected to handle and what they should always escalate to the IT or operations team.
Field staff should be trained to handle:
- Checking whether a device is plugged in and powered on
- Performing a physical power cycle by holding the power button, following the device-specific restart procedure
- Checking whether the device is connected to the correct Wi-Fi network using a simple visual indicator
- Reporting the device’s asset tag or name to IT when logging a support request
- Placing a device in a defined out-of-service state so customers do not interact with a malfunctioning device while a fix is in progress
- Completing a physical device swap when a replacement has been shipped, following a documented procedure
Field staff should always escalate rather than attempt to resolve:
- Any issue involving the device’s software settings or configuration
- Any situation where the device is displaying an unexpected screen or unfamiliar interface
- Any suspected tampering, physical damage beyond superficial scratches, or signs that a device has been accessed in an unauthorized way
- Any payment-related device issue without following the specific incident procedure defined by the payment compliance policy
Writing these boundaries down and including them in the training material prevents scope creep, where well-intentioned staff attempt fixes that make problems worse or introduce security risk.
Create a Tiered Troubleshooting Guide
The most effective training tool for non-technical field staff is a simple, visual troubleshooting guide organized by symptom. Staff should not need to understand how the device works. They should be able to match what they see to a step in the guide and follow it.
A practical tiered guide for most kiosk and POS deployments looks like this:
Tier 1: Things staff check first without touching the device
- Is the screen on? If not, is the power cable connected?
- Is the device displaying the correct app, or is something unexpected on screen?
- Are other devices at this location having the same issue, or is it isolated to this one?
If the screen is off and the power cable is disconnected, staff reconnect it and wait two minutes. If the device does not come back on, they escalate. If other devices at the same location are all having issues simultaneously, they escalate immediately as this suggests a network or power issue rather than a device problem.
Tier 2: Physical restart
If the device is powered on but frozen or unresponsive and IT has confirmed remotely that a physical restart is needed, staff follow the device-specific restart procedure documented in the training guide. This should be written as a numbered step list with photos specific to the exact hardware model deployed at their location.
Tier 3: Device swap
If IT confirms that a replacement device has been shipped and the swap procedure has been authorized, staff follow the documented swap checklist. This covers powering down the old device, noting its asset tag, completing the physical swap, powering on the new device, confirming it displays the correct app, and notifying IT that the swap is complete.
Each tier should end with a clear escalation instruction so staff know exactly when to stop and call for help rather than continuing to troubleshoot on their own.
Make the Guide Accessible at the Point of Need
A training guide that lives in a shared drive folder that staff have to search for is not useful at the moment a device goes down. The guide needs to be accessible instantly at the location where devices are deployed.
Practical formats that work in field environments include:
- A laminated quick reference card posted in the back-of-house area near the device management station or IT equipment cabinet
- A QR code posted near each device that links to the digital version of the troubleshooting guide
- A pinned message in the location’s group chat with the IT or operations team that links directly to the guide
- A brief video walkthrough of the physical restart procedure for each device type, saved to the location’s shared drive or intranet
For organizations using Moki’s platform with real-time alerting, it also helps to give managers visibility into which devices in their location are showing alerts through a simple status summary, so they are aware of potential issues rather than only discovering them when a customer reports a problem.
Train for the Specific Hardware at Each Location
Device restart procedures, power connection layouts, and physical swap steps differ between hardware models. Training that covers generic concepts without addressing the specific devices at each location creates confusion at the moment of need.
For each hardware type deployed in your fleet, create a location-specific version of the troubleshooting guide that includes:
- A photo of the specific device model with the power button, cable connections, and reset points labeled
- The exact restart procedure for that model, including how long to hold the power button and what the restart sequence looks like
- The specific Wi-Fi indicator and what a connected versus disconnected state looks like on that device
- The asset tag location so staff can report it accurately when logging a support request
If your fleet includes iOS tablets, Android devices, and BrightSign players, each needs its own location-specific guide. Do not combine them into a single document that requires staff to identify which section applies to their device under pressure.
Build the Support Request Process Into the Training
One of the most operationally valuable things field staff training can accomplish is ensuring that support requests include the information IT needs to resolve issues quickly. A support request that says “the kiosk is broken” requires a follow-up conversation before troubleshooting can begin. A support request that says “kiosk CHI-KIOSK-AND-02 has been offline since approximately 9:15 AM, the power cable is connected, a physical restart did not restore connectivity, and no other devices at this location are affected” allows remote troubleshooting to begin immediately.
Train field staff to include the following in every device support request:
- The device name or asset tag
- The specific symptom they are observing
- When the issue started or when they first noticed it
- What they have already tried, following the Tier 1 and Tier 2 steps
- Whether other devices at the location are affected
Many organizations build a simple support request template, either as a form in their ticketing system or as a structured message format in their communication tool, that staff fill out rather than writing free-form. The template ensures the right information is captured every time without requiring staff to remember what IT needs.
Refresh Training When Hardware or Procedures Change
Field staff training on device support is not a one-time event. It needs to be refreshed when hardware changes through a fleet refresh, when new device types are added to the deployment, when the restart or swap procedure changes, or when the support escalation path changes.
Build a simple version control process for the training materials: date each version, note what changed, and have a defined method for distributing updates to all locations. A laminated quick reference card that has been superseded by a hardware refresh but is still posted at the location is worse than no guide at all because it creates confusion.
Moki’s support resources include platform-specific guidance that can inform the technical sections of field staff training materials. Schedule a Moki demo to see how the platform’s alert and remote management capabilities complement a well-trained field support model, or start a free trial to begin building the operational infrastructure that makes both remote and on-site device support more effective.