Fewer 'My Device Isn't Working' Tickets: How to Set Up an On-Device Check-Up for Frontline Workers

"My device isn't working." If you run a helpdesk for frontline Android fleets, you see this ticket every week. It comes from a rugged scanner in a warehouse, a kiosk tablet at a store entrance, or a PICO headset in a training room in another city. It has no screenshot or error message. Often the worker who sent it has already gone back to their shift.

You can't visit every site. What you can do is give workers a standard first step to take before they contact IT. That step should fix the simple problems on the spot and send you a clear result for the rest.

This tutorial shows you how to set up that first step with the Check-up screen in the Nomid Settings app. You'll learn what the check-up tests, how to write a one-card guide for workers, what you'll see in the portal afterwards, when to escalate, and how to measure the change using your own ticket data.

Why "My Device Isn't Working" Tickets Keep Arriving

On frontline fleets, most vague tickets come from a small set of causes. These are the ones that come up again and again:

• No network, or a firewall blocking the servers. The device has Wi-Fi but can't reach the management servers. The site network may block the ports or hostnames the device needs, or a captive portal may be holding the connection.
• An app that never finished installing. The policy assigns an app, but the download stalled, the file was corrupted in transit, or the install failed. To the worker, "the app is missing" looks the same as "the device is broken."
• A permission switched off. Someone turned off usage access, accessibility or another permission the management agent needs. A device reset can also leave a permission unset.
• Outdated Play Store or Google Play Services. Managed Google Play installs and many app features depend on these. If they're old or not working, installs and updates can stop quietly.
• Location turned off or locked. Location-dependent apps fail. The worker may also not know that the policy locks the location setting.

Vague tickets cost both sides time. The worker waits while IT asks basic questions: Is it on Wi-Fi? What app? What does the screen say? IT then spends the first part of every ticket collecting facts that the device could have reported by itself. A standard check-up moves that fact-gathering to the start of the process and makes it the same every time.

What the On-Device Check-Up Tests and What Each Result Means

The worker runs the check-up from the Check-up screen in the Nomid Settings app on the managed device. The rows are grouped into three sections: Sync, Advanced permissions and System components. Each failed row offers an action, such as Resolve, Enable, Update or Details. The worker can run the check-up again after taking that action. When everything is set, it ends with "Checkup completed".

• Every Library (Nomid Store) app the policy assigns, with per-app status What a problem usually means: An app is missing or stuck. See the status list below. What the worker does: Wait if it's downloading or installing. Otherwise press the suggested action and run the check-up again.
• Reachability of the Nomid API (enrollment, policies, status reports) What a problem usually means: The device can't get policy updates or report its status. This usually means a network or firewall problem. What the worker does: Check Wi-Fi, then run the check-up again. If it still fails, report it to IT.
• Reachability of the Nomid Remote servers (ID server, relay, NAT test), with response time in ms per server What a problem usually means: Remote support sessions may not connect. High response times point to a slow or congested path. What the worker does: Report it to IT. This is usually a network team fix.
• Play Store version, Google Play Services version, and whether Play Services is working What a problem usually means: Outdated or broken components can block app installs and updates. What the worker does: Press Update and follow the step-by-step instructions.
• Google location services What a problem usually means: Location is off. If the policy locks location settings, the check-up says so. What the worker does: Enable location. If it's locked, ask the admin.
• Agent permissions: usage access, accessibility, modify system settings, Wi-Fi permission What a problem usually means: The agent can't do part of its job, such as reporting usage or managing Wi-Fi. What the worker does: Press Resolve and follow the instructions.
• Wallpaper and sync token state What a problem usually means: The device's configuration state is out of step with its policy. What the worker does: Use Details. If the row still fails, report it to IT.

The per-app status in the Sync section tells you a lot. Here is what each status means in plain words:

• Waiting to download / Downloading (with progress) / Downloaded, waiting to install / Installing: The install is in progress. The worker should be patient.
• Installed: The app is fine.
• Download failed: The file didn't arrive. This usually means a network problem.
• Corrupted file (SHA-256 mismatch): The downloaded file doesn't match the expected checksum. It got damaged in transit or was altered.
• Install failed: The file arrived, but Android refused to install it.
• Recorded as installed but not found on the device: The records say the app is there, but it isn't. Someone may have removed it, or the device was reset.

Note: The check-up surfaces problems and guides the worker to fix the common ones. It does not fix every issue automatically. Some rows, such as blocked servers or a locked location setting, need action from IT or the network team. The point is that the ticket arrives with that information already attached.

Roll Out the Check-Up: Step by Step

Step 1: Turn on the Check-up button in your policies

Start the baseline from Step 7 now. It needs at least four weeks of ticket data from before the cards go out. You decide, per policy, whether the Check-up button appears in the Nomid Settings app. Open each policy that covers frontline devices and enable the Check-up button.

1. List the policies that cover devices your helpdesk supports, such as scanner policies, kiosk policies and training-headset policies.
2. Enable the Check-up button in each of those policies.
3. Save the policies and let the devices sync.

Expected result: On devices assigned to those policies, the Nomid Settings app shows a Check-up button.

Warning: On kiosk devices, confirm that workers can actually reach the Nomid Settings app from the kiosk setup. A button that workers can't open won't reduce any tickets. Test this on a real kiosk device before you print cards.

Step 2: Pilot it on one device of each type

Pick one device of each type: a rugged scanner, a handheld, a kiosk tablet, and a PICO headset if you support them. Run the check-up on each one and write down what you see.

1. Run the check-up on a healthy device and confirm it ends with "Checkup completed".
2. Create a known fault on purpose. For example, turn off location, or connect to a guest Wi-Fi network that blocks outbound traffic. Then run the check-up again.
3. Note which rows appear on each device type. Some rows depend on what is installed on the device. For example, Play Store rows depend on Google Play being present. Adjust your worker guide to match.

Expected result: You have a short list showing which rows appear per device type and what each fault looks like on screen.

Step 3: Write a one-card guide for workers

Workers won't read a manual. Give them one card with four steps: run the check-up, press the suggested action, run it again, and contact IT with the result. Keep the card short enough to tape to a charging station or print on a lanyard.

Here is a sample card you can adapt:

DEVICE NOT WORKING? DO THIS FIRST.
1. Open the Settings app (Nomid) and tap Check-up.
2. If a row is red, tap the button next to it (Resolve, Enable, Update or Details) and follow the steps.
3. Run Check-up again.
4. Still not "Checkup completed"? Contact IT and tell us:
- your device name
- which row is still red
- "I ran the check-up"
Location locked? That's set by IT. Just tell us.
App "downloading"? Stay on Wi-Fi and wait a few minutes.

Expected result: You have a printable card that any worker can follow without training, written in the language(s) your sites use.

Note: The words "I ran the check-up" matter. They tell the helpdesk agent to look at the device's command timeline before asking any questions.

Step 4: Update your helpdesk intake

Change your ticket form, chat script or phone script so the first question is "Did you run the check-up?" If the answer is no, the agent walks the worker through the card before triaging anything else.

Expected result: Every new device ticket records whether a check-up was run. You'll need this field for measurement in Step 7.

Step 5: Read the result in the portal before you act

The check-up result is sent to Nomid. In the portal, the device's asset page shows when the last manual check-up ran. Every manual check-up is also recorded in the device's command timeline. Before you open a remote session, you can confirm that the worker ran it and see what it found.

Review these items, in this order:

1. Last check-up time on the asset page. Confirm it matches when the worker says they ran it.
2. The check-up entry in the command timeline. Note which rows failed.
3. Device status: last-seen and contact status, battery, and the security posture view (encryption, ADB, unknown sources, developer options).

If the check-up result never reached the portal, that tells you something too. The device probably can't reach the Nomid API at all. Treat it as a network problem first.

When the server rows fail: If the Nomid API or Nomid Remote rows fail, or show high response times, the cause is usually the site network rather than the device. Ask the site's network team to allow the servers and ports listed in the check-up. Get the current hostnames and ports from Nomid's documentation or support so the request is exact. For Google Play and Android Enterprise traffic, Google publishes its own Android Enterprise network requirements. Include those in the same request.

Warning: Don't ask network teams to "open everything for the scanners." A specific allow-list of hostnames and ports is easier to approve, easier to audit, and less likely to be rolled back at the next firewall review.

Expected result: For each escalated ticket, you know which part failed (app, network, permission, system component or location) before you contact the worker again.

Step 6: Escalate on purpose

Once the check-up has run and you've reviewed the result, choose one of three paths:

• Remote support session. Use this when the check-up passes but the worker still reports a problem, or when a failure needs hands-on investigation. Nomid Remote is a separate step from the check-up, and remote access is not included on the free plan. Screenshots and a remote reboot may answer the question before you need a full session.
• Reassign the policy. Use this when the problem is configuration. For example, a device in the wrong policy group is missing apps, or a location lock doesn't fit the worker's role. Move the device to the correct policy, let it sync, and ask the worker to run the check-up again.
• Swap the device. Use this when installs keep failing on one unit but not on others with the same policy, or when there are signs of hardware trouble. Record the swap in the device's allocation fields so its history stays traceable.

Expected result: Each escalation has a documented reason that is tied to a specific check-up finding.

Step 7: Measure it without invented numbers

You'll need to justify the rollout to directors. Use your own data, not industry averages. Track three metrics:

1. Device tickets per 100 devices, per month: (device tickets ÷ active managed devices) × 100. Measuring per 100 devices keeps the number comparable as the fleet grows or shrinks.
2. Share of tickets that arrive with a check-up already run: tickets marked "check-up run" ÷ all device tickets. This shows whether workers are using the card.
3. Time to resolve: median hours from ticket opened to ticket closed. Report it separately for tickets with a check-up and tickets without one.

Collect a baseline for at least four weeks before you roll out the cards. Then compare the same period after rollout. Report the results as you find them, including any metric that didn't move.

Expected result: You have a before-and-after report built only from your helpdesk data and the check-up records in the portal.

Copy-Ready Rollout Checklist

• ☐ Before rollout, record a four-week baseline: tickets per 100 devices, check-up share, median time to resolve
• ☐ List every policy that covers frontline devices
• ☐ Enable the Check-up button in each of those policies
• ☐ Confirm workers can reach the Nomid Settings app on kiosk devices
• ☐ Pilot on one scanner, handheld, kiosk tablet and PICO headset (if used)
• ☐ Create a known fault and confirm the check-up flags it
• ☐ Note which rows appear per device type
• ☐ Write and translate the one-card guide
• ☐ Print cards for charging stations and lanyards
• ☐ Add "Did you run the check-up?" to helpdesk intake
• ☐ Train agents to check the asset page and command timeline first
• ☐ Send the network team the server and port allow-list, plus Google's Android Enterprise network requirements
• ☐ Review the metrics after four weeks

Troubleshooting FAQ

The worker says there's no Check-up button.

Check the device's assigned policy. The button only appears when the policy enables it. If you recently changed the policy, confirm the device has synced by checking its last-seen time on the asset page.

An app has been stuck on "Downloading" for a long time.

Check whether the Nomid API row passes and look at the network the device is on. Guest Wi-Fi often throttles or blocks large downloads. Move the device to the production network and run the check-up again.

The check-up reports a corrupted file (SHA-256 mismatch).

The downloaded file doesn't match its expected checksum. Run the check-up again to trigger a fresh download. If the same app fails on several devices, check the APK you uploaded to the Nomid Store before you look at the devices.

An app is "recorded as installed but not found on the device."

The device's records and its actual state disagree. This is common after a reset or a manual removal. Run the check-up again. If the app doesn't reinstall, check that it's still assigned in the policy, or reassign the policy.

The worker can't turn on location.

If the policy locks location settings, the check-up tells the worker to ask their admin. Decide whether that worker's role needs location. If it does, move the device to a policy that allows it.

The Nomid Remote server rows fail, but everything else passes.

The device can be managed, but remote sessions may not connect. Send the network team the list of Remote servers and ports from the check-up. Use the per-server response times in your request to show where the path is slow.

Play Services shows as not working even after the worker pressed Update.

Ask the worker to follow the step-by-step instructions shown under Update, then reboot and run the check-up again. If it still fails, escalate with a remote session or a device swap.

The check-up says "Checkup completed," but the worker still has a problem.

That's useful information. The issue is likely inside a specific app or in the worker's workflow, not in device configuration. Escalate to a remote session or the app owner.

Next Steps

A shared first step won't eliminate device tickets. It does change what arrives at your helpdesk. Workers fix the simple issues themselves, and the rest reach you with a recorded result: which app is stuck, which server is unreachable, which permission is off. Start with one policy and one site, print the card, track your baseline, and expand once the numbers from your own fleet support it.

If you manage Android devices or PICO headsets with Nomid MDM, the Check-up screen is built into the Nomid Settings app, and you can turn it on per policy. You can try it on the free plan with up to 10 devices and no time limit. Remote access is not included on that plan. That's enough devices to run the pilot in Step 2 before you roll it out across your sites.