About kiosk integration
Understand how an OmniLab experience runs on a touchscreen kiosk, and who owns which part of the setup.
Visitors scan a card or a voucher at an in-store kiosk to start playing. Three parties are involved: you, OmniLab and the company that supplies or builds the kiosk. Agree who does what before any build starts: an unclear split causes most of the delays on these projects.
How a kiosk session works
The kiosk stays in charge. It shows your welcome screen, reads the barcode, then opens the experience full screen, in a WebView or a frame. Everything inside it comes from OmniLab: the game, the form, the branding, the reward. Everything around it belongs to the kiosk.
- 1Home button — the visitor’s way out at any moment
- 2Session bar, kept outside the frame so it never covers the experience
- 3The OmniLab experience: game, form, branding, reward
- 4On-screen keyboard for form entry
- 5Barcode scanner
Everything outside the dashed frame is built by your kiosk provider.
- 1The kiosk shows its own welcome screen
- 2The visitor scans a barcode on the kiosk's scanner
- 3The kiosk builds the address and opens it in its WebView or frame
- 4The OmniLab experience loads inside that frame
- 5The visitor plays — everything on screen now comes from OmniLab
- 6The idle script tells the kiosk when the screen goes quiet
- 7The kiosk clears the frame and returns to its welcome screen
- 8At any moment the visitor can press the kiosk’s Home button, which jumps straight to step 7
Steps 4 to 6 run inside the WebView or frame the kiosk opened — the kiosk application never hands over, it stays in control the whole time.
Two ways to start a session
Your choice changes what the visitor does at the screen, and what you print on the barcode.
| Approach | The visitor scans | What happens next | Use it when |
|---|---|---|---|
| Known member | Their loyalty card | The member signs in with their customer account, or goes straight in with a recognition integration | You already run a loyalty programme and want little friction at the screen |
| New participant | A printed invitation or voucher | The visitor fills in the acquisition form on the kiosk, then plays | You're recruiting new contacts and want the visit to produce a sign-up |
The known-member route needs your customer identity system connected to OmniLab first: see About customer accounts. Without a recognition integration for the campaign, members still see a sign-in screen. For the exact addresses, see Kiosk URLs.
Who owns what
Share this table with your kiosk provider at the first technical meeting.
| Responsibility | Owner |
|---|---|
| Welcome screen design and build | Kiosk provider |
| Barcode scanner and the values it reads | Kiosk provider |
| WebView or frame that loads the experience | Kiosk provider |
| Building the experience address and adding the scanned value | Kiosk provider |
| On-screen keyboard for form entry | Kiosk provider |
| The "Are you still there?" message and the return to the welcome screen | Kiosk provider |
| The idle script that notices a visitor has walked away | Kiosk provider writes it; your Studio admin adds it |
| The experience itself: game, form, branding, reward | OmniLab |
| Campaign configuration, rewards and prize stock | You, in Studio |
| Barcode stock: which cards or vouchers are printed and handed out | You |
| Staff supervision and prize handover in-store | You |
In short: OmniLab owns the experience, and your kiosk provider everything around it, plus the idle script. You own the campaign and the barcodes.
Before you brief a provider
- The campaign is built and published in Studio, so there's a real address to test.
- You've chosen one of the two start routes, and decided the barcode values.
- If members should skip the sign-in, you've asked your Customer Success Manager for a recognition integration.
- Rewards and prize stock are set up, because they change what the visitor sees at the end.
- Your venue IT team knows the kiosk needs internet access: see the network points in Kiosk requirements.