Core Data
Location Data
Location data defines the buildings and spaces Trebellar should track and provides the headcount and capacity context used to calculate attendance and utilization.
At a minimum, Trebellar requires building-level information to get up and running. More detailed space- and workstation-level data can be added over time to support additional features and analyses.
Structure-Level Data
Structure-level data defines the buildings Trebellar tracks and provides the foundation for attendance and utilization calculations across the platform.
Each row in the table below represents a single building (structure). See the field descriptions below for details on each column.
Fields:
Structure (required): Name of the building. Must be unique within your organization.
Address (required): Full street address of the structure.
Timezone: Timezone in IANA format (TZ identifier).
Floors: Comma-separated list of floors. If left blank, a default floor is created.
Headcount: Number of workers assigned to the structure.
Seats: Number of seats assigned to the structure.
Square Feet: Total square footage of the structure.
External ID: Alternate identifier used to map external datasets (such as badge data) to this building.
While headcount, seats, and square feet are optional, they are used in attendance and utilization calculations and are strongly recommended for producing meaningful insights.
Space-Level Data
Space-level data defines the individual spaces within a building, such as meeting rooms, common areas, and other shared spaces. This data is optional at onboarding but supports more detailed utilization analysis and space-specific insights.
Each row in the table below represents a single space within a building. See the field descriptions below for details on each column.
Fields:
Structure (required): Name of the building where the space is located. Must match a structure defined in Structure-Level Data.
Floor (required): Name of the floor within the structure where the space is located.
Space (required): Name of the space.
Capacity: Assigned capacity of the space.
Bookable: Indicates whether the space can be reserved.
External ID: Alternate identifier used to map external datasets (such as room booking or sensor data) to this space.
Space-level data can be added at any time and is commonly used to support meeting room analytics, booking insights, and more granular utilization reporting.
Workstation-Level Data
Workstation-level data represents individual desks or seats within a building. This data is optional at onboarding and is typically used to support more granular seating, allocation, and utilization analysis.
Each row in the table below represents a single workstation. See the field descriptions below for details on each column.
Fields:
Structure (required): Name or external ID of the building where the workstation is located. Must match a structure defined in Structure-Level Data.
Floor (required): Name or external ID of the floor within the structure where the workstation is located.
Space: Name or external ID of the space or neighborhood where the workstation is located.
Department: Name or external ID of the department (also referred to as a People Group) assigned to the workstation.
External ID: Alternate identifier used to map related datasets (such as people data) to this workstation.
Workstation-level data can be added at any time and is commonly used for detailed seating analysis and departmental allocation planning.
Badge Data
Badge data captures in-office presence and is used to calculate attendance and utilization across the platform. This data is required to enable attendance-based insights.
Badge data can be provided in either unaggregated (preferred) or aggregated formats. Both options are supported and outlined below.
Any personally identifiable information (PII) should be removed before upload.
Unaggregated Badge Data (Preferred)
Unaggregated badge data provides the most granular view of attendance and enables deeper analysis.
Each row in the table below represents a single badge event.
Fields:
Structure (required): Name of the building where the badge event occurred. Must match a structure defined in Structure-Level Data.
Date (required): Date and time of the badge event. Unix timestamp in UTC is preferred, but other common time formats are accepted. Timezone consistency is critical.
Department: Department or group the badge belongs to.
User (required): Unique identifier for the individual who badged in.
Aggregated Badge Data
Aggregated badge data summarizes badge events by structure and department on a per-day basis. This format is supported when unaggregated data is not available.
Each row in the table below represents the total number of badge events for a given structure, department, and day.
Fields:
Structure (required): Name of the building where the badge events occurred.
Date (required): Date of the badge activity.
If a specific timestamp is not provided, Trebellar assumes the badge events occurred on that date in the timezone of the associated structure.
Department: Department or group the badge entries belong to.
Count (required): Number of badge entries for the structure and department on the given day. Trebellar automatically expands aggregated counts into individual badge events at the start of the business day.
Additional Notes
Floor and space identifiers may be included to associate badge events with more specific locations within a building.
Multiple badge events from the same user on the same day are not double-counted.
If external IDs are provided in location data, they may be used in place of structure, floor, or space names.
Using a consistent user identifier across badge and people datasets enables analysis of attendance patterns by categories of workers, such as departments or other groups. If different identifiers are used, a mapping between datasets will be required.
People and Departments
People and department data provides the context needed to analyze attendance and utilization by categories of workers, such as departments or other organizational groups.
Within Trebellar, these groupings may be referred to internally as People Groups. Most organizations use terms such as Department or ELT. The concepts are equivalent.
People Data
People data represents individual employees and is used to associate badge activity with organizational context.
Each row in the table below represents a single employee.
Fields:
ID (required): Unique identifier for the employee.
Department: Department the employee is assigned to. Strongly recommended, as it enables analysis of attendance patterns by categories of workers. This value must match the ID or Name of a department defined below.
Assigned Location (required): Location the employee is assigned to. This is typically a building, but may also reference a specific neighborhood or seat if available.
Postal Code: Postal (ZIP) code of the employee. This is used for commute analysis only and is not used in attendance calculations.
Department Data
Department data defines the organizational groups used to categorize people and analyze attendance patterns across the portfolio.
Each row in the table below represents a single department.
Fields:
ID (required): Unique identifier for the department.
Name (required): Human-readable name of the department.
Description: Optional description of the department.
Why this matters
When people and department data are consistently mapped to badge data, Trebellar can analyze attendance and utilization across different categories of workers, such as teams or organizational groups, rather than only at the building level.
Optional Data
The datasets below are not required to get started, but can be added over time to support additional analysis and insights across the platform.
Lease Data
Lease data provides cost and lease context for locations and is used to support financial analysis, reporting, and AI-driven recommendations.
Fields:
Lease Start Date (required): Start date of the lease.
Lease End Date (required): End date of the lease.
Payment Amounts (required): Lease payment amounts (monthly, quarterly, or annual).
Currency: Currency of the lease payments. Defaults to USD.
Monthly Non-Rent Expenses: Ongoing expenses such as utilities, maintenance, or other operating costs.
External ID (required): External ID of the location (structure, floor, or space) the lease applies to.
Sentiment and Engagement Data (NPS)
Sentiment data, most commonly Net Promoter Score (NPS), is used to understand employee experience by location and analyze how engagement varies across the portfolio.
Fields:
User: Unique identifier for the employee. Should match an ID in the People dataset.
Date (required): Date the survey or feedback was submitted.
Structure: Building the employee is assigned to.
Score or Responses (required): Overall score and/or responses to individual questions. Including both numeric scores and free-form feedback is preferred.
Room Booking Data
Room booking data is used to analyze meeting room usage and supports insights related to booking behavior and space utilization.
Fields:
External ID (required): Name or external ID of the space where the booking occurred.
Time (required): Date and time of the booking.
Attendees: Users who attended the meeting, including in-person versus virtual participation if available.
Presence or Occupancy Data: If sensors are available, data indicating how many people were physically present and for how long.
Sensor Data
Sensor data enables occupancy, presence, and environmental insights, such as air quality or dwell time.
Sensor data is typically connected to Trebellar via API rather than CSV.