Occupancy monitoring

Highlights occupancy use cases for end-users and describes how to implement them with akenza.

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 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.

Both metrics (concurrent occupancy and time-based occupancy) can be useful to analyse and optimize occupancy within a managed building.

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?

As a starter, we recommend using the concurrent occupancy logic. When doing in-depth analysis, looking at both metrics is recommended.

Capabilities of each method	Concurrent occupancy	Time-based occupancy
Provide absolute figures (e.g. "5 desks are occupied")	✅	❌
Provide relative figures (e.g. 70% of the desks are occupied)	✅	✅
Provide availability and total capacity	✅	❌
Identify capacity crunch	✅	❌
Identify margin for possible "optimizable" space	❌	✅

Limitations

• occupancy data (both concurrent and time-based) are available only at hourly (or higher: daily, weekly ...etc) resolution