Report glossary

What each report answers, and the terms on it that are easy to misread.

Read out of the platform

This page is generated from the code that runs your instance, so it cannot drift from what the platform actually does.

Nearly every figure on a report page has a unit that reads like something slightly different from what it is, and the misreadings are the expensive kind: a "move" is not a person, a dwell row is a stay and not a visitor, a device-day is neither.

This is the same text as the What this report is panel at the foot of each report page, collected in one place so you can search it — and so you can read it before you open the report rather than after you have already drawn a conclusion from it.

Last 24 hours

/admin/report/last-24h

Everything from the last twenty-four hours in one feed — counts and events together. The page to open when you want to know what has been happening right now rather than what a date range adds up to.

A rolling window, not today — It ends now and starts twenty-four hours ago, so it spans two calendar days and will not match a report run for "today".

The most recent minutes are still filling in — Counts are rolled up every few minutes, so the newest end of the window is the least complete part of it.

Central Alerts

/admin/report/alerts

Every alert the platform raises, in one feed — device anomalies, battery warnings, gateway outages and recoveries, positioning coverage, toilet and Security Watch incidents, rule triggers and failed webhook deliveries — so you do not have to check eight places to find out what happened. Gateway and coverage rows are the same events the bell announced, folded to one row per event.

Different kinds, different meanings — A rule trigger is something you asked to be told about. An anomaly is the system noticing something unusual on its own. An emergency is a panic button, with how many people were paged. They are worth reading differently.

What can be done from here — Anomalies and battery alerts can be acknowledged and deleted; button presses and dead webhook deliveries deleted. Gateway, coverage, rule and emergency rows are the bell's notifications folded to one row per event, and toilet and Security Watch incidents belong to their own apps — those are read here and handled there. Selecting a mix acts on what accepts the action and leaves the rest.

Rules that only email — A rule fires into this feed through its in-app alert action. A rule whose only actions are email, SMS or a webhook leaves no row here — its rule page shows when it last fired.

One row is one raising — A condition that keeps being true can raise repeatedly. A long run of the same alert is usually one situation, not many.

Quiet is not always good — Alerts depend on rules existing and sensors reporting. An empty feed can mean nothing is wrong, or that nothing is watching.

Enter / Exit

/admin/report/enter-exit

Counts of people crossing a doorway, as recorded by the sensor watching it, for a date range and location. It answers how busy an entrance was and when.

Enter / Exit — People crossing the doorway, by direction — not how many are inside. One person who steps out for coffee and comes back is two enters and two exits.

Balance (in minus out) — Not how many are inside. Over a whole range the two directions should roughly agree; a gap of more than a tenth means a counter is missing one direction (a beam mounted so people cluster on the way out, say), and the counter strip marks which. A live occupancy figure needs every way in and out counted and a re-zero while the space is empty — that is the Right Now page's job, not this report's.

Counter — The counts belong to the door counter that saw them, so a doorway covered by two counters reports under both. The strip under the cards names each counter behind the range and says whether it is still counting.

Source — A door counter (sensor) counts everyone who crosses. Older rows marked gateway were inferred from tags moving between zones and count only tag carriers; filter by source when comparing like with like.

Where the numbers come from. Each counter's crossings are added to its hourly row as the packets arrive, so the current hour is live to within a few minutes; hours are shown on your clock. There is no daily rebuild — a day is its hours. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Devices Detected

/admin/report/total

How many distinct BLE devices were detected, by location, venue and date range. The broadest measure of "how many were here" the platform has — and the coarsest.

What is counted — Registered tags, and any unregistered BLE address a gateway heard. Fixed installations — sensors, door counters, wall switches — are left out, because they advertise from one spot every day and were counting the estate itself. Wi-Fi is no longer counted: phones randomise their Wi-Fi address every few minutes, so one phone looked like dozens of devices.

A device is a radio, not a person — A phone and a smartwatch on the same person are two devices; a person carrying nothing is zero. Treat the number as a trend rather than a headcount — the People Count report is the one built for people.

Distinct — Counted once per period, not once per detection — a device seen a thousand times in an hour is one.

Daily and hourly — Hourly figures do not add up to the daily one: a device present all afternoon is distinct in each hour it appears, and once for the day.

Where the numbers come from. Packets are rolled up into report tables every five minutes, which updates the hourly rows. The per-day figure is built once, just after the day ends on your clock — your calendar day, not a UTC one —, so today's daily total is provisional until then while the hourly rows stay current to within about five minutes. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Loyalty

/admin/report/loyalty

Whether the devices you are seeing are new or coming back, and how long since each was last here. The question behind it is retention: is the same population returning, or is it a different crowd each day?

The unit is a device-day — One device on one day, wherever in the venue it went. A device here on three days counts three times across the range, once per day.

New — No earlier sighting on record. A device the platform has simply not seen before will read as new even if the person is a regular.

Returning — Seen before, bucketed by how long ago: recent is within three days, then one, two, three and four-or-more weeks since the last visit. Short buckets are your regulars; long ones are people coming back after a gap.

Who is counted — Devices registered on the Devices page and heard by your gateways — tags and sensors, not passing phones. On a workplace where everyone carries a badge this reads as attendance regularity rather than customer loyalty; the table at the bottom names the devices, which is usually the more useful view there.

Where the numbers come from. Once an hour the sensor trail is re-read and every device's first sighting on each of your calendar days is classified against its own history, so today's figures are up to an hour behind. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Dwell Time

/admin/report/dwell-time

How long devices stay, bucketed by duration and broken down by zone. It answers whether a space is somewhere people pass through or somewhere they settle.

The unit is a stay — One registered sensor's continuous presence in one zone — not a person, and not a visit to the building. A device that crosses three zones produces three stays. Passing phones are not counted: only tags and sensors registered on the Devices page leave a trail.

Pass-by, visit, engaged — A stay of zero minutes — heard once, then gone — is a pass-by. A stay shorter than the venue's engaged threshold (dwell time on the venue, 5 minutes unless changed) is a visit; at or over it, engaged. The strip above names the threshold in force.

Buckets — Stays are grouped by length rather than averaged, because an average hides the shape: a zone with many brief stays and a few long ones averages to a number that describes neither.

Short stays — A zone beside a doorway collects a lot of very short stays from people walking past. Read the shortest bucket as traffic, not occupancy.

Where the numbers come from. Each stay is a row in the sensor trail, closed when the sensor is next heard somewhere else or falls silent. Once an hour those stays are bucketed into one row per zone per day — the day the stay began, on your calendar. A stay still in progress is counted with its length so far and moves up a bucket as it grows, so the newest hour's figures settle on the next run. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Heatmap

/admin/report/heatmap

Where activity concentrated, drawn on the venue's floor plan. Use it to see at a glance which parts of a floor carried the traffic over a date range. The three overlays answer different questions and come from different data, so pick by the question, not by which looks busiest.

Zone presence (dwell) — the default — Zones tinted by how much time registered sensors spent in them, straight from the sensor trail. The best answer to "where were people", because it uses every sighting rather than only doorway crossings — but it counts tags, not phones: a person without a tag leaves no presence.

Zone traffic (enter/exit) — Zones tinted by door-counter crossings, which count everyone who passes the counter, tagged or not. Only zones with a counter on them can ever light up, so a dark zone here may simply have no sensor; most crossings on a floor without zone-mapped counters fall to the venue rather than a zone.

Gateways — Intensity around each gateway's position rather than by room. Useful for judging sensor coverage, not for reading room occupancy.

Zones need an outline — A zone with no polygon drawn on the floor plan cannot be shaded. It is listed under the map instead so its activity is not silently lost.

Where the numbers come from. Presence reads the sensor trail directly — a stay is written when a sensor is placed in a zone and closed within a minute of it leaving or falling silent, so this overlay is current to about a minute. Traffic and the gateway overlay read the enter/exit rollup, rebuilt every five minutes from door-counter and gateway packets. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Detection Heatmap

/admin/report/heatmap-total

A grid of venues, zones or locations against days (or hours of the day), each cell shaded by how many distinct BLE devices were detected there. Brighter is busier. Good for spotting the pattern of a week at a glance — which days, which spaces — and for seeing where the gateways can hear at all, which is a different question from where people are.

Devices, not people — Registered tags and any unregistered BLE address a gateway heard; fixed sensors and actuators are left out. A device is counted once in every space it was seen in, so a person walking through four zones adds one to each, and a phone and a smartwatch are two. Column totals are larger than the number of people who were in the building.

Distinct per cell — Within one cell a device counts once however many times it was seen. Cells do not add up across the grid: the same device is in every cell it visited.

Daily and hourly — Daily cells are your calendar days, midnight to midnight on your clock. Hourly cells are the hour of the day on your clock, summed across every day in the range — a device seen at 10:00 on five days adds five.

Where the numbers come from. The hourly rows are rolled up from packets every five minutes, so the hourly view is current to about five minutes. The daily row for a day is built once, just after that day ends on your clock, from every packet of the day — so today has no daily cell yet, and yesterday's appears in the morning. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Flow

/admin/report/flow

Every tracked device leaves a trail of stays — “in this zone from this time to that time”. When two consecutive stays are in different zones and the second began soon after the first ended, the device moved — that is one move, and this report counts them for one floor over a date range. It answers where people go after they arrive somewhere: which rooms feed which, which corridor is actually used, and whether a route runs one way or both.

Moves — Zone-to-zone changes, not people. One device pacing between two rooms all afternoon produces many moves.

Devices — How many distinct devices produced those moves. Moves high and devices low means one tag is doing all the walking.

Return trips — The same route counted backwards. A route with almost none is a one-way door, a queue, or an exit; a route with roughly as many is an ordinary corridor.

Direction — One way when a direction beats its reverse by 1.5× or more, otherwise two way.

Min stay — Moves where the device was in the first zone for less than this are dropped — measured on the stay itself, from when it was placed there to when it was last heard there. Without it a zone next to a doorway collects a large number of moves from people who only passed through.

Max gap — How long the device may be out of sight between leaving the first zone and appearing in the second. A tag last seen in Sales at 10:15 and next seen in the Director Room at 18:22 did not walk between them; it left the floor and came back, and counting that as a route says the wrong thing about the corridor. Ten minutes by default; set it to any to see every zone change regardless.

Zones need an outline drawn on the floor plan to be part of the picture — a zone with no outline has no place to put an arrow. Devices the positioning engine could not place are counted separately and are not in any route.

Environment

/admin/report/environment

Temperature, humidity, noise, light and air pressure from environmental sensors, hour by hour and per room, with a Compliance tab that measures rooms against a spec range. Light and pressure cards appear only when something in the range measured them.

Readings are per sensor, not per room — A sensor measures its own position. One near a vent or a window will disagree with the rest of the room, and that is the sensor being right about where it is rather than wrong about the room.

Thresholds and alerts — This page sets no thresholds. A limit on a metric is a rule — set one under Rules on temperature, humidity or noise and it alerts when crossed; the strip under the cards shows what fired in the last 30 days, or says that nothing is set. The Compliance tab is different: its spec range is typed on the tab and the history is re-read against it, so a days-in-spec count is a statement about the range you typed, not a fixed historical fact.

Fixed sensor or tag — A wall or ceiling sensor measures the room; a roaming tag measures its own case, in a pocket or on a desk. The two are never averaged together — the card takes the fixed reading where the scope has one, and says "tag-derived" when it does not. Temperature shows in the unit set on the organisation.

Gaps — A flat line is not the same as a stable room. A sensor that stopped reporting leaves a gap, so check the battery report if a series goes suspiciously quiet.

Compliance tab — The regulator's table: per room, the days a fixed sensor recorded, the days no hourly mean left the spec range, the excursion days (any hour outside the range) with their lowest and highest reading, the days with no record at all, and the mean kinetic temperature over every hourly mean in the window. Only fixed sensors count — a roaming tag measures itself, not the room — and a sensor not yet placed in a room is not in the table. Days are the organisation's calendar days; the window runs from that many days ago to today. The CSV carries the same rows plus the excursion-day and no-record lists.

Battery

/admin/report/battery

Battery levels reported by BLE devices over time, so you can find the units that will need attention before they go quiet.

Levels are self-reported — The figure is whatever the device says, and different models estimate differently. Compare a device against its own history rather than against another model.

The shape matters more than the number — A steady decline is normal ageing. A cliff usually means cold, a bad battery, or a device transmitting far more often than it should.

A device that stops reporting — ...stops reporting its battery too. The last known level is the last thing it said, not its level now. Some models send the battery in its own frame less often than the rest, so a level can be days old on a device heard this morning — the card says how old.

Alerts — The nightly check raises low under 20 % and critical under 10 %, once per episode: a cell that stays low is one alert until someone acknowledges it or the device comes back above 25 %, when the alert closes itself as recovered. A low that worsens becomes one critical alert (and a work order), not a fresh row every day. The Battery column shows the level the alert was raised at and, when it differs, what the device says now.

The forecast — "~N d to replace" is the nightly battery check's estimate: a straight line through the last fourteen days of daily minimums, run down to the 20 % alert threshold. It is not given when the level is already below 20 % (the alert applies instead), when there are fewer than five days of readings, or when the level is not falling — which on a mains- or USB-powered sensor is the normal state, and on a tag means a fresh cell. Levels are self-reported and step in whole percents, so a slope under 0.1 %/day is treated as flat.

Where the numbers come from. Every packet that carries a battery level updates the device's current level and its hourly row in the battery report, so the history is current to the last packet. The forecast on each device is recomputed once a night. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Trigger Event

/admin/report/button-press

Trigger events raised by devices — double-click, triple-click, motion, and any other press type registered for the hardware you run. Use it to see what was pressed, where, and when.

One row is one event — Not one person and not one incident. A panic button held down or pressed repeatedly produces several rows.

Press types depend on the device — What counts as a double-click is decided by the hardware and its decoder, so two models can report the same physical action differently.

Absence is not silence — No events for a device could mean nothing happened, or that the device is flat or out of range. Cross-check against the battery report.

Raised — A press pages people only when it matches a panic-button routing (Devices → Panic Buttons: by the device, by press type, or by the button's id). The Events table marks the presses that did and names the routing; a press from a device not registered on the Devices page can never match one.

Where the numbers come from. Every press is written as its own row the moment the packet arrives — nothing is rolled up or rebuilt. A button advertises the same press for several seconds and more than one gateway may hear it; the decoder keeps one row per press, credited to the gateway that reported it first. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

People Count

/admin/report/people-count

How many people were in each space, hour by hour. Unlike the device counts elsewhere in Reports, this is an occupancy figure: how many were present at a time, not how many passed through in total.

Occupancy, not visits — Twenty people for the whole afternoon and twenty different people passing through both read as twenty. Pair it with Dwell Time to tell those apart.

Source — Two kinds of count, never added together. A counting sensor — a radar or time-of-flight counter in the room — counts every person it sees, tagged or not, and only the ones inside its calibrated coverage. Tags present counts the registered tags the gateways placed in the zone, so a person without a tag is invisible to it. They will disagree wherever not everyone carries a tag; filter by source before comparing spaces.

Peak, not average — Each hour's figure is the most people seen at once in that hour. A room that held ten for a minute and two for the rest reads as ten — the number a capacity question needs; the hour's average is shown beside it in the per-space view.

Per hour, per space — Each cell is its own measurement. Do not add hours together to get a daily total; that counts the same people once an hour.

Where the numbers come from. Counting-sensor rows are updated on every reading the sensor sends, so the current hour is live to within a minute. Tags-present rows are recomputed every fifteen minutes from where the gateways last placed each tag. A day's peak and average are read straight from its hours — nothing is rebuilt overnight. Old monthly partitions are dropped on your tenant's retention setting, so how far back you can look has a limit.

Room Usage Map

/admin/report/room-usage

Where people actually are inside a room, from a radar that reports each person's position. The heat map is the room seen from above: darker cells are where people spent more time over the selected days. A meeting room whose far end never lights up is a room that could be smaller; a desk area with two dark spots and six empty ones is two desks in use.

Only people inside the room's counting area count — the radar sees through glass, and the calibration on the device page tells it where the walls are. Peak occupancy is the most people inside at one moment; average group is the mean while somebody was there; hours occupied are hours with anyone inside, shown against the venue's operating hours that have already happened (a range ending today does not count this afternoon against the room).

A radar writes a position only while it sees somebody, so an empty hour and an hour the radar was off look the same in the positions. The coverage line under the heat map uses the radar's own count rows — written on every reading, zero included — to say how many of the hours judged it was actually awake for; when that is under 80%, the usage figures are a floor, not a verdict.

Rooms appear here only once their radar has been calibrated. The radar places up to five people per frame (ten when paged), so a very full room is sampled rather than counted exactly.

Space Utilisation

/admin/report/space-utilisation

Every zone side by side: how much of its operating time it was occupied, how many people it typically held, whether it ever ran at capacity, and — where the venue has a cost per m² — what the empty hours cost. The portfolio question: which rooms are too big, which too small, and what the underused floor area is buying.

Occupied — An operating hour in which at least one person was seen. The share is taken over the operating hours that have already happened, so a range that ends today does not count this afternoon against a room. The full count of operating hours in range is in the Hours column's tooltip.

Who is counted — Where a zone has a radar or counting sensor, everyone in its coverage. Elsewhere, only people carrying a registered BLE tag — those zones under-report wherever not everyone is tagged, and the seat-planning confidence column says how many zones in a venue count everyone.

Sensor gap — A counting sensor that fell silent leaves hours that are unknown, not empty. A zone whose sensor reported in under 80% of the elapsed operating hours is marked with a warning and a ? on its verdict: its occupancy is a floor. The row names the sensor and when it was last heard; the Devices page has the rest.

Typical and peak — Typical is the 90th-percentile hourly peak among occupied hours — the headcount the room needs to fit on a normal busy hour. Peak is the single highest. Both are shown against capacity when one is set.

Verdict — Unused: never occupied. Underused: occupied under 25% of operating hours. Busy: 70% or more. In use: between. A room used for one long meeting a day and a room used for eight short ones can share a verdict; the hour-of-day profile tells them apart.

Idle cost — The zone's floor area (set on the zone, or taken from the polygon drawn on the floor plan) times the venue's cost per m² per month, times the empty share of operating hours. Only shown when the venue has a cost.

Where the numbers come from. The hourly People Count rows — a counting sensor's rows are updated on every reading, tag rows every fifteen minutes — bucketed into tenant-local days and hours against the venue's operating hours and days. Operating hours come from the venue (or the tenant default); capacity, area and cost from the zone and venue under Spaces. Nothing is rebuilt overnight: the current hour is live.

Sensor Status

/admin/report/device-status

Every hour a registered sensor is heard by a gateway is written to the device-status table, with a note of whether anything it sent that hour decoded to a reading. This report reads those hours back for the range you pick and shows, per sensor, the share of hours it was heard in — availability — and a strip of the hours themselves, so a sensor that drops out every night looks different from one that died on Tuesday.

Heard is not the same as delivering — A green hour carried a reading, a count or an event. An amber hour means the gateway heard the sensor's radio but nothing it sent could be decoded — a temperature sensor advertising only its device-info frame, a switch whose state is not a measurement. A sensor that is amber all range long is alive and not reporting: look at the sensor's model and advertising settings, not at the gateway. Hours before 15 Sep 2026 were recorded on decode only, so older history has no amber.

Availability is against the sensor's own expectations — A fixed sensor is expected every hour from the hour it was registered — a sensor added mid-range is not marked absent for the days before it existed. A tag is expected only while it is on site; its hours off site are not counted against it, so its availability is measured over the hours from its first to its last sighting in the range. An actuator reports on change only and is not scored.

Hours in the future are not counted — A range that ends today is measured up to the current hour.

Which gateway heard it — A sensor heard by one gateway only is a sensor that goes dark when that gateway does. The gateway chips per row are the ones that heard it in the range. A sensor behind the Home Assistant bridge lists the bridge.

Now — The state on the Devices page's rule: reporting within the last hour, late inside its own silence threshold, silent past it. It can say reporting next to a low availability — that is a sensor that is heard now but was not for much of the range, or one heard without readings.

Sensor Trail

/admin/report/device-trail

Where a registered sensor went and how long it stayed — the zone-by-zone history for one device. Pick an entity instead of a sensor to follow a person or asset across every device bound to them.

Registered sensors only — This follows tags you have registered, not passing phones. If a device is not in your list it has no trail here.

A zone change needs a position fix — The trail is built from positions the engine could resolve. Where coverage is thin the device may appear to jump, or to sit still while it was moving. The Method column says what each stay rests on: triangulated, fused or bounded fixes are positions; presence is only "the nearest gateway is in this zone". "How it was positioned" totals that up for the range.

Stays that cross the range — A stay belongs to the range if any part of it falls inside — a tag that settled somewhere last night and is still there is where that tag is today. Such a stay is marked ← before range; the time tiles and "Where the time went" count only the part inside the range, the Dwell column shows the whole stay.

Still here — A device's latest stay, last seen within the last ten minutes, has not ended. Its Left says so instead of showing the last sighting as if the device had gone.

One stay, several pieces — The engine writes a new piece each time it places the device in a different zone. Pieces on the same floor less than five minutes apart are shown as one stay — a tag drifting between two adjacent zones is one visit to that floor — and the row then names the zones with the time in each. "Where the time went" and "How it was positioned" are counted on the pieces, so a floor-level stay still credits each zone with its own time. Leaving a floor and coming back is two stays.

A stay marked "overlaps later stays" — The engine reopened an old stay when the device came back to that zone, stretching it over hours the device spent elsewhere. Rows written before 15 Sep 2026 can carry this; the "Where the time went" total credits that zone with more than its share for such rows. Fixed at the writer since.

Entity mode — Follows the person or asset rather than the hardware, stitching together every tag bound to them — so replacing a tag does not break the history.

Custom Reports

/admin/report/dynamic

Build your own report: choose a data table, pick the metrics and the dimensions to group by, and save it to run again. For the questions the fixed reports do not answer.

You are querying the same data — These read the same tables as the reports beside them, so the same units apply — a device is still a radio, a stay is still not a person.

Group by changes the meaning of a count — The same metric grouped by zone and by venue will not sum to the same number, because a device seen in three zones counts in each.

Saved reports re-run, they do not snapshot — Opening a saved report runs it again over its date range, so a relative range moves with time.

Times are your clock — Date and hour groupings are on the organisation's time zone, and the date range is applied on that clock too — the same days the fixed reports show.

Devices Detected has two kinds of row — One per hour and one per day, both counting distinct devices. Group by hour and you read the hourly rows; otherwise the daily rollup — never both, which would count every device twice.

Two sources, never added — Temperature and People Count carry a source: a fixed sensor in the room, or a roaming tag / the tags present. Group by source before summing or averaging across it, or a wall sensor and a tag in a pocket blend into a number that is neither.

Names, not ids — A location, venue, zone, gateway, device or rule in a grouping shows its name; the CSV keeps the id underneath.

Impact Events

/admin/report/impact-events

Record something that happened — a promotion, a layout change, a closure — and compare the period after it against the period before, for the locations, venues or zones it applied to.

Before and after, not cause and effect — A difference across the boundary is a correlation. Weather, holidays and anything else you did that week land in the same window.

Scope decides the comparison — An event scoped to one zone is measured on that zone only. Scope it wider than it really applied and the effect gets diluted by spaces it never touched.

Give it comparable periods — A week against a week reads cleanly; a week against a long weekend does not. The comparison is on the per-day rate, so a three-day event is not measured against a seven-day week as if both were totals.

What is measured — Device-days: distinct BLE devices seen in the scope on each day, from the daily Devices Detected rollup (your calendar days), and the average of that per day. Avg dwell: from the Dwell Time buckets, each stay counted at its bucket's midpoint. A window still running is rated on the days that have happened, and says so.

Zone compare

/admin/report/zone-compare

Two zones side by side across ten measures — unique devices, entries, peak and average occupancy, capacity utilization, anomalies, battery alerts, work orders, busiest hour and busiest day — with the difference marked on each.

Compare like with like — A lobby and a meeting room differ on every row, and none of it is interesting. The comparison earns its keep between two spaces meant to behave the same way.

Capacity utilization needs a capacity — It is occupancy against the capacity set on the zone. A zone with no capacity recorded cannot report it.

A worse number is not always a problem — Higher occupancy is good in a shop and bad in a fire escape. The markers point at the difference, not at a verdict.

Meeting Room

/admin/report/meeting-room

How the meeting rooms are actually being used over the selected window — how much they are booked, how often a booking goes unused, and how much of the booked time is real.

Booked is not used — The gap between the two is the point of this report. A room booked solid and empty half the time is the most expensive room you have.

No-show — A booking with no presence detected in the room. A room whose sensor is flat or missing will look like nothing but no-shows.

Utilization — Occupied time against available time. Read it next to booking volume — low utilization with low bookings is a room nobody wants, low utilization with high bookings is a booking habit.