Back to Portfolio

What 132 assets carry between one callout and the next

The register behind a quick service restaurant: what each asset holds, and where its own record is still thin.

Video
Summary
Burger King is operated in Clickpad as a register: the dining room, the front counter, the kitchen line and the two drive-through lanes, each asset opened from where it sits. Every asset carries its own specs, its own fault history and the inspections carried out on it, alongside a plain list of what we do not yet know about it.
Read article
Tour of the twin0:30
Asset page and its historyScreenshot
Maintenance and CapExScreenshot
Overview
Clickpad copilotScreenshot

Burger King sits in Clickpad as a register of 132 assets. The intercoms, menu boards and payment terminals on both drive-through lanes, the front counter, the kitchen line, and the plant that serves the dining room — each one entered against the place it actually stands, so it is opened from the plan of the restaurant rather than looked up in a row of a spreadsheet.

An asset page is not a specification sheet. The specs are on it, and under them sit the service logs and a history timeline: what was attended, when, and against which job it was raised. The front counter register — a PAR EverServ — reads as a sequence rather than a status: a PIN-entry device inspection passed with no tampering, P2PE keys rotated, the card reader bezel replaced for wear, firmware brought up to PCI PTS 6.x. The receipt printer jamming on long orders lands against that history instead of arriving on its own.

Every asset also carries a section for what the register does not know about it. A serial nobody has read off the plate, an install date that was never captured, no manual on file, a service interval nobody has confirmed. Those gaps are written down as gaps rather than left as assumptions, so the coverage is visible for what it is and the holes get closed on a scheduled visit instead of surfacing in the middle of a fault.

The copilot is per property. Asked about the mic on lane 1, it answers out of this restaurant’s register: the intercom that serves that lane, the fault already attended on it in the last seven months, the warranty that ran out in April 2025, and the work order raised at the time still sitting on the card. A second fault reads as a second, which is the thing that gets missed when the person raising the job is not the person who paid for the last visit.

Maintenance runs off the same entries. Intervals live on the asset, so a unit that has gone past its own interval is visible as itself and not as a line in a schedule kept somewhere else, and a compliance inspection stays on the terminal it was carried out on rather than in a folder ordered by date, which is what makes it producible on demand. CapEx planning is a separate hub reading the same register — the assets, their ages, their fault counts and their warranty status — so replacing a unit instead of repairing it again is a decision made against what is recorded rather than against what is remembered.

Drawings Geometry Room Data Assets Warranties Records Transfer WORK ORDERS Dispatch Ownership Capital Drawings Geometry Room Data Assets Warranties Records Transfer WORK ORDERS Dispatch Ownership Capital
What it produces

Built for the properties behind these brands

Drawings and BIM become a measured 3D twin

[Map]

0 % Agreement
Every asset carries its own status and history

[Manage]

0 % Visibility
Renovations priced off the geometry, logged back

[Improve]

0 % Faster