Rockbot Business Glossary
Authoritative reference for consistent terminology across all teams — from board presentations to daily operations
Purpose
This glossary defines the core business concepts that drive Rockbot's operations, revenue, and customer relationships. Use it to ensure accurate reporting and metrics, prevent costly data misunderstandings, onboard new team members, and align cross-functional communication.
Why This Glossary Exists
Rockbot started as a modern jukebox for bars and restaurants, then pivoted to enterprise background streaming when the sales team discovered the platform was a superior commercial media service. The data model never caught up with that pivot. Terminology accumulated across teams — "customer" means different things to Sales, Product, and NetSuite. "Brand" got misused across systems. The Revenue Architecture Redesign (RAR) is fixing the data model; this glossary fixes the language.
Rockbot's Two Businesses
Rockbot effectively operates as two separate businesses with different sales motions, deal cycles, and data patterns. Understanding this is critical for interpreting metrics correctly:
- SMB / Midmarket: Fast sales cycle, single-location or small portfolio deals, operator = customer = brand in most cases. Simpler data model — one Account, one Location, one Zone.
- Enterprise / Franchise: Complex, multi-stakeholder deals. Brand, Operator, and Billing Entity are often three different companies. Master contracts with long ramp-up periods where Contracted ARR significantly leads Consumed ARR. This is where the franchise model complexity lives.
The Three Questions Every Executive Asks
| Question | Answer | Key Insight |
|---|---|---|
| "How many customers do we have?" | Count of Contracting Customers | Billing entities are not customers. NetSuite "customers" are not customers — they're payment methods. Contracting Customer count is much smaller than billing arrangement count. Use Consuming Customer count for utilization metrics. |
| "What's our total ARR?" | Sum of Contracted ARR | Use Contracted ARR for forecasting. Consumed ARR shows utilization. Never add them together. |
| "Who pays for what?" | Billing Entity → Subscription → Zone | The company relationship (Account) is separate from who receives invoices (Billing Entity). |
Critical Distinctions
| These Are Different | Why It Matters |
|---|---|
| Account vs. Billing Entity | One customer can have many invoicing arrangements |
| Location vs. Zone | One address can have multiple hardware units |
| Contract vs. Subscription | What we agreed vs. what we're actually delivering |
| Contracted vs. Consumed ARR | Promise vs. reality — especially in franchise deals |
| Brand vs. Operator vs. Owner | Three different companies can be involved in one location |
| NetSuite Customer vs. Salesforce Customer | A NetSuite "customer" is a payment method / billing entity — not an actual customer |
| Logo (product) vs. Brand (Salesforce) | Product team's "logo" = dumb branding assets. Salesforce "Brand" = the Account relationship on a Location |
| Contract (product) vs. Contract (business) | Product team's "contract" = content rules and permissions. Business "contract" = legal agreement with pricing |
| Contracting Customer vs. Consuming Customer | Who signs vs. who uses — critical for franchise reporting |
Account — The business we do business with
A single legal business entity — the company behind the relationship, regardless of how many locations they operate, contracts they sign, or ways they pay. One company = one Account, always.
System of Record: Salesforce (primary), synced to NetSuite and Admin Platform
Why It Matters
Account is the foundation of all customer metrics. When we count "customers," we count Accounts. When we measure customer health, retention, or lifetime value, we measure at the Account level. Getting this wrong inflates customer counts and distorts strategic decisions.
Key Attributes
| Attribute | Description |
|---|---|
| Name | Legal business entity (e.g., "Planet Fitness Holdings LLC") |
| Record Type | Customer, Partner, or Franchisor |
| Contracted ARR | Total value committed across all contracts |
| Consumed ARR | Actual revenue being generated |
| Location Count | Physical sites associated with this account |
| Contract Count | Number of active contracts |
| Customer Status | Active, Inactive, or Former (derived) |
Business Rules
- One Account per legal entity — never duplicate for payment or contract changes
- Record type determines available fields and processes
- Parent-child relationships only between same record type
- Contracted ARR and Consumed ARR tracked separately (differ in franchise scenarios)
- Account is not Billing Entity — Who pays invoices is tracked separately
- Account is not Payment Method — Changing credit cards doesn't create a new Account
- One company with 50 franchises = ONE Account, not 50
Location — A physical place where Rockbot delivers service
A real-world address — a gym, restaurant, retail store, or any brick-and-mortar site with Rockbot hardware installed. Locations exist independently of who owns, operates, or brands them.
System of Record: Salesforce (Physical_Location__c custom object)
Why It Matters
Location count is a key operational metric. It answers "How many places do we serve?" and drives hardware deployment, support coverage, and market penetration analysis. Locations also reveal the complex relationships in franchise businesses.
Key Attributes
| Attribute | Description |
|---|---|
| Physical Address | Street, city, state, postal code (required) |
| Location Type | Single-Tenant, Multi-Tenant, Shared-Facility, or Mobile |
| Brand | The brand customers see (e.g., Planet Fitness) |
| Operator | Who manages daily operations (e.g., Blackduck Partners) |
| Owner | Property owner, if tracked |
| Primary Account | Formula field: returns Brand if populated, else Operator, else Owner |
| Guidelines | Brand standards applied to this location |
| Zone Count | Hardware units installed at this address |
| Total ARR | Revenue generated from this location |
| Status | Active, Inactive, Pending, or Closed |
The Three Location Relationships
| Relationship | Question It Answers | Required | Example |
|---|---|---|---|
| Brand | "What brand do customers see?" | Yes | Planet Fitness |
| Operator | "Who runs this location?" | No | Blackduck Partners |
| Owner | "Who owns the property?" | No | Main Street Properties LLC |
Business Rules
- Location defined by physical address, not Account ownership
- At least one of Brand, Operator, or Owner should be populated
- Brand typically populated for franchise locations; Operator for the entity managing day-to-day operations
- Every Zone must have a parent Location
- One Location can have Zones from multiple Subscriptions (split billing)
- Location is not Account — A location is a place, not a company
- One location can involve multiple Accounts (Brand, Operator, Owner)
- Locations are defined by address, not by business relationship
Zone — Individual hardware delivering Rockbot services
A single hardware unit — a screen or media player — installed at a specific area within a Location. It's where service actually happens: the TV in the cardio area, the display behind the front desk.
System of Record: Salesforce (Zone__c, master), synced to NetSuite (billing) and Admin Platform
Why It Matters
Zones are the atomic unit of service delivery and billing. ARR flows up from Zones. When we ask "What are we charging for?", the answer is Zones. Each Zone connects a physical Location to one or more billing Subscriptions.
Business Rules
- Every Zone must belong to exactly one Location
- One Zone can have multiple Subscriptions (e.g., music + digital signage)
- One Location can have multiple Zones under different Subscriptions
- Zone ARR = sum of Product Line Item monthly values across all its Subscriptions
- Zone is not Location — Multiple zones can exist at one location
- Zone is not Subscription — One zone can have multiple subscriptions for different services
Contract — The formal agreement defining what we'll deliver and at what price
The legal agreement between Rockbot and a customer Account. It defines the rates, terms, duration, and scope of services we've committed to provide. Contracts establish the financial relationship; Subscriptions fulfill it.
System of Record: Salesforce (source of truth), PandaDoc (document creation)
Why It Matters
Contracts are the source of Contracted ARR — the revenue we've promised. They determine pricing for all downstream billing. When rates need to change, we modify Contracts. When we want to know "what did we agree to?", we look at Contracts.
Key Attributes
| Attribute | Description |
|---|---|
| Account | The customer this contract belongs to |
| Start Date / End Date | Contract term |
| Status | Draft, Active, Expired, Terminated |
| Contract Line Items | Specific products and rates included |
| Contracted ARR | Total annual value committed |
- Contract is not Subscription — Contract = what we agreed; Subscription = what we're delivering
- One Contract can have multiple Subscriptions as zones are added over time
Contract Line Item — A specific product or service with its contracted rate
The individual lines within a Contract that specify which products the customer has purchased and at what price. They're the pricing source for Product Line Items on Subscriptions.
System of Record: Salesforce, synced to NetSuite
Key Attributes
| Attribute | Description |
|---|---|
| Contract | Parent contract |
| Product | The service being provided |
| Monthly Rate | Price per month |
| Quantity | Number of units contracted |
Subscription — The billing arrangement that collects revenue for delivered services
The billing mechanism that connects a Contract to actual service delivery. It groups Zones together for invoicing purposes and tracks what's actually being consumed versus what was contracted.
System of Record: NetSuite (primary), synced to Salesforce
Zone-Subscription Relationship
Zones and Subscriptions have a many-to-many relationship. One Zone can have multiple Subscriptions (e.g., a single screen receiving both music service and digital signage). One Subscription can cover multiple Zones (e.g., a single billing arrangement for all zones at a location).
Why It Matters
Subscriptions are where revenue actually happens. They track Consumed ARR — what we're billing for right now. The gap between Contracted ARR (from Contracts) and Consumed ARR (from Subscriptions) reveals ramp-up progress or utilization issues.
Key Attributes
| Attribute | Description |
|---|---|
| Contract | Parent contract defining rates |
| Billing Entity | Who receives invoices |
| Zones | Hardware units covered by this subscription |
| Product Line Items | Actual services being delivered and billed |
| Status | Active, Suspended, Cancelled |
| Consumed ARR | Annual revenue from active Product Line Items |
- Subscription is not Contract — Many Subscriptions can exist under one Contract
- Subscription is not Billing Entity — Subscription is what; Billing Entity is who
Product Line Item — A specific service being delivered and billed on a Subscription
The actual services being delivered to a specific Zone under a Subscription. They inherit rates from Contract Line Items and generate the charges that appear on invoices.
System of Record: NetSuite, synced to Salesforce
Business Rules
- Rates must reference Contract Line Items — never enter manually
- Product Line Item ARR rolls up to Subscription and Account Consumed ARR
- Each Product Line Item connects to one Zone
Billing Entity — Who receives invoices and makes payments
An invoicing arrangement — a specific entity that receives bills and makes payments. One Account can have multiple Billing Entities (different divisions, franchisees, or payment arrangements), but each Billing Entity belongs to one Account.
System of Record: NetSuite (primary), synced to Salesforce
Why It Matters
Billing Entity separates "who is our customer" (Account) from "who pays the bills" (Billing Entity). This distinction is critical: our customer count (Accounts) is far smaller than our billing arrangement count (Billing Entities).
Business Rules
- Billing Entity is about who, not how — payment method changes don't create new Billing Entities
- One Account can have multiple Billing Entities
- Each Billing Entity has one or more Payment Methods
- NetSuite "customer" records map to Billing Entities, not Salesforce Accounts
- Billing Entity is not Customer — Billing entity count ≠ customer count
- Billing Entity is not Account — Many Billing Entities can exist under one Account
- NetSuite "customer" is not a customer — It's a billing/payment entity
- Card expired? Update Payment Method, don't create new Billing Entity
Payment Method — How a Billing Entity pays their invoices
The specific instrument used to pay — credit card, ACH, check, etc. Payment Methods belong to Billing Entities and can change without affecting the billing relationship.
System of Record: NetSuite + Paystand
ARR (Annual Recurring Revenue) — The annual value of recurring revenue, measured two ways
Contracted ARR
The total annual value committed in signed Contracts. Use for forecasting, investor reporting, and capacity planning. Source: Contract Line Items.
Consumed ARR
The actual annual revenue being generated by active Subscriptions. Use for cash flow analysis and utilization tracking. Source: Product Line Items (via NetSuite_Subscription__c.ARR__c).
ARR Date Semantics
ARR calculations depend on understanding three distinct dates that often differ — especially in enterprise and franchise deals:
| Date Type | Source Field | Definition | Use For |
|---|---|---|---|
| Contract Date | Contract__c.StartDate | Date the agreement was legally executed | Forecasting, "deals closed" reporting, Contracted ARR start |
| Service Billing Start | NetSuite_Subscription__c.Start_Date__c | Date billing charges begin (first invoice date) | Cash flow, MRR/ARR recognition, Consumed ARR start |
| Activation Date | Zone__c.Activation_Date__c | Date hardware went live and service began | Utilization tracking, consumption metrics |
- Never add Contracted and Consumed ARR together — they measure different things
- Gap between them = ramp-up remaining or over-utilization
- In franchise deals, one Account's Contracted ARR may be consumed by many Operator Accounts
- Use Contract Date for forecasting, Service Billing Start for revenue recognition
Guidelines — Brand-specific content rules applied to Locations
Formerly known as Logo__c in Salesforce. Brand-specific content rules applied to Locations.
System of Record: Salesforce, synced to Admin Platform
Guidelines define what content can play at a Location — the music genres, video types, and messaging approved by the Brand. They ensure consistency across all locations operating under a brand's standards.
- Logo (product term) — Intentionally "dumb." Just visual branding assets: colors, images, the logo file itself. No business logic.
- Guidelines / Contract (product term) — The "smart" layer. Content rules, permissions, what music can play, what messaging is approved. This is what the product team calls a "contract."
- Brand (Salesforce term) — An Account relationship on a Location. Represents the company whose name is on the door. NOT the same as "logo" or "guidelines."
Domain — A web identity used for lead routing and account deduplication
A web identity tied to an Account. Domains serve two critical operational functions: routing inbound leads to the correct Account, and preventing duplicate account creation.
System of Record: Salesforce (Domain__c)
Key Fields
| Field | Purpose | Example |
|---|---|---|
Domain_URL__c | Raw input as entered | https://www.planetfitness.com/locations |
Clean_Domain__c | Normalized, unique External ID for matching | planetfitness.com |
Business Rules
- One Account can have many Domains (redirects, regional sites, etc.)
- One Domain can only exist on one Account
- When a lead comes in via any Domain, it routes to the associated Account
Why It Matters
Without proper Domain mapping, inbound leads from secondary websites would create duplicate accounts. For example, if a prospect fills out a form on a regional redirect URL, the Domain object ensures they're matched to the existing parent Account rather than creating a new record.
Brand / Operator / Owner — The three ways an Account can relate to a Location
Every Location can have up to three Account relationships, each answering a different question about who's involved with that physical site.
| Role | Question | Typical Use |
|---|---|---|
| Brand | "What name is on the door?" | Franchise parent (e.g., Planet Fitness). Typically NOT the contracting party. |
| Operator | "Who manages day-to-day?" | The entity running the location (e.g., Blackduck Partners). Typically the contracting party. |
| Owner | "Who owns the property?" | Real estate owner, if relevant |
Contracting vs. Consuming Account — Who signs the deal vs. who uses the service
Contracting Account
The Account that signs the Contract and commits to the ARR. This is where Contracted ARR is tracked. In most Rockbot scenarios, this is the Operator (the entity running the locations), not the Brand.
Consuming Account
The Account(s) that actually use the service at Locations. Consumed ARR rolls up here. In simple cases, the Contracting and Consuming Account are the same entity. In franchise scenarios, they often differ.
Contract Inheritance and Termination
When a master contract is terminated, consuming entities must transition their service. Typical outcomes include:
- Independent contract activation: The consuming entity signs their own contract, becoming both contracting and consuming party
- Service discontinuation: Locations under the terminated contract are deactivated
- Contract transfer: A new contracting party assumes the master agreement (requires legal renegotiation)
The transition path depends on whether the consuming entity has an existing Account relationship and their willingness to contract directly.
Customer — An Account with Record Type = Customer
Customers are the businesses that contract for Rockbot services. They can be the contracting party, the consuming party, or both. Customer count = Account count where Record Type = Customer.
- Product/Engineering (Bill's team): "The person making decisions about what to buy from us" — typically the franchisee/operator, NOT the brand. "It's the franchisees that operate locations that we think of as a customer."
- Sales (Aron's team): The contracting entity — whoever signs the deal and commits ARR.
- NetSuite (Kevin's world): "Coincidentally, that NetSuite customer is just a payment method." A NetSuite "customer" is a billing entity, NOT a customer.
- Canonical definition: A Salesforce Account with Record Type = Customer.
- Customer is not Billing Entity — Customer count is far smaller than billing entity count
- NetSuite "customer" is not a customer — It's a payment/billing entity
- One customer can have hundreds of locations — Planet Fitness is one customer with thousands of locations
Contracting Customer — A Customer Account that has signed a contract with Rockbot
Contracting Customers are the entities with purchasing authority — they sign contracts, commit to ARR, and control upgrades, downgrades, and renewals. Use this count when reporting on contractual relationships or forecasting.
Use For
Sales pipeline reporting, ARR forecasting, customer acquisition metrics, renewal tracking.
Consuming Customer — A Customer Account actively using Rockbot services at one or more Locations
Consuming Customers have active Zones delivering service. They may or may not be the same entity as the Contracting Customer. Use this count when reporting on service delivery or utilization.
Use For
Utilization reporting, support coverage planning, operational metrics, consumption analysis.
Active Customer — Both an active contract AND active service consumption
Active Customers represent the healthiest customer relationships — they've committed contractually AND are actively using the service. This is typically the most meaningful customer count for retention and health metrics.
Formula: Active Customer = Contracting Customer ∩ Consuming Customer (has both)
Use For
Customer health dashboards, retention analysis, executive reporting, board presentations.
Partner — An Account with Record Type = Partner
Partners are businesses that resell or distribute Rockbot services. They bring us customers but aren't the end users. Partners earn commissions or referral fees tracked through Partner attribution.
Partner Attribution
When a Partner sources a deal, the Contract or Subscription tracks the Partner Account for commission and reporting purposes.
Franchisor — An operating entity that manages multiple locations under one or more brand licenses
In Rockbot's simplified model, the Franchisor is typically the contracting party for locations they operate — they sign contracts and commit ARR on behalf of their location portfolio.
System of Record: Salesforce (Account object with Record Type = Franchisor)
Why It Matters
Franchisors are often the primary business relationship in franchise scenarios. A single franchisor may operate hundreds of locations across multiple brands, making them significant contracting partners.
Business Rules
- Franchisors typically contract ARR for their locations
- One Franchisor can operate locations across multiple Brands
- Franchisor appears on Location records as the Operator
- Use Franchisor record type to differentiate from standard Customer accounts
- Franchisor is not Partner — Franchisors don't sell for us; they operate locations and contract services
- Franchisor IS typically the contracting party — They sign contracts for their location portfolio
- One Franchisor, multiple Brands — A franchisor account relates to multiple brands through their locations, not through account hierarchy
Franchisee — A Location characteristic, not a separate object or Account type
Any Location where Brand and Operator are different Accounts is a franchised location. The Operator in this scenario is typically a Franchisor account.
Formula: Brand + different Operator = Franchised Location
Common Mistakes to Avoid — What goes wrong and how to prevent it
| Wrong | Right | Why |
|---|---|---|
| Creating new Account when payment method changes | Add new Payment Method to existing Billing Entity | Preserves relationship history |
| "We have X billing entities as customers" | "We have Y customers with X billing arrangements" | Billing Entity is not Customer |
| Contract = Subscription | Contract defines rates; Subscription = consumption | Different concepts, different purposes |
| Manually entering rates on Product Line Items | Reference Contract Line Item | Ensures billing matches contract |
| Using "Venue" in new documentation | Use "Zone" | Venue is deprecated terminology |
| Assuming franchisors don't contract | Franchisors typically DO contract ARR | They're often the primary contracting party |
| Using "franchisor" and "franchisee" interchangeably | Franchisor = Account type; Franchisee = Location characteristic | Different objects in the data model |
| Using Contract Date for revenue recognition | Use Service Billing Start Date | Contract Date ≠ when billing begins |
| Counting Contracted ARR as revenue | Only Consumed ARR is recognized revenue | Contracted is commitment; Consumed is actuals |
System of Record vs. Source of Truth — Where data is created vs. where it's accessed
These terms are often conflated but serve different purposes in Rockbot's architecture.
Definitions
System of Record: Where content is created. The system where data originates and is initially captured.
Source of Truth: Where systems go to access authoritative data. The reference point all other systems use for that information.
Subscriptions: NetSuite is currently the system of record, but Salesforce subscriptions should eventually drive NetSuite subscription creation — reversing the flow.
Entity Reference
| Entity | Primary System | Salesforce Object | Syncs To |
|---|---|---|---|
| Account | Salesforce | Account | NetSuite, Admin Platform |
| Location | Salesforce | Physical_Location__c | Admin Platform |
| Zone | Salesforce | Zone__c | NetSuite, Admin Platform |
| Contract | Salesforce | Contract__c | NetSuite |
| Contract Line Item | Salesforce | Contract_Line_Item__c | NetSuite |
| Subscription | NetSuite | NetSuite_Subscription__c | Salesforce |
| Product Line Item | NetSuite | — | Salesforce |
| Billing Entity | NetSuite | NetSuite_Billing_Account__c | Salesforce |
| Payment Method | NetSuite + Paystand | — | — |
| Guidelines | Salesforce | Guidelines__c | Admin Platform |
| Domain | Salesforce | Domain__c | — |
The Four Data Paths — How data flows through the system
Understanding how data flows helps interpret reports correctly:
Contract Path
Account → Contract → Contract Line Items
What was agreed.
Physical Path
Account → Location (via Brand/Operator/Owner) → Zone
Where hardware is installed.
Billing Path
Account → Billing Entity → Payment Method
How they pay.
Service Path
Contract → Subscription → Zone → Product Line Items
What services are delivered.
Deprecated Terminology — Legacy terms and their current replacements
| Legacy Term | Current Term | Notes |
|---|---|---|
| Venue | Zone | "Venue" too easily confused with "Location" |
| Franchise / Franchisee | Operator | Adopted Jan 15, 2026. "Operator" is the business-facing term; "Franchisor" remains the Salesforce Record Type |
| Ultimate_Parent | Top_Level_Parent__c | Use Top_Level_Parent__c for hierarchy calculations |
| Logo (Salesforce) | Guidelines / Guidelines__c | The old Logo__c object was renamed. Product team still uses "logo" to mean visual branding assets only |
Cross-Team Terminology Map
The same concept often has different names depending on which team you're talking to. This table is the Rosetta Stone:
| Concept | Product / Engineering | Salesforce / RevOps | NetSuite / Billing |
|---|---|---|---|
| Physical hardware unit | Zone | Zone (Zone__c) | — |
| Physical address | Location | Physical Location (Physical_Location__c) | — |
| Company / business entity | Group (polymorphic, legacy) | Account | Customer (but means payment entity) |
| Visual branding assets | Logo ("intentionally dumb") | Guidelines (Guidelines__c) | — |
| Content rules / permissions | Contract | Guidelines (Guidelines__c) | — |
| Legal agreement / pricing | — | Contract (Contract__c) | Sales Order |
| Who runs the location | Customer | Operator / Franchisor | — |
| Who pays | — | Billing Entity | Customer |
| Unique system identifier | Admin Customer ID | Salesforce Account ID | NetSuite Customer ID |
Key Architectural Principles — The rules that govern the data model
- One Customer, One Account: Never duplicate accounts for payment changes. 67,000 legacy accounts represent only ~2,000 actual customers.
- Location Has Three Account Fields: Brand, Operator, Owner — use whichever apply
- Billing Entity is not Customer: Who gets invoiced is separate from business relationship
- Contract is not Subscription: Agreement vs. actual consumption
- No Double Counting: Contracted and Consumed ARR tracked separately
- Rates Flow from Contracts: Product Line Items inherit rates from Contract Line Items
- Zone, not Venue: Use "Zone" in all new documentation — "Venue" is deprecated
- Operator, not Franchise: Use "Operator" in business-facing contexts — "Franchisor" is the Salesforce Record Type only
- Operators Contract, Brands Don't: Rockbot typically contracts with Operators (the entity running locations), not Brands (the name on the door)
- Many-to-Many Zone-Subscription: One zone can have multiple subscriptions; one subscription can cover multiple zones
- Hierarchy Uses Top_Level_Parent__c: NOT Ultimate_Parent — calculated via batch jobs and formula fields
- Three Dates for ARR: Contract Date (forecasting), Service Billing Start (recognition), Activation Date (utilization)