The moment a corporate real estate department decides to replace its patchwork of tools with a unified platform, two groups that rarely share the same vocabulary find themselves at the same table. Facility managers track preventive maintenance windows, occupancy densities and service contracts. Portfolio strategists watch lease expirations, capital commitments and market comparables. Getting both teams through a disciplined joint evaluation — without one group overriding the other or settling for the lowest-common-denominator shortlist — requires a structured process rather than goodwill and hope.
Why a Joint Evaluation Differs from a Standard Software Selection
Most technology selections are run inside a single function. One department owns the requirements, writes the scoring criteria and controls the vendor demonstrations. A joint evaluation introduces competing mental models of what "good" looks like, and those models are rooted in genuinely different day-to-day realities.
A facility manager thinks in square footage, utilization rates and service-level agreements. A portfolio strategist thinks in net present value, effective rent and critical-date exposure. Neither set of concerns is more important than the other, and a platform that satisfies one group but ignores the other will eventually be abandoned or siloed — which recreates the very fragmentation the evaluation was supposed to solve.
The joint format also raises the organizational stakes. If the evaluation fails, both teams own the failure. That shared accountability is actually a structural advantage: it forces explicit negotiation about priorities before any vendor enters the room, rather than during contract negotiations when leverage is lower.
Running a joint process well requires more preparation than a single-function review, but the output is more durable.
Forming the Evaluation Committee and Assigning Clear Roles
The first structural decision is who sits on the committee and what authority each member holds. A joint committee with twelve people and no clear decision rights will drift toward consensus-by-exhaustion, where the tool that offends the fewest people wins rather than the one that serves the business best.
A working group of six to eight members is typically manageable. Facility representation should include at least one operations lead who lives inside the building management workflow daily, and one person who understands capital planning cycles. Portfolio representation should include a lease administrator familiar with critical-date tracking and at least one person involved in site selection or transaction execution.
Beyond those functional seats, the committee needs a procurement or legal representative who can evaluate contract terms, and a technology lead who can assess integration architecture. These two roles are often underweighted in real estate platform evaluations, which is why many teams discover commercial and technical problems only after a letter of intent is signed.
Assigning roles explicitly at the outset — evaluator, subject-matter expert, final approver — prevents the common failure mode where everyone provides input but no one is accountable for the outcome. Document who can escalate a disagreement and how tie votes get resolved before the scoring phase begins.
Building a Requirements Document That Represents Both Functions
A requirements document is the backbone of any disciplined evaluation. In a joint process, it also serves as a negotiated artifact: both teams have to agree that the documented requirements represent their actual needs before any vendor sees them.
Start with a capability inventory rather than a wish list. Each team separately catalogs the workflows they perform today, the data they rely on, and the decisions those workflows support. Facility teams will surface things like space utilization reporting, maintenance scheduling and occupancy planning. Portfolio teams will surface lease analysis software needs — NPV modeling, rent escalation tracking, holdover risk and renewal option management.
Once the separate inventories exist, the joint committee runs a reconciliation session. The goal is to identify which requirements are shared, which are team-specific, and which conflict. Shared requirements — a single source of record for lease terms, for example — carry the highest weight because they represent the platform's integration value. Team-specific requirements are scored separately.
Conflicting requirements are the most revealing. Conflicts identified during requirements drafting become the hardest test cases for vendor demonstrations.
Weight every requirement before approaching vendors. A common approach is a three-tier system: must-have, important, and nice-to-have. Must-haves are binary — the platform either meets them or it does not — and a single unmet must-have eliminates the vendor regardless of its performance elsewhere. Weighted scoring on the remaining tiers gives the committee a defensible, quantitative shortlist.
When both teams complete their inventories, a pattern almost always emerges: document and lease data management sits at the intersection of both functions, because the facility team needs lease obligations to plan maintenance and capital timelines, while the portfolio team needs those same obligations to model financial exposure. This shared dependency means the capability deserves especially careful scrutiny during demonstrations, regardless of how any individual vendor positions it.
Structuring the Vendor Demonstration to Expose Real Gaps
A standard vendor demonstration follows the vendor's preferred narrative. The vendor shows its strongest features in the sequence that makes them look most coherent. That is rational behavior from a sales perspective, but it means the demonstration tells you very little about how the platform behaves under your conditions.
A structured demonstration script flips that dynamic. The committee prepares a scenario library — real workflows, anonymized — and asks each vendor to walk through those scenarios in sequence. For a joint facility-and-portfolio evaluation, that library should include at least one scenario from each function and at least one scenario that requires both functions to interact.
A portfolio scenario might be: given three lease expirations in the same submarket over an eighteen-month window, show how the platform helps the team evaluate hold-versus-exit decisions against current market comparables. A facility scenario might be: given a building undergoing a capital refresh, show how the platform connects the capital spend timeline to the lease horizon and service contract obligations.
The cross-functional scenario is the most revealing. When both teams watch the same demonstration simultaneously, disagreements about what they observed become a direct window into where the platform's design assumptions diverge from the joint committee's actual requirements. Those disagreements are more useful than any individual evaluator's notes.
Assign one evaluator per scenario, not one evaluator per vendor. This structure means the same person watches every vendor perform the same scenario, which produces more consistent scoring. Evaluators who watch all vendors on a single scenario calibrate their expectations more accurately than evaluators who watch a single vendor perform all scenarios.
Asking each vendor to demonstrate this specific workflow — using your own anonymized data if possible — reveals integration assumptions that no sales narrative will surface on its own.
Scoring Methodology and Avoiding Common Bias Traps
Once demonstrations are complete, the committee moves into structured scoring. The scoring session should happen within forty-eight hours of the final demonstration, while impressions are fresh and before informal conversations begin to shift opinions outside the structured process.
Each evaluator scores independently before any group discussion. Independent scoring preserves the range of perspectives the joint committee was assembled to capture. If the facility lead and the portfolio strategist disagree on a vendor's scoring for financial modeling depth, that disagreement contains information the group needs to surface, not suppress.
After independent scores are collected, calculate a weighted average that reflects the pre-agreed requirement weights. A platform with strong lease analysis capability but weak space utilization reporting should score differently in a lease-heavy portfolio than in a facility-intensive campus environment. Adjusting the weights after seeing the scores is a form of rationalization; the weights must be locked before demonstrations begin.
Two common bias traps appear in joint evaluations. The first is demonstration effect: a vendor that presents confidently and attractively scores higher than one that presents awkwardly, even when their actual capabilities are equivalent. Counteract this by requiring evaluators to cite specific scenario evidence for every score above or below the midpoint. The second trap is anchoring to the incumbent: the committee unconsciously scores challengers against the tool they are already using, rather than against the requirements document. Incumbent familiarity is a sunk-cost argument, not a capability argument, and the requirements document is the right baseline.
When the committee compiles requirement weights before scoring begins, it is worth distinguishing which capabilities matter most to each team. For portfolio-oriented evaluations, financial modeling depth and lease comparison functionality tend to drive the highest-stakes decisions. For facility-oriented evaluations, space management and the connection between lease timelines and operational planning tend to carry equivalent influence. Naming these priorities explicitly in the scoring matrix prevents one team from inadvertently dominating the outcome.
Integration with existing data sources, the vendor's implementation approach, and the total cost of ownership should each appear as scored line items in the matrix rather than as after-the-fact considerations. Teams that wait until contract negotiation to assess these factors often discover that the platform they selected on capability grounds carries implementation complexity or ongoing cost that changes the economics of the decision.
Evaluating Integration Architecture Before Signing
Integration requirements are almost always underspecified at the demonstration stage. Both facility and portfolio teams use external data sources — market rent data, building systems feeds, HR occupancy records — and a platform that treats those connections as secondary considerations will impose ongoing manual data management burdens that compound over time, eroding the adoption gains the evaluation was designed to produce.
Before moving to final contract discussions, the committee's technology lead should run a structured integration review. This review covers which connections the vendor supports out of the box, which require custom development, and which are simply not on the product roadmap. Vendors will often characterize any connection as "possible," but the distinction between a supported integration and a future custom project has significant cost and timeline implications.
For portfolio teams, the integration review should cover how the platform connects to lease administration data, market comparables feeds and financial modeling outputs. For facility teams, it should cover building management systems, space utilization sensors and capital project tracking.
Ask the vendor to provide a technical specification document — not a sales deck — that describes each integration's data schema, refresh frequency and error-handling behavior. Vendors with mature integration architectures can produce this document; vendors whose integrations are shallower than advertised will hedge. That hedging is diagnostic information.
Running a Parallel Reference Check Process
Reference checks are often treated as a formality at the end of the evaluation. In a joint process, they are a primary research channel and should run in parallel with the demonstration and scoring phases rather than after a preferred vendor has been identified.
Each team — facility and portfolio — should conduct separate reference conversations with organizations that reflect their own use case. A facility team speaking to a reference from a high-volume retail portfolio will learn different things than a portfolio team speaking to a reference from a single-tenant industrial owner. The relevant comparator is an organization with a similar workflow complexity, not simply a similar industry.
Prepare a structured reference guide with specific questions rather than open-ended conversation prompts. Ask references how long deployment took, how the vendor responded to requests for configuration changes after go-live, and what the platform could not do that the reference had originally expected it to do. That last question surfaces capability gaps that demonstrations never reveal.
Cross-reference what different references say about the same capability. If three references independently describe the same limitation — for example, that the financial modeling module requires a workaround for certain lease structures — that pattern is more reliable than any single reference's opinion. Document every reference conversation so the committee can compare notes rather than relying on individual recall.
Understanding Total Cost and Contract Terms
Software platform economics are rarely as simple as the headline license fee. A joint evaluation must account for the full cost of deployment, adoption and ongoing operation for both teams, which often differs from the per-seat list price that dominates early conversations.
Assess implementation costs separately from license costs. Build a simple five-year total-cost-of-ownership model — clearly labeled as hypothetical for your organization's size — that includes license fees, implementation, training, integration development and estimated change-order risk.
Contract terms deserve as much scrutiny as capability scores. Notice periods for cancellation, auto-renewal clauses, data portability rights and price escalation caps are the terms that most organizations regret not reading carefully. The joint committee's legal representative should redline the standard agreement before the final vendor is selected, not after, so that contract risk is factored into the final decision rather than negotiated under time pressure.
User-based pricing models — where the cost scales with the number of licensed seats — require the committee to define the intended user population carefully. If facility managers who use the platform occasionally are priced at the same rate as portfolio analysts who use it daily, the economics may look very different once deployment expands beyond the initial pilot group.
How Facility and Portfolio Teams Should Run a Joint Software Evaluation: The Decision Session
The formal decision session is the moment when the committee translates weeks of structured work into a recommendation. Running this session well prevents the most common late-stage failure: reverting to political decision-making after a rigorous analytical process.
Present the scoring matrix first, before any discussion. Every committee member sees the same data simultaneously. The weighted scores should show a clear ranking in most cases; if two vendors are within a few points, the committee focuses discussion on the specific requirements where they diverge rather than relitigating the entire evaluation.
Structured debate time — where advocates for each finalist make the case for their preferred option, and skeptics respond — surfaces considerations that scored data alone may not capture. That judgment requires a conversation, not just a matrix.
Document the decision rationale in writing, including the requirements that the selected vendor does not fully meet and the mitigation plan for each gap. This documentation serves two purposes: it creates accountability for the mitigation plan, and it provides the baseline against which post-deployment performance is measured.
Governing the Platform After Selection
Selecting a platform is the beginning of the evaluation's value, not the end.
Assign a named owner for each team's use case within the platform. The facility team's owner is responsible for keeping space and maintenance data current and for escalating configuration issues. The portfolio team's owner owns lease data quality and financial model accuracy. These are operational roles, not project roles — they continue after go-live.
Establish a joint review cadence — quarterly is typical — where both teams assess whether the platform is performing against the requirements document that drove the selection. Requirements that the vendor promised to address in a future release should be tracked explicitly, not passively. If a roadmap commitment slips by two consecutive quarters, the governance review should trigger a formal conversation with the vendor's customer success team.
When two teams have write access to the same record without a defined owner, competing updates become difficult to reconcile, and the shared record — which is the platform's primary source of value — loses integrity. Document these rules in the governance plan and train both teams on them during onboarding.
Connecting the Evaluation to Ongoing Portfolio Strategy
A joint software evaluation is not just a procurement exercise. Done well, it surfaces alignment — or misalignment — between how facility and portfolio teams understand the organization's real estate position and where it is heading.
The requirements reconciliation phase often reveals that the two teams are operating from different versions of the portfolio. The facility team may be managing buildings that the portfolio team has already flagged for exit. The portfolio team may be modeling scenarios that assume space density targets the facility team has no operational plan to achieve. These gaps are not created by the evaluation; the evaluation makes them visible for the first time.
Using the evaluation as an occasion to align on a shared portfolio strategy — defining which buildings are core, which are transitional and what the decision criteria are for each — creates a foundation that the selected platform can then support.
Treating the joint evaluation as the starting point for a shared data model — rather than as a one-time buying decision — reframes what the committee is selecting. The goal is not to buy software; it is to establish an operating architecture that both teams can build on as the portfolio evolves.
Calibrating the Evaluation Timeline Realistically
Compressed evaluation timelines are one of the most common causes of poor platform decisions in commercial real estate. A lease expiration or a budget deadline creates pressure to close the evaluation quickly, and that pressure tends to collapse the structured steps that produce good outcomes.
A joint evaluation of meaningful scope — covering both facility and portfolio functions with multiple vendors — realistically requires ten to fourteen weeks from committee formation to signed contract. The requirements drafting phase alone, done properly, takes two to three weeks when both teams are building their inventories from scratch and reconciling them together.
When a genuine deadline forces a shorter timeline, the appropriate response is to reduce the vendor pool rather than to compress the per-vendor process. Bringing fewer candidates to the demonstration stage by tightening the initial RFI screening criteria allows the committee to maintain the depth of evaluation on the vendors that remain. Running two vendors through a rigorous process is more defensible than running four vendors through a process so compressed that each vendor receives only superficial scrutiny.
Build evaluation milestones into the project plan with explicit decision gates rather than treating the timeline as a continuous negotiation. If the requirements document is not locked by week three, the demonstration phase does not begin. This gate discipline prevents the evaluation from sliding indefinitely while also preventing stakeholders from forcing premature decisions.
A written scope document for the evaluation itself — separate from the requirements document — should define what is in scope for each vendor demonstration, what questions are out of scope for the scoring phase, and who has authority to add new requirements after the document is locked. Evaluations without a written scope tend to drift: participants bring in new concerns mid-process, vendors are asked to demonstrate things the committee had not previously agreed to weight, and the scoring results reflect the last conversation rather than the full structured process. Locking the scope is not bureaucratic overhead; it is the mechanism that keeps both teams aligned through a multi-week process.
Aligning on the Commercial Real Estate Workspace Standard
The commercial real estate sector has moved toward platforms that integrate functions which were previously handled in separate tools — a CRM for client relationships, a spreadsheet for lease comparisons, a project tracker for transaction milestones and a separate system for portfolio reporting. The expectation that a single platform can carry all of those workflows is newer, and the evaluation criteria need to reflect it.
It documents not just what was decided, but how the decision was made and what the organization will do if the selected platform does not perform as expected. That documentation is what separates a joint evaluation from a purchasing event.
About Advantai
Advantai is a commercial real estate intelligence and operations platform operated by ADVANTAGE AI LLC, a Delaware limited liability company. It connects client relationships, property research, documents and financial decisions in one workspace for commercial real estate teams — advisers and brokerage teams, occupier and facility teams, and portfolio teams. The platform covers CRM and origination, requirements and site selection, Property X-Ray (an interactive 3D building workspace), financial modeling and comparison, document intelligence, transactions and diligence, client collaboration, and portfolio strategy with critical dates. The optional Super Agent upgrade adds specialist, source-backed research and automated scenario analysis.
Get Started with Advantai
Ready to see your next move clearly? Go to advantaico.com, click Request a demo and tell us about your next project. Prefer to start with a single project? Visit advantaico.com/getting-started to plan your first one.