How to connect office pod occupancy sensors to Power BI

Instead of manually counting booth use, connect office pod occupancy sensors to Power BI through a repeatable sensor-data export, then build a report from time-based occupancy records. Start with a CSV import to validate the numbers before automating collection and refresh.

Why this matters

A sensor message is not a booking, a person count or an occupied minute. Your report needs a defined interpretation of each reading before it can support decisions about booth demand.

Soundbox Store acoustic office pods suit businesses seeking private workspaces; occupancy reporting needs a separately verified sensor-data connection. For a single-person workspace, the Quell Office Pod Solo is a relevant commercial starting point. The reporting workflow below does not assume that this pod includes a sensor, an API or a Power BI integration.

Keep the responsibilities separate: the sensor platform records presence, your data preparation converts readings into intervals, and Power BI presents the results. That separation makes faults easier to find.

Before you start

• Sensor-platform access: Obtain an export containing a stable sensor identifier, reading timestamp and documented occupancy state. Confirm whether the platform records periodic samples, state changes or completed occupancy intervals.
• Reporting access: Have Power BI Desktop and permission to publish to your intended Power BI workspace. Ask your administrator to confirm the access and refresh arrangements needed by report readers.
• Refresh access — the easily missed dependency: A CSV on your computer does not become accessible to the Power BI service just because you publish the report. For the local-file route below, arrange an on-premises data gateway and a file location its service account can read before scheduling refresh.

Also decide who owns the sensor-to-pod mapping. A device identifier that changes without an updated mapping can split one pod's history into separate records.

Sensor data and reporting route

Choose the connection route

Use the connection route your sensor platform actually supports. A repeatable CSV export is best for validating the reporting model; a supported database connection is best for maintaining an established reporting pipeline.

Route	Best for	Advantage	Limitation
CSV export imported into Power BI	Initial validation and a small reporting pilot	Lets you inspect records before building calculations	Automated reporting still needs a repeatable export and accessible file location
Supported database connector	An existing managed sensor-data pipeline	Separates collection from report development	Requires database access, maintained tables and suitable refresh configuration

Neither route establishes compatibility between a particular sensor and a particular pod. Confirm that separately with the relevant suppliers; do not infer it from the presence of a smart lock, booking system or network connection.

Prepare an interval table

1. Export a small period of sensor history using the platform's documented export process. Retain the original file for checking.
2. Create a pod register with one row per physical pod. Use a stable pod_id, a readable pod_name and a sensor_id mapping.
3. Convert readings into bounded intervals in your data-preparation process. For state-change data, pair each reading with the next reading from the same sensor, ordered by timestamp.
4. Split intervals at reporting-day and office-hours boundaries. Preserve UTC timestamps and derive the local reporting date using the location's time-zone rules.
5. Produce the following reporting fields. These are suggested field names for your prepared table, not claimed fields from a sensor vendor.

Field	Meaning
pod_id	Stable identifier for the physical pod
report_date	Local date used for daily reporting
occupied_minutes	Valid observed time classified as occupied
known_minutes	Valid observed time classified as occupied or vacant
eligible_minutes	Time included in the defined reporting schedule
last_observed_utc	Latest observation represented in the prepared record

Preserve the detailed intervals upstream so you can investigate a daily total. Aggregate the reporting table to one row per pod and reporting date, with the latest observation timestamp for that group.

Expected result: Every reported minute has a defined classification, and every reporting row maps to a physical pod.

Define missing-data behaviour

Do not extend the last occupied state indefinitely when a device stops reporting. Apply the sensor platform's documented state-validity or timeout behaviour; where none exists, agree and record an analytical rule before publishing results.

A change-only feed also needs a known starting state. Retrieve the last valid event before the reporting window rather than assuming the pod started vacant.

Treat time without a valid state as unknown. Exclude unknown time from known_minutes, but retain it within eligible_minutes when it falls inside the reporting schedule. This makes observation gaps visible instead of disguising them as unused capacity.

Power BI import and utilisation model

Import the prepared file

1. Open Power BI Desktop and select Get data, then Text/CSV.
2. Select the prepared reporting file and choose Transform Data. Check the delimiter and column headings before continuing.
3. In Power Query Editor, rename the query PodIntervals. Set identifiers to text, minute fields to Decimal Number, and report_date to Date.
4. Check that minute fields are non-negative and that occupied time does not exceed known time. Check that known time does not exceed eligible time for each reporting row.
5. Select Close & Apply to load the table.

Do not replace every null with zero. A missing duration is not evidence of a vacant pod; correct its classification in the preparation process first.

Expected result: PodIntervals loads without type errors, and its totals reconcile with the prepared source file.

Create time-based measures

1. Select New measure and create the following measures. The names and fields depend on the prepared table above.

Occupied minutes =
SUM(PodIntervals[occupied_minutes])

Known minutes =
SUM(PodIntervals[known_minutes])

Eligible minutes =
SUM(PodIntervals[eligible_minutes])

Observed utilisation =
DIVIDE([Occupied minutes], [Known minutes])

Observation coverage =
DIVIDE([Known minutes], [Eligible minutes])

2. Format Observed utilisation and Observation coverage as percentages.
3. Add a table visual containing pod_id, report_date and the measures. Compare a selected pod and day against the source intervals.
4. Check a period with no valid observations. Keep the utilisation result blank rather than forcing it to zero.

For an arithmetic illustration, 20 occupied minutes within 40 known minutes gives 50% observed utilisation. If the reporting schedule contains 60 eligible minutes, observation coverage is approximately 66.7%. These are example calculations, not measured workplace results.

Use the ratio of total minutes, not an unweighted average of pod percentages. Otherwise, a pod with little observed time can influence the combined result as much as a pod with complete coverage.

Expected result: Your report distinguishes actual observed use from the completeness of the observations.

Build the report page

1. Add Slicer visuals for report_date and pod_id.
2. Add cards for Occupied minutes, Observed utilisation and Observation coverage.
3. Add a daily chart showing observed utilisation by pod. Keep coverage visible alongside it rather than hiding it on a separate page.
4. Add last_observed_utc to a table visual and label it clearly as a UTC observation timestamp.
5. Add a short report note defining the office-hours schedule, occupied state and missing-data treatment.

A presence sensor that only reports occupied or vacant cannot establish how many people used a meeting booth. Keep person-count and seat-utilisation metrics out of this model unless the source explicitly provides validated counts.

Expected result: A facilities manager can see use, coverage and freshness without confusing them with bookings or headcount.

Publication and refresh configuration

Publish the validated report

1. Save the Power BI Desktop file, then select Publish and choose the intended workspace.
2. In the Power BI service, open the semantic model's Settings.
3. Configure Gateway and cloud connections for the local-file source using the gateway connection prepared by your administrator.
4. Complete Data source credentials where required. Confirm that the source location remains accessible independently of your personal desktop session.
5. Run a manual refresh and inspect Refresh history before enabling Scheduled refresh.

Choose a schedule that matches how often the export is actually updated. Refreshing an unchanged file more frequently does not create newer observations.

Expected result: The published semantic model refreshes successfully without depending on your computer being open and signed in.

Validate an end-to-end update

1. Observe a controlled occupied-to-vacant change using the sensor platform's documented test process. Record the times for comparison; do not alter the device configuration without the responsible administrator.
2. Confirm that the new reading reaches the raw export.
3. Confirm that preparation produces the expected interval and reporting totals.
4. Refresh the semantic model and check the report's latest observation timestamp.
5. Compare the new totals with the source, including any documented sensor detection delay.

A successful refresh only proves that Power BI processed its source. It does not prove the source received fresh sensor readings.

Expected result: You can trace an observed state change from the sensor platform through to the published report.

Update Power BI whenever sensor data changes

For an established pipeline, replace the file hand-off with a supported database source containing the same reporting fields. Keep sensor ingestion separate from Power BI so delayed readings and corrections can be handled before reporting.

1. Have the data owner write validated occupancy intervals and daily reporting totals to the database.
2. In Power BI Desktop, select Get data and choose the connector matching that database.
3. Select Import for a refresh-based model. Consider DirectQuery only where the connector supports it and the reporting requirements justify the additional source dependency.
4. Reconcile the database-backed measures against the validated file version before replacing the published model.

Import mode retains a refresh boundary; DirectQuery queries the source during report interactions, but does not make delayed sensor ingestion instant. Neither route should be described as a live availability system without testing the complete data path.

Best for: Teams with a maintained database pipeline and a clear freshness requirement. The trade-off is greater dependence on database performance, permissions and ongoing ownership.

Troubleshooting

The report counts messages instead of occupied time

A chatty sensor contributes more rows, not necessarily more use. Replace message counts with bounded intervals and calculate utilisation from occupied and known minutes.

Utilisation rises above the reporting window

Check for duplicate exports, overlapping intervals and multiple active sensor mappings for the same pod. Resolve duplicates using a source event identifier where available; do not remove legitimate repeated state readings merely because their values match.

The report refreshes but the timestamp stays old

Check the export or database ingestion timestamp before changing Power BI settings. Confirm that the reporting source contains new records and that the preparation process includes them.

Desktop refresh works but service refresh fails

Check gateway availability, source-path consistency and the gateway service account's read access. A local path accessible to your user account is not automatically accessible to the gateway.

Daily patterns shift by an hour

Inspect UTC conversion, daylight-saving handling and office-hours boundaries. Derive local reporting dates with the correct time-zone rules rather than applying a fixed offset throughout the reporting period.

Customise your workflow

Keep the first release focused on pod-level demand. Soundbox Store supplies acoustic office pods in different configurations; your reporting register should describe the physical workspace without assuming its sensor capabilities.

Add a pod-type field to compare single-person workspaces with meeting booths, but retain separate definitions for occupied-pod time and occupied-seat time. A booth being occupied does not establish that every seat is in use.

Next, compare occupancy intervals with booking intervals using the same pod identifier and time basis. Classify booked-but-unoccupied periods separately from unbooked use, and preserve unknown sensor periods rather than labelling them as missed bookings.

Assign an owner to the export, mapping table, preparation process and published report. A dashboard without those owners becomes difficult to correct when devices move or data stops arriving.

FAQ

One last thing

An empty chart and an empty pod are not the same thing. Before using a low-utilisation result to change workspace provision, inspect observation coverage and the latest reading. Missing data is a reporting problem, not evidence that a booth is unnecessary.

Related guides

• How to calculate how many pods your office floor needs
• How to measure ROI for office pod investment
• How to manage pod booking and scheduling in the office