> For the complete documentation index, see [llms.txt](https://docs.akenza.io/akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/akenza.io/analytics-use-cases/occupancy-monitoring.md).
# Occupancy monitoring
Occupancy monitoring allows to improve space utilization; allowing saving on real-easte, utilities and cleaning costs as well as enhancing your workplace experience. Yet managing and interpreting occupancy data generated by many sensors is challenging. Akenza offers advanced analytics capabilities to gain insights into your occupancy patterns.
## Example with concurrent desks occupancy
Let's assume we equipped 4 desks with occupancy sensors and we track their state over four hours. Green means the desk is empty, yellow means it was occupied at one point during the hour. Recording the state of a desk every hour, we can represent the time-series of each desk as follows:
On the bottom two lines, we can read that at 12:00 PM only 1 desk was free, at 1:00 PM all were occupied and at 2:00 PM all were free.
## Problem definition and concepts
Based on the example above we define 5 key metrics for tracking occupancy:
* OCCUPANCY\_ABSOLUTE
* absolute count of **occupied** desks
* AVAILABILITY\_ABSOLUTE
* absolute count of **free** desks
* **CAPACITY**
* total number of desks, whose occupancy is tracked/which can be used
* \= OCCUPANCY\_ABSOLUTE + AVAILABILITY\_ABSOLUTE
* OCCUPANCY\_RELATIVE
* relative share (%) of **occupied** desks
* \= OCCUPANCY\_ABSOLUTE */* CAPACITY
* AVAILABILITY\_RELATIVE
* relative share (%) of **free** desks
* \= AVAILABILITY\_ABSOLUTE / CAPACITY
## Business use cases
### "Capacity crunch": Identify periods when no desks are available
> As a property manager, I want to avoid the situation where all desks are occupied and employees cannot find a desk to work.
In the example chart below, we plot an example of occupancy over a working day. At 10:00 AM, we see that the occupancy reaches 100%, corresponding to a "capacity crunch". Employees arriving at 10:00 AM will be unable to find a free desk.
The "capacity crunch" is identified when relative occupancy reaches a maximum over the day. This is the default time aggregation behaviour (MAX over time) of the "concurrent occupancy" aggregation, selectable in datasource section of dashboards:
Additionally, you can also compute the availability (complementary of occupancy) and the capacity. The following screenshot showcases all those capabilities:
## What is the difference with existing occupancy calculation (time-based occupancy in %)?
Additionally to the concurrent occupancy described above, you can also compute a so-called "Time-based occupancy in %" (the underlying algorithm is described there [Querying Device Data](/akenza.io/get-started/reference/api-documentation/querying-device-data.md#time-based-occupancy)).
It can be selected below in the selector of datasource in dashboards:
This time-based occupancy averages occupancy first over time and **then** over desks. It means that it doesn't take into account **whether two desks are occupied at the same time (concurrently)** to compute the occupancy, it only averages the occupancy in % over time and then over desks. Hence the time-based occupancy can only output relative values (%), whereas the concurrent occupancy can either output an absolute number of desks or a relative ones.
{% hint style="info" %}
Both metrics (concurrent occupancy and time-based occupancy) can be useful to analyse and optimize occupancy within a managed building.
{% endhint %}
Let's take two examples to **better understand the differences:**
* Example 1
Here we have two desks which are mostly occupied during the day, with some breaks (meeting, lunch break), optimizing it further looks difficult as it is quite packed. The time-based occupancy would report around 77.5% whereas the concurrent occupancy would report 100%. **In this case, the concurrent occupancy seems to be the "relevant" metric.**
* Example 2
Here we have 2 desks, but one is not used at all during the morning, only in the afternoon. The time-based occupancy reports 60% (averaged over time), whereas concurrent occupancy still reports 100% (because it's maximized over the day). Here we see that there *might be* some optimization potential (e.g. by shifting office policies or using another desk in another floor). **In this case, it was useful to also look at the time-based occupancy in %.**
Hence the time-based occupancy in % can be seen as a "theoratical occupancy". It is always below or equal to the concurrent occupancy.
* time-based occupancy in % can almost never reach 100% (because of breaks, short interruptions), whereas concurrent occupancy can reach it
* if concurrent occupancy reaches 100% but time-based occupancy does not, then there *might be* some optimization potential (by shifting office policies, using another desk in another floor...)
* the "effective occupancy" - which directly reflects the daily workplace experience - is somewhere between time-based occupancy (lower bound) and concurrent occupancy (upper bound)
## TL;DR: which occupancy calculation should I use?
{% hint style="info" %}
As a starter, we recommend using the concurrent occupancy logic. When doing in-depth analysis, looking at both metrics is recommended.
{% endhint %}
| Capabilities of each method | Concurrent occupancy | Time-based occupancy |
| ------------------------------------------------------------- | :------------------: | :------------------: |
| Provide absolute figures (e.g. "5 desks are occupied") | :white\_check\_mark: | ❌ |
| Provide relative figures (e.g. 70% of the desks are occupied) | :white\_check\_mark: | :white\_check\_mark: |
| Provide availability and total capacity | :white\_check\_mark: | ❌ |
| Identify capacity crunch | :white\_check\_mark: | ❌ |
| Identify margin for possible "optimizable" space | ❌ | :white\_check\_mark: |
## Limitations
* occupancy data (both concurrent and time-based) are available only at hourly (or higher: daily, weekly ...etc) resolution
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.akenza.io/akenza.io/analytics-use-cases/occupancy-monitoring.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.