Ask a managing broker how a tenant rep deal is going and the answer comes from the broker who is running it, not from the CRM. The CRM says the deal is at the stage called Touring. It does not say what the client needs, which buildings have been toured, which were rejected and why, whether the budget moved after the second tour, or that the client's board meets next Thursday and will decide. All of that is in the broker's notes, the tour sheets and their head, and the pipeline shows a stage with no state behind it.
That is not a discipline problem. It is a shape problem. Brokerage CRMs are shaped for listings, and tenant representation is not a listing.
On the landlord side, the deal is a property. A building has space, the space has a price, prospects come and go, and the deal closes when one of them signs. A CRM built around a property record with a pipeline of prospects fits this well, which is why most commercial real estate CRMs are built this way.
On the tenant side, the deal is a requirement. A client needs twelve thousand square feet, in two submarkets, with a loading dock and parking for forty, on a five-year term, for occupancy in the second quarter, at a budget that is a range, with three things they will not compromise on and six they say they will not. The requirement is the thing that exists on day one. Properties are candidates against it, found, toured, shortlisted, rejected. The requirement changes: the budget moves after the first tour, the submarket widens after the third, the occupancy date slips when the current landlord offers a renewal.
A listing-shaped CRM has nowhere to put that. It has a deal record with a property field, so the broker either picks one building, which is wrong until the end, or leaves it blank, which is where most tenant rep deals sit for months. The requirement, the actual state of the deal, lives outside the system. We described the same problem from the opposite direction in a commercial real estate CRM deal with two sides: a generic pipeline cannot hold a deal that has two parties and two sets of facts. The tenant side is the harder case, because one of the parties is a moving target.
The managing broker cannot see the book. Which requirements are live, which are stale, which are about to decide. Forecasting is a conversation with each broker, and the conversation is as accurate as the broker's optimism that week.
Tours are not a record. Which buildings were shown, when, with which outcome, is on a tour sheet, often a document, sometimes an email. When the client asks three weeks later why the building on Fifth was ruled out, the answer is reconstructed. When a landlord's broker asks whether the client has seen their space, the answer is a guess.
Rejections are not learned from. A requirement that rejects six buildings is telling you something about the requirement. If the rejections are not recorded with reasons, the lesson is in one broker's head, and so is the requirement.
And the broker leaves with the deal. A tenant rep broker who moves firms takes the requirements with them because the requirements were never in the firm's system. The pipeline shows the stage; the stage is worthless without the state.
Listings are easier to sell software for. A property is a thing with an address, a photograph and a price, and a pipeline of prospects against it looks like every other CRM demo. A requirement is a set of constraints that changes, and the demo of a requirement is a form with twelve fields and a history, which does not photograph well. So the category is built around the listing, the tenant rep broker is given a deal record with a property field, and the mismatch is filed under broker discipline.
The brokerages that do tenant representation well have usually built the requirement record themselves, in a spreadsheet or a custom object, because they had to. The spreadsheet works for one broker and fails for the firm, for the reasons above: it is one person's record, not the firm's state.
The requirement is the record, and properties are a list against it.
The requirement record carries the client, the space criteria as structured fields rather than a notes box, the term, the budget as a range with its history, the timing with the decision dates, the must-haves and the nice-to-haves separately, and the decision-makers with their roles. It has a status that is the state of the search, not the stage of a sale: defining, sourcing, touring, shortlisting, negotiating, done.
Against it, a candidate list: each property considered, with its source, the date it was proposed, whether it was toured and when, the outcome, and the reason if rejected. The tour is an event on the candidate, not a document in a folder. The shortlist is the candidates with a flag. The deal that closes is the one candidate that reaches signed, and the commission that follows is computed from it, which is the point where the money has to be reconstructed in most firms today, as we described in commission reconstruction across four systems.
And the history. Every change to the requirement is dated, because the requirement at the time of the third tour is a different requirement from the one on day one, and the difference is the deal.
This can be built in Zoho CRM and in most of its competitors, because the CRMs are flexible enough to hold a custom record and a related list. What they are not is shaped this way out of the box, and the configuration that makes them so is a design decision a brokerage has to make deliberately: the requirement as the primary record, the property as a related candidate, the tour as an activity on the candidate, the stage replaced by a search state. We covered what deal management software should do for a commercial broker in deal management software for commercial brokers; the tenant rep record is the piece of that most often missing.
Once it exists, the managing broker's question is a report: live requirements by decision date, tours this week, shortlists with no activity in fourteen days. The broker's notes become the record rather than the only copy of it.
Pick the three largest live requirements and try to write each one as structured fields from what is in the CRM today. Most firms find they can fill in the client and the stage and nothing else, and that the rest is in three places per deal. That gap is the design.
We build the requirement record and the candidate list into the CRM the firm already runs, with the tour and commission wires, under a guaranteed estimate. Discovery is no-risk: we map your three largest requirements with you, and you pay only if you go ahead.
In a no-risk discovery we look at how a deal moves from listing to commission across your CRM and accounting today and show what one connected system would change. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
