Cisco Spaces Occupancy Day 2 Guide

OVERVIEW

The Cisco Spaces Occupancy Day 2 Guide provides Day 2 operational guidance for Occupancy outcomes in Cisco Spaces. It is intended for customers, partners, and Cisco teams who are responsible for ongoing operations, monitoring, and optimization of occupancy data after an initial deployment is complete.

Cisco Spaces Occupancy capabilities enable organizations to understand how spaces are actually used, from campus and building levels down to floors, zones, and rooms. These insights support outcomes such as space optimization, capacity planning, safety and compliance, and improved workplace experiences. While achieving these outcomes begins with a successful deployment, their long-term value depends on effective Day 2 operations.

Purpose of This Guide

The purpose of this guide is to:

• Describe ongoing operational tasks required to maintain accurate and reliable occupancy data

• Define monitoring, reporting, and troubleshooting practices for occupancy outcomes

• Provide guidance on how to interpret and act on occupancy insights over time

• Support continuous improvement and alignment with business and facilities objectives

This guide focuses on operational excellence after go-live, rather than initial setup.

Intended Audience

This guide is intended for:

• IT operations teams managing Cisco Spaces

• Facilities and workplace experience teams consuming occupancy insights

• Partners supporting managed services or ongoing operations

• Cisco internal teams supporting customer success and adoption

The guidance assumes familiarity with Cisco Spaces concepts, location hierarchy, and deployed occupancy technologies.

Scope

The Cisco Spaces Occupancy Day 2 Guide applies to occupancy outcomes delivered through Cisco Spaces applications such as:

• Space Utilization

• Right Now

• Space Manager

• Related occupancy and location analytics capabilities

Technology-specific deployment details (e.g., sensor placement, onboarding steps) are intentionally minimized and referenced back to the deployment runbook where appropriate.

Relationship to the Occupancy Deployment Runbook

This document is not a replacement for the Cisco Spaces Occupancy Deployment Runbook.

• The Deployment Runbook focuses on Day 0 / Day 1 activities, including:

  • Architecture and technology selection

  • Prerequisites and onboarding requirements

  • Initial configuration of Cisco Spaces and supporting technologies

  • Validation of occupancy data at deployment time

• This Day 2 Occupancy Operations Guide focuses on:

  • Ongoing health and accuracy of occupancy data

  • Monitoring and dashboards

  • Reporting and analytics usage

  • Troubleshooting common operational issues

  • Long-term optimization and outcome realization

Readers should ensure that occupancy has been successfully deployed and validated according to the deployment runbook before relying on this guide for operations.

OPERATIONAL PRIORITIES & KPI’S

Once Cisco Spaces Occupancy has been successfully deployed, Day 2 operations shift focus from enablement to sustained value delivery. The primary objective of ongoing operations is to ensure that occupancy data remains accurate, reliable, and actionable, and that it continues to support business and workplace outcomes over time.

Cisco Spaces includes a Monitor page in the dashboard that displays system and app health details such as connected locations, anomalies, and app latency or uptime status. These operational signals help validate the KPIs listed above and should be used as part of routine checks. Refer to Section 3 for specifics on accessing and interpreting these monitoring screens within Cisco Spaces.

This section defines the core operational priorities for occupancy and the KPIs that teams should monitor to validate success.

Day 2 Operational Priorities

Day 2 operations for occupancy in Cisco Spaces typically align to the following priorities:

Data Accuracy and Trust

Occupancy insights are only valuable if stakeholders trust the data. Operational teams must ensure:

• Occupancy counts reflect real-world usage patterns

• Location hierarchy, maps, and metadata remain accurate

• Data collection is consistent across time and locations

Maintaining trust in the data is foundational for adoption by facilities, real estate, and business teams.

Availability and Continuity

Occupancy data should be continuously available to support:

• Real-time monitoring (e.g., Right Now)

• Historical analysis (e.g., Space Utilization)

• Scheduled reports and dashboards

Day 2 operations must identify and address gaps caused by device outages, connectivity issues, or configuration drift.

Outcome Alignment

Operational teams should continuously validate that occupancy insights are aligned with intended outcomes, such as:

• Space optimization and consolidation

• Capacity planning and growth forecasting

• Safety, density monitoring, and compliance

• Improved employee and visitor experiences

This often requires collaboration between IT, facilities, real estate, and workplace stakeholders.

Operational Efficiency

Day 2 operations should minimize manual effort by:

• Standardizing monitoring and reporting

• Leveraging alerts and dashboards

• Establishing repeatable processes for troubleshooting and maintenance

Key Performance Indicators (KPIs)

The following KPIs help measure the health and effectiveness of occupancy operations in Cisco Spaces. Not all KPIs will apply to every deployment; teams should select those that best align to their use cases.

Occupancy Data Health KPIs

These KPIs indicate whether occupancy data is being collected and processed correctly:

• Percentage of locations reporting occupancy data

• Frequency of missing or stale occupancy data

• Consistency of occupancy counts over time

• Sensor or device reporting status (where applicable)

Application Availability KPIs

These KPIs measure the operational availability of Cisco Spaces occupancy applications:

• Availability of Space Utilization dashboards

• Availability of Right Now real-time occupancy views

• Successful generation of scheduled reports

Accuracy and Validation Indicators

While absolute accuracy can vary by technology, operational teams should track indicators such as:

• Expected vs. observed occupancy trends (e.g., weekdays vs. weekends)

• Sudden or sustained anomalies at room, floor, or building levels

• Correlation between occupancy data and known events or schedules

These indicators help identify when deeper investigation or recalibration may be required.

Usage and Adoption KPIs

These KPIs help assess whether occupancy outcomes are being consumed and acted upon:

• Number of active users accessing occupancy dashboards

• Frequency of report exports or views

• Stakeholder feedback from facilities and real estate teams

Adoption is a key signal that occupancy data is delivering value.

Operational Ownership

Clear ownership is critical for effective Day 2 operations. Organizations should define:

• Who monitors occupancy data health

• Who responds to alerts or anomalies

• Who owns reporting and stakeholder communication

• How issues are escalated and resolved

Defining ownership upfront helps ensure occupancy outcomes remain reliable and aligned with business needs.

MONITORING & DASHBOARDS

Effective Day 2 operations for occupancy outcomes in Cisco Spaces rely on continuous monitoring and visibility across the entire system. Monitoring ensures that occupancy data remains reliable, applications remain available, and insights continue to reflect real-world space usage.

Cisco Spaces supports monitoring through multiple complementary mechanisms, including:

• Built-in dashboards and monitoring views within the Cisco Spaces user interface

• Programmatic access to telemetry and events via the Cisco Spaces Firehose API

Together, these mechanisms enable both operational awareness and integration with external monitoring, analytics, or automation systems.

Monitoring Objectives

The primary objectives of monitoring occupancy in Cisco Spaces are to:

• Validate that occupancy data is being collected and processed consistently

• Detect issues that could impact data accuracy, timeliness, or availability

• Provide confidence in real-time and historical occupancy insights

• Enable proactive response to anomalies before they affect downstream systems or stakeholders

Monitoring should be treated as a continuous operational discipline, regardless of whether insights are consumed directly in Cisco Spaces or externally.

Layers of Monitoring

Occupancy monitoring in Cisco Spaces spans multiple layers, each contributing to overall system health and outcome reliability.

Platform and Service Health

At the highest level, operational teams must ensure that the Cisco Spaces platform and enabled services are functioning as expected. This includes:

• Overall platform and service availability

• Health of occupancy-related applications

• Processing latency that could affect dashboards, reports, or data streams

These signals confirm that the platform is capable of delivering occupancy insights.

Data Flow and Continuity

Monitoring should confirm that occupancy data:

• Is continuously generated by source technologies

• Flows reliably through the Cisco Spaces platform

• Is delivered without significant gaps or delays

This applies equally to data viewed in the Cisco Spaces UI and data consumed through APIs such as the Firehose.

Location and Hierarchy Coverage

Occupancy monitoring should account for coverage across the full location hierarchy, including:

• Campuses, buildings, and floors

• Zones and rooms where applicable

Operational teams should be able to identify:

• Locations that are not reporting occupancy data

• Changes in reporting behavior at specific hierarchy levels

These gaps may surface visually in dashboards or programmatically through missing or inconsistent data streams.

Consumption and Delivery Monitoring

Occupancy outcomes are often consumed through multiple channels:

• Cisco Spaces dashboards and reports

• External systems consuming data via the Firehose API

Monitoring should validate that:

• Dashboards and reports remain accessible and current

• Firehose streams are active and delivering expected events

• Downstream systems continue to receive and process occupancy data

This ensures continuity of outcomes across the entire ecosystem.

Dashboards and Streams as Operational Tools

Both dashboards and data streams play a central role in Day 2 operations:

• Dashboards provide consolidated, human-readable views of system health, trends, and anomalies.

• Firehose API streams provide near real-time telemetry that can be used for:

  • External monitoring and alerting

  • Custom analytics and visualization

  • Integration with ITSM, facilities, or data platforms

Operational teams may use one or both mechanisms depending on organizational needs, but the monitoring goals remain the same.

From Monitoring to Action

Monitoring is only valuable if it leads to action. Day 2 occupancy operations should establish:

• Thresholds or conditions that trigger investigation

• Defined responses to common monitoring signals

• Escalation paths when issues affect business outcomes or downstream systems

Triggers may originate from:

• Visual indicators in Cisco Spaces dashboards

• Missing, delayed, or anomalous data observed via the Firehose API

• Alerts generated by external systems consuming occupancy data

These scenarios are explored in later sections.

Relationship to Cisco Spaces Monitoring Capabilities

Cisco Spaces provides built-in monitoring views within the platform as well as programmatic access to occupancy data and events via the Firehose API. Together, these capabilities support a holistic monitoring strategy for Day 2 occupancy operations.

Subsequent sections will provide more detailed guidance on:

• Routine configuration checks

• Alerting and thresholds

• Troubleshooting common occupancy issues

• Operational best practices for sustained outcomes

ROUTINE CONFIGURATION CHECKS

Day 2 occupancy outcomes depend on the ongoing correctness of configuration, not just the initial deployment. Over time, changes to spaces, devices, organizational structures, or business requirements can introduce configuration drift that impacts occupancy data quality and reliability.

Routine configuration checks help ensure that Cisco Spaces continues to reflect the current physical and organizational reality of the environment.

Purpose of Routine Checks

The goals of routine configuration checks are to:

• Maintain accuracy and trust in occupancy data

• Detect configuration drift before it impacts reporting or decision-making

• Ensure alignment between physical spaces and digital representations

• Support consistent monitoring and troubleshooting

These checks should be performed on a regular cadence and as part of any significant change to the environment.

Location Hierarchy Validation

The Cisco Spaces location hierarchy (campus, building, floor, zone, room) provides the structural foundation for all occupancy insights. Day 2 operations should periodically verify that:

• Locations are correctly defined and organized

• Hierarchy relationships accurately reflect real-world layouts

• New or modified spaces are properly represented

• Deprecated or unused locations are cleaned up

Inaccuracies at this layer can propagate through dashboards, reports, and APIs, resulting in misleading occupancy outcomes.

Maps and Spatial Metadata

Digital maps and spatial metadata play a critical role in occupancy visualization and analytics. Routine checks should confirm that:

• Floor maps are current and aligned with physical layouts

• Zones and rooms are correctly drawn and labeled

• Spatial boundaries match intended use cases (e.g., open areas vs. enclosed rooms)

Changes such as renovations, space reconfiguration, or repurposing should trigger map and metadata reviews.

Device and Data Source Association

Occupancy outcomes rely on correct association between data sources and locations. Operational teams should verify that:

• Devices or sensors remain assigned to the correct locations

• New devices are properly onboarded and mapped

• Decommissioned or relocated devices are updated or removed

• Data sources align with expected occupancy use cases

Incorrect associations can lead to over-counting, under-counting, or missing occupancy data.

Application Configuration Consistency

Cisco Spaces applications that deliver occupancy outcomes may include configurable parameters such as:

• Reporting intervals and aggregation levels

• Thresholds for alerts or notifications

• Visibility and access controls

Routine checks should ensure that application settings:

• Remain consistent with operational goals

• Reflect current stakeholder requirements

• Have not been unintentionally altered over time

Change Management Considerations

Routine configuration checks should be closely aligned with change management processes. Any of the following events should prompt additional validation:

• Physical space changes or renovations

• Organizational or tenant changes

• Device replacements or technology upgrades

• Updates to reporting or monitoring requirements

Documenting configuration changes and their impact on occupancy outcomes helps maintain long-term stability and operational clarity.

Cadence and Ownership

Organizations should define:

• How often routine configuration checks are performed

• Which teams are responsible for specific checks

• How findings are documented and addressed

Common cadences include monthly reviews and post-change validations, but frequency should align with the pace of change in the environment.

REPORTS & ANALYTICS

Reports and analytics are the primary mechanisms by which occupancy data is translated into insight and action. In Day 2 operations, the focus shifts from simply viewing occupancy data to using it consistently and confidently to support planning, optimization, and decision-making.

This section describes how reporting and analytics should be approached operationally, independent of any specific visualization or export method.

Purpose of Occupancy Reporting

The purpose of occupancy reporting in Cisco Spaces is to:

• Provide evidence-based visibility into how spaces are used

• Support trend analysis over time as well as point-in-time views

• Enable informed decisions related to space planning, consolidation, and investment

• Establish a common, trusted data source for multiple stakeholders

Effective reporting helps ensure that occupancy outcomes extend beyond IT and are embedded into business and facilities processes.

Types of Occupancy Insights

Day 2 operations typically support multiple categories of occupancy insights.

Historical Utilization Trends

Historical reporting helps answer questions such as:

• Which buildings or floors are underutilized or overutilized?

• How usage patterns change by day of week or time of day

• How occupancy evolves over months or quarters

These insights are commonly used for space optimization and long-term planning.

Comparative Analysis

Comparative analytics enable teams to:

• Compare usage across locations or regions

• Identify inconsistencies in space utilization

• Benchmark performance before and after changes (e.g., return-to-office initiatives)

This type of analysis supports continuous improvement efforts.

Exception and Outlier Identification

Reports can also be used to identify:

• Unexpected spikes or drops in occupancy

• Locations that consistently deviate from expected patterns

• Anomalies that warrant deeper investigation

These insights often feed into alerting and troubleshooting workflows.

Reporting Cadence and Rhythm

Day 2 occupancy reporting is most effective when it follows a defined cadence, rather than being ad hoc.

Common reporting rhythms include:

• Weekly summaries for operational awareness

• Monthly reports for facilities and workplace teams

• Quarterly reviews aligned to real estate and planning cycles

Establishing a consistent rhythm helps normalize occupancy data as part of routine decision-making.

Stakeholder Consumption

Occupancy analytics are typically consumed by multiple stakeholders, including:

• IT and operations teams monitoring system health

• Facilities teams managing space usage

• Real estate and workplace strategy teams planning future needs

• Business leaders evaluating workplace effectiveness

Day 2 operations should ensure that:

• Reports are aligned to stakeholder needs

• Metrics are clearly defined and consistently interpreted

• Occupancy data is presented in a way that supports decision-making, not just observation

Delivery Models for Reports and Analytics

Occupancy insights may be delivered through multiple mechanisms, such as:

• Native dashboards and reports within Cisco Spaces

• Scheduled exports for offline analysis

• Integration with external analytics or business intelligence platforms via APIs

Regardless of delivery model, operational teams should ensure that:

• Reports are generated reliably and on schedule

• Data sources remain consistent over time

• Changes to reporting logic are communicated to stakeholders

Operational Considerations

As part of Day 2 operations, teams should periodically validate that:

• Reports continue to reflect current location structures and use cases

• Metrics remain relevant as business needs evolve

• Stakeholders understand how to interpret occupancy data correctly

Reporting should evolve over time, but changes should be intentional and well-governed to preserve trust in the data.

ALERTING & THRESHOLDS

Alerting enables operational teams to move from passive monitoring to proactive management of occupancy outcomes. In Day 2 operations, alerts help surface conditions that require attention, investigation, or action before they impact decision-making or downstream systems.

This section defines how alerting and thresholds should be approached conceptually for occupancy in Cisco Spaces, independent of any specific implementation method.

Purpose of Alerting in Day 2 Operations

The purpose of alerting is to:

• Highlight conditions that deviate from expected behavior

• Reduce reliance on manual dashboard reviews

• Enable timely response to issues affecting data quality or availability

• Protect the integrity of occupancy insights used by stakeholders

Effective alerting focuses on exceptions, not normal operational behavior.

Types of Alerting Scenarios

Alerting for occupancy outcomes typically falls into several categories.

Data Availability and Continuity

Alerts may be triggered when:

• Occupancy data stops reporting for one or more locations

• Data becomes stale or delayed beyond acceptable thresholds

• Coverage gaps appear in the location hierarchy

These alerts help ensure continuity of reporting and analytics.

Data Quality and Anomalies

Alerts can also surface unexpected behavior, such as:

• Sudden spikes or drops in occupancy

• Occupancy patterns that contradict historical trends

• Inconsistent reporting between related locations (e.g., floor vs. room)

These signals often require investigation rather than immediate remediation.

Application and Delivery Issues

Alerts may indicate:

• Unavailability of occupancy dashboards or reports

• Failures in scheduled report generation

• Disruptions in data delivery to external systems

These alerts help protect downstream consumers of occupancy data.

Business and Operational Thresholds

In some cases, alerts are tied directly to business conditions, such as:

• Density thresholds being exceeded

• Sustained underutilization or overutilization

• Conditions relevant to safety, compliance, or experience objectives

These alerts may be consumed by non-IT stakeholders.Defining Meaningful Thresholds

Defining Meaningful Thresholds

Thresholds should be defined carefully to avoid alert fatigue. Effective thresholds:

• Are based on historical baselines and expected patterns

• Vary by location type or hierarchy level

• Distinguish between transient anomalies and sustained conditions

Thresholds may evolve over time as occupancy patterns change.

Alert Sources and Mechanisms

Alerts related to occupancy may originate from multiple sources, including:

• Visual indicators or notifications within Cisco Spaces

• Programmatic signals derived from Firehose API data

• External systems that consume occupancy data and apply their own logic

Regardless of source, alerts should be:

• Actionable

• Clearly understood by the receiving team

• Mapped to defined response processes

Response and Escalation

Alerting must be paired with clear response expectations. Day 2 operations should define:

• Who receives specific types of alerts

• What initial actions are expected

• When and how issues are escalated

Not all alerts require immediate action, but all alerts should have a defined owner.

Review and Tuning

Alerting strategies should be reviewed periodically to ensure they remain effective. Reviews should consider:

• False positives and alert fatigue

• Missed conditions that should have triggered alerts

• Changes in occupancy patterns or business requirements

Alerting is not static; it should mature alongside the occupancy deployment.

Example Alerting Implementations

The following examples illustrate common ways organizations implement alerting for occupancy outcomes. These are examples, not requirements.

Example 1: Alerts Within Cisco Spaces

Where

• Cisco Spaces dashboard and monitoring views

What

• Visual indicators of anomalies

• Status of locations, apps, and data health

• Immediate operational awareness

Best For

• Human-in-the-loop operations

• Daily or weekly operational reviews

• First-line detection

These alerts typically require manual review rather than automated notification.

Example 2: Alerts via Firehose API and External Monitoring

Where

• Third-party monitoring or analytics platforms
  (e.g., Splunk, Elastic, Datadog, custom BI)

What

• Missing or delayed occupancy events

• Sustained threshold violations

• Data volume or pattern anomalies

Best For

• Automated alerting

• Integration with ITSM workflows

• Large or distributed deployments

In this model, thresholds are defined outside Cisco Spaces, using Firehose data as the signal source.

Example 3: Hybrid Alerting Models

Where

• Cisco Spaces for visibility

• External systems for alerting and escalation

What

• Cisco Spaces confirms the issue visually

• External systems generate alerts and tickets

Best For

• Enterprises with established NOC or SOC processes

Connector Health and Performance Monitoring

Connector health is a critical component of alerting for occupancy outcomes, particularly when data is consumed by external systems. Even when Cisco Spaces is operating normally, connector degradation can prevent occupancy insights from reaching downstream consumers.

Common Connector Health Signals

• Connector availability (up/down)

• Message or event delivery rate

• Processing latency

• Resource utilization (CPU, memory)

• Errors and service issues

Alerting Use Cases

• Connector becomes unavailable

• Message rate drops below expected baseline

• Sustained resource saturation

• Services impacted on the connector or errors present

These alerts are typically implemented in:

• The Cisco Spaces connector monitoring interface (where available)

• External monitoring platforms observing connector behavior

• Container or platform-level monitoring tools

Connector health alerts should be treated as delivery-impacting events, even if occupancy data generation appears healthy within Cisco Spaces.

TROUBLESHOOTING

Despite well-designed monitoring and alerting, Day 2 operations will occasionally encounter issues that affect occupancy outcomes. Troubleshooting focuses on identifying root causes, validating assumptions, and applying corrective actions to restore confidence in occupancy data.

This section outlines common troubleshooting scenarios and the types of actions typically taken to resolve them.

Troubleshooting Approach

Effective troubleshooting of occupancy outcomes follows a consistent approach:

1. Identify the symptom (what appears wrong)

2. Scope the impact (which locations, apps, or consumers are affected)

3. Validate data flow and configuration

4. Apply targeted corrective actions

5. Monitor for resolution and stability

This approach applies regardless of whether issues are detected via dashboards, alerts, or external systems consuming occupancy data.

Common Symptoms and Investigation Areas

Missing or Stale Occupancy Data

Symptoms

• Locations show no occupancy data

• Reports contain gaps or missing periods

• Firehose streams stop delivering expected events

Investigation Areas

• Platform and application health

• Data source connectivity

• Location hierarchy and associations

• Recent configuration or environmental changes

Unexpected Occupancy Spikes or Drops

Symptoms

• Sudden increases or decreases in occupancy

• Patterns that do not align with historical baselines

• Inconsistent counts across related locations

Investigation Areas

• Changes in user behavior or schedules

• Temporary events or anomalies

• Data source behavior and aggregation

• Filtering or inclusion logic

Inflated or Skewed Occupancy Counts

Symptoms

• Occupancy consistently higher than expected

• Guest or non-business traffic influencing metrics

• Discrepancies between Wi-Fi-based and sensor-based data

Investigation Areas

• Scope of data sources contributing to occupancy

• Inclusion or exclusion criteria (e.g., SSIDs or device types)

• Alignment between occupancy use case and data sources

Corrective Actions

• Refine occupancy data scope to align with business-relevant traffic

• Adjust inclusion or exclusion criteria for data sources

• Validate changes through trend comparison and monitoring

This is a common scenario where SSID filtering or equivalent scoping mechanisms may be applied to improve data relevance.

Inconsistent Room or Zone-Level Occupancy

Symptoms

• Rooms appear occupied when they are not

• Adjacent spaces show conflicting occupancy patterns

• Room-level insights do not match expectations

Investigation Areas

• Map accuracy and spatial boundaries

• Device or sensor placement and association

• Aggregation logic between rooms, zones, and floors

Downstream Consumption Issues

Symptoms

• External systems report missing or delayed occupancy data

• Discrepancies between Cisco Spaces dashboards and external analytics

• Alerting failures in integrated systems

Investigation Areas

• Firehose API stream status

• Event volume and filtering logic

• Downstream processing or ingestion pipelines

Corrective Actions

• Validate Firehose stream configuration and continuity

• Refine filters to ensure relevant events are delivered

• Align expectations between Cisco Spaces data and downstream consumers

Validation After Remediation

After corrective actions are applied, operational teams should:

• Monitor affected locations for stability over time

• Compare post-change trends to historical baselines

• Confirm resolution with impacted stakeholders

• Document findings and corrective actions

This helps prevent recurrence and improves future troubleshooting efficiency.

When to Escalate

Issues should be escalated when:

• Symptoms persist after reasonable corrective actions

• Multiple locations or outcomes are impacted

• Issues affect safety, compliance, or business-critical decisions

• Root cause is unclear or systemic

Clear escalation paths help minimize impact and recovery time.

Example Troubleshooting Entry Points

Example 1: Investigating in Cisco Spaces

Go Here When

• Dashboards look wrong

• Locations show missing data

• Occupancy patterns look suspicious

Where

• Cisco Spaces monitoring views

• Location-level dashboards

• App-level health indicators

What You’re Looking For

• Gaps in reporting

• Location-specific anomalies

• App availability issues

Example 2: Investigating via Firehose Data

Go Here When

• External systems report issues

• Dashboards and downstream systems disagree

• You need event-level visibility

Where

• Firehose event streams

• External log or analytics tools

What You’re Looking For

• Missing or delayed events

• Unexpected event volumes

• Filtering or ingestion errors

Example 3: Investigating Environmental or Configuration Changes

Go Here When

• Issues start after a known change

• Only specific locations are affected

Where

• Change records

• Location hierarchy and map configurations

• Device associations

Connector-Related Troubleshooting Scenarios

Symptoms

• Occupancy dashboards appear normal, but external systems receive no data

• Delayed or sporadic occupancy events downstream

• Inconsistent data delivery across connectors

Investigation Areas

• Connector availability status

• Message throughput compared to baseline

• CPU and memory utilization

• Errors or backpressure indicators

• Recent configuration or scaling changes

Corrective Actions

• Restart or scale connector resources (where applicable)

• Adjust throughput or batching parameters

• Investigate downstream ingestion bottlenecks

• Coordinate with platform or infrastructure teams if resource constraints persist

Connector health issues should be resolved before deeper data-level troubleshooting is attempted.

Occupancy outcomes depend on multiple operational layers: data generation, platform processing, connector delivery, and downstream consumption. Issues at any layer can impact outcomes and should be monitored and troubleshot accordingly.

MAINTENANCE & DEVICE MANAGEMENT

Long-term success with occupancy outcomes in Cisco Spaces depends on intentional maintenance and lifecycle management. While monitoring and troubleshooting address immediate issues, maintenance activities help prevent degradation over time and ensure that occupancy insights continue to reflect real-world conditions.

This section outlines the key maintenance considerations for sustaining occupancy outcomes throughout the lifecycle of the deployment.

Maintenance Objectives

The objectives of Day 2 maintenance activities are to:

• Preserve accuracy and consistency of occupancy data

• Ensure continued reliability of data sources and delivery mechanisms

• Align occupancy insights with evolving business and physical environments

• Minimize operational risk through proactive management

Maintenance should be planned and repeatable, rather than ad hoc.

Device and Sensor Lifecycle Considerations

Occupancy outcomes may depend on a variety of devices, sensors, or data sources. Day 2 operations should account for:

• Device health and operational status

• Battery life and replacement cycles (where applicable)

• Firmware or software updates

• Replacement or decommissioning of aging hardware

Changes at the device level should trigger validation of occupancy data to confirm continued accuracy.

Connector and Integration Lifecycle

For deployments that integrate with external systems, connectors play a critical role in delivering occupancy data. Lifecycle considerations include:

• Connector version upgrades

• Scaling or performance adjustments

• Compatibility with downstream systems

• Monitoring resource utilization over time

Connector updates or changes should be coordinated and validated to avoid disruptions in data delivery.

Platform and Application Updates

Cisco Spaces platform and application updates may introduce:

• New capabilities

• Performance improvements

• Behavioral changes affecting data or reporting

Operational teams should:

• Stay informed about platform updates

• Validate occupancy outcomes after significant changes

• Communicate changes that may affect stakeholders or integrations

Environmental and Organizational Changes

Occupancy deployments are influenced by changes beyond technology, including:

• Office renovations or space reconfiguration

• Changes in workplace policies or schedules

• Organizational growth, consolidation, or relocation

Day 2 operations should include processes to:

• Revalidate location hierarchies and maps

• Adjust reporting and analytics assumptions

• Revisit thresholds and alerting logic

Periodic Validation and Review

In addition to continuous monitoring, organizations should perform periodic reviews to:

• Reconfirm alignment between physical spaces and digital representations

• Validate that occupancy insights remain meaningful and trusted

• Identify opportunities for optimization or improvement

These reviews often align with quarterly or semi-annual planning cycles.

Documentation and Knowledge Management

Sustaining occupancy outcomes over time requires clear documentation, including:

• Configuration decisions and assumptions

• Known limitations or caveats

• Historical issues and resolutions

Maintaining this institutional knowledge helps reduce risk during personnel or organizational changes.

PRIVACY & COMPLIANCE CONSIDERATIONS

Occupancy outcomes provide valuable insights into how spaces are used, but they must be managed in a way that respects privacy, complies with regulations, and maintains stakeholder trust. Day 2 operations play a key role in ensuring that occupancy data continues to be protected, properly scoped, and used appropriately throughout the lifecycle of the deployment.

The Cisco Spaces privacy model supports these objectives by defining how data is collected, processed, and protected in compliance with industry standards and customer governance requirements.

Privacy Objectives

The primary privacy objectives for occupancy operations are to:

• Ensure occupancy data is used for aggregate and business-level insights, not individual tracking

• Maintain transparency with stakeholders regarding what data is collected and why

• Align data handling practices with organizational policies and legal or regulatory requirements

• Preserve trust as occupancy insights are shared with broader audiences or external systems

Privacy considerations are ongoing and should be revisited periodically, not just at deployment time.

Cisco Spaces Privacy Model

Cisco Spaces follows a privacy model that distinguishes between the data controller (the customer) and the data processor (Cisco). Under this model:

• Customers determine what data is collected and how it is used — Cisco processes the data on the customer’s behalf.

• Cisco processes only non-sensitive personal data (e.g., network identifiers such as MAC addresses), and does not collect highly sensitive personal data, such as race, health data, or biometric data.

• Cisco does not intentionally collect personal data from minors.

Occupancy outcomes are typically delivered as aggregated, non-PII insights, not as individual tracking or identification. This supports both privacy compliance and broad adoption by business stakeholders.

Data Access and Governance

Occupancy data access should be governed according to organizational roles and responsibilities, including:

• Who can view occupancy dashboards and reports

• Who can export or consume data via APIs

• How access aligns to job functions and least-privilege principles

Governance practices should ensure that data is only accessible to appropriate audiences and that sensitive access paths (e.g., API tokens) are managed securely.

Data Usage and Limitations

Occupancy data in Cisco Spaces may be used for:

• Trend analysis and occupancy reporting

• Space utilization and planning

• Safety and density compliance

• Integration with other operational systems

However:

• The purpose of data collection is defined by the customer, per their governance and agreements with Cisco.

• Data retention and usage policies must be established based on organizational needs and applicable laws, not simply on technical defaults.

Operational teams should document usage policies and ensure stakeholders understand how occupancy data may and may not be used.

Integration with External Systems

When occupancy data is sent to external systems via connectors or APIs (e.g., Firehose streams), additional privacy considerations arise:

• Downstream systems may combine occupancy data with other datasets, potentially increasing data sensitivity

• External systems must enforce their own privacy and access controls

• API consumers must adhere to customer governance and data protection policies

Day 2 operations should govern not only the data within Cisco Spaces, but how it is consumed and protected downstream.

Retention and Lifecycle Management

Data retention for occupancy insights should align with:

• Business analysis needs (e.g., trend comparisons over months or years)

• Regulatory requirements (e.g., GDPR, industry-specific mandates)

• Organizational data governance policies

Operational teams should be able to articulate:

• How long occupancy data is retained in Cisco Spaces

• How long it persists in external analytics platforms

• What processes exist for archiving or deletion when appropriate

Compliance, Logging, and Audit Readiness

Cisco Spaces adheres to recognized security and privacy best practices, including:

• Adoption of Cisco Secure Development Lifecycle (CSDL) processes

• Compliance with industry frameworks such as ISO 27001 and GDPR

• Use of logging, auditing, and privileged access controls to protect data and support incident response processes

Operational teams should be prepared to:

• Explain how occupancy data is collected and processed

• Demonstrate controls around access and usage

• Provide evidence of privacy governance during audits

Communication and Transparency

Maintaining trust requires ongoing communication with stakeholders about:

• What data is collected and why

• How occupancy data is used to support business outcomes

• How privacy and compliance are enforced operationally

Clear messaging helps internal users and external visitors understand the boundary between aggregate occupancy insights and individual tracking, supporting both privacy and adoption.

CONTINUOUS IMPROVEMENT & FEEDBACK

Occupancy outcomes are not static. As organizations, workplaces, and usage patterns evolve, Day 2 operations must continuously adapt to ensure that occupancy insights remain relevant, trusted, and actionable.

This section describes how organizations can apply continuous improvement practices to maximize the long-term value of Cisco Spaces occupancy capabilities.

Purpose of Continuous Improvement

The purpose of continuous improvement in Day 2 occupancy operations is to:

• Ensure occupancy insights continue to support business and workplace objectives

• Refine operational practices based on real-world usage

• Adapt to changes in space design, organizational behavior, and technology

• Strengthen trust and adoption across stakeholders

Continuous improvement ensures that occupancy outcomes mature over time rather than stagnate.

Feedback Loops

Effective improvement depends on structured feedback loops between:

• IT and operations teams managing Cisco Spaces

• Facilities and real estate teams using occupancy insights

• Business stakeholders making planning or investment decisions

Feedback may include:

• Questions about data accuracy or interpretation

• Requests for new reports or views

• Observed mismatches between expected and actual space usage

• Lessons learned from operational issues or incidents

Capturing and acting on this feedback is a key Day 2 responsibility.

Periodic Outcome Reviews

Organizations should establish periodic reviews focused on outcomes, not just system health. These reviews may include:

• Validation of key occupancy KPIs

• Assessment of whether insights are driving decisions

• Identification of underused or overused spaces

• Review of alerting effectiveness and noise levels

Reviews are often aligned with monthly, quarterly, or planning cycles.

Refinement of Monitoring, Alerting, and Reporting

As occupancy patterns change, operational mechanisms should evolve accordingly:

• Monitoring views may be adjusted to highlight new priorities

• Alert thresholds may need recalibration

• Reports and analytics may be refined to better serve stakeholders

Refinement should be deliberate and documented to preserve consistency and trust.

Incorporating Change and Innovation

Continuous improvement also includes evaluating:

• New Cisco Spaces capabilities

• New data sources or occupancy technologies

• Changes in workplace strategy (e.g., hybrid work models)

• Integration opportunities with other systems

Day 2 operations should provide a structured way to test, validate, and adopt changes without disrupting existing outcomes.Measuring Success Over Time

Measuring Success Over Time

Success should be measured not only by system stability, but by:

• Adoption and sustained use of occupancy insights

• Stakeholder confidence in data-driven decisions

• Reduced reactive troubleshooting through proactive operations

• Improved alignment between physical space and business needs

These signals indicate that occupancy outcomes are delivering lasting value.

Closing the Loop

Continuous improvement closes the Day 2 lifecycle by feeding lessons learned back into:

• Operational practices

• Documentation and runbooks

• Deployment assumptions for future rollouts

• Organizational decision-making

This creates a virtuous cycle where each iteration improves both operations and outcomes.

APPENDIX

Appendix A — Day 2 Occupancy Operations Reference Matrix

This reference matrix provides a quick lookup for common Day 2 operational scenarios related to occupancy outcomes in Cisco Spaces. It helps operators quickly determine where to investigate, which monitoring mechanism to use, and which section of this guide provides context.

This appendix is intended as a practical companion to the conceptual guidance in Sections 1–7.

Monitoring, Alerting, and Troubleshooting Matrix

Monitoring Mechanisms at a Glance

Operational Guidance

• Always validate connector health before assuming data generation issues.

• Use historical trends to contextualize anomalies before acting.

• Treat alerting as signal-based, not volume-based.

• Document corrective actions to improve future troubleshooting efficiency.

Appendix B — Day 2 Occupancy Operations Checklist

This checklist provides a practical, repeatable reference for teams responsible for ongoing occupancy operations in Cisco Spaces. It is intended to complement the guidance in Sections 1–10 and can be used as part of routine operations, audits, or handoffs.

Baseline Validation (Post–Go-Live or Major Change)

☐ Occupancy deployment validated using the deployment runbook
☐ Location hierarchy reflects current physical environment
☐ Floor maps, zones, and rooms are accurate and current
☐ Devices, sensors, and data sources are correctly associated
☐ Initial occupancy trends align with expectations

Monitoring Readiness

☐ Cisco Spaces monitoring views reviewed and understood
☐ Key dashboards available and accessible to operators
☐ Firehose API streams active (if used)
☐ External monitoring systems receiving data as expected
☐ Connector health and performance visible (availability, rate, resources)

KPI and Reporting Validation

☐ Operational KPIs defined and documented
☐ Reports aligned to stakeholder needs
☐ Reporting cadence established (weekly, monthly, quarterly)
☐ Historical trends reviewed for baseline understanding
☐ Stakeholders trained on report interpretation

Alerting and Thresholds

☐ Alerting responsibilities clearly defined
☐ Alert sources identified (Cisco Spaces, Firehose, connectors, external tools)
☐ Thresholds based on historical baselines
☐ Alert noise reviewed and tuned
☐ Escalation paths documented

Troubleshooting Preparedness

☐ Common symptoms and investigation paths documented
☐ Access to Cisco Spaces monitoring views verified
☐ Firehose data accessible for investigation (if applicable)
☐ Connector metrics available for diagnosis
☐ Troubleshooting outcomes documented for reuse

Configuration Integrity

☐ Routine configuration check cadence established
☐ Location hierarchy periodically reviewed
☐ Map and spatial metadata validated after changes
☐ Application settings reviewed for consistency
☐ Change management processes aligned to occupancy impacts

Maintenance and Lifecycle Management

☐ Device and sensor lifecycle tracked
☐ Firmware and software update process defined
☐ Connector versions and performance reviewed
☐ Platform updates reviewed for occupancy impact
☐ Periodic validation reviews scheduled

Privacy and Compliance

☐ Data access aligned to role-based governance
☐ Downstream data usage reviewed and approved
☐ Retention policies documented and enforced
☐ Privacy considerations communicated to stakeholders
☐ Audit and compliance readiness maintained

Continuous Improvement

☐ Feedback mechanisms in place with stakeholders
☐ Periodic outcome reviews conducted
☐ Monitoring, alerting, and reporting refined over time
☐ Lessons learned documented
☐ Opportunities for optimization identified and tracked

Ownership and Accountability

☐ Day 2 ownership clearly defined
☐ Backup ownership documented
☐ Operational documentation kept current
☐ Onboarding process for new operators established

Appendix C — Reference Links

This appendix provides authoritative reference material that complements the Day 2 Occupancy Operations Guide. These resources offer deeper technical, architectural, and governance details without duplicating content in this document.

Cisco Spaces Deployment and Operations

• Cisco Spaces Occupancy Deployment Runbook (Cisco Validated)
  Provides Day 0 / Day 1 guidance for designing, deploying, and validating occupancy outcomes.
  https://runbooks.ciscospaces.io/docs/cisco-spaces-occupancy-runbook-cisco-validated

• Cisco Spaces Configuration Guide — Monitoring and Support
  Describes platform monitoring, application health, and operational visibility within Cisco Spaces.
  https://www.cisco.com/c/en/us/td/docs/wireless/spaces/config-guide/ciscospaces-configuration-guide/m_monitoring_and_support.html

APIs, Integrations, and Data Access

• Cisco Spaces Firehose API Documentation
  Reference for programmatic access to occupancy and location events, including integration and downstream analytics use cases.
  https://developer.cisco.com/docs/cisco-spaces-firehose/api/

• Cisco Spaces Developer Documentation
  Broader API and integration reference for Cisco Spaces.
  https://developer.cisco.com/docs/cisco-spaces/

Privacy, Security, and Governance

• Cisco Spaces Privacy White Paper
  Describes Cisco’s privacy model, data handling practices, and compliance posture for Cisco Spaces.
  https://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/dna-spaces/white-paper-c11-742079.html

• Cisco Trust Center
  Central reference for Cisco security, privacy, and compliance information.
  https://www.cisco.com/site/us/en/about/trust-center.html

Cisco Validated and Solution References

• Cisco Spaces Overview and Solution Resources
  https://www.cisco.com/go/spaces

• Cisco Validated Designs (CVDs)
  https://www.cisco.com/c/en/us/solutions/design-zone.html