Overview

Butlr provides occupancy and utilization insights based on real-world sensing signals.

A fundamental principle applies across the entire platform:

The data you see - at any level - is determined by the sensors and features configured in your space.

This applies to:

• Floor-level dashboards

• Room and zone views

• Desk-level insights

Understanding this relationship is critical during project scoping to ensure expectations match outcomes.

This article explains:

• How sensor setup maps to data capabilities

• Why data may differ across spaces

• The role of features like PIR Zeroing

• What customers must align on during project scoping

1. The Core Principle: Sensor Setup → Data Capability

Butlr is not a one-size-fits-all sensing system. Each sensor mode captures a different type of signal, which defines what metrics are possible. Read more What are Traffic Mode and Presence Mode?

2. How Sensor Setup Shapes What You See

Different spaces in Butlr may show different data depending on how they are instrumented.

This applies across floors, rooms, and desks.

What this looks like in practice

• Some spaces show real-time occupancy, while others do not

• Some show only IN / OUT activity

• Some include calibrated occupancy and utilization metrics

These differences reflect the signals available in each space, not inconsistencies in the system.

👉 Butlr surfaces only what can be accurately supported by the underlying data

Example

• A floor without entrance coverage → no floor-level traffic insights

• A room with presence sensing → shows live occupancy

• A space with only traffic sensing → shows IN / OUT activity

👉 No signal → no metric

3. Key Limitations to Understand

3.1 Traffic ≠ Real-Time Occupancy

Traffic sensors estimate occupancy by balancing IN and OUT counts.

However:

• Small counting errors accumulate over time (drift)

• Occupancy becomes less reliable without calibration

• Accuracy depends on movement patterns, not just sensor quality

👉 This is why:

• Live dashboards do NOT show floor occupancy from traffic alone

• Occupancy is only shown after calibration (historical view)

3.2 Coverage Determines Completeness

If entrances or areas are not fully covered:

• Occupancy may be undercounted or overcounted

• Some spaces may have no occupancy data at all

Data is only available where sensors are installed:

• Missing entrances → inaccurate floor counts

• Uncovered areas → no data

• Partial deployment → reduced analytics effectiveness

3.3 Presence Reflects Real-World Variability

Presence sensors detect activity within a space, but results can vary based on real-world conditions.

• Measurements are influenced by layout, density, and movement patterns

• Different room types (e.g., open areas vs. enclosed rooms) may behave differently

• Short stays, overlapping movement, or edge-of-coverage activity can affect readings

👉 Variability is expected and indicates the system is capturing dynamic, real-world usage, not static counts

3.4 Calibration Improves Accuracy Over Time

Calibration helps correct drift in inferred occupancy:

• PIR Zeroing provides near real-time correction

• End-of-day calibration improves historical accuracy

4. Project Scoping: What Must Be Aligned

To ensure success, customers must align on what data they expect and how it will be generated.

4.1 Define Required Insights

Examples:

• Flow and traffic trends

• Real-time occupancy

• Space utilization

• Desk usage

Each requires different sensor configurations.

4.2 Define Coverage Scope

Decide:

• Which entrances are tracked

• Which spaces are instrumented

• Whether full or partial coverage is acceptable

4.3 Align on Accuracy Expectations

Customers should understand:

• Some metrics are measured directly (presence)

• Some are estimated (traffic-based occupancy)

• Some are corrected via features (PIR Zeroing)

4.4 Accept Tradeoffs

There is always a balance between:

• Cost

• Coverage

• Accuracy

• Granularity

4.4 Future Expansion Tradeoffs

If higher accuracy is required later:

• Additional sensors may be needed

• This may require:

  • Hardware costs

  • Installation updates

  • Re-scoping

4.5 Acceptance of Limitations

• Data may not reflect true 100% occupancy

• Variances may occur due to uncovered areas

• Butlr is not liable for impacts caused by excluded coverage

5. Key Takeaways

• Sensor setup determines what data exists—at every level

• Traffic, Presence, and PIR Zeroing each unlock different capabilities

• Partial coverage leads to partial truth

• Real-time vs historical data behave differently by design

• Clear alignment during scoping prevents confusion later