What is kiosk management software?
Kiosk management software is the cloud platform that watches, updates and repairs a fleet of self-service terminals from one screen: remote kiosk management, kiosk monitoring and kiosk fleet management in a single console. A small client inside each kiosk application reports whether the device is up, whether the application is running, whether the printer, scanner or card terminal reports ready, how much battery is left, which version is installed and what the last error was. The platform turns that into a fleet view and alert rules, and from the same console an operator can release a new build, take a screenshot, put a message on the screen and restart the application without a site visit.
AtashiTech builds this platform and the client that reports into it, and every kiosk solution we deliver can be enrolled in it. It is the operations layer beneath the rest of our kiosk and self-service solutions. We write the software; the terminals, enclosures and network links are yours.
A kiosk estate you cannot see costs more than the kiosks did
One kiosk in a lobby is a device. Forty kiosks across a state are an estate, and an estate needs an operations model, not a phone number.
The old way
A terminal stops working. Nobody at head office knows. A customer tries it, gives up, and either queues at a counter or leaves. Eventually a branch manager calls somebody, who calls the vendor, who sends an engineer, who arrives to find the printer out of paper. Meanwhile a new software version is distributed by emailing an installer to forty branches with instructions, which produces forty slightly different installations and no way to confirm which sites applied it.
The reporting is just as blind. Nobody can say how available each terminal really was last month, which device fails most often or whether the uptime clause in the maintenance contract was met, so hardware and support decisions are made on impressions.
The AtashiTech way
The client built into the kiosk application sends a regular heartbeat, so the console shows every terminal's state within minutes. Alert rules catch a terminal gone silent, an application that keeps crashing, a peripheral not ready and a tablet battery running low, and push them to the team's phones, with e-mail as an optional second channel.
Fixing follows the same route. A new build goes to pilot terminals first and then to the rest of the estate as a tracked release. A stuck application is fixed with a remote restart; only faults that need hands get a site visit, and the engineer already knows what to bring.
How remote kiosk management works
The loop is the same for a lobby terminal and a gate kiosk on a remote site: report, evaluate, act, learn.
Enrol the terminal
The console issues a one-time enrolment code for a customer, site and application; the kiosk enters it once and registers itself with its role and the peripherals fitted. For a pilot, a product can also enrol new kiosks into a chosen site automatically. Enrolment is part of the standard build, so a new site joins the estate the day it is commissioned.
Stream kiosk telemetry
The client reports device and application state, the installed version, battery and storage, the status of each peripheral, and warning and error events with their stack traces. Events are buffered on the device when the link is down and delivered when it returns, so an outage leaves a gap in connectivity, not in the record.
Evaluate rules and alert
The platform checks every terminal continuously: silent after it has been heard from, a crash loop of repeated critical errors, a low battery while not charging, a peripheral not ready. One alert stays open per terminal and rule until the condition clears, and a digest of new and resolved alerts is pushed to the operations team.
Act remotely, then review
From the console an operator takes a screenshot, puts a message on the screen, reloads settings, restarts the application or signs a device out, and releases new builds to pilot terminals first. Every action is recorded against the terminal, and the measured uptime feeds the reports that shape the next hardware and support decisions.
Kiosk monitoring and management features
Everything a kiosk management software console has to do is here, operated with role-based access, so administrators who act and staff who only need to look see the same estate through different permissions.
Real-time health and uptime
Live state for every terminal with the history behind it. Each outage is recorded from the moment heartbeats stop to recovery, so an availability figure for a month is a measurement rather than an estimate, and a repeatedly failing device is visible as a pattern.
Fleet view by customer and site
Terminals grouped by customer and site with status colouring, filterable by application, site or alert state, which is how an operations manager finds the three terminals that need attention this morning.
Remote restart, screenshot and on-screen message
Restart the application, capture what is currently on a kiosk's screen, show a message to the person standing at it, reload its settings or sign it out, all without a site visit and all recorded against the terminal.
Over-the-air software updates
Publish a new application build for Windows or Android. The file is checked before it is offered, pilot terminals get it first, the rollout is widened step by step, and a release can be paused, resumed or withdrawn. The console shows which terminals have updated.
Peripheral, battery and crash alerts
A printer out of paper, a scanner disconnected or a card terminal that stopped answering shows as a peripheral not ready, named on the alert. Tablets raise a low-battery alert, and repeated crashes raise a crash-loop alert before the public notices.
Role-based operator and technician access
Administrators can act on terminals and publish releases; read-only users can follow the fleet, the alerts and the reports. Every action is attributed to the person who took it.
Downtime and service-level evidence
Outages are timed from first missed heartbeat to recovery, and time when the monitoring service itself was down is excluded from both sides, so a contractual argument starts from fair data.
One log across every device
Errors and warnings from every terminal in one list, filtered by application, level, customer or text, each linked to its device with the stack trace attached. The level collected can be set per application. See the kiosk reports below.
Kiosk reporting: uptime, usage and incidents in one place
Kiosk reporting turns telemetry from every terminal into reports operations, finance and service partners can act on, per customer or site over any date range, in each site's own time zone.
Availability report
Measured uptime per terminal and site, with every outage listed from first missed heartbeat to recovery and short drops counted separately: the figure a support agreement is checked against.
Usage and transaction report
Journeys and transactions per terminal, site and hour, showing which kiosks earn their place and when to staff a counter. Built per project from the counts the kiosk application records.
Incident and fault report
Alerts raised and resolved within the period, alongside the error log for each terminal, so repeat faults on one device or one application show up as a pattern.
Consumables report
Peripheral status over time, so a printer that runs out of paper every week stands out. Detailed paper, card, badge and cash levels are added on request where the device reports them.
Release and compliance report
Which software version each terminal runs and where each release stands, so an audit has a current answer.
Scheduled delivery and export
The uptime report downloads as an A4 PDF per customer or site, ready to send to whoever needs it. Scheduled e-mail delivery and exports to CSV, Excel, Power BI or your own warehouse are set up on request.
Platform and integrations
The reporting client is built into our Windows and Android kiosk applications, and the console runs in any browser. Terminals make outbound calls only and collect waiting remote actions and offered updates in the reply to their own heartbeat.
What the client reports and what you can do about it
The useful question about a monitoring platform is not what it displays but which faults it lets you close without a van. The table lists the conditions we instrument by default and the action available from the console.
| Condition | Detected from | Typical alert | Remote action |
|---|---|---|---|
| Terminal offline | Missed heartbeats | Silent-terminal alert | None until it returns; the outage is timed from the first miss |
| Application crashing repeatedly | Critical error events | Crash-loop alert | Read the stack trace, restart the application, release a fix to pilot terminals |
| Printer out of paper or jammed | Printer status via the driver or SDK | Peripheral not ready, naming the printer | Dispatch with the consumable already known |
| Tablet battery low | Battery level and charging state | Low-battery alert while not charging | Message on the screen asking staff to reconnect the charger |
| Peripheral not responding | Peripheral status in the heartbeat | Names the device, not just the kiosk | Restart the application; read the device's error log first |
| Screen looks wrong to the public | A report from a site | Not applicable | Screenshot to see what the public is actually looking at |
The console, the client and the hosting come from our web application, kiosk application and cloud, DevOps and integration teams.
Estates that need remote kiosk monitoring
Any deployment past a handful of terminals, and any single terminal that is far away.
Bank and utility self-service networks
Payment and collection terminals hold cash and print receipts, which are the two things that fail quietest. Operators running our bill payment and collection kiosk use peripheral alerts on the printer and the cash module to send someone before a machine starts refusing customers.
Restaurant and retail chains
New versions must reach every store without a store manager running an installer. Chains running self-ordering kiosks or self-checkout terminals release a build to a pilot store first, widen the rollout and see which stores have updated.
Hospital groups
Registration terminals across several campuses are maintained by a small biomedical or IT team. A single fleet view with alert states tells them which terminal to attend first, and the shared error log answers most questions before anyone walks across a hospital.
Industrial sites and remote gates
Gate kiosks running safety induction or contractor access sit in gatehouses with poor connectivity. Events buffered on the device mean a site with an intermittent link still reports its history, and a new build reaches every gate as a tracked release.
Corporate campuses and shared services
Reception terminals, HR terminals and queue displays across a property portfolio are one estate for the facilities team. Terminals running our visitor management and employee self-service kiosks are enrolled the same way and monitored on the same console.
Deployment, connectivity, AMC and data
A monitoring platform is only worth having if the estate is fully enrolled and the alerts are believed. Both are operational problems more than technical ones.
Deployment
Enrolment is part of the kiosk build. The platform monitors kiosks that run our applications: an existing estate of our kiosks gets the reporting client with an application update, and a third-party application is scoped with its vendor. Alert rules are deliberately few and specific, because a team that is paged for nothing soon stops reading the alerts.
Connectivity and offline behaviour
Kiosk management software must never make the kiosk depend on the cloud. The terminal keeps serving the public with no connection; the client buffers its events on the device and delivers them when the link returns, remote actions wait in the console until the terminal next reports, and the console shows which terminals have gone silent.
Annual maintenance contract
The platform is normally taken alongside an AMC, because the two answer the same question: who is responsible when a terminal stops. Our consulting and AMC support service covers platform updates, client updates as kiosk hardware changes, alert-rule changes and a support channel for your operations team. Where a third-party service partner does the field work, both sides work from the same uptime and incident record. Terms are agreed per customer.
Data and reporting
Telemetry, alerts and logs are yours. Heartbeats, events and screenshots are kept for set periods and then deleted, outage history is kept long enough for annual reporting, and everything is reported as described in kiosk reporting. Longer notes on running kiosk estates appear on the blog.
Managed IoT kiosk services
A modern kiosk is a connected device: the PC or tablet, the printer, the cash module, the card terminal and the scanner all report their state, and the client turns that into telemetry. Some operators want to watch that telemetry themselves; others want someone to watch it for them.
We run the console, you run the sites
Under an annual maintenance contract our team can operate the platform on your behalf. We watch the alerts, resolve what can be resolved remotely (a restart, a settings reload, a message to staff on the screen, a release that needs pausing), schedule software releases across the fleet, and hand anything physical to your field partner with the diagnosis already attached, so the technician arrives with the right part.
What a managed kiosk fleet looks like week to week
Alerts are triaged before they reach your staff, updates go to pilot terminals first, recurring errors are fixed in the next release, and the split of responsibilities between our team, your staff and any hardware partner is written into the contract.
Or keep it in-house
An operator that runs its own estate uses the same console; we provide platform support, client updates and alert-rule changes, and your team keeps day-to-day control.
See the whole estate on one screen
Tell us how many terminals you run, where they are, what is fitted inside them and who does the field work today. We will scope the enrolment, the alert routing and the console access your teams need, and quote the work.