A chain of stores, plants, or branches produces the same three kinds of record at every site: orders, a utility meter, and a building system. Site Benchmark reads them under one site roster you keep. Square locations and Shopify locations carry the orders. UtilityAPI meters carry the kilowatt-hours and the bill. Metasys trended attributes carry runtime and setpoints. Each period it computes the metrics you define, such as energy per order or fan hours per opening hour, and ranks every site on each one.
Sites that sit far from the group on a metric are proposed for review. A person approves the ranking before it is posted and approves each review before a site manager hears about it. The approved table lands in your warehouse so the next period can be compared with the last.
This is a reference listing. It documents what Fibric would read from Site Benchmark and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
Square locations from GET /v2/locations, with id, name, address, timezone and status, and orders per location from POST /v2/orders/search
Shopify locations through the locations query, and each order's retailLocation, so a sale is credited to the site that took it
UtilityAPI meters with base.service_address and base.meter_numbers, mapped to a site, and their bills with bill_total_kwh and bill_total_cost
UtilityAPI intervals per meter_uid, with kwh readings by start and end, where the utility makes interval data available
Metasys trended attributes and their samples between startTime and endTime, such as supply fan status or a zone setpoint per building
Prior period rankings and site attributes you keep in BigQuery or Snowflake, such as floor area and opening hours
Proposed actions
Target capability: propose the period ranking table, one row per site per metric with rank, value and change from last period, for approval
Target capability: propose a review for each outlier site, naming the metric, the site's value, the group median and the two sites nearest it
Target capability: propose a Slack message to the site's channel through chat.postMessage carrying its rank and the metric that placed it there
Target capability: propose a write of the approved ranking to BigQuery or Snowflake, so next period's change column has a base
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Rank stores on energy per order
Square orders per location_id for the month, divided by the UtilityAPI bill_total_kwh for the meter mapped to that store, ranked across the estate with last month's rank beside it.
Metasys samples for supply fan status per site, summed against Square business hours, so a site whose HVAC runs long after close is proposed for review.
Compare sales per square foot across retail locations
Each Shopify order's retailLocation is credited to a site. Divided by the floor area in your BigQuery roster, the table ranks every site and writes the approved result back for next month.
Once the ranking is approved, propose a chat.postMessage to each site's Slack channel with its rank, its metric values and the group median, so managers see the same table you do.
A commerce connector that records which site took each order: Square, with orders searched by location_ids, or Shopify with retailLocation on the order
An energy connector with per-meter bills or intervals: UtilityAPI or Green Button Connect My Data, with each meter mapped to one site
A building platform connector that serves trended attributes per building, such as Johnson Metasys or Tridium Niagara
A warehouse for the site roster and prior rankings: BigQuery, Snowflake or PostgreSQL
A site roster you keep: which location ids, meter uids and building objects belong to each site, plus floor area and hours
Authentication
Site Benchmark holds no credentials of its own. It reads orders, meters and trends through the connectors you have connected, and every ranking, review and message waits for a person's approval.
Limits
A meter that serves two sites cannot be split by the operator. It ranks that pair as one site until the roster says otherwise.
Utility bills post on the utility's cycle. A site whose bill is not in is ranked on the metrics present and marked incomplete elsewhere.
Square's order search takes at most 10 location_ids per call. Larger estates are read in batches; a ranking is as fresh as the last batch.
The operator ranks. It never changes a setpoint, price, or schedule. A review is a note to a person, not a building system task.
Access and pricing
Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
Two things. The period ranking itself, shown as a table with every site, metric, value and rank, and each outlier review, shown with the site, the metric, and the sites it is compared against. Messages to site channels go out only after both approvals.
Who defines the metrics?
You do. A metric is a numerator from one source and a denominator from another, such as bill_total_kwh over orders, or fan runtime over opening hours. The operator computes what you define and adds no metric of its own.
What record is left?
One entry per period: the sources read, the roster version used, each site's values and ranks, which sites were proposed for review, who approved, and where the table was written. The same period rerun from the same sources produces the same ranking.
Ask about Site Benchmark
Ask about the capabilities and requirements in this listing.
This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy