Does one account cover all our sites?
Yes, and it is the default rather than something to switch on. Every building you add sits in the same account, every list and report opens on the whole estate, and what differs between one country and the next — working hours, public holidays, the local clock — is carried by the building and its schedules. Several properties, hotels or campuses under one account: what is set per building, what stays account-wide (branding, badge design), and how each report is scoped. What is not comparable across sites, said plainly.
Yes. One Offision account holds every office, campus and region you run. There is nothing to merge, federate or connect: a second site is a second building, added on the same page as the first.
Open LocationsEverything is filed under a building
Every room, desk, panel, screen, sensor and floor plan sits on a floor, and every floor sits in a building. That is the whole hierarchy, and it is why buildings live under Directory rather than under Booking — they are not a booking concept, they are where everything else is filed.
A building is added in the same place whether it is your second or your thirtieth. See Add a building and its floors.
Every list opens on the whole estate
The default direction matters, and it is the opposite of what people expect from systems they have had to join together: a page in Offision starts with everything and is narrowed by a filter. It is never widened by one.
The booking calendar, the device list, the visitor records, the reports — each opens on the whole estate, and the floor or building picker on it is a way of seeing less. So “can we see all sites in one place” is not a feature to look for; it is what the page does before you touch it.
What actually differs per site
An office in Tokyo and an office in London do not run on the same clock or the same calendar, and three objects carry that difference. None of them is a separate system.
| What differs | Where it is set | What it decides |
|---|---|---|
| The local clock | The building’s pin on the map | Its time zone, worked out from where the pin is — there is no time-zone field. See How the map location is used. |
| Open days and hours | A Booking hours schedule, applied to resources | When those rooms may be booked, counted in the schedule’s own time zone. See Limit booking times to business hours. |
| Public holidays | The Public calendar inside that schedule | Which whole days are closed, subscribed per country. See Close the office on public holidays. |
So a Tokyo schedule and a London schedule are two records in one account, each with its own time zone and its own country’s holidays. Nobody has to keep them in step, because they were never meant to agree.
Which is why estate-wide numbers already allow for it
A usage rate compares booked hours against available hours, and the available hours are each resource’s own business hours, with its own closed days and its own public holidays taken out. Add up a floor, or the whole estate, and the bottom line is every resource’s own hours summed — a Tokyo room measured against Tokyo’s working week, a London room against London’s.
That is the normalisation, and it is on by default in Business hours mode. See What a room’s usage rate counts.
What is per building, and what is account-wide
Several properties — hotels, campuses, a landlord’s buildings — run under one account the same way several offices do. Three things are worth knowing before the question “can each property have its own…” comes up:
| Per building | Account-wide |
|---|---|
| Address and map pin, and the time zone that follows from it | The account name |
| Visiting: visiting types, forms, terms, receptionists, opening hours, visitor licences | Branding — the login page logo, the home page logo, the email logo, the logo on room and desk panels, and the visitor badge logo are each set once for the whole account |
| Booking hours and public holidays, through the schedules applied to that building’s resources | The visitor badge design |
| Which floors, rooms, desks, panels and screens it holds | Booking policies, panel designs and signage content, which any building may use |
So per-property branding is not something Offision does: a hotel group’s properties share one set of logos, and a badge printed in one property looks like a badge printed in another. Where the logos are set is in Where your company’s name, address and logo are set.
Reporting is scoped by what a report can filter on, and that differs by report: booking reports by floor (each building is a heading in the floor picker), the usage pivot by Location, which is the building, and visitor reports by building. A branch, below, narrows what an administrator’s console shows and therefore what their reports open on — which is the nearest thing to “separate reporting per property”.
Branches narrow the console, not the data
Where several campuses each have their own administrators, branch management files every building and every administrator under a branch, so each one manages their own site and never meets the one beside it.
It is worth being precise about what that is and is not. A branch decides which slice of the estate an administrator’s console shows them. It is not a wall between two companies sharing one account, and it is not a per-site database. An account with no branches — which is the default — is one flat estate.
What you cannot compare across sites
Utilisation is the usual reason for asking, and most of it is comparable: every rate is estate-wide by default and already normalised per site. These are the honest limits, so they are not discovered in a report:
- Booking reports filter by floor, not by building. The floor picker lists each building as a heading with its floors under it, so a site is reachable, but there is no “one row per building” filter. See Which report answers which question.
- The pivot’s Location dimension is the building, and there is no floor dimension. So “hours per building” is a report you can build, and “hours per floor, every site side by side” is not. See See how much your rooms are used.
- The heat map’s floor picker only scopes the map. The ranking, trend, top users and peak hours beneath it stay estate-wide whatever floor is showing. See See which rooms are worth the space.
- Data residency is per account, not per region. An account lives in one data centre, chosen when it is created. Several regions inside one account is not something Offision offers.
- Visitor badge design is company-wide, even though visiting forms, opening hours and receptionists are all per building.