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. A small agent on each kiosk reports what the operator cannot see from head office: whether the machine is up, whether the application is running, how much paper is left in the printer, how full the cash box is, whether the card terminal answered, what the last error was and when the terminal last completed a transaction. The platform turns that stream into a live map and a set of rules, so a fault raises an alert instead of waiting for a customer to complain. From the same console an operator can push new content or a new software build, pull a screenshot or a log, and restart a terminal without anyone driving to the site.
AtashiTech builds this platform and the agent 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 content update is distributed by emailing a file to forty branches with instructions, which produces forty slightly different versions of the same screen and no way to confirm which sites applied it.
The reporting is just as blind. Nobody can say how many transactions each terminal completed last month, which sites are barely used, which device fails most often, or whether the uptime clause in the maintenance contract was actually met. Decisions about where to add terminals, which hardware to buy next and whether to renew a support agreement are made on impressions, because the evidence was never collected.
The AtashiTech way
The agent installed with the kiosk application reports continuously over MQTT, so the console shows every terminal's state within seconds rather than at the next site visit. Rules you define turn conditions into alerts: paper below a threshold, a cash box near capacity, an application that has stopped, a terminal that has not transacted since morning, a peripheral that stopped answering. Alerts go to the people who can act, by role and by region, and they carry the context an engineer needs before setting off.
Fixing follows the same route. Content, configuration and software builds are published from the console to a group of terminals, staged and confirmed, so an update is a tracked release rather than an email. Where the fault is a stuck application, a remote restart or a screenshot resolves it in minutes. Only the faults that genuinely need hands get a site visit, and the engineer already knows what to bring.
How it 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
A lightweight Windows service is installed alongside the kiosk application and registers the terminal with its site, group, hardware profile and the peripherals fitted. Enrolment is part of the standard build, so a new site joins the estate the day it is commissioned rather than months later.
Stream health and usage
The agent publishes uptime, application state, peripheral status, consumable levels, disk and memory, network quality, error events and transaction counts. Messages are queued locally when the link is down and delivered in order when it returns, so an outage leaves a gap in connectivity, not in the record.
Evaluate rules and alert
Thresholds and conditions are set per group: low paper, high cash, application not responding, no transaction since a given hour, a peripheral offline, a site unreachable. Matching conditions raise an alert routed by role and region, with severity and an escalation path when nobody acknowledges.
Act remotely, then review
From the console an operator pushes content or a software release to selected terminals, pulls a screenshot or a log bundle, or restarts the application or the machine. Every action is recorded against the terminal, and the resulting uptime and usage data feed the reports that shape the next hardware and staffing decisions.
Core features of the remote monitoring platform
Everything a kiosk management software console has to do is here, operated with role-based access, so an operator, a technician and a finance analyst see the same estate through different permissions.
Real-time health and uptime
Live state for every terminal with the history behind it, so an availability figure for a month is a measurement rather than an estimate, and a repeatedly failing device is visible as a pattern.
Geographic fleet map
Terminals plotted by site with status colouring, filterable by region, customer, hardware model or alert state, which is how a regional manager finds the three sites that need attention this morning.
Remote reboot, screenshot and log pull
Restart the application or the machine, capture what is currently on the screen, and fetch a log bundle for the last incident, all without a site visit and all recorded against the terminal.
Over-the-air content and software updates
Publish screens, media, price lists, languages, configuration or a new application build to a group of terminals, staged in waves with confirmation from each device and a rollback path if a wave fails.
Consumable and peripheral alerts
Paper low, cash box near capacity, card terminal unreachable, scanner disconnected, badge stock out. Consumables are the most common cause of a dead kiosk and the easiest to prevent.
Role-based operator and technician access
Head office, regional operations, field technicians and third-party service partners each get scoped access, so a partner sees the terminals they maintain and nothing else, with every action attributed.
Downtime and service-level alerting
Outages are timed from first missed heartbeat to recovery, and breaches of the availability targets in your own support agreements raise their own alerts, so a contractual argument starts from data.
Usage analytics and export
Transactions and journeys per terminal, per site and per hour, with export to Power BI or your own warehouse so kiosk usage can sit next to counter and branch data in the same analysis.
Platform and integrations
The agent is a .NET Windows service. Telemetry travels over MQTT into an Azure IoT Hub ingestion layer, the React console receives live updates over SignalR, and the API is REST with webhooks for anything downstream. The platform is designed to sit beside the tools you already run rather than replace them.
What the agent 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 | Immediate, escalating by region | None until it returns; the outage is timed from the first miss |
| Application stopped or frozen | Agent watchdog | Immediate | Restart the application, then the machine if needed |
| Printer paper low or out | Printer status via the driver or SDK | Warning, then critical | Dispatch with the consumable already known |
| Cash or coin box near capacity | Cash device counters | Threshold you set per site | Schedule collection before the kiosk refuses notes |
| Peripheral not responding | Device interface heartbeat | Names the device, not just the kiosk | Restart the service; pull a log bundle for the engineer |
| No transactions since a set hour | Usage counters | Silent-terminal alert | Screenshot to see what the public is actually looking at |
The console is built by our web application team, the agent and its device interfaces by the same engineers who build our kiosk applications, and hosting, ingestion and the links into your service desk are set up by our cloud, DevOps and integration team. The same MQTT store-and-forward telemetry pattern carries vehicle data in our FleetFlow platform, where the moving asset is a truck rather than a terminal.
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 cash-level and paper alerts to schedule collections and refills before a machine starts refusing customers.
Restaurant and retail chains
Menus, prices and promotions change centrally and must reach every store at once. Chains running self-ordering kiosks or self-checkout terminals publish content in staged waves and confirm which stores applied it, instead of trusting a store manager to run an installer.
Hospital groups
Registration terminals across several campuses are maintained by a small biomedical or IT team. A single map with alert states tells them which terminal to attend first, and remote log pulls answer 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. Store-and-forward telemetry means a site with an intermittent link still reports its history, and revised induction content reaches every gate as a tracked release.
Government and citizen-service centres
Terminals distributed across districts are operated by staff with no IT background. Remote restart and screenshot resolve most incidents centrally, and usage analytics show which centres justify more terminals and which are barely used.
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, so a terminal registers itself on first start with its site and group. For an existing estate we deploy the agent alongside the running application, which does not require the kiosk software to be replaced, and back-fill the site, hardware and peripheral profile from your asset list. Alert thresholds are set conservatively at first and tuned during the first weeks, because an operations 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 at all; the agent simply queues its telemetry locally and delivers it in order when the link returns. Remote actions are queued the same way, so a restart requested while a site is offline is applied when it reconnects, and the console shows clearly which terminals are reporting late rather than pretending the data is current.
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, agent 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, they can be given scoped console access so both sides work from the same record. Terms are agreed per customer.
Data and reporting
Telemetry, alerts and usage counters are yours. They can be exported to Power BI or a warehouse, pushed to a service desk as tickets, or read through the REST API, and the retention period is set to suit your own policy. Longer notes on running kiosk estates, from consumable planning to update strategy, appear on the blog.
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 agent, the alert rules and the console access your teams need, and quote the work. Reach us through the contact page.