The conference room on four is booked through a shared calendar that three people can edit and nobody owns. The fitness centre runs on a fob the front desk hands out and mostly gets back. Parking is a spreadsheet with the waiting list on the second tab. None of it is broken enough to fix on a Tuesday, and all of it is why your amenity floor is quieter than the pro forma said it would be.

Amenity management software for commercial buildings is supposed to close that gap. Most of it stops at the booking screen. Booking is the visible half. The half that decides whether an amenity earns its square footage is everything around it: who is allowed in, who pays, what it cost to run, and whether anyone came back a second time.

The amenity you built and the amenity they use

Amenity space gets underwritten as leasing collateral and then lives as an operational service. Those are two different jobs. The second one usually has no owner once the ribbon is cut.

Watch the path a tenant actually takes. They need to know the board room exists, see that Thursday is free, book it without emailing anyone, and get through the door when they arrive with a client. Break any link in that chain and the room becomes "always booked" in the tenant's mind and empty in your utilisation report. Both of those are expensive, and only one of them shows up in a system.

Booking is the easy half

Every calendar tool can hold a reservation. The questions that follow are where buildings lose the thread.

Who is eligible? A tenant on floor three with a full-building membership, a tenant on eleven whose lease includes four hours a month, a vendor who wants the loading dock at 6am. Eligibility is a lease question wearing a booking question's clothes.

Who pays, and how? Some amenities are included, some are billed monthly, some are per use. A building that cannot bill an amenity ends up giving it away, then quietly restricting access to keep the cost down, which is the worst version of both options.

And what happens at the door? A booking that does not reach the access system is a promise your building has not made. The tenant arrives, the badge does not work, and the front desk becomes the amenity.

What good amenity management looks like

Whether you buy something or fix the process you have, these are the requirements worth holding out for.

• One catalogue, priced. Rooms, parking, memberships and events live in one place with their rules and prices attached, not in three calendars and a rate card someone keeps in a drawer.
• Eligibility comes from the lease. What a tenant may book, and how much of it, follows their suite and their agreement rather than the memory of whoever is covering the desk.
• Payment is part of the booking. Card on file, monthly invoice or included allowance, decided at the moment of reservation and not reconciled later from a paper log.
• The reservation reaches the door. A confirmed booking grants the credential for that window and takes it back afterwards, without anyone printing a list.
• Cancellation is as easy as booking. Buildings that make cancelling awkward do not get fewer cancellations. They get no-shows, and a utilisation number that lies.

Utilisation is the number that settles arguments

Ask an owner how the amenity floor is performing and you usually get an anecdote. Ask the same question in a building that tracks reservations and you get a distribution: which spaces fill, which hours are dead, which tenants never book anything.

That last group is the interesting one. A tenant who has never used the amenity they are paying for through their rent is a renewal conversation waiting to go badly. You can act on that a year out. You cannot act on it in the last quarter of the term, which is when most buildings notice.

Utilisation also decides capital. A yoga studio that runs at ten per cent and a bookable board room turning away requests are telling you exactly what to build next. Neither of them will say it out loud.

Parking belongs in the same system

Parking is usually run as its own business with its own vendor, its own gate and its own spreadsheet. That works until a tenant expands, or a monthly parker leaves, or someone wants a day pass for a visiting client at nine in the morning.

The moment parking sits in the same catalogue as the rest of the amenity programme, the awkward cases get easy. A tenant books a visitor space the way they book a room. A monthly account starts and stops with the lease. The revenue lands in the same place as everything else you bill, and you stop discovering in December that the garage has been running at eighty per cent of what it should collect.

The part that is genuinely hard

Adoption. A building can buy the right platform and still watch tenants keep emailing the property manager, because emailing the property manager has always worked.

The fix is not a memo. It is making the new path faster than the old one on the first try: a link in the tenant portal that takes three taps, a confirmation that arrives before they have put the phone down, a credential that is waiting when they show up. Tenants change habits for speed, not for policy.

Events are amenities too, and they die the same way

A tenant events programme starts with a good turnout in month one and a nearly empty room by month four. The usual explanation is that tenants are busy. The real explanation is usually that nobody could see what was on without opening an email from three weeks ago.

Events need the same three things as a board room: visibility in the place tenants already look, a registration that takes one tap, and a capacity number that is real. A coffee morning with twenty places and forty sign-ups is a better problem than a fire safety briefing nobody knew about, and only one of those two failures is visible without a system.

The cost side, which nobody models

Amenity conversations skew to revenue because revenue is the fun half. The cost half decides whether the programme survives a tight budget year.

A bookable floor has a cleaning cost that scales with use, a staffing cost that scales with hours, and a wear cost that arrives all at once in year four. If you cannot say how many hours a space was occupied last quarter, you cannot defend its budget when someone with a spreadsheet comes looking for savings, and the amenity that gets cut is rarely the one that deserved it.

Reservation data solves this quietly. Hours booked, hours used, cost per occupied hour. Three numbers, one of which will surprise you.

Where BuildingHub fits

Reservations, memberships, day passes and monthly parking run through Amenity Hub, with prices and eligibility attached to each product and payment handled at the point of booking. Because it sits in the same platform as Security Hub, a confirmed reservation can carry the access it needs for the window it covers, and hand it back afterwards. Utilisation reporting comes out of the same records, so the question of which spaces earn their footage has an answer rather than an opinion.

At 8:52 on a Monday there are eleven people in your lobby. Four are contractors who were told to ask for someone whose name they have spelled wrong. Three are candidates for an interview on nine. Two are couriers. One is a tenant who forgot their badge. One is a fire inspector, and nobody knows that yet.

The front desk handles all of it with a paper log, a phone and goodwill. That is the system in most multi-tenant buildings, and it holds up until the morning it does not. A tenant visitor management system is what replaces the goodwill with a record, without turning the lobby into an airport.

The front desk is doing three jobs at once

It is checking identity, granting access, and creating a record. Those jobs have different owners and different consequences.

Identity is the tenant's business. The host knows who they invited. Access is the building's business, because the building owns the turnstiles and the lifts. The record is everyone's business the day something goes wrong, and it is the one that gets written last, in the worst handwriting, on the page that later cannot be found.

Most lobby friction comes from asking one person at a desk to carry all three at the same time while a queue builds behind the courier.

What pre-registration actually changes

When a host registers a guest in advance, the building stops improvising. The name is spelled the way the host spelled it. The visit has a date, a window and a destination floor. The credential can be prepared before the guest arrives rather than negotiated at the desk.

It also changes who does the work. Pre-registration moves the data entry to the person who has the information, which is the tenant, and leaves the desk to do the thing only the desk can do: look at the human being in front of them.

What good visitor management looks like

• Hosts register their own guests. From the tenant portal, in under a minute, with a repeat option for the contractor who is here every Wednesday for the next two months.
• The pass is digital and expires. A wallet credential or QR that works for the window of the visit and stops working after it, without anyone collecting a plastic card.
• Approval exists where it is needed. Most visits need none. A rooftop, a data hall or an after-hours entry needs one, and the rule should live in the system rather than in a manager's head.
• Vendors are checked against compliance. If a contractor's certificate of insurance has lapsed, the front desk should know that before the lift does, not after an incident.
• Every entry is searchable. Name, host, company, floor, time in, time out. The record is the point. It should be an export, not an archaeology project.

The evacuation question

There is one question that separates a visitor log from a visitor management system, and it gets asked on the worst day: who is in the building right now?

A paper log can answer who signed in. It cannot answer who signed in and has not left, across three entrances, in the four minutes you have while the alarm is sounding. A live record can, and it can do it on a phone in the assembly area.

Fire wardens and life-safety teams already run this drill. Most of them run it on a clipboard that is out of date the moment the last person walks through the door.

Where visitor management meets access control

Visitor management that does not talk to the door is a very organised waiting room. The value arrives when the registration and the credential are the same event: the host invites, the system issues, the turnstile accepts, the record closes itself when the guest leaves.

This is also where buildings should be careful about rip-and-replace. Most multi-tenant buildings already own an access control system that works, and the tenants already have credentials in it. The right integration adds a visitor layer on top of what is installed. It does not ask a building to re-badge two thousand people to fix a lobby problem.

The tenant experience nobody credits

Ask a tenant what they think of the building and they will tell you about the lift, the temperature, and how their guests were treated. That third one is unmeasured in almost every building and remembered in all of them.

A candidate who was greeted by name at 8:55 tells the hiring manager. A client who stood in a queue for eleven minutes tells the tenant's CEO. Neither of those conversations appears in an operating report, and both of them show up at renewal in a tone you can feel.

What to fix first

If you are starting from paper, the sequence that gets results fastest is unglamorous. Put pre-registration in the tenants' hands. Give the desk a live list for the day. Connect the credential so the turnstile stops being a manual override. Then, and only then, worry about kiosks and badge printers, which solve the part of the problem that was never really the problem.

Contractors are not guests

A visitor comes to see someone and leaves. A contractor comes to work on the building, often out of hours, sometimes with tools that can set off an alarm, and always with an insurance obligation attached.

Treating both as one category is how buildings end up with an uninsured technician on a roof at 7pm with nobody aware they are there. The distinctions worth building into the process are unglamorous and short: is the certificate current, does this trade need an escort, is the work order they are here for actually open, and does the access they receive expire when the job ends rather than when someone remembers.

None of that needs to slow anyone down at the desk. It needs to be decided before they arrive.

What to measure once you have a system

Before any of that, one habit is worth building: read the previous day's arrivals once a week. Not as an audit, as a sanity check. Patterns show up fast when a person looks at them, and the ones that matter are rarely the ones a report would flag. A vendor appearing daily on a job that was supposed to take an afternoon, an interview candidate logged at a floor with no vacancy, twelve deliveries to a tenant who has complained about the loading dock twice.

Three numbers tell you whether the change took.

The share of visits that were pre-registered, which is the adoption number. Time from arrival to access, which is the tenant experience number. And the share of vendor entries where compliance was verified, which is the number your insurer would ask about if they thought to ask.

None of the three needs a dashboard project. They come out of the visit records if the visit records exist, which is the entire argument for having them.

Where BuildingHub fits

Security Hub handles guest pre-registration from the tenant side, issues the pass to Apple Wallet for the window of the visit, and logs every entry against the host and their company. It works with the access control already in the building through integrations with Genea, LenelS2 and HID rather than replacing them, and vendor visits can be checked against the certificate tracking in Operations Hub before anyone reaches a lift.

Somewhere in your portfolio there is a lease with a notice window that opens in eleven months. Miss it and a tenant gets another five years at a rate you set in a different market. Nobody is going to miss it on purpose. It will be missed because the person who knew about it moved to another firm in March, and the calendar reminder went with their mailbox.

This is the argument for lease administration software in commercial real estate, and it has nothing to do with storing documents. Storage is solved. Every building has a folder full of PDFs. What is not solved is the set of obligations buried inside those PDFs, each with a date attached and a consequence for arriving late.

The lease is a schedule, not a document

Read a commercial lease as an operator rather than a lawyer and it stops being prose. It becomes a list of things that happen on dates: rent steps, options to renew, options to expand, rights of first offer, termination windows, insurance renewals, restoration obligations, audit rights, escalation true-ups.

Each of those has an owner, a trigger date and a window. Most of them are silent. The lease does not send an email when a notice period opens, and the tenant, who reads their own lease more often than you read theirs, may well be counting.

The teams that handle this well have made one shift: they treat the document as the source and the schedule as the working object. The PDF is evidence. The schedule is what gets managed.

Where critical dates actually get lost

Not in the abstract. In four specific places.

At transition. A property changes managers, or an asset changes hands, and the abstracts come across as a spreadsheet that was accurate on the day it was exported. Nobody re-reads eighty leases to check.

In amendments. The original term is in the system. The second amendment that moved the option date by six months is in an email thread with an attachment called final_v3.

In the gap between leasing and operations. Leasing knows a tenant is expanding. Operations finds out when the contractor arrives. The dates that matter to both sit in one team's memory.

In the last ninety days. The window opens, everyone is busy, and the notice goes out on day sixty-two of a sixty-day requirement.

What good lease administration looks like

• Every obligation is a dated record, not a paragraph. Abstracted once, with the clause reference kept beside it so anyone can check the original in one click.
• Alerts fire early and to a role. Not to a person's inbox. Roles survive turnover; inboxes do not.
• Amendments amend the schedule. When a date moves, it moves in the system on the day it is signed, or the system is already wrong.
• The packet travels with the alert. When a renewal window opens, the notice provisions, the delivery method and the current contact should arrive in the same message, not be assembled from three folders.
• Leasing and operations read the same record. One expiry schedule, visible to the people who market the space and the people who have to turn it over.

The stacking plan is the honest version of the rent roll

A rent roll tells you what is signed. A live stacking plan tells you what is about to happen, floor by floor, in a shape a human can hold in their head.

Colour a plan by expiration year and the risk announces itself: three suites on the same side of the building rolling in the same eighteen months, or a single tenant with an option that quietly controls the future of two floors. That picture changes conversations with lenders and with brokers, and it takes ten seconds to read.

It also changes what leasing chases. Space that is legally available in fourteen months is a different marketing problem from space that is available now, and the two should never sit in the same pipeline.

Sitting on top of the system of record

Most portfolios already run accounting in Yardi, MRI or something similar, and the finance team is not going to move. That is fine. Lease administration for operations does not require displacing the general ledger. It requires the dates, the documents and the contacts to be usable by people who are not in accounting, on a screen that does not require an accounting login.

The failure mode to avoid is a second source of truth. If the rent roll lives in two places and they disagree, the building will trust neither. One system holds the record, the other reads from it, and the direction of that arrow gets decided before implementation, not during.

What this is worth

The value is not a software line item that pays for itself in efficiency. It is one avoided event.

One option exercised at yesterday's rate because nobody sent a notice. One termination right that survived because the estoppel was late. One expansion that went to the building across the street because your team could not answer, on the phone, whether the fourteenth floor was actually free in June. Those are not efficiency stories. They are the whole return.

Abstracting is a project, not a feature

Every vendor demo shows a clean abstract screen. Nobody shows the two weeks it takes to fill it, and pretending otherwise is how implementations lose trust in month one.

Getting eighty leases into a schedule means reading eighty leases, plus their amendments, and making judgement calls about what counts as a critical date. Some teams do it internally, some use an abstraction service, most do a hybrid: the ten largest tenants by hand and carefully, the rest in a batch.

The part worth protecting is verification. An abstract nobody checked against the document is a confident-looking source of error, and it will be trusted precisely because it looks tidy. Sign off tenant by tenant, or accept that the schedule is an estimate.

Notices are a delivery problem too

Knowing a window has opened is half the job. Delivering the notice the way the lease requires is the other half, and it is where a well-run process still trips.

Leases specify method and address, and both go stale. The notice address is often a law firm that has moved, or a corporate parent that has been acquired. Certified mail needs a receipt somebody keeps. Email is valid in some leases and worthless in others.

The practical fix is to store the delivery requirement beside the date, not in the document, and to keep the proof of delivery attached to the record afterwards. When a tenant disputes receipt eighteen months later, the argument is settled by a file, not by a memory.

Where BuildingHub fits

Leasing records, floor plans, contractual notices and critical dates live in Leasing Hub, with a live stacking plan drawn from the same records rather than rebuilt in a spreadsheet each quarter. It integrates with Yardi so the accounting system stays the system of record, and because the platform also runs Operations Hub, the people preparing a suite for turnover are reading the same expiry schedule as the people marketing it.

The first objection in almost every building technology conversation is the same, and it is a good one. "We run on Yardi. We are not moving off Yardi." Nobody says it apologetically. They say it the way you would say the building has a foundation.

They are right, and the honest answer is that a Yardi integration for building operations is a better outcome than a migration. The accounting system of record should stay exactly where it is. The question is what happens to the twenty things a building does every day that the accounting system was never built to do.

What the system of record is for

Yardi holds the lease, the rent roll, the receivables, the general ledger, the budget. It is where the auditor looks and where the owner's reporting comes from. It is correct, it is controlled, and changing it is a project with a steering committee.

That control is a feature. It is also why nobody wants a porter raising a work order in it, and why no property manager is going to give a vendor a login to upload a certificate of insurance.

What happens in the gap

Below the ledger there is a layer of daily work with no natural home. A tenant reports a leak. A contractor needs access on Saturday. A COI expires. An inspection is due. A guest arrives for the eleventh floor. A parking space changes hands. An amenity is booked and needs to be billed.

In most buildings this layer runs on email, a phone number, three spreadsheets and one person's memory. That is not a technology failure. It is what happens when the only system available is the wrong shape for the work.

Sit on top, do not replace

An operations platform that integrates with Yardi reads what it should read and writes only what it should write.

It reads tenants, suites, lease terms and contacts, so a work order knows which suite it belongs to and a notice knows who to reach. It reads the rent roll so the stacking plan matches the accounting rather than a version someone rebuilt in a spreadsheet.

It writes back sparingly and deliberately: billable amenity charges, parking revenue, chargeable work order costs. The rule that keeps this clean is simple. Money settles in the system of record. Work happens in the operations platform. Neither pretends to be the other.

What to ask a vendor about integration

• Which direction does each object flow? A vendor who cannot answer this per object, rather than in general, has not built the integration you need.
• What is the refresh, and what happens when it fails? Nightly is fine for most objects. Silent failure is not. Somebody should be told.
• Who wins on a conflict? If a suite is renamed in both systems, the answer must be a rule, not a support ticket.
• What does it need from our Yardi administrator? Credentials, a service account and a defined scope, agreed before implementation rather than discovered in week three.
• What breaks if we turn it off? The honest answer is a good sign. A platform that becomes unusable without the integration has made your system of record its dependency, and yours.

The integration nobody scopes and everybody needs

Access control. The lease data in Yardi decides who belongs in which suite. The access system decides who gets through which door. In most buildings those two facts are reconciled by a human being with a spreadsheet, usually late.

A move-out is the clearest case. Accounting knows the term ended. The badge does not, and a credential that should have died on the thirtieth keeps working into the next quarter. Connecting lease data to access control through the operations layer closes that gap without asking either system to change what it is.

What implementation actually looks like

Set expectations honestly. Reading tenant and lease data is straightforward and usually the first thing to go live. Writing charges back takes longer, because it touches accounting policy and someone in finance has to approve the mapping. Access control depends on which system is installed and how it was configured, which is a site question, not a product question.

The projects that go badly are the ones that try to do all three at once, in a building where nobody has agreed which system owns a suite name. The projects that go well start with reads, prove the data matches, and add writes when finance is comfortable.

The case for keeping the ledger where it is

Every hour spent migrating an accounting system is an hour not spent on the layer where tenants actually experience the building. Owners rarely lose a renewal because the ledger was in the wrong package. They lose it because a request took nine days, a guest was treated badly, or a suite was not ready when it was promised.

Leave the foundation alone. Fix the floor everyone walks on.

The "one more system" objection

Somebody in the room will point out that the team already logs into too many things, and they are right. The answer is not to promise fewer systems. It is to be specific about who uses which one.

Accounting stays in Yardi and rarely opens anything else. Engineers and porters live in the operations platform on a phone and never open Yardi at all. Property managers move between both, and that is the seat where the integration has to earn its keep, because they are the ones who currently reconcile the two by hand.

Counted properly, a good integration removes work from the person with the most work. Counted badly, it adds a login for everyone and helps nobody.

Reporting across the two

There is also a cultural question hiding in the reporting one. Accounting measures a building monthly, in arrears, with everything reconciled. Operations measures it hourly, in the present, with everything still moving. Both are right, and the first argument in a joint report is usually about which version of a number is the real one. Decide that before the report exists rather than in the meeting where it is presented.

Owners ask questions that cross the line: what did we spend on this suite, what is the cost of running the amenity floor, how long does this building take to close a request compared with the one across town.

Answering those means agreeing early on which identifiers travel between the systems. A shared property code and suite identifier make later reporting a query. Skipping that agreement makes every cross-system question a manual join, which is the tax nobody quotes in the business case.

It is a half-day conversation at implementation and it saves a quarter of arguing later.

Where BuildingHub fits

BuildingHub integrates with Yardi rather than replacing it, and the four Hubs run the layer above: work orders, preventive maintenance and certificate tracking in Operations Hub, credentials and visitors in Security Hub, critical dates and stacking in Leasing Hub, bookings and parking in Amenity Hub. Access control connects through Genea, LenelS2 and HID, so a lease change can reach a door without a spreadsheet in the middle. The full list is on the integrations page.

A tenant on eleven emails the property manager at 4:40 on a Friday: the men's room on their floor has a leak under the sink. The manager is on a lease call. The email is read at 6:10, forwarded to the engineer at 6:12, and the engineer sees it Monday at 7. By then the tenant has told three colleagues that nothing happens when you report something in this building.

Nothing in that story is a hard problem. No part of it requires a better plumber. It is a routing failure, and routing is what work order management for commercial property is actually for.

The anatomy of a request that closes on time

Watch a request that goes well and it has the same five stages every time: it is captured with enough detail to act on, routed to whoever owns that trade, accepted by a human being, worked, and closed with the requester told. Skip any one and the request does not fail immediately. It just gets slower, and slowness is what tenants actually experience.

Most buildings have all five stages. What they lack is a place where the stages happen in sequence without a person carrying the request from one to the next by memory.

Capture: the detail you get is the detail you asked for

A request that says "it's cold" costs two visits. A request that says "Suite 1104, north side conference room, cold since Monday, thermostat reads 68" costs one.

The difference is not the tenant. It is the form. A free-text box gets free-text answers. A short structured intake, issue type, location, and one description field, gets you an engineer who arrives with the right part. Three fields, chosen well, are worth more than a fourteen-field ticket nobody completes.

The other half of capture is where it happens. If the fastest route for the tenant is an email to the manager they already know, they will email the manager, and every routing rule you built is bypassed on the first request of the day.

Routing: the step buildings skip

Routing is the difference between a request system and a to-do list. It means a plumbing issue in the Office Block reaches the plumbing vendor for that building, at that hour, without a manager choosing.

Three rules cover most of it: issue type to trade, building to vendor, and hour of day to whoever is covering. The fourth rule is the one that matters after hours, which is what happens when nobody accepts inside a set window.

Duplicates are a signal, not a nuisance

Three tenants reporting the same leak is not three problems. It is one problem with three people watching, and it should collapse into one dispatch with three subscribers.

Systems that cannot do this create a specific kind of waste: three engineers dispatched, three sets of notes, three closures, and a tenant on the fourth floor who never hears anything because their duplicate was quietly deleted.

What good work order management looks like

• Structured intake with three fields, not fourteen. Issue type, location, description. Everything else can be inferred or asked later.
• Automatic routing by type, building and hour. With an explicit rule for what happens when nobody accepts inside the window.
• Status the tenant can see without asking. The single largest source of "chasing" is a requester who has no way to know whether anything is happening.
• Duplicates collapse and carry their subscribers. One dispatch, everyone told at closure.
• Closure requires a note. "Completed" with no detail is how the same fault gets fixed four times in a year without anyone noticing it is the same fault.

The numbers worth watching, and the one worth ignoring

Two measures tell you almost everything: time to acceptance and time to closure. Acceptance is the one you can fix this month, because it is a process problem rather than a labour problem. Closure follows the trade, the part and the schedule.

Volume, on its own, is the number worth ignoring. A building with rising request volume may be failing, or it may finally have tenants who believe reporting something works. Read volume next to acceptance time or do not read it at all.

Recurring work is not the same work

A quarterly filter change and a burst pipe do not belong in the same queue with the same urgency, and a system that treats them identically will bury the pipe under the filters.

Planned work should generate itself on a schedule, carry its own procedure, and sit in a separate lane that gets worked when reactive volume allows. Buildings that mix the two end up doing reactive work only, then wondering why equipment fails early.

After hours, and the escalation nobody tests

Every building has an after-hours procedure. Fewer have one that has been tested since the last time the answering service changed hands.

The failure is rarely the first call. It is the second. The tenant reaches someone, someone reaches the on-call engineer, the on-call engineer does not pick up, and the process has no defined next step, so it ends with a voicemail and a building that finds out at seven in the morning.

Write the escalation as a chain with times attached: who is called first, how long before the second name is tried, who is woken at the third step and for which categories of fault. Water, smoke, no heat in January and a stuck lift belong in a different tier from a jammed door.

Then test it twice a year at an inconvenient hour. A procedure that has never been run at 2am is a document, not a procedure. The test costs one uncomfortable evening and it is the only way to find out that the number on the sheet belongs to somebody who left in March.

The part nobody enjoys: closing the loop

Ask a property manager what tenants complain about and "nobody told me it was done" comes up more than the fix itself. Closure notification is the cheapest tenant experience improvement available to any building, and it is the one most often left switched off because someone worried about noise.

Send it. A tenant who is told their request closed will report the next thing they notice, which is the whole point.

One more habit is worth the ten minutes it costs. Once a week, read the requests that took longest to accept, not the ones that took longest to close. Closure time is usually a part on a truck somewhere. Acceptance time is almost always a rule that is wrong, a vendor who has stopped answering, or a category nobody owns, and all three are fixable by the person reading the list.

Where BuildingHub fits

Work orders in Operations Hub capture a structured request, route it by issue type and building, collapse duplicates into a single dispatch and keep the requester informed to closure, with preventive maintenance running in its own lane so planned work does not compete with a leak. If you want the arithmetic on what routing delay costs across a portfolio, we will work it through with you, and the difference between a portal and a platform is worth reading before any vendor demo.

Every building has a preventive maintenance schedule. Most of them live in one of three places: a binder from the year the building opened, a spreadsheet maintained by an engineer who has been there eleven years, or that engineer's head. All three work perfectly until the day the engineer takes another job.

That is the honest case for preventive maintenance software for commercial buildings. Not efficiency. Continuity. The schedule has to survive the person who knows it.

What actually gets lost at turnover

Not the obvious items. Nobody forgets the elevator inspection or the fire panel test, because those come with a regulator and a date.

What gets lost is the local knowledge wrapped around each task. That the north cooling tower needs its strainer checked more often than the south one because of the tree. That the emergency generator has to be exercised before eight, because a tenant on two complains about the noise. That the roof drains fill with seed pods for three weeks every spring.

None of that is in the manufacturer's manual. All of it is why the building runs. A schedule that captures the task but not the note is half a handover.

Frequency is a judgement, not a manual

Manufacturer intervals are a starting point written by someone who has never seen your building. Run time, load, water quality, filter loading and how hard the equipment is pushed in August all shift the real interval.

The teams that get this right treat frequency as something they revise. Twice a year, they look at what was found on each visit. If a quarterly task finds nothing four times running, it becomes semi-annual. If a semi-annual task keeps finding something, it moves the other way. That review is fifteen minutes per system, and it is the difference between a schedule that reflects the building and a schedule that reflects a PDF.

Procedures beat task names

"Quarterly AHU service" means one thing to the engineer who wrote it and something else to the contractor covering a shift. A procedure with steps, torque values, part numbers and the two things that usually go wrong means the same thing to both.

Procedures are also what makes vendor work auditable. When a contractor marks a task complete, you want to know which steps were performed, not that a box was ticked at 14:03.

What good preventive maintenance looks like

• Tasks hang off an asset, not a floor. Equipment carries its own history, so when the chiller is replaced its schedule and its record go with it rather than being rebuilt.
• Schedules generate work automatically. The task appears in the queue on its own. It does not depend on somebody remembering to raise it.
• Every task carries its procedure. Steps, parts, and the local note about the tree, the noise complaint or the seed pods.
• Findings become work. An inspection that finds a worn belt should produce a repair with one action, not an email that somebody re-types on Monday.
• Completion produces a record. Who, when, what was found. Insurers, buyers and regulators all eventually ask, and the answer should be an export.

The deferral problem

Preventive work loses to reactive work every single time, because a leak is in front of you and a filter change is not. In a busy quarter the planned queue quietly grows and nobody makes a decision about it.

Deferral is legitimate. Silent deferral is not. The practical fix is to make skipping a task an action that leaves a trace: a reason, a new date, and visibility for whoever is accountable. A schedule with three documented deferrals is a managed building. A schedule with forty untouched overdue tasks is a building that has stopped using its schedule, and the second one is far more common.

Inspections are the cheap half

Routes matter as much as tasks. A porter walking a set floor route with a phone, logging what they see, generates more useful early signal than any sensor you can buy this year, and it costs nothing you are not already spending.

The requirement is that findings turn into work orders without leaving the phone. A clipboard route that ends in a photo nobody looks at is worse than no route, because it creates the impression of coverage.

In-house, vendor, or both

Who performs the work changes what the system has to do, and it is worth deciding deliberately rather than inheriting it.

In-house engineers are fast, know the building and cost the same whether the queue is full or empty. Their weakness is the record. Work done by someone who has been there for years tends to get logged thinly, because the person doing it already knows what happened.

Vendors bring specialist skill and produce paperwork by default, since paperwork is how they get paid. Their weakness is context. A contractor on a rotation has never met the tree, the noise complaint or the seed pods, so whatever is not written down does not happen.

Most buildings run both, which means the system has to serve two audiences at once: quick completion for the person who knows the building, and structured procedure for the person who does not. A platform that only does one of those will be worked around by half your team within a month.

The cleanest split is usually by asset criticality. Life safety, lifts and anything with a compliance date go to the specialist with the certificate and the paper trail. Filters, belts, drains and rounds stay in-house where speed matters more than documentation, with a procedure attached anyway so the record survives.

What this is worth

Avoid the temptation to promise a specific percentage. The defensible case is narrower and stronger: equipment that is serviced on a schedule fails less often at inconvenient times, warranty claims survive scrutiny when there is a service record, and a building that can produce a complete maintenance history is worth more in diligence than one that cannot.

The other return is the one nobody puts in the model. When the engineer with eleven years of local knowledge leaves, the building keeps running the same way in month two.

One caution about starting. The instinct is to load every asset in the building before going live, which turns a four-week project into a nine-month one and usually stalls. Start with the equipment whose failure would cost the most: chillers, boilers, lifts, the fire system, anything with a compliance date. Get those on schedule with real procedures. Add the long tail as it comes up, because the second year of data is worth more than a complete first-year inventory that nobody trusts.

Where BuildingHub fits

Preventive maintenance in Operations Hub hangs schedules off the asset, generates the work when it is due, carries a procedure with each task and turns inspection findings into work orders without re-keying. Reactive requests run in the same system but their own lane, so a leak never competes with a filter change, and the completion record is exportable when an insurer or a buyer asks. Related reading: the anatomy of a work order that closes on time.

A tenant on the sixth floor gave notice in June and moved out on the thirty-first of July. Their accounting system knows. Their suite is being marketed. And on the fourteenth of September, one of their former employees taps a badge at the turnstile at 7:40 in the morning and the door opens.

Nobody did anything wrong. The move-out was handled by leasing, the badge was issued by security, and the two facts never met. That gap is what building access control software is supposed to close, and in most multi-tenant buildings it is still closed by a person with a spreadsheet.

Access is a lease question that gets answered by a security system

Who belongs in suite 604 is decided by a lease. Who gets through the door to suite 604 is decided by a credential database. Those two live in different systems, are maintained by different teams, and drift apart the moment anything changes.

Every one of these is a drift event: a new hire, a departure, a suite expansion, a sublease, a contractor on a six-week job, a tenant taking swing space for a refit, a move-out. In a building with forty tenants there are several a week, and each one is a small manual reconciliation somebody has to remember.

The move-out is the one that matters

New hires get fixed quickly because someone complains. A new employee whose badge does not work will be at the front desk within the hour, and the problem announces itself.

Departures are silent. Nobody reports a credential that still works. It sits there until an audit, an incident, or a curious former employee, and the building has no way to know it exists because nothing in the system says it should have died.

Tenant self-service, with a boundary

The instinct is to centralise: property management owns the credential list, tenants submit requests, the desk processes them. This is safe, slow, and it makes the property manager the bottleneck for every hire and departure in the building.

The better shape is delegation with a boundary. A tenant administrator manages their own people, inside their own suite and the common areas their lease grants, without being able to grant access to anything else. The building keeps the perimeter, the amenity floors and anything shared. The tenant keeps their own roster, which is the only list they can actually maintain accurately.

That boundary is the whole design. Get it wrong in the permissive direction and a tenant can badge into a mechanical room. Get it wrong in the restrictive direction and you are back to the property manager processing badge requests on a Friday afternoon.

What good access control looks like

• Lease dates drive credential dates. A term that ends on the thirty-first should expire access on the thirty-first without anyone deciding to do it.
• Tenants manage their own roster. Inside their suite and their granted common areas, with the building keeping everything shared.
• Credentials expire by default. Contractors and visitors get a window, not an open-ended card that has to be collected.
• One audit view across doors and systems. Who has access to what, exportable, without joining three exports by hand.
• Vendor access checks compliance. A contractor whose certificate of insurance has lapsed should not receive a working credential that morning.

Mobile credentials change the operational maths

Plastic has a physical lifecycle: printed, handed over, lost, replaced, occasionally returned. Every step is somebody's time at a desk.

A wallet credential is issued and revoked remotely, which removes the collection problem entirely and makes expiry practical rather than theoretical. It also survives the most common failure in any building, which is a person who forgot the thing they need, because almost nobody arrives without their phone.

Two cautions worth saying out loud. Not every reader in an older building supports mobile credentials, so this is usually a phased upgrade rather than a switch. And a plan for the person whose phone is dead is still required, which usually means the front desk can issue a temporary pass with a short window.

After hours is a different building

Between six in the evening and six in the morning the same doors mean something else. The lobby is unstaffed, the lifts may be locked to floors, and the people in the building are a much smaller and less predictable set.

Access rules should reflect that rather than treating the day as uniform. A tenant's general staff may not need weekend entry. Their overnight IT contractor does, for four floors, for three weeks. A cleaning crew needs the whole building at eleven at night and none of it at eleven in the morning.

Buildings that manage this well express it as schedules attached to groups rather than exceptions granted to individuals, because individual exceptions are never reviewed and never expire.

The tailgating conversation

Every credential system is defeated by a person holding a door open for someone carrying a box, and no software fixes that. It is worth being honest about the limit rather than selling around it.

What the system can do is narrow the consequences. If credentials are current, expiries are enforced and the log is complete, then the building's exposure is one uncontrolled entry rather than an unknown number of live cards belonging to people who left. That is a meaningful difference on the day something happens, and it is achievable. Eliminating tailgating in a lobby with turnstiles and a hundred people at 8:50 is not.

Do not rip out what works

Most multi-tenant buildings already own an access control system that functions, with readers, panels and wiring that were expensive and are fine. The failure is almost never the hardware. It is that nothing connects the credential database to the lease data, so the reconciliation is manual.

Adding a layer that reads lease terms and writes credential changes into the existing system solves the actual problem for a fraction of a replacement, and it does not ask a building to re-badge two thousand people to fix an administrative gap. Replace hardware when it fails or when it cannot do something you need. Do not replace it to fix a data problem.

The audit you should be able to run today

Here is a test that takes an afternoon and tells you where you stand. Pull every active credential. Join it against current tenants and their suites. Count the ones that belong to a tenant whose lease has ended, a person who left, or a contractor whose job closed months ago.

Almost every building that runs this for the first time finds more than it expected. The number is not an indictment of the security team. It is the predictable result of two systems that were never introduced to each other.

Where BuildingHub fits

Security Hub manages credentials and real-time keycard permissions on top of the access control already installed, integrating with Genea, LenelS2 and HID rather than replacing them. Because lease records live in Leasing Hub in the same platform, a term that ends can expire the access it granted, and vendor credentials can be checked against the certificate tracking in Operations Hub before anyone reaches a lift. Related: the front desk problem.

A senior living community runs the same operational stack as a commercial office building, plus a regulator, plus families who call on Sunday, plus a resident population for whom a slow work order is not an inconvenience but a fall risk. The software market treats it as a niche. The operating reality is that it is commercial building operations on a shorter fuse.

Teams looking at a building operations platform for senior living usually arrive with a specific frustration: their clinical system is excellent at care and knows nothing about the building, and their maintenance is a paper log in a binder behind the front desk.

The compliance load nobody budgets for

Every operator knows about state survey. Fewer people outside the industry appreciate how much of survey readiness is building work rather than clinical work.

Water temperature checks at fixtures. Generator load tests with a record. Fire door inspections. Kitchen equipment servicing. Call system testing. Elevator certificates. Pest control records. Preventive maintenance on anything that touches life safety. Each has a frequency, most have a form, and all of them need to be produced on request rather than reconstructed the week before.

The work is not hard. The record is the hard part, and it is almost always where an otherwise well-run community loses time under scrutiny.

Work orders in an occupied home

In an office building a work order is a service transaction. In senior living the unit is somebody's home, the occupant may be present throughout, and the request often arrives through a third party: a family member, a care aide, a nurse who noticed on rounds.

That changes what a good request contains. It needs the unit, obviously, but it also needs whether entry is permitted when the resident is out, whether the resident needs notice, and whether the maintenance tech should be accompanied. None of that is clinical information and none of it belongs in the care record. It belongs on the work order.

Priority is not a dropdown here

A dripping tap is a dripping tap. A dripping tap next to a resident with mobility issues is a wet floor next to somebody who falls.

Communities that get this right define priority by consequence rather than by trade: anything creating a trip or fall hazard, anything affecting a call system, anything affecting heating or cooling for a vulnerable resident, and anything in a corridor used for evacuation. Those go first regardless of how minor the underlying fault looks on the ticket.

What good looks like in senior living operations

• Compliance tasks generate themselves and produce records. Water temperatures, generator tests, fire doors, call system checks, with completion evidence exportable for survey.
• Entry rules live on the work order. Notice, escort and permission, visible to whoever is dispatched.
• Priority is defined by resident consequence. Not by trade, and not by who asked loudest.
• Vendor compliance is checked at the door. Contractors in a community with vulnerable residents are the clearest case for verifying insurance before entry rather than after.
• Families can see something. Not the clinical record. That a request was received and closed, which removes most of the Sunday phone calls.

The turnover problem is worse here

Maintenance staffing in senior living turns over faster than in commercial office, and the local knowledge is more consequential. Which rooms have a resident who cannot be disturbed before nine. Which corridor floor gets slippery when the cleaning crew is heavy-handed. Which call button has been intermittent for a month.

None of that survives in a binder. It survives in a system where the note attaches to the unit and the asset, so the technician who started on Monday reads what the technician who left in March knew.

Emergency preparedness is an operations record

Every community has an emergency plan. What separates the ones that hold up is whether the building facts inside the plan are current, and building facts change constantly.

Which residents are on the second floor and cannot use stairs. Where the shutoffs are. When the generator was last exercised under load and for how long. Which rooms are on emergency power and which only look like they are. Whether the fire doors that were adjusted in March still latch.

Almost all of that is maintenance data, and it is usually held separately from the plan, which is why the plan ages quietly. Keeping the asset record current means the plan can be rebuilt from facts rather than from memory when a state surveyor or a storm makes it urgent.

What families actually ask

Families rarely ask about your maintenance programme. They ask three questions that maintenance answers: is my mother's room too warm, did anyone fix the thing I mentioned last week, and is somebody coming.

A community that can answer the second one in a sentence, with a date and a name, spends far less time on the phone than one that has to go and find out. The effect on staff time is larger than it sounds, because those calls land on whoever is nearest the front desk, which is usually the person who was doing something else.

This is the same argument for closure notifications in an office tower, with more emotional weight attached. The mechanism is identical: a request that is tracked can be answered, and a request that lives in somebody's memory cannot.

Do not put building work in the clinical system

It is tempting, because the clinical system is already there and already has the residents. Resist it.

Clinical records carry obligations that maintenance work does not need and should not inherit, and a maintenance tech should not require access to a system full of protected health information to see that a tap is dripping in 214. Keep the building layer separate and let it hold what it needs: units, assets, tasks, vendors, entry rules. Where the two must meet, they meet on the unit, not on the resident.

Multi-site is the norm, not the exception

Most operators run several communities, and the second one is where the spreadsheet approach collapses. Regional maintenance directors need to compare, corporate needs to see compliance status across the portfolio before a survey window, and the local team needs their own building without noise from the other five.

That shape, one platform, per-community operations, portfolio-level visibility, is exactly what commercial multi-building operators need too. The requirement is not special. Only the consequences are.

One practical note on buying. Communities often evaluate building software during a survey cycle, when the pain is loudest and the timeline is shortest. That is a bad moment to start a migration and a good moment to write the requirement down. Capture what the surveyor asked for and could not be given quickly, because that list is a better specification than any vendor's feature comparison, and it will still be accurate in three months when there is time to act on it.

Where BuildingHub fits

BuildingHub runs the building layer for senior living the same way it does for commercial office: work orders, preventive maintenance, inspections and certificate tracking in Operations Hub, visitor and contractor entry in Security Hub, and portfolio visibility across communities rather than one building at a time. It sits alongside the clinical system rather than inside it. Related: schedules that survive staff turnover.

Ask a property manager what the garage earns and you will usually get a monthly number that has not changed in two years. Ask how many spaces are actually occupied on a Tuesday and the answer is a shrug, because nobody counts. Parking is the one part of a commercial building that is simultaneously a revenue line, an amenity, a tenant negotiation and a source of weekly complaints, and it is usually run on a spreadsheet and a gate.

Parking management software for a commercial building gets pitched as a way to sell more spaces. The more useful framing is that it turns an unmeasured asset into a managed one, and the selling follows from that.

The spreadsheet works until three things happen

It works while the garage is full and stable. It breaks on expansion, on churn, and on visitors.

A tenant expands from twelve spaces to twenty and wants them adjacent, which means somebody has to know where the free ones are. A monthly parker leaves mid-month and the space sits empty until the next renewal cycle because nothing surfaces it. A tenant's client arrives at nine in the morning for a meeting nobody told the desk about.

Each of those is a small failure. Together they are the reason garages run below what they could collect, without anyone being able to say by how much.

Three products, not one

Most buildings sell parking three ways and manage it as though it were one thing.

Monthly is a subscription with a lease-like relationship: a start date, an end date, a rate, a person, sometimes a plate. Reserved is monthly with a specific stall attached, which sounds trivial and is the source of most disputes. Transient is a day pass or a visitor space, which is where the tenant experience lives and where the revenue leaks.

They have different lifecycles and want different handling. A system that treats a day pass like a monthly account creates work; a system that treats a monthly account like a day pass loses money.

Visitor parking is a tenant experience problem wearing a revenue costume

The nine o'clock arrival is the test. A tenant's client shows up, the barrier does not know them, the desk is on the phone, and the client circles the block for eleven minutes before finding a public garage two streets away.

The building lost a small transaction. The tenant lost something bigger, and they will remember it at renewal in a way that never appears in an operating report.

The fix is not complicated: let the tenant issue the visitor pass themselves, in advance, the same way they pre-register a guest for the lobby. It costs the building nothing and removes the entire failure mode.

What good parking management looks like

• One inventory with real status. Total, assigned, available and reserved, current enough to answer an expansion question on the phone.
• Accounts follow the lease. A tenant's parking starts and stops with their term, and expansions do not require someone to rebuild a tab.
• Tenants issue their own visitor passes. Ahead of time, within a limit the building sets.
• Billing happens once, in one place. Card, invoice or lease charge, decided at the point of sale rather than reconciled monthly from a paper log.
• The barrier knows what the system knows. Otherwise every change is entered twice, and the second entry is the one that gets skipped.

The number that changes the conversation

Utilisation against inventory, read monthly. Not revenue on its own, which hides everything.

Two garages can bill the same amount while one is at ninety per cent occupancy with a waiting list and the other is at sixty with three tenants over-allocated and hoarding spaces they do not use. The first one should raise rates. The second one has spaces to sell today and does not know it.

Over-allocation is the most common finding and the most awkward one, because reclaiming unused spaces from a tenant is a conversation nobody wants. It is a much easier conversation with a utilisation number attached.

Enforcement, and who has to do it

Every parking policy is only as real as its enforcement, and enforcement in a commercial building is uncomfortable work performed by people who would rather not do it.

A car in a reserved stall means a tenant with a contract is standing in the garage at 8:50 with nowhere to go. The response has to be immediate to matter, which means whoever is on site needs to know instantly whose stall it is and who to call, not fifteen minutes later after a phone call to whoever keeps the sheet.

The system's job is to remove the lookup. Plate to account, account to contact, contact to phone, in one screen. Whether you tow, warn or shrug is a policy decision for the building. Not being able to answer the question at all is a software decision, and it is the one worth fixing.

Rates are a leasing decision, not a parking decision

Parking rates get set once and then live forever, usually below market, because nobody owns them. They belong in the same review as rent, since they are frequently traded in negotiation and just as frequently given away without being priced.

The practical habit is to review parking whenever a lease is reviewed. What is included, what is charged, what the market rate is now, and whether the allocation matches the tenant's actual headcount rather than the headcount they had when they signed.

EV charging is now part of this

Charging stalls introduce a scarcity problem the rest of the garage does not have. A charger occupied for nine hours by a car that finished charging in two is a stall out of service, and the resulting complaints arrive at the property manager rather than the driver.

Buildings handle this with time limits, session-based pricing, or reservation windows. Which one you pick matters less than picking one before the third complaint, because the default, an unmanaged charger, converts an amenity you paid for into a recurring annoyance.

Where the garage meets the rest of the building

Parking is where a lot of building systems have to agree. Lease data says who is entitled to what. The access system decides whether the barrier opens. Billing needs to collect. The tenant wants to do all of it from the same place they book a conference room.

Running that as four disconnected systems is what produces the spreadsheet in the first place. Somebody has to be the person who reconciles them, and that person is always the property manager.

Where BuildingHub fits

Short-term and monthly parking run in Amenity Hub alongside bookable space and memberships, so a visitor pass is issued by the tenant the same way a room is booked, accounts follow the lease term, and billing happens at the point of sale through Stripe rather than in a monthly reconciliation. Amano McGann integration connects the gate, and because Security Hub sits in the same platform, the credential and the parking entitlement do not have to be maintained twice.

At some point in every evaluation the conversation stops being about features and becomes a sentence somebody has to say out loud to an owner: this costs a certain amount per year, and here is what we get for it. Most of the material available to help with that sentence is written by vendors, which is why it tends to lean on percentages nobody can source.

What follows is how to build the case honestly, including the part where building management software cost is compared against something other than zero, because the current way of working is not free.

Start with what the status quo costs

The comparison is never software against nothing. It is software against the current arrangement, and the current arrangement has a price that is spread across payroll and therefore invisible.

Four figures, all of which you can gather in an afternoon without a vendor in the room:

• Coordination time. Hours a week your property managers spend routing requests, chasing vendors and answering "did anyone do this yet". Ask three managers for an honest estimate and take the middle.
• Re-keying. Every place the same fact gets typed twice: a work order into an invoice, a lease date into a calendar, a certificate into a spreadsheet, a badge into a roster.
• Existing licences. What you already pay for point tools that would be replaced or consolidated, including the ones expensed by individual sites.
• The events. One missed option date, one lapsed vendor certificate at the wrong moment, one tenant who left partly because service was slow. Rare, expensive, and the reason anyone starts looking.

The first three are a number. The fourth is a risk.

Keep them apart in the model, because they get evaluated differently and mixing them is how a business case loses credibility in the room.

Coordination time, re-keying and licence consolidation are recurring and estimable. They belong in the arithmetic, discounted honestly: recovering an hour a week from a property manager does not create cash, it creates capacity, and you should say so rather than converting it to dollars and hoping nobody asks.

The fourth is a low-probability, high-consequence event. It belongs in the case as exactly that. One missed renewal notice on a mid-sized suite will dwarf a year of software cost, and pretending it is an annual saving invites a finance director to take the whole model apart.

What actually appears on the invoice

Ask every vendor to break the first-year cost into four lines, because the headline subscription is rarely the whole of it.

Subscription, usually per building or per square foot. Implementation, which is real work and should not be quoted at zero. Data migration, which depends on the state of your records rather than the vendor's product. Integration, which is where the surprises live, because connecting to an accounting system or an access control system is a project with two sides.

Then ask the question that separates quotes: what does year two look like, and what triggers a price change. A per-building price with a portfolio that grows is a different commitment from a flat platform fee.

The costs that are yours, not the vendor's

Two line items get left out of nearly every business case and then show up anyway.

Internal time during implementation. Somebody on your side has to make decisions, gather data and answer questions for several weeks. That person has a day job. Budget the hours or accept a slower go-live.

Adoption. A platform that half the team uses produces less than half the value, because the people still working the old way generate reconciliation work for everyone else. The cost of doing this properly is training time and one person who owns the rollout. It is small. Skipping it is what makes implementations fail.

Per building, per square foot, or per user

All three pricing shapes exist and each rewards a different portfolio.

Per building suits owners with large assets and few of them. Per square foot tracks value reasonably but punishes big low-intensity properties like warehouses. Per user looks cheap until you realise the people who most need visibility, engineers, porters, tenant administrators, are the ones you will be tempted not to license.

Whichever shape you take, model it against your portfolio in three years rather than today. The wrong shape is not usually expensive on signing. It becomes expensive on the third acquisition.

What a payback period should look like

Be suspicious of anything under six months, because that usually assumes headcount reduction the operator has no intention of making.

A defensible range for this category is somewhere between twelve and twenty-four months on recurring value alone, with the risk-avoidance case sitting outside the arithmetic as the reason the decision is worth making now rather than next year. If your own model produces something dramatically better than that, find the assumption doing the work. It is usually an hourly rate applied to hours that were never going to be released.

Phasing beats a single big number

A portfolio-wide rollout produces one intimidating figure and one long wait before anything is proven. A phased start produces a smaller figure and evidence.

The usual sequence that works: one building, the operational layer only, for a quarter. That building generates the numbers the rest of the case needs, in your own portfolio, with your own tenants, rather than from a vendor's benchmark. It also surfaces the integration problems early, when they are cheap to fix and before every site is depending on them.

The trade is real and worth naming. Phasing costs more per building in the early stage and delays the consolidation savings, since you are running old and new side by side for a while. Most owners accept that in exchange for a decision that gets made on evidence, and finance teams tend to prefer the smaller first commitment anyway.

Who signs, and what they each need

Three people usually have to agree, and giving them the same document is why approvals stall.

Operations needs to believe the tool is better than the current arrangement on a Tuesday, which is a demo question, not a spreadsheet question. Finance needs the four-line cost breakdown, the year-two number and the assumption list. The owner or asset manager needs the risk paragraph and one sentence on tenant retention.

Write those three things separately. A business case that tries to persuade all three with the same page tends to persuade none of them.

The question the owner will actually ask

Not what it costs. What happens if we do not.

The honest answer for most portfolios is that nothing happens for a while, and then something does: a tenant leaves after a bad year of service, a notice is missed, a certificate lapses on the day a contractor drops something. The case for acting is not that the current way is unbearable. It is that its failures are unpredictable and the fix is not expensive relative to a single one of them.

Say that plainly. Owners have heard the efficiency pitch and they discount it. They have not usually heard a vendor concede that the payback is mostly capacity and insurance, and that concession is what makes the rest of the number believable.

Where BuildingHub fits

We will run this arithmetic with you on your own portfolio, keeping the recurring figure and the risk figure separate for the reasons above. If you would rather see the platform against your own numbers first, the four Hubs are described on the Operations and Leasing pages, and the ten-point checklist covers the questions worth asking every vendor, including us.

Ask a property manager what tenants complain about and you get a list shaped by whoever shouted most recently. Ask the request log and you get a different list, in a different order, and the two rarely agree. The gap between them is where most tenant satisfaction work goes wrong: buildings fix the loudest thing rather than the most common one.

What follows is the pattern that shows up across commercial office buildings when you sort by volume rather than by volume of voice. It is not a survey and we are not going to pretend it is one. It is the shape of a request log in a multi-tenant building, and it is remarkably consistent.

1. Temperature, and it is not close

Too hot, too cold, hot in the morning and cold by three. In almost every office building, thermal comfort generates more requests than everything else combined, and it is the category most likely to be reported repeatedly by the same person because the underlying condition never fully resolves.

The operational trap is treating each report as a new incident. The fifth complaint from the same suite in a month is not five problems. It is one unresolved problem with a person who has now decided the building does not listen, and the difference between those two readings is whether your system can see that history at a glance.

2. Restrooms

Cleanliness, supplies, a fixture that runs. Individually trivial, collectively the second largest category, and the one with the shortest fuse: nobody submits a polite ticket about a restroom. They report it once, and if it is still like that at lunchtime they tell their office manager, who tells you in a different tone.

Restroom issues are also the clearest argument for scheduled rounds. A porter walking a set route four times a day catches most of this before anyone reports it, which converts a complaint category into an invisible one.

3. Access and badges

A new hire whose badge does not work. A contractor who cannot get to the mechanical room. A tenant administrator who has emailed twice about a departure. These are administrative rather than physical, which is why they get triaged below a leak and why they annoy people disproportionately: the person waiting knows nothing needs to be fixed, only that someone has to press a button.

4. Cleaning quality in the suite

Bins not emptied, vacuuming missed, glass left marked. This category is unusual because the tenant is often reporting on a vendor you manage but do not supervise directly, and because the evidence disappears overnight. Without a log, month three of a declining cleaning contract feels like the tenant becoming fussy rather than the vendor slipping.

5. Lifts

Wait times more than faults. A lift out of service is an incident everyone understands; a lift bank that is slow at 8:50 is a grievance that never quite becomes a ticket and comes up in every renewal conversation instead.

6. Noise and construction

Almost entirely a notice problem rather than a noise problem. Tenants tolerate a fit-out on the floor above if they were told, and they escalate to the landlord's asset manager if they were not. This is the cheapest category on the list to fix, because the fix is a broadcast message sent two days earlier.

7. Parking and visitors

The nine o'clock arrival with nowhere to park, the reserved stall someone else is in, the guest who could not get through the lobby. Low volume, high emotional weight, because the tenant was trying to impress someone at the time.

What is missing from the list

Two things you would expect near the top and rarely find there.

Security incidents are far down the volume list in most office buildings, which surprises people who have just sat through a security vendor's pitch. They matter enormously per event and almost never in aggregate, and a programme built around them will misallocate attention for years.

Amenities barely register as complaints at all. Tenants do not file tickets about a conference room they could not book; they simply stop trying and mention it eleven months later when someone asks why they are looking at another building. Amenity dissatisfaction is invisible in a request log by its nature, which is exactly why utilisation data matters more there than complaint data.

What the ranking is actually telling you

Two things, and neither is about the categories.

First, most of the list is recurring rather than novel. Buildings that measure repeat rate by suite, rather than total volume, find a small number of locations generating a disproportionate share of everything, and fixing those is a capital conversation rather than a service one.

Second, satisfaction tracks acknowledgement more closely than it tracks resolution time. A tenant told "we have it, the engineer is on four, expect it after lunch" is calm. The same tenant with the same wait and no message is composing an email to their broker. That is not a platitude; it is why closure notification is the single highest-return switch in most buildings.

The survey trap

Annual tenant satisfaction surveys are useful for benchmarking and almost useless for operations, because they arrive months after the events that shaped the answers and they average away the thing you need: which suite, which floor, which week.

The request log is the continuous version of the survey, and it is already in your building. It has no response bias, no recall error and no seasonal timing problem. What it lacks is anyone reading it as a whole, which takes twenty minutes a month and almost nobody does.

What to do with this on Monday

• Sort last quarter by category and by suite. Two lists, ten minutes. The second one is the interesting one.
• Find the repeat reporters. Anyone who has raised the same category three times has an unresolved condition and a forming opinion.
• Check acknowledgement time separately from closure time. They have different causes and only one of them is free to fix.
• Turn on closure notifications. If they are off because someone worried about noise, turn them on for a month and count the "any update?" emails before and after.
• Send notice before disruption, not during. Fit-outs, water shutdowns, fire tests, lift maintenance. Two days is enough.

One caution on acting from a ranked list. Volume tells you where the work is, not where the risk is. A category with four reports a year can still be the one that produces an incident, and thermal comfort at the top of the list does not mean the sprinkler valve inspection can wait. Read the ranking as an operations plan, not a risk register, and keep the two conversations separate.

Where BuildingHub fits

Requests, repeat rate by suite and acknowledgement time all come out of the work order records in Operations Hub, and broadcast notices go to the tenants a disruption actually affects rather than the whole building. Rounds and inspections run in the same place, which is how the restroom category quietly stops being a category. Related: the work order that closes on time.

Somewhere in your building there is a clipboard. It holds a route somebody walks, a set of boxes somebody ticks, and a signature at the bottom. When the route is finished the clipboard goes into a drawer, and the information on it stops existing in any way that can be searched, counted or acted on.

That is the honest starting point for building inspection software for property management. The inspections are usually already happening. What is missing is the part where they turn into a record and, more importantly, into work.

An inspection that ends in a drawer is a cost

It costs the porter's hour, and it returns nothing except the reassurance that the walk happened. The value of a route is not the walking. It is the early signal: the belt starting to fray, the door closer that no longer latches, the ceiling tile with a stain that was not there in June.

Signal only has value if it reaches somebody who can act, in a form they can act on. A tick in a box does not do that. A finding attached to a location, with a photo and a work order behind it, does.

Routes are the unit, not checklists

Buildings that make this work think in routes rather than forms. A route has a sequence, a rhythm and a person: lobby and ground floor at eight, mechanical rooms at ten, restrooms four times a day, roof and drains weekly.

The sequence matters more than it looks. A route ordered by geography gets walked; a route ordered by asset category makes the porter cross the building six times and quietly gets truncated in week three. Design the route the way somebody would actually walk it, or design a route nobody completes.

What good inspections look like

• The route lives on a phone. Not on paper that gets transcribed later, because transcription is where detail and enthusiasm both die.
• A finding becomes a work order in one tap. If reporting a problem means leaving the route and writing an email, the route becomes an exercise in ticking boxes.
• Photos are the default, not the exception. A picture of a stained tile settles in one second what three sentences argue about for a week.
• Location is structured. Floor, room, asset. Free text means you cannot ask the obvious question later, which is whether this is the same spot as last time.
• Completion is evidence. Who walked it, when, what they found. That is the artefact an insurer, a buyer or a regulator asks for.

The adoption question nobody asks in the demo

The person who will use this every day is often not in the room when it is bought, and they have a phone with cracked glass, gloves on, and forty minutes to walk a route before something else needs them.

That constrains the design more than any feature list. Big targets. Works with one hand. Survives a basement with no signal and syncs later. Does not log you out between floors. A route that takes eleven taps per item will be completed in the van at the end of the shift from memory, which produces a record that is worse than paper because it looks authoritative.

If you are evaluating tools, put the phone in the hands of whoever walks the route and watch them do one floor. That single test predicts adoption better than the rest of the evaluation combined.

Compliance rounds are a different animal

Life-safety inspections carry a date, a standard and a consequence: fire doors, extinguishers, emergency lighting, sprinkler valves, exit signage. These are not judgement calls and they are not optional, and the record is as important as the work.

The practical distinction worth building into the process is between rounds that generate insight and rounds that generate evidence. Insight rounds can flex. Evidence rounds cannot, and their outputs need to be exportable in the shape whoever asks expects, which is usually a date-stamped list with a name against it.

The photo problem, and how it goes wrong

Photographs are the most valuable thing a route produces and the fastest way to create an unusable archive. Ten thousand images with no location, no asset and no finding attached are indistinguishable from no images at all.

The fix is boring. Every photo attaches to a finding, every finding attaches to a location or an asset, and nothing is uploaded on its own. Once that holds, the archive becomes a before-and-after record you can put in front of a contractor who says the damage was already there.

Frequency is a decision you should revisit

Most inspection frequencies were set once, by someone who has left, based on the building as it was then. Occupancy changes, use changes, equipment ages.

The review takes an hour twice a year: for each route, what did it find last period? Routes that consistently find nothing are candidates for stretching. Routes that consistently find something are telling you either that the interval is too long or that an underlying condition needs capital rather than more walking.

Who walks the route

In-house staff know what normal looks like in your building, which is most of the skill. A contractor walking a route for the first time will miss the thing that is subtly wrong and catch the thing that is obviously wrong, which is the reverse of what you want from a preventive programme.

Where third parties do add real value is in specialist compliance rounds with a certificate at the end, and in an annual pass by fresh eyes precisely because they have not stopped seeing the corridor everyone walks past.

Where inspections meet the lease

Two inspection types sit on the boundary between operations and leasing, and they are the ones most often improvised.

Move-out condition reports decide whether a restoration obligation gets enforced or quietly written off. Done with photographs against a structured checklist, they are a negotiating position. Done from memory a week later, they are an argument you lose.

Suite readiness before a new tenant takes occupancy is the other. A twenty-minute walk with a defined list catches the five small things that otherwise become the new tenant's first five work orders, which is the worst possible introduction to how the building runs.

What this is worth

Do not model it as labour saving; the walking still happens. Model it as three things: fewer failures that arrive without warning, a defensible record when somebody asks, and a shorter argument with vendors and insurers because the evidence exists.

The one number worth watching is the conversion rate from findings to work orders. If a hundred routes produce four work orders, your team is ticking boxes. If they produce sixty, some of them trivial, the programme is doing its job and you should leave it alone.

Where BuildingHub fits

Rounds and inspections run inside Operations Hub, on a phone, with findings that become work orders without leaving the route and photos that attach to the asset rather than to somebody's camera roll. Because preventive maintenance lives in the same place, a finding on a route and a scheduled service on the same equipment appear against one record. Related: schedules that survive staff turnover.

Every building accumulates paper that matters. Warranties, as-builts, commissioning reports, roof guarantees, elevator certificates, fire panel test records, vendor contracts, tenant estoppels, the letter from the city about the sidewalk. Almost none of it is needed this week. All of it is needed eventually, usually urgently, and usually by someone who does not know it exists.

Ask where it lives and you get a shrug and a folder path. That is the real state of building document management for property managers: solved in theory by a shared drive, unsolved in practice because a shared drive answers "where is the file" and never answers "what do we have".

Storage was never the problem

Nobody in this industry lacks somewhere to put a PDF. Buildings have SharePoint, Dropbox, a network share, a folder on the desktop of a laptop that was replaced in 2023.

The problem is that a folder is a location, not a record. A file called Elevator_Cert_final_v2.pdf in a folder called Compliance tells you nothing about which elevator, which building, when it expires or who signed it. To learn any of that somebody has to open it, and because opening it is work, nobody does until the day the information is needed at speed.

The four questions a document system has to answer

Not "where is the file". These:

• What do we have for this asset? Every document attached to the chiller, the roof, the lift, the suite. Not a search, a list.
• What expires, and when? Certificates, warranties, contracts and insurance all have dates, and a date in a PDF is invisible.
• Which version is current? The third amendment, not the original lease. The as-built, not the tender drawing.
• Who is allowed to see it? A vendor needs the equipment manual. They do not need the rent roll.

Structure beats search

Search is what you reach for when structure has failed. It works when you remember roughly what the file was called and roughly when it arrived, which describes the person who filed it and nobody else on the team.

The alternative is unglamorous: documents hang off the thing they describe. A warranty attaches to the asset it covers. A certificate attaches to the vendor and carries its own expiry. A notice attaches to the lease it was served under. Once that holds, the folder structure stops mattering, because nobody navigates to a document any more, they open the asset and see what is there.

Diligence is the moment this becomes expensive

A sale, a refinance or an insurance review turns a filing habit into a valuation input. The request list is always the same and always urgent: maintenance records, compliance certificates, warranties, service contracts, capital work documentation.

Teams that can produce them in a day look like teams that run their buildings well, and the diligence period stays short. Teams that spend three weeks reconstructing a folder from three people's inboxes create doubt about everything else, and doubt in diligence is priced.

The handover problem, again

Building knowledge does not usually leave in a dramatic way. It leaves when a chief engineer retires, a property manager moves firms, or a management agreement changes hands and a new team inherits a share drive with no map.

What survives a transition is what was attached to something structural: the asset, the vendor, the lease. What does not survive is what lived in a naming convention only one person understood, and that is most of it in most buildings.

What to fix first

Do not start with a migration project. Nobody finishes those, and a half-migrated archive is worse than an unmigrated one because it creates two places to look.

Start at the point of arrival. From today, every certificate that comes in attaches to its vendor with an expiry date. Every warranty attaches to its asset. Every signed contract attaches to its counterparty. Then backfill the categories that carry a date, because those are the ones that hurt when missed, and let the rest of the archive stay where it is until somebody actually needs it.

Drawings are their own problem

As-builts, floor plans and mechanical drawings behave differently from the rest of the archive. They are large, they are versioned badly, and they are consulted under pressure by someone standing in a plant room.

Three habits cover most of it. Keep one current set per building and mark it as current, rather than trusting a filename to communicate that. Record what changed after every capital project, because the drawing that no longer matches the building is more dangerous than no drawing. And keep a phone-readable version of the floor plans, since the person who needs to find a shutoff at eleven at night is not carrying a plan table.

Email is not a filing system, but it is the intake

Almost every document a building receives arrives as an email attachment, which means the archive is downstream of somebody's inbox and inherits its habits.

The realistic fix is not to change how vendors send things. It is to make filing take one action at the moment of arrival rather than five later: forward it to a place that attaches it to the vendor or the asset, or upload it from the phone that received it. Anything that requires opening a laptop, navigating a folder tree and renaming a file will be done on Friday, or not at all, and "not at all" is what produces the folder nobody trusts.

Retention, and the part people get wrong

Keeping everything forever feels safe and is not. Old tenant files carry personal information you have no reason to hold, and holding it is a liability rather than a precaution.

The practical version for a property team: keep compliance and capital records for the life of the asset plus the statutory period, keep lease documents for the term plus the limitation period, and set a disposal date on tenant personal data rather than keeping it because deleting felt risky. Write it down once, apply it at the point documents arrive, and stop making the decision file by file.

Access is part of the design

A vendor should reach the equipment manual and the site rules without a mailbox round trip, and should never see a lease. A tenant should reach their own documents and nobody else's. A regional manager should see every building; a site team should see theirs.

Most buildings solve this today by emailing PDFs, which is the least controlled option available: once sent, the document is everywhere, permanently, in a form nobody can withdraw.

One last test, and it is worth running this week. Pick a piece of equipment somebody would panic about, the main switchgear or the fire panel, and ask a colleague to produce its warranty, its last service record and the name of the contractor who commissioned it. Time them. Whatever that number is, it is also your diligence answer, your insurance answer and your two-in-the-morning answer, because they are all the same question asked with different amounts of pressure.

Where BuildingHub fits

Smart Record Storage in Operations Hub attaches documents to the asset, vendor or lease they belong to, tracks the ones that expire, and keeps vendor-facing material separate from anything commercial. Certificates of insurance are handled as records with dates rather than files in a folder, which is the difference between tracking and hoping. Related: COI tracking for commercial buildings.

The pitch for occupancy sensors is always the same slide: a heat map of a floor, some warm colours near the windows, and a number claiming a percentage of desks are empty. It is a compelling slide. It is also the point at which most sensor projects stop being useful, because nobody in the room has decided what they would do differently if the number were true.

Occupancy sensors in an office building are worth installing when a specific decision is waiting on a specific measurement. Installed without that, they produce a dashboard somebody opens twice.

Three questions worth measuring

Only three come up often enough to justify the hardware in a commercial building, and they are not the same question.

How much of this space is used, and when? Landlord-side, this drives cleaning schedules, HVAC run times and amenity sizing. Tenant-side it drives their space decisions, which eventually becomes your renewal conversation.

Is this room free right now? A live question with an immediate answer, which is a booking problem rather than an analytics one.

Did the booking actually happen? The gap between reservations and attendance is the most actionable number in the amenity programme, and the one nobody has.

What the data actually changes

Cleaning is the clearest case. A floor cleaned five nights a week regardless of whether forty people or four were on it is a contract written for a building that no longer exists. Occupancy data converts that from a negotiation about rates into a conversation about scope, which is a much better conversation to have.

Conditioning is the second. Running full HVAC for a floor at fifteen per cent occupancy on a Friday is expensive in a way that shows up in the operating statement without ever being attributed to anything.

Amenity sizing is the third, and the one that changes capital decisions. A conference centre that turns away requests at eleven and sits empty at three does not need to be larger. It needs different booking rules, and knowing that costs a lot less than building another room.

Ghost bookings, the most useful number

Every building with bookable rooms has them: the recurring meeting that stopped happening in March and still holds the best room every Tuesday, the reservation made in case, the block held by someone who left.

Pairing a reservation with an occupancy signal turns this from a suspicion into a rule you can apply. If a room is booked and nobody enters within ten minutes, the booking releases. That single behaviour recovers more usable capacity in most buildings than any amount of additional space, and it does not need a heat map to work.

Badge data first, sensors second

Most buildings already hold a rough occupancy record and never look at it. Access control logs every entry, by floor, with a timestamp, going back as far as retention allows.

It is a blunt instrument. It counts entries rather than presence, misses people who tailgate, and says nothing about which room anyone sat in. What it does give you, free, this week, is the shape of the week: which days are busy, when the peak arrives, whether Friday looks like Tuesday, and how that has changed over two years.

For most of the decisions on the list above, that shape is enough to act on. Buy sensors when badge data has taken you as far as it can and a specific question remains, not before, because the second dataset is much easier to justify once the first one has already changed something.

The privacy question, answered honestly

Tenants will ask, and the answer has to be better than "it is anonymous".

The technologies differ in what they can see, and that difference matters. Passive infrared and thermal sensors count bodies and cannot identify anyone. Camera-based counters can, in principle, whatever the vendor's processing claims. Badge and Wi-Fi data are identifiable by construction, because they are tied to a person's credential or device.

The defensible position for a landlord is to measure spaces rather than people: counts and durations at the room or zone level, no individual tracking, no desk-level attribution of a named person, and a plain-language note in the tenant handbook saying exactly that. Any programme that would embarrass you if described accurately to a tenant should be redesigned rather than explained better.

Where sensors are usually oversold

Desk-level occupancy in a landlord-run building is the clearest example. It answers a tenant's question with the landlord's money, generates the most privacy friction, and requires the densest and most expensive deployment.

Predictive maintenance from occupancy is another. Vendors will connect footfall to equipment wear, and the connection is real, but the interval you would derive from it is a refinement most buildings cannot yet act on because their preventive schedule is not being followed reliably in the first place.

Start small, in the places where the decision is already waiting

Meeting rooms and shared amenity spaces first: cheap to instrument, immediate booking value, no privacy argument, and the data has an obvious owner. Then common areas and entrances, which give you building-level patterns for cleaning and conditioning without touching tenant space.

Tenant floors last, and only in partnership with the tenant, funded in a way that reflects who gets the benefit. A landlord instrumenting a tenant's floor without them is buying a difficult conversation for a number they cannot act on alone.

What it costs to run, not to buy

The hardware quote is the easy part. Three ongoing costs turn up later.

Batteries, which sounds trivial until a five-year battery life across two hundred sensors becomes a recurring maintenance route with its own schedule. Network coverage in the places sensors sit, which is usually the corridor ceiling and the basement where coverage is worst. And somebody's time to read the output, which is the cost most often left out entirely and the one that determines whether the project produces anything.

What to ask a sensor vendor

• What exactly is captured, and at what granularity? Counts per zone is a different product from identities per desk, whatever the marketing says.
• Where does the data go and who else can see it? Their cloud, your tenancy, both. Ask what happens to it if you cancel.
• What is the battery life in this deployment? Not the datasheet number under ideal conditions.
• Does it push to our systems, or only to their dashboard? A dashboard nobody opens is the default failure mode of this category.
• What happens when a sensor stops reporting? Silent failure produces confident graphs built on missing data, which is worse than no graph.

Where BuildingHub fits

BuildingHub integrates with Density and Butlr, so occupancy signal arrives next to the things it should change rather than in a separate dashboard: bookings in Amenity Hub can be released when a room goes unused, and utilisation sits with the reservation records instead of beside them. The full integration list is on the integrations page. Related: what amenity software should actually do.

Every year the same cycle: budgets lock in the fall, and the buildings that spend Q4 "just looking" at operations technology spend the next twelve months explaining why nothing changed. Not because the tech failed — because the timing did.

Why timing beats features

Building platforms are rarely rejected on merit. They're deferred: "not this cycle," "after the lobby project," "let's revisit in spring." Deferral feels costless because the status quo is invisible — the duplicate truck rolls, the chased statuses, the spreadsheet that missed an option date. Those costs don't appear on any budget line, which is exactly why they survive every budget review.

What to model before you budget

You don't need a vendor's glossy ROI deck — you need four numbers from your own operation:

• Work-order volume per building per month, and the minutes each one burns in routing, status calls and re-keying.
• Duplicate rate — what share of tickets describe a problem already reported.
• Compliance exposure — how many vendor COIs you hold, and how many are expired right now (count them; the answer surprises).
• Critical dates — lease options and expiries in the next 24 months, and where they're tracked.

Put honest values on those and the platform conversation stops being about software. It becomes a staffing and risk conversation that happens to have a software answer.

The calendar that works

Summer: run the numbers, shortlist, see demos on your own floor count. Early fall: reference calls, pick, get the line item in. Winter: implement while leasing is quiet. Spring: the building runs on the new system before the busy season tests it. Buildings that follow this calendar go live in 30–60 days because implementation lands when the team has bandwidth — instead of being wedged between crises in July.

If you want the four numbers without the homework, our team will build the model with you — using your portfolio, not industry averages. It's the same math either way; the only variable is whether it's done before the budget locks.

Most commercial buildings have a tenant portal, and most of them were bought to solve one problem: stop the front desk drowning in phone calls. On that narrow measure, they work. A tenant types instead of calling, a ticket exists, everyone moves on.

Then the portal's real nature shows itself. A ticket is logged — and nothing else happens. The tenant hears silence. Engineering sees a queue with no context. Three tenants report the same leak and become three tickets, three truck rolls, three chances to look disorganized. The portal recorded everything and coordinated nothing.

The gap between logging and running

Running a building means the request is one event in a connected system: it's routed to the right trade, duplicates collapse into one dispatch, the tenant sees status without asking, the resolution posts to accounting, and the pattern feeds your maintenance planning. None of that is a portal feature. All of it is a platform feature.

Five questions for your current portal

• When three tenants report one problem, does anyone or anything merge them?
• Does the tenant see live status, or do they call to ask — defeating the point?
• Does a resolved work order bill itself, or does someone re-key it into accounting?
• Can it verify a vendor's insurance before granting building access?
• Does ownership see any of this, or does it die in a report nobody exports?

If the answers are no, the portal is a suggestion box with a login screen.

What switching actually involves

The honest objection to replacing a portal is migration fatigue — nobody wants to lose history or retrain tenants. It's a fair concern and a solvable one: work orders, tenant directory and COI records come across as data, and a tenant who could use a portal can use a better portal. The switching cost is real but bounded. The cost of silence at renewal is neither.

Operations Hub was built by owners who lived with the logging-only portals first. The difference is the connective tissue: routing, deduplication, status, billing and compliance in one record — the same record Security, Leasing and Amenity share.

Ask a property manager what keeps them up at night and you'll hear about roofs, chillers and renewals. Almost nobody says "certificates of insurance." That's precisely what makes them dangerous.

A COI is paperwork until the moment it isn't. The vendor whose coverage quietly lapsed in March is the same vendor cutting steel in your lobby in July. If something goes wrong, the question your carrier asks first is the one your spreadsheet can't answer: was their insurance verified on the day they walked in?

Why spreadsheets fail at this

Most buildings track COIs in a spreadsheet maintained by whoever inherited it. It fails for a predictable reason: expiry dates don't announce themselves. A spreadsheet is a record, not a watchdog — it will happily hold a date that passed four months ago and never say a word.

The failure is silent, and compounding. One building, thirty vendors, each with liability, workers' comp and auto policies renewing on different dates — that's roughly a hundred expiry events a year that someone is supposed to catch by looking.

What good looks like

• Every certificate lives with the vendor record, not in a folder named "COIs FINAL v3".
• Expiry dates fire notifications before they arrive — to the vendor to re-submit, and to your team to chase.
• Access is tied to compliance. A vendor whose coverage has lapsed shouldn't clear building access without someone deliberately deciding to let them.
• The audit trail writes itself. When the carrier or counsel asks, the answer is an export, not an archaeology project.

This is exactly how we built Smart Record Storage in Operations Hub: certificates tracked with end-date notifications, wired to the same system that governs vendor access. Compliance stops being a memory exercise.

The math is not close

One uninsured incident can run to six or seven figures once liability, delay and legal costs stack. The cost of tracking properly is a rounding error against that. Few risks in this industry offer this much protection for this little effort — which is exactly why the buildings that get burned are the ones that never got around to it.

Every commercial building runs on vendors — elevator crews, HVAC contractors, janitorial teams, fire-protection techs. Every one of them carries insurance, and every one of those policies expires. Certificate of insurance (COI) tracking is the discipline of knowing, at any moment, that everyone working in your building is actually covered.

It sounds administrative. It is actually one of the highest-leverage risk controls a property team owns — and one of the most commonly neglected.

What a COI actually certifies

A certificate of insurance is a one-page summary issued by a vendor’s broker showing active policies: commercial general liability, workers’ compensation, auto, umbrella. For building work you should expect to see your ownership entity named as additional insured, limits that match your lease or vendor agreement, and effective dates that cover the work period.

The certificate is not the policy — it is evidence. Which is precisely why tracking matters: evidence goes stale silently.

Why spreadsheets fail at this

• Expiry dates don’t announce themselves. A spreadsheet holds a date that passed four months ago without a word.
• Volume compounds. Thirty vendors × three policies each is roughly a hundred renewal events a year to catch by eye.
• The tracker leaves. COI spreadsheets are personal systems; the habit walks out with the person who kept it.
• No connection to access. The spreadsheet can be perfectly current and the uninsured vendor still walks in, because the sheet and the door don’t talk.

What good COI tracking looks like

Whether you buy software or build process, these are the requirements that matter:

• Certificates live on the vendor record — not a shared drive folder — with coverage types, limits and dates structured, not just a PDF.
• Notifications fire before expiry — to the vendor to re-submit and to your team to chase, on a schedule (30/14/7 days) rather than on memory.
• Status is visible where work is dispatched. Whoever assigns the work order sees compliance next to the vendor’s name.
• Access depends on compliance. A lapsed policy should hold building access until someone deliberately overrides it — a decision, not an accident.
• The audit trail writes itself. When counsel or the carrier asks, the answer is an export.

The tenant side

Vendor COIs get the attention, but tenant insurance obligations sit in every lease — and lapse just as quietly. The same tracking discipline applies: structured records, end-date notifications, and renewal requests that send themselves before the lease team ever notices a gap.

Where BuildingHub fits

Smart Record Storage in Operations Hub was built exactly for this: every certificate tracked with expiry alerts, compliance status beside the vendor wherever work is assigned, and vendor access tied to coverage — in the same system that runs your work orders. Compliance stops being a memory exercise.

Most building software gets bought under pressure — a portal contract expiring, an audit finding, an owner asking why the answer took three days. Pressure buys badly. This checklist is what we’d put in front of any property team evaluating building management software, including ours.

The ten questions that separate platforms from portals

• 1. Does one record connect everything? The work order, the vendor’s insurance, the tenant’s contact, the access log — if these live in separate tools, you are buying another silo.
• 2. Do duplicate requests merge? Three tenants will report the same leak. If that becomes three dispatches, the software is recording chaos, not reducing it.
• 3. Can tenants see status without calling? Live status on their phone is the single feature that most reduces front-desk load — and renewal-time resentment.
• 4. Is compliance wired to access? Ask the vendor to demo a lapsed COI. If nothing stops that contractor at the door, keep looking.
• 5. Does maintenance run proactively? PM schedules, inspection rounds and recurring work orders should generate themselves.
• 6. Does billing post to accounting? Re-keying work-order charges into the accounting system is a hidden headcount cost. Ask exactly how the integration works with your system of record.
• 7. Are leasing dates alarmed? Options and expiries should alert people, with the paperwork attached — not live in a spreadsheet named FINAL-v3.
• 8. Can amenities take payment? Bookable rooms and parking only produce revenue if payment happens at booking.
• 9. Who does the migration? The honest answer to switching costs is a vendor who moves your history — work orders, tenant directory, COI records — as part of onboarding. Get the go-live window in writing; 30–60 days is achievable.
• 10. Will the roles fit your building? Ownership, managers, engineers, security, tenant admins, vendors and visitors see different things. Permissions should match how a building actually staffs, out of the box.

Score it against your own numbers

Feature lists don’t make the case to ownership — recovered hours do. Before any demo, pull four numbers: monthly work-order volume per building, the minutes each one burns in routing and status-chasing, your duplicate-request rate, and how many vendor COIs are expired right now. Then make every vendor show, on your numbers, what changes.

Try the math first

We will do that arithmetic with you against your own portfolio — and if you’d rather see the platform against your own floor count and tenant mix, a 20-minute demo uses your numbers, not a sandbox.