Which sources produce closings, which agents are converting, which deals are at risk, and what the commission run will look like. Twopir Consulting builds the report types, the roll-ups and the sharing-aware dashboards that make those answerable in Propertybase — and fixes the data quality underneath first, because a fast wrong number is worse than a slow one. Reporting is a data model problem wearing a chart.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose pipeline, attribution and commission reporting Twopir Consulting designs and maintains.
What We Report On
Almost no brokerage lacks reports. What it lacks is a report a managing broker will make a decision on without checking it against something else first. A number that has to be verified is not a number.
Standard report types cover one object well and two related objects badly. The question leadership actually asks — which lead source produced which closing, at what cost — spans inquiry, transaction and commission, and no out-of-the-box report type reaches across all three.
Duplicate listings from a feed matched on address, sources stamped inconsistently, stages advanced days after the fact. The dashboard renders instantly and is wrong, which is worse than the weekly spreadsheet it replaced — because now the error is fast and confident.
An agent needs their own pipeline, a team lead needs their office, and the managing broker needs all of it. One shared dashboard means either agents see each other's numbers or leadership sees a filtered subset — and both erode trust in different directions.
Current pipeline is visible; how it changed is not. Without historical trending nobody can say whether conversion is improving, whether an office is slipping, or whether last quarter's intervention worked — so decisions get made on anecdote and the loudest recent deal.
Calls logged, tasks completed, records touched. All easy to measure and none of it tells a managing broker which deals are at risk this week. Activity metrics make agents perform for the dashboard rather than for the pipeline.
The information exists on a dashboard somebody has to remember to open. By the time an underperforming region is noticed, two weeks of pipeline have gone unaddressed — and the fix is threshold alerting, not another chart.
Propertybase reporting is standard Salesforce reporting pointed at packaged real estate objects. Because Listing, Property and Inquiry are ordinary Salesforce objects, everything the platform offers applies: reports and report types, dashboards with dynamic running users, roll-up summary and formula fields, reporting snapshots for historical trending, and CRM Analytics where the question outgrows a standard report. That is the whole reason a brokerage puts its real estate model on this platform rather than on a fixed product.
Three technical facts do most of the work in practice. Custom report types are what let a report span the packaged objects and your own — no standard type joins inquiry, transaction and commission in one place, and building those types is usually the first real deliverable. Roll-up summaries require a master-detail relationship, so a reporting requirement discovered after a custom object was built with a lookup is a data model change rather than a report change. And reports respect the sharing model, which means a dashboard shows each viewer what they are entitled to see — a feature, but one that surprises leadership the first time a total differs between two people.
Who this is for: managing brokers, operations leaders and CRM managers who have Propertybase live and still assemble the important numbers by hand. We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at greater scale — and if the answer is that your data is not yet reportable, we will say so before building a dashboard on top of it.
Four audiences, four different dashboards, built from one set of records
| Agent | Team lead / office | Managing broker | Finance & back office | |
|---|---|---|---|---|
| The question | What do I need to do today, and what is slipping? | Who on my team needs help, and which deals are at risk? | Which sources and offices produce closings, and where is the trend going? | What is closing this month, and what does the commission run look like? |
| Reads | Own inquiries, listings and transactions only | Office or team records, by the sharing model | All offices, with trend as well as current state | Closed transactions, commission and disbursement records |
| Built with | Dynamic dashboards running as the viewer, plus list views | Filtered dashboards on office and team hierarchy | Reporting snapshots for trend, plus comparison by office | Custom report types joining transaction to commission records |
| Fails when | It shows activity instead of what is at risk | The sharing model does not match the real org chart | There is no history, so every reading is a snapshot | Commission lives outside the CRM and has to be reconciled |
The row that catches firms out is the third. Historical trending needs to be turned on before the history exists — a snapshot started today gives you a trend next quarter, and there is no way to reconstruct one retroactively. It is the cheapest thing on this page and the most often skipped.
Reporting engagements arrive as the third and almost always start with the first. There is no point building a dashboard on records nobody trusts.
The data-quality work that has to precede any dashboard. Duplicates, inconsistent sources, stages that lag reality, and fields with no defined meaning — every one of them is a wrong number waiting to be rendered quickly.
The report types, roll-ups and dashboards themselves — built per audience, sharing-aware, and answering the four questions on the table above rather than displaying everything the objects contain.
Where standard reporting runs out: many offices, several years of history, or analysis that should never run against the production org. This is an architecture decision, not a licence purchase.
Three constraints turn a reporting request into an architecture conversation, and all three are worth knowing before you ask for a dashboard. Roll-up summary fields require a master-detail relationship, so if a custom object was built with a lookup, the total leadership wants is a data model change rather than a formula. Custom report types are what let a report span the packaged objects and yours, so the join has to exist before the report can. And reports respect the sharing model, which means a number that differs between two viewers is usually correct — each is seeing what they are entitled to.
None of that is a limitation of Propertybase; it is the Salesforce Platform behaving as designed. It is, however, why we look at the model before quoting a dashboard, and why reporting is the discipline that most reliably exposes decisions made badly during implementation. Where that turns out to be the real story, the wider fix is Propertybase optimization.
Each of these answers a question somebody is currently answering with a spreadsheet. Most firms need four of the six, and the audit decides which — and in what order.
What is open, what is at risk, and what closed. The dashboard a managing broker opens first, and the one that has to be right before any other is worth building.
Cost per closing rather than cost per lead. This is the reporting that changes where a brokerage spends its marketing budget, and it depends entirely on source being stamped correctly at capture.
Performance reporting that a team lead can act on, which means capacity alongside outcome. Ranking agents without showing workload produces league tables, not management.
What the firm is carrying, how it is moving, and where pricing is wrong. Reporting on the listing side is often the most neglected and the fastest to produce a conversation with a seller.
What is closing, what it earns, and what the disbursement run looks like — reported from the deal record rather than reconciled against it. The reporting agents check most carefully.
Evidence assembled on demand rather than gathered before every review. The reporting that turns an audit from a two-day exercise into a filter on a report.
A dashboard is the last thing built and the first thing blamed. These are the eight upstream dependencies that decide whether a number is trustworthy — and where we look when one is not.
Days-on-market and price-change reporting are only as accurate as the feed's status reconciliation. Duplicated listings from address matching inflate every inventory number in the firm.
Cost per closing by portal requires the source stamped at capture and carried through to the transaction. Retrofitting attribution is impossible: the data was never recorded in the first place.
At-risk reporting is driven by milestone dates and document state. If those live only in the transaction platform, the CRM's risk indicators are guesses dressed as data.
SLA reporting needs to see the response. Without activity sync onto the record, every reply an agent sends from their phone reads as a breach and the metric loses credibility immediately.
Commission reporting that does not agree with the ledger creates a monthly reconciliation meeting. Native inside the org where the accounting application allows it; a monitored sync where it does not.
Reports respect record visibility, so the org chart expressed in roles and sharing rules is what each viewer's dashboard shows. A total that differs between two people is usually correct, and always needs explaining once.
Multi-year analysis and heavy modelling should not run against the production org. Streaming record changes into a warehouse keeps analytics off the transactional system as volume grows.
The layer that means nobody has to remember to look. Alerts fire when conversion dips below threshold, a region falls behind target or a deal stalls — turning a dashboard into a notification.
Where those upstream systems are the actual problem, the fix is Propertybase integration; where the org as a whole underperforms, it is Propertybase optimization.
We start from the decisions leadership needs to make weekly and work backwards. A metric nobody would act on differently is a metric that does not need a chart.
What decisions get made, by whom, how often, and what would change the answer. This produces a short list of metrics that matter and a much longer list of things people asked for out of habit. The second list is where most of the saving is.
For each metric: is the data present, current, unique and consistently stamped? Duplicated listings, sources recorded three different ways, stages advanced days late. This is where a reporting engagement usually discovers it is partly a data-quality engagement, and we would rather say so at stage two.
The unglamorous deliverable that makes everything else possible: custom report types joining the packaged objects and your own, roll-up summary and formula fields for velocity, age and conversion, and any relationship change the requirement implies. Snapshots are started here too, so history begins accumulating immediately.
Built per audience rather than one shared view — agent, team lead, managing broker and finance each get what they can act on and what they are entitled to see. Dynamic running users where each viewer needs their own numbers, and threshold alerting so nobody depends on remembering to open a tab.
Metric definitions written down and agreed, so two people quoting the same number mean the same thing. Then who may create reports, where the sanctioned ones live, and a review after a month — because the first version of any dashboard contains at least one chart nobody uses.
Two engagements, both real estate. The first replaced weekly Excel with live dashboards and threshold alerts across four offices; the second made commission reporting agree with the ledger. The numbers are the ones those clients measured.
We had Salesforce. We had Propertybase. We had agents using three different follow-up tools. Nothing was connected, and our managing broker was flying blind. Twopir came in, mapped everything, and built a single operating model that our entire team actually uses. We went from not knowing where deals were to having a live dashboard that tells us exactly what's open, what's at risk, and what closed last week.
Weekly Excel reporting replaced with live role-based dashboards and threshold alerting across four offices.
Commission reconciliation used to take our back office three full days at the end of every month. Agents were questioning their splits, and we had no clean audit trail. Twopir connected our deal records to Accounting Seed and built automated disbursement workflows. We now close commission statements the same day a transaction closes. The trust that has rebuilt with our agents because of that alone has been significant.
Commission and disbursement reporting produced from the deal record rather than reconciled against it.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Reporting is where implementation decisions come due — which is why our reporting engagements so often start by fixing something that was never a reporting problem.
If a number would not change what anybody does, it does not need a chart. Mapping the weekly decisions first produces a short dashboard people use, rather than a long one they screenshot into a slide once a quarter.
Duplicated listings, sources stamped three different ways, stages advanced late. A dashboard on top of that is a wrong number delivered faster, and it costs more credibility than the spreadsheet it replaced.
Snapshots cannot be backdated. Turning them on at the beginning of an engagement costs almost nothing and means trend analysis exists next quarter — and it is the single most commonly skipped item on this page.
An agent, a team lead, a managing broker and the back office need four different dashboards from one set of records. Dynamic dashboards give each viewer their own entitled numbers instead of forcing a choice between exposure and blindness.
Threshold alerting when conversion dips, a region falls behind or a deal stalls. Leadership responding the same day rather than a week later is worth more than any additional chart on the page.
Anything in the org, because Listing, Property and Inquiry are ordinary Salesforce objects. In practice brokerages run on six areas: pipeline and deal risk, lead source attribution through to closing, agent performance with capacity alongside it, inventory and listing analytics, commission and financial reporting, and compliance evidence. All of them use standard Salesforce reporting — reports and report types, dashboards, roll-up and formula fields, reporting snapshots for trend, and CRM Analytics where a question outgrows a standard report. That breadth is precisely why a brokerage puts its real estate model on this platform rather than on a fixed product.
Because the questions leadership asks span objects that no standard report type joins. "Which lead source produced which closing, and what did it earn" reaches across Inquiry, the transaction record and commission records, and out of the box you can report on those separately but not together. Custom report types are what create that join, and building them is usually the first real deliverable of a reporting engagement — unglamorous, invisible on a dashboard, and the thing that makes every subsequent report possible. They also control which fields are available to report builders, which is how you stop five people producing four different versions of the same number.
Only if your sharing model says they can. Salesforce reports respect record visibility, so a dashboard shows each viewer what they are entitled to see, and dynamic dashboards run as the person looking at them — meaning one dashboard can serve every agent with their own pipeline. That is the correct behaviour, and it surprises leadership the first time two people quote different totals from the same dashboard. It also means reporting exposes any mismatch between your sharing model and your real org chart very quickly: if a team lead cannot see their own team's deals, the problem is in the role hierarchy rather than in the report.
Yes, but only from the point you start capturing it. Standard reports show current state; historical trending needs reporting snapshots, which take a periodic copy of a report's results so you can compare across time. The catch is that snapshots cannot be backdated — a snapshot started today gives you a trend next quarter, and there is no way to reconstruct one retroactively from records that have since changed. It costs almost nothing to turn on and is the most commonly skipped item in a reporting build, which is why we start it at stage three of every engagement rather than when somebody first asks for a trend line.
Usually neither, and the gap is the finding. In our experience the difference comes from one of four things: duplicate records inflating the CRM side, typically listings matched on address rather than on a stable identifier; a metric two teams define differently, such as whether a deal counts at acceptance or at close; sharing scope, where the two people running the numbers are entitled to see different records; or timing, where stages are advanced in the CRM days after they happened. We reconcile them line by line, because until the two agree nobody will act on the dashboard — they will keep maintaining the spreadsheet as insurance, and you will be paying for both.
For most brokerages, standard reports and dashboards are enough for longer than vendors suggest — and they are maintainable by your own admin, which matters more than capability. The honest triggers for going further are: analysis that spans several years of history and slows the production org; blending Propertybase data with sources that do not live in Salesforce; multi-office comparison with dimensions standard reports cannot express; or genuinely exploratory analysis rather than defined metrics. Where those apply, CRM Analytics or a warehouse fed by Change Data Capture is the right architecture. Where they do not, the extra licence buys complexity you will pay to maintain.
Yes, and it is usually worth more than any additional chart. Threshold alerting fires when a conversion rate dips below an agreed level, a region falls behind target, or a deal stalls beyond a defined stage age — so the system tells the right person rather than waiting to be opened. On the brokerage in our case study, that shift moved leadership from weekly Excel reports to responding to pipeline issues the same day instead of seven days after the fact. The design discipline is restraint: alerts that fire too often get muted, and a muted alert is worse than none because everybody believes it is still working.
A dashboard that disagrees with the spreadsheet, a question the objects cannot answer, an attribution chain that stops at the enquiry, or no reporting at all. We will tell you whether it is a chart problem, a model problem or a data problem — before anyone builds anything.
Salesforce architecture, Propertybase delivery & real estate operations
