Inactivity management

Reset a kiosk automatically when a visitor walks away mid-experience, so the screen is ready for the next person.

3 min read

Make a kiosk clear itself when someone walks away halfway through a game, so the next visitor finds a welcome screen instead of a stranger's abandoned session. Without this, an unattended kiosk stays stuck on whatever screen the last person left behind until a staff member notices.

This works in two halves. The OmniLab experience notices that nobody has touched the screen and says so. Your kiosk software receives that signal and decides what to do about it — because only the kiosk can actually close the session and go back to its own welcome screen.

How the reset happens

The kiosk application — always runningInside the kiosk’s web frame123456
  1. 1The visitor stops touching the screen
  2. 2OmniLab counts 10 seconds with no activity
  3. 3OmniLab signals the kiosk that the screen looks idle
  4. 4The kiosk shows its own message and countdown
  5. 5Stay puts the visitor back in the experience; no answer clears the frame
  6. 6The kiosk returns to its welcome screen
Runs inside the OmniLab frameRuns in the kiosk application

OmniLab only does steps 1 to 3. Everything the visitor sees during the reset is the kiosk application.

  1. The visitor stops interacting with the experience.
  2. After 10 seconds of no touches, taps, or scrolling, OmniLab signals that the screen looks abandoned.
  3. The kiosk shows a message asking whether the visitor is still there, with a visible countdown.
  4. If the visitor touches Stay, the message closes and they carry on where they left off.
  5. If nobody responds before the countdown ends, the kiosk closes the experience and returns to its welcome screen.

A typical setup frees an abandoned kiosk in about 20 seconds — 10 seconds of silence, then a 10-second countdown. Set the countdown long enough that someone reading the screen or thinking about a quiz answer is not thrown out mid-game.

OmniLab cannot reset the kiosk on its own

OmniLab only sends the signal. Everything after that — the message, the countdown, the Stay button, and the return to the welcome screen — is built and owned by your kiosk provider, because only the kiosk software can close a session. Confirm they have committed to building it before you rely on unattended operation.

The modal is yours to design — OmniLab has no control over how it looks:

123456789
  1. 1Background image and your branding
  2. 2“Touch the screen to start”
  3. 3Animated pointer towards the scanner
  4. 4Home and close buttons — the visitor’s way out at any moment
  5. 5The experience stays loaded behind the modal
  6. 6“Are you still there?” message
  7. 7Visible countdown
  8. 8Stay — returns to the experience
  9. 9Return home — ends the session
Provided by OmniLabBuilt by your kiosk provider

The experience stays loaded behind the modal, so Stay puts the visitor back exactly where they were.

Turning it on for a campaign

Idle detection is not on by default, and it is not a setting inside a campaign. Your developer writes a small script, an admin adds it once under the Global organisation, and it lists exactly which campaigns it applies to.

Ask your developer for the script

This is the OmniLab side of the setup — the part that notices the screen has gone quiet. Send your developer Kiosk integration (technical deep-dive).

Ask your kiosk provider to handle the signal

The signal does nothing on its own. Your kiosk provider has to build the message, the countdown, the Stay button, and the return to the welcome screen — and that work is theirs, not OmniLab's. Put it in the scope you agree with them rather than assuming it arrives with the campaign.

The same technical guide describes the signal they will receive and what their side has to do with it.

List the campaigns it should cover

The script only activates on campaigns you name in it. Everything else is untouched, which is what stops the behaviour leaking onto campaigns people open on their phones — where an idle timer would be a nuisance rather than a help.

Give your developer the address of every kiosk campaign it should apply to. Each new kiosk campaign has to be added to that list.

Have an admin add it

An admin adds the script under General Settings in the Global organisation. See Organisation scripts.

Republish every campaign it affects

A saved script does not reach a live campaign until that campaign is republished. This is the step that gets missed.

Test on the kiosk itself

Start a session, stop touching the screen, and watch the whole reset. Then test the Stay button, and confirm the countdown does not silently restart and leave the message on screen forever.

What to check before launch

  • The reset returns to your welcome screen, not to a blank frame or a reloaded game.
  • A visitor who is reading rather than tapping is not thrown out too early.
  • The message is readable from the distance people stand at.
  • Adding a new kiosk campaign later means updating the list — put that in your launch checklist for the next campaign.
Kiosk integrationKiosk integration (technical deep-dive)The script itself, the signal it sends, and what the kiosk provider builds to receive it.OrganisationsOrganisation scriptsThe admin workflow for adding, enabling, and disabling a script.Kiosk integrationKiosk requirementsThe screen controls the kiosk has to provide, including the welcome screen it returns to.Kiosk integrationKiosk implementation checklistWhere session reset fits in the rollout stages.

On this page

How the reset happensTurning it on for a campaignAsk your developer for the scriptAsk your kiosk provider to handle the signalList the campaigns it should coverHave an admin add itRepublish every campaign it affectsTest on the kiosk itselfWhat to check before launchRelated