A kiosk can look complete during a five-minute demonstration and still fail in the field. Production terminals must survive network interruptions, application errors, unexpected restarts, peripheral faults and routine updates without leaving users or support teams stranded.
The purpose of a kiosk pilot is therefore not to prove that a full-screen application can launch. It is to prove that the entire service can be deployed, observed and recovered under realistic conditions.
1. Define one user journey per terminal
Write down the exact task the kiosk must support, from the user's first touch to a confirmed outcome. Examples include checking in, printing a ticket, viewing a menu, making a payment or finding a room.
For each step, specify:
- the application or URL involved;
- the data entered or displayed;
- the expected response time;
- what the user sees when a dependency is unavailable;
- how the session ends and returns to a clean start state.
If a terminal supports several unrelated journeys, decide whether one managed application can contain them safely or whether the design is becoming a general-purpose workstation rather than a kiosk.
2. Build an application readiness matrix
FydeOS Kiosk can start a designated application or website in a controlled full-screen environment. The application remains responsible for its own availability, authentication, content and error handling.
Test the production build against:
| Condition | What to observe |
|---|---|
| First boot | The intended application starts without an administrator present |
| Application crash | The terminal returns to service through the agreed recovery path |
| Authentication expiry | The screen does not become stuck on an unusable sign-in state |
| Server error | The user receives a useful message without access to the underlying desktop |
| Offline period | Cached or fallback behaviour matches the service requirement |
| Restart | The device returns to the correct application and policy state |
Do not use a staging URL or administrator account as evidence that the production journey is ready.
3. Test every peripheral as part of the workflow
Create a matrix containing the exact display, touch controller, scanner, printer, card reader, camera, audio device and other peripherals used in production. Record firmware, connection type and driver requirements.
Test normal use and failure cases:
- disconnect and reconnect the peripheral;
- run out of paper or consumables;
- present an unreadable barcode or card;
- restart the device while a peripheral is attached;
- leave the kiosk operating for the planned service window;
- confirm that users cannot reach unintended device functions through peripheral dialogs.
Hardware support varies by model and FydeOS build, so compatibility must be confirmed on the actual production combination.
4. Complete a site-readiness survey
For every location, record the mounting method, service access, power source, cable routing, ventilation, network handover point, opening hours, local contact, physical protection and applicable accessibility requirements.
Confirm that a technician can reach serviceable components without exposing users to power, sharp edges or unsecured equipment. Photograph the approved installation and record who may open, move or disconnect the terminal.
5. Design for imperfect networks
A reliable kiosk has an explicit network failure state. Test DNS failure, loss of internet access, captive portals, proxy changes and intermittent connectivity where relevant.
Document:
- required destinations, ports and certificates;
- ownership of wired, wireless or mobile connectivity;
- whether the service can continue offline;
- how long cached data remains valid;
- how transactions are queued or abandoned;
- who receives an alert and who owns the incident.
Avoid hiding a network problem behind an endless loading screen.
6. Define the managed baseline
Use FydeOS Management Cloud to organise kiosk devices and apply the settings required by the deployment. Depending on the selected plan and configuration, the baseline may cover the allowed application or URL, auto-launch behaviour, device restrictions, power settings and system update controls.
Keep policy ownership clear. A content team may own the kiosk application, while IT owns the operating system, network and device groups. Changes should have a named approver and a rollback method.
The current FydeOS Kiosk documentation provides product-specific setup guidance.
7. Plan updates as an operational event
An update policy needs more than a preferred time of day. Decide how the organisation will:
- validate an application and peripheral set against a candidate system version;
- deploy to a canary group before the full fleet;
- avoid updating all terminals at one location simultaneously;
- confirm that the application returned after restart;
- pause or recover when acceptance checks fail.
Include application, certificate and content changes in the same release calendar when they can affect the user journey.
8. Write the remote recovery runbook
Before deployment, the support team should be able to answer these questions:
- How do we know that a kiosk is offline or unhealthy?
- Can we identify its location, model, policy group and current owner?
- Which diagnostic information can be collected remotely?
- When is a restart appropriate?
- When may remote access be used, and how is it authorised?
- What can a local employee do safely?
- When must a technician visit the site?
- How is a failed device replaced and enrolled?
Remote tools reduce unnecessary travel only when the team has a clear decision path.
9. Run field tests, not only lab tests
Place a small number of kiosks in representative locations. Test lighting, noise, temperature, physical access, network quality and real peripheral use. Observe how users recover from mistakes and whether instructions are understandable without assistance.
Measure:
- successful completion rate for the intended journey;
- time from power-on to application-ready state;
- unplanned offline time;
- time from fault detection to restored service;
- incidents requiring a site visit;
- application, peripheral and policy versions on each device.
These measurements form a defensible baseline for the rollout decision.
Pre-rollout checklist
- The complete user journey and failure states are documented.
- Production application, accounts and endpoints are tested.
- Every production peripheral has passed normal and failure tests.
- Mounting, power, cabling, ventilation, service access and accessibility have been approved for each site.
- Network destinations, certificates and offline behaviour are known.
- Kiosk policies, ownership and change approval are defined.
- Updates use canary devices and a written stop condition.
- Remote diagnosis, local action and site-visit thresholds are documented.
- A representative field pilot has completed recovery exercises.
Run a site acceptance test
For the wider support process, see the multi-site remote device management guide.
Bring the target application, hardware, peripheral list and network design to a FydeOS Kiosk trial. A small field pilot is the most useful place to confirm compatibility and recovery before ordering or converting a wider fleet.