The short version
- Start from the workflow that needs to change, not from a feature list. A rent-accounting problem, a maintenance problem and a room-booking problem usually need different tools
- Split mandatory requirements from preferences, and record the evidence for each one, including “not tested”
- Give every vendor the same scenarios: an ordinary booking, a conflict, a cancellation and an exception, using two synthetic tenants and your real roles. See multi-tenant for what separation should mean
- Compare the whole cost of operating the tool, including what happens when you add a building, and run a small pilot with the people who will use it
To review property operations software properly, define the workflow that must change, separate mandatory requirements from preferences, give every vendor the same demonstration scenarios, compare the total cost of operating each option and test adoption with a small pilot before you approve anything. Write the decision so someone outside the process can check it.
Commercial property managers can make a software shortlist more useful by starting with the workflow that needs to change. Define the task, the people involved and the evidence required before comparing product features.
A rent-accounting problem, a maintenance-routing problem and a shared-room booking problem may need different tools. Treating them as one purchase can make demonstrations longer while leaving the important questions unanswered.
Map the responsibilities first
Create a simple list of the systems that currently own leases, accounts, maintenance requests, room reservations, parking and visitor records. Beside each system, name the person responsible for keeping its data correct.
Then describe the problem in observable terms. “Reception handles repeated calls to confirm room availability” is more useful than “our technology is fragmented”. It gives the team something to count and a result to test. If you have not yet observed the tenant journey, the guide to making shared amenities easier to use shows how to run that audit first.
In a 2025 discussion about commercial tenant portals, the buyer asked about tenant-maintained contact details, insurance documents, controlled document access and connections to existing property systems. That request illustrates the importance of defining scope: a booking interface alone would not answer those needs.
Separate the requirements that can stop the purchase
Agree the requirements that can stop the purchase. These might include tenant-data separation, the intended sign-in method, usable exports, support availability or an essential connection to another system. For sign-in and leaver handling, the comparison of workplace software with SSO and SCIM explains what to ask for.
Keep preferences separate. A useful reporting layout or attractive mobile screen should not compensate for a failed access-control test.
For each requirement, record the proposed behaviour, the evidence, who checked it and the result. Use “not tested” when a demonstration has not established the answer. It is more useful than a reassuring tick based on a sales presentation.
| Requirement | Type | How to test it | Evidence to record |
|---|
| Tenant-data separation | Mandatory | Two synthetic tenants search, book, view and export; then the landlord role does the same | What each role could see, with screenshots |
| Sign-in method and leavers | Mandatory | Sign in with your identity provider; remove a user and confirm access ends | Time to revoke, any manual steps |
| Calendar connection | Mandatory if claimed | Create, amend and cancel in each direction the vendor supports | Which actions synced, recovery steps on failure |
| Exports and reporting | Mandatory | Export a month of bookings and reconcile against the log | Fields present, gaps found |
| Reception fallback | Mandatory | Change the host of a synthetic visit; try an unannounced arrival | The working process and its fallback |
| Mobile layout | Preference | Complete a booking on a tenant’s own device | Completion and help needed |
Give every vendor the same scenarios
A consistent demonstration brief makes a comparison easier to assess. Ask each vendor to show an ordinary booking, a conflict, a cancellation and an exception using your proposed roles. A free meeting room booking template is a quick way to write the scenarios down before the first demonstration.
For a building with separate tenant organisations, create two synthetic tenants. Test what each can search, book, view and export. Then test the landlord or building-management role. Confirm which data is shared by design and which must remain restricted.
For calendar connections, test creation, amendment and cancellation in each direction the vendor claims to support. Ask what happens when a connection fails, a user leaves or an administrator changes a resource. Record any manual recovery steps.
For reception, change the host of a synthetic visit and try an unannounced arrival. The objective is to understand the working process and its fallback, not simply to see a successful check-in animation. The guide to what a visitor log must record lists the fields that matter.
Compare the whole cost of operating it
Request a quote for the same period and scope from every shortlisted supplier. Include recurring fees, implementation, hardware, migration, training, required modules and internal administration. The total cost of occupancy definition is a useful frame for the internal costs people forget.
Ask how the price changes when another building, tenant organisation or resource is added. Confirm any minimum commitments and which support services are included. Document the renewal and exit conditions while the buyer still has a choice.
A commercial property software discussion from October 2024 began with concern about charges across locations. Treat historical prices in that thread as dated user reports, not current vendor quotes. The useful buying question is how the proposed charging model behaves as your own portfolio changes.
Test adoption with the people who will use it
Include tenant representatives, reception and the future administrator in a small pilot. Ask them to perform real tasks on their normal devices without the vendor narrating every click. The companion guide on building a useful shared-space pilot gives the 30-day plan and metric definitions.
Measure completion, assistance needed and administrative effort. A product can pass a technical demonstration and still create daily work if nobody owns exceptions or maintains its data.
A February 2026 discussion about CRM adoption in commercial real estate raised manual communication and difficulty changing established workflows. This is a useful reminder to test the operating process alongside the application; it is not evidence that a particular product will fail.
Approve the evidence and the remaining work
Write the decision so someone outside the pilot can review it. State what passed, what failed, what remains unknown and who must resolve it. Keeping the current system with a better process should remain a valid option.
HybridHero is relevant to workplace booking, visitors and parking, and the facility managers page shows how those workflows fit together. Confirm the scope and configuration you need. Do not treat it as a demonstrated replacement for lease accounting, service-charge reconciliation or maintenance software without separate evidence.
Download the Property Operations Buyer Scorecard from the free property manager operations pack for a requirements worksheet, demonstration tests, total-cost prompts and a decision record. For a deeper technical review, use the IT Approval Pack.
Common questions
What is property operations software?
A broad label for the tools a building team uses to run day-to-day operations: leases and accounts, maintenance requests, shared-room and parking bookings, visitor records and tenant communication. Few products cover all of these well, which is why the review should start from one workflow rather than the label.
How many vendors should be on a property software shortlist?
Enough to compare against the same scenarios without exhausting the team, which in practice is usually two to four. Every vendor should get the same brief, the same synthetic tenants and the same requirement list, so the differences you record are real.
Should tenant-data separation be tested in a demo?
Yes, with your own synthetic tenants rather than the vendor’s sample data. Confirm what each tenant role and the landlord role can search, view and export. A product that fails this test should not pass on the strength of its interface.
What should the final decision record contain?
The original problem, what passed, what failed, what was not tested, the whole-life cost for the agreed scope, and who owns the remaining work. Keep “stay with the current system and fix the process” as a valid outcome.