Blog / Article

Ownership · Buying Guides

Building the business case for building management software

The comparison is never software against nothing. It is software against an arrangement whose cost is spread across payroll and therefore invisible.

BuildingHub Team · September 2026 · 7 min read

Operations Hub dashboard showing live work orders, building events and contacts in one view
Operations Hub: the daily coordination work that the status quo pays for in salary.

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 instead of 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.

A business case that survives scrutiny is one where the recurring number is conservative and the catastrophic number is clearly labelled as a risk instead of a saving.

What 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 instead of 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 on your side

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 instead of 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 instead of 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, instead of 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, and only a demo can answer that. 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 ask

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

For most portfolios, 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 that the current way fails unpredictably 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.