A tenant-representation deal runs backwards compared with a listing. You start from a client who needs space, not from a building that needs a tenant, and everything that follows hangs off that brief. Good tenant representation software has to model that shape: a chain of records where each stage carries the last one forward with no re-keying. This post walks the demand-side pipeline the way REPM stores it on Microsoft Dataverse, from the space requirement through the market survey, the options, the proposals, the lease and the landlord-paid commission, and explains why building on Dataverse changes what a firm that already lives in Microsoft 365 can do with the data.
Where tenant representation software starts: the space requirement
Everything begins with the occupier brief. In REPM that is a requirement record: the target area range, headcount, budget, desired timing, the expiry on the current lease, and the must-haves that will disqualify half the market before you tour anything. In a spreadsheet the brief is a header row that people stop updating. As a record it becomes the anchor every later record points back to, and it carries its own pipeline stage, from brief to survey to touring to RFP to negotiation to LOI to execution. When a colleague opens the requirement six weeks in, the brief, the shortlist, the tour notes and the live proposals are all attached to it, so the context of the engagement is read off one record instead of reassembled from an inbox.
The market survey and the client's verdict per option
Off the requirement hangs the market survey: a curated shortlist of candidate buildings assembled for this client. The survey is versioned, because the market moves, and the second draft you send after three towers come off the table is a different document from the first. Each building on the survey is a space option, and each option carries the client's verdict as a field you can report on: favorite, interested, or pass. That verdict is data, not a note in the margin, so you can pull the favorites across every open requirement into one view, and you never lose the reason an option dropped out. Tour stops attach to the options where they happened, with the sequence walked and the client's score per stop, so the feedback lives on the record rather than in someone's memory of the afternoon.
Proposals normalized to net effective rent
An option gets interesting once the landlord puts numbers on it, and this is where tenant rep software earns its place. A headline rent tells you almost nothing on its own. One building quotes a lower base rent with a thin fit-out contribution, another quotes higher but adds six months free and a generous fit-out allowance, a third escalates faster over a longer term. REPM normalizes each proposal on the same components: base rent, the service charge or operating expense, the tenant-improvement or fit-out allowance, free-rent months, the escalation, and the term. From those it derives a net effective rent, the figure that lets best-and-final rounds compare like with like. Because every proposal sits on its option, and every option on the requirement, the comparison is a view over records you already keep, not a spreadsheet someone rebuilds the night before the client call.
How tenant representation software carries the option into the lease
Negotiation rounds and the letter of intent track against the option they belong to, so the history of who offered what, and when, stays attached instead of scattered across email threads. Then comes the step most tools fumble: signature. In a typical stack the deal closes and the lease starts life again in another system, re-keyed by hand. In REPM the winning option carries its economics straight into an occupier lease. Term, break options, free rent, the fit-out allowance and rent commencement come across as the fields they already were, so critical-date tracking and occupancy cost start on day one instead of after a migration. The lease is not a fresh copy of the deal. It is the same chain of records continuing past the signature.
Commission the way it is actually paid
The last record in the chain is the money. Tenant-rep commission is usually landlord-paid, which already breaks the assumption baked into a generic tenant rep CRM that the fee comes from the client. It is often split with a co-broker on the other side of the table, then split again with the house, and it rarely arrives in one payment. REPM models the commission as a record with its basis and rate, the gross figure, the co-broke and house splits down to the net that reaches your firm, and the tranches that land on execution and on occupancy, each with its own invoice status. Because the commission points back to the requirement and the lease, you can read net-to-firm across the whole live pipeline without exporting anything into a side workbook.
Why tenant representation software belongs on Dataverse
Every record so far could be built in a purpose-built tenant rep software product. The difference is where the records live. REPM stores them in Microsoft Dataverse, the platform that also sits under Dynamics 365 and the wider Power Platform, deployed into your own Microsoft tenant. For a firm already running on Microsoft 365, that has consequences a closed vertical tool cannot match.
Start with security. Dataverse security is role-based, so the analyst assembling a survey can read requirements, options and buildings while the commission economics stay hidden from them through column-level security. The partner who owns the relationship sees the whole chain. A co-broker or a client contact sees only what you assign. These are the same security roles your administrators already manage for email and files, not a second permission scheme you maintain inside a vendor's app.
Then reporting. Because the pipeline is ordinary Dataverse data, Power BI reads it directly for pipeline dashboards, net-effective-rent comparisons across live requirements, and net-to-firm forecasting, over the same records the deal team edits. Outlook, Teams and Excel reach that data too. And the data is yours: it stays in your tenant, in a region you choose, and it leaves through the Dataverse Web API rather than a request-an-export form. In a closed tenant-rep SaaS the pipeline is the vendor's asset and you rent access to your own deals. The IT case for that difference is worth reading on its own, and we make it in real estate software on Dataverse.
None of this replaces judgment about the deal. What it changes is how much of the engagement survives as structured, reportable data instead of evaporating into attachments. REPM is honest about its edges: it does not do ASC 842 or IFRS 16 lease accounting yet, and a loginless client survey portal is on the roadmap rather than in the product. What it covers is the demand-side chain from the requirement to the commission, on one record model you own. See the full capability set on the tenant representation page, check what a seat costs on pricing, and for the stage-by-stage version of the engagement read our tenant representation process guide.