Real estate operating systems: an evaluation checklist

A real estate operating system should make a recurring piece of work easier to complete and check. A useful evaluation starts with a reporting pack, an underwriting model or a document review that your team already understands. Ask the provider to show how the work moves through your existing systems, who reviews it and what you retain afterward.

The term covers different products. In this guide, it means a software layer that connects real estate data, documents and business rules so a team can run work across them. Confirm what each vendor actually provides. A product name alone does not establish integration coverage, ownership rights or permission controls.

Write the acceptance brief before the demo

Choose one deliverable and describe the recipient, reporting period, required sources, output format and reviewer. For example, an asset manager might need a monthly portfolio pack that reconciles operating statements to an approved account mapping and identifies unresolved variances. That is specific enough to test.

JLL's guidance on integrating AI into a real estate technology stack starts with the business problem before tool selection. Use that order to decide what evidence a demonstration must produce. A vendor's sample report can show presentation quality; your own approved test material shows whether the process fits your work.

Record the current process alongside the proposed one. Include preparation, reconciliation, review, corrections and delivery. Assign an owner to the evaluation and agree which failures would stop a rollout.

Map the sources and definitions

List each system or document the first deliverable requires. Record who owns it, the permission needed, available history, refresh timing and how a failed connection becomes visible. Confirm the exact integration and supported fields. A logo on an integrations page is not evidence that a particular report, property hierarchy or historical period is available.

Then choose the definitions the output will use. Property identifiers, account mappings, reporting periods and occupancy measures should remain consistent across the pack. Ask the provider to demonstrate how an analyst can inspect a mapping, correct it and identify which outputs need to be rerun.

Keep the source system's role explicit. If the new platform can write back to it, identify which changes are permitted and who approves them. A reporting pilot can begin with read access and reviewed exports where that meets the agreed scope.

Use a practical evaluation worksheet

Use the same evidence requests for each candidate. Record what was demonstrated, what depends on configuration and what remains unverified.

Area	Evidence to request	Question to resolve
Source coverage	A sample import with property, period and refresh information	What is missing or delayed?
Definitions	Visible account mappings and calculation rules	Who can change a definition, and what is affected?
Traceability	A report figure traced to its source and transformation	Can the reviewer reproduce the result?
Permissions	Tests with users who have different property access	Do outputs respect the intended access limits?
Review and delivery	An approval tied to the released output version	What happens when a source changes after approval?
Portability	A usable export of agreed data, rules and output history	What can the firm retain or move under the contract?

Test exceptions with the people who review the work

Include a missing statement, a renamed property, an amended lease and a user who cannot access one asset. Ask the system to identify the limitation rather than silently substitute older data or return an apparently complete answer. Check the actual output and its sources with the analyst who would sign off on it.

Try a correction after the first draft. Can the team tell which version changed, rerun the affected schedules and obtain fresh approval? Also test a delivery interruption. The workflow should distinguish a prepared report from one that reached the intended destination. Our guide to workflow handoffs and recovery provides a worksheet for these transitions.

Do not treat a successful demo as proof of readiness across the whole portfolio. Keep a list of formats, sources and permissions that the pilot has not tested, then decide whether they belong in the next stage.

Agree ownership, operating effort and exit requirements

Ask which records the firm retains, which formats it can export and which configurations depend on the provider. Distinguish access to data from contractual rights to reuse it. Confirm treatment of documents, prompts, outputs and any retained training records with the people responsible for your organization's agreements and data policies.

Compare the full delivery cost. Include setup, source mapping, internal review, recurring support, model usage and changes to templates. Measure time to an approved output and the work needed to correct it. A cheaper model or faster first draft may still require more analyst time before release.

Choose the implementation and service scope together

Some teams want their own staff to operate the workflow. Others need a specialist to prepare and check a recurring deliverable. Decide who owns source follow-up, reconciliation, exception handling and final approval before the first cycle.

Leni's own-your-AI offering connects supported portfolio sources and company knowledge with model choice and recurring workflows. Source coverage, history, access and refresh requirements need to be scoped for the organization. Leni's AI-native services add specialist support across asset management, finance and accounting, deal flow and diligence, and fund administration. The client's team retains approval of decisions and external communications.

Finish the evaluation with a short decision record: demonstrated capabilities, unresolved gaps, named owners and the conditions for expansion. That record gives the next reporting cycle a clear starting point.