Agents working around it, listing data nobody trusts, feeds that silently stopped, automation built for a process the firm no longer follows. Twopir Consulting audits the architecture, the data and the actual usage, delivers written findings, then rebuilds the parts holding the brokerage back. Starting from a blank org is rarely necessary and almost never the cheapest route.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups who came to Twopir Consulting with a Propertybase org that was live, expensive and not working.
What We Audit
Nothing here happened on a single day. Each one is a slow drift between what the org was built for and what the brokerage now does — and by the time it is visible, it is expensive. Orgs do not fail. They are outgrown.
An agent finds it faster to keep a listing in their notes app. Then two do. Nobody decides to abandon the system, and yet within a year the pipeline data is a partial account of what is actually happening — and the reports built on it stop being worth reading.
The brokerage added an office, changed how leads are allocated, or introduced a new transaction type. The rules built two years ago still fire, still route by the old model, and now actively fight the way the firm works.
Duplicates from a feed matched on address, sources stamped inconsistently, contacts entered three ways. There is a point where people stop correcting the data and start working around it, and recovering from that costs far more than preventing it would have.
Fields nobody can account for, triggers whose author left, three generations of automation firing in an undocumented order. Each new requirement is quoted higher than the last because nobody can predict what it will disturb.
A credential expired, a board renamed a field, a nightly job stopped. Nothing alerted because nothing was built to, and the gap is discovered by an agent calling a buyer about a property that sold three weeks ago.
Without a sandbox on the upgrade path, each vendor release is a risk rather than a routine. So it gets postponed, then postponed again, and the firm falls behind supported versions — losing the fixes and features it is already paying for.
Propertybase optimization is a diagnostic and remediation engagement on an org that is already live. It examines four layers — architecture and data model, data quality and feed health, automation and customization debt, and what agents actually do compared with what was built — and produces written findings on which of them is costing the brokerage money. Only then does anything get rebuilt, in the order the findings prioritise.
The order matters more than the work. Almost every firm arrives naming a symptom — reporting is wrong, adoption is poor, the feed is unreliable — and the cause is usually one layer down. Reporting that disagrees with reality is a data-quality problem; poor adoption is usually a process-design problem; an unreliable feed is normally an ownership problem rather than a technical one. Rebuilding the named symptom without finding the cause produces a better-looking version of the same failure six months later.
Who this is for: managing brokers, operations leaders and CRM managers with Propertybase live and underperforming — including firms whose original implementation was delivered by somebody else. 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 a large share of our real estate work starts exactly here.
Three honest answers to an underperforming org, and how to tell which one you are in
| Optimise what exists | Rebuild parts of it | Replatform | |
|---|---|---|---|
| You are here when | The architecture is sound and the problems are data, process, adoption or monitoring | The data model or sharing design cannot express how the firm now works, but the platform still fits | The firm's revenue model is no longer listing-driven, or requirements have moved off this product entirely |
| Typical work | Data cleanup, feed ownership, automation consolidation, reporting, retraining | Object and sharing redesign, migration within the org, phased re-launch by workstream | A different Salesforce build or a different product, with a migration off this org |
| What it protects | Everything — no data moves and no retraining beyond the changed workflow | History and integrations, if the redesign is staged rather than done at once | Nothing automatically; every integration and report is rebuilt |
| How often we recommend it | Most engagements. The cause is usually below the symptom, not in the architecture | A meaningful minority, normally where offices or teams were never modelled properly | Rarely, and we will say so plainly at the audit rather than after the invoice |
If the honest answer is the third column, we will tell you — a Sales Cloud build or a wider Salesforce for real estate engagement may be the better route. We have no licence revenue riding on the answer.
Most firms take the first two. The third is what stops you needing this page again in eighteen months, and it is the one most often declined.
A fixed-scope diagnostic across the four layers, ending in written findings you own — whether or not you engage us for the remediation. No proposal is written before this exists.
The rebuild, in the order the findings prioritise rather than the order the symptoms were reported. Delivered as workstreams so the brokerage sees value before the whole programme completes.
The habits that keep an org from decaying again: monitoring, a sandbox on the upgrade path, a change process, and somebody named who owns each moving part.
Optimization engagements go wrong when the named symptom is treated as the requirement. A firm arrives saying reporting is unreliable, and the reporting is fine — it is faithfully reporting duplicated listings from a feed that matches on address. Another says adoption is poor, and the system is technically sound but asks agents for eleven fields at a moment when they have one hand free. Rebuilding the symptom produces a better-looking version of the same failure.
So the audit comes first, it is fixed-scope, and the written findings are yours whether or not you engage us for the work. That order also protects you from us: a consultancy that scopes remediation before diagnosis has an obvious incentive to find a large problem. Where the honest finding is that the org needs very little, we would rather say so and be called back when it does.
Ordered as they usually run. Data first, because everything downstream inherits its errors; adoption last, because retraining people on a system that still fights them wastes both.
The workstream everything else depends on. Deduplication that survives the next sync, keys assigned retroactively, and the rules that stop the same decay recurring. Where records are moving between systems rather than being cleaned in place, that is Propertybase data migration.
Finding what stopped, fixing it, and making sure the next failure announces itself. Most orgs we audit have at least one integration that has been quietly degraded for months.
Three generations of rules reduced to one documented layer. These engagements almost always end with fewer automations than they started with, and an org that is finally safe to change.
Where the firm genuinely outgrew the design — new offices, new transaction types, a sharing model that no longer matches the org chart. Staged so the brokerage keeps running throughout.
Once the data is true, the numbers become worth building. Usually the workstream that convinces leadership the wider programme was worth funding.
Last, deliberately. Retraining agents on a system that still fights them wastes the training and the goodwill; fix the friction first, then re-launch by role.
The symptom a firm reports and the finding that matters are rarely the same thing. These are the eight we check on every engagement, in roughly the order they produce surprises.
Is every board still syncing, and does the record count reconcile against the source? A feed that halved six weeks ago and told nobody is the most common single finding we report.
Whether listings and contacts carry stable identifiers, or are matched on address and name. Duplication is a key problem wearing a data-quality costume, and cleaning it without fixing the key just delays it.
Whether the roles and sharing rules still describe the firm. New offices and team structures are usually added to the business long before they are added to the org, and every report inherits that gap.
Everything that fires on each object, in what order, and whether any of it contradicts the rest. Orgs commonly carry rules built for a process that changed two reorganisations ago.
How many custom fields exist, how many are populated, how many are read. The gap between those three numbers predicts how expensive the next change will be better than anything else we measure.
Which screens agents use, which fields they skip, and where they leave the system entirely. Login counts prove nothing; the shape of the work inside the org is what tells you whether it is being used.
Whether anybody still maintains a parallel spreadsheet. If they do, that is the real measure of whether the org is trusted — and the spreadsheet usually shows exactly which number is wrong.
Whether a sandbox sits on the package upgrade path and whether anything resembling a test set exists. Firms without both defer upgrades, and deferred upgrades compound into their own project.
Where the findings point at one layer specifically, the deeper page is Propertybase integration, automation or reporting & dashboards.
We audit Propertybase and Salesforce setups and deliver written findings in five business days. You own that document regardless of what you do next — including taking it to somebody else.
Read access to the org, plus a conversation with the people who use it rather than the people who bought it. We measure the current state before opinions are attached to it — record counts, feed reconciliation, automation inventory, custom object and field usage.
Delivered in five business days: what is working, what is broken, what is costing money, and what each finding will take to put right. Ordered by business impact rather than by how technically interesting it is. This is the deliverable, not a sales document.
Which findings to act on, in what order, and which to consciously accept. Some debt is worth carrying. The output is a sequenced roadmap where each workstream delivers something visible on its own, so the brokerage sees value before the programme finishes.
Built in a sandbox, released in sequence, with the brokerage running throughout. Data first, because everything downstream inherits its errors; adoption last, because retraining people on a system that still fights them wastes both the training and the goodwill.
Monitoring with named owners, a sandbox on the upgrade path, a data-quality report your team runs, and a change process so new requirements do not become the next generation of debt. The measure of success is that you do not need this engagement again.
Two engagements, both real estate, both starting from software the client already owned. The first firm had been through two failed implementations before we audited it. The numbers are the ones those clients measured — scoped exactly as they measured them.
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.
Workflow audit across four offices, fourteen handoff gaps identified and prioritised, then remediated in sequence.
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.
Back-office remediation: commission reconciliation moved from a three-day manual close onto the deal record.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. A large share of our real estate work starts with an org somebody else delivered — and we would rather inherit one than argue about who built it.
Fixed-scope audit, written findings in five business days, and the document is yours whatever you do next. A consultancy that scopes remediation before diagnosis has an obvious incentive to find a large problem.
Reporting that disagrees with reality is usually a data problem; poor adoption is usually a process-design problem; an unreliable feed is usually an ownership problem. Rebuilding the reported symptom produces a better-looking version of the same failure.
Not every finding is worth fixing. Part of the deliverable is which problems to consciously accept, because a remediation programme that tries to fix everything stalls before the workstreams that mattered are delivered.
Occasionally the honest answer is that this is no longer the right product for the firm's revenue model. We do not resell Propertybase or Salesforce licences, so nothing about that answer costs us anything.
Login counts prove nothing. The shape of the work inside the org — which screens are used, which fields are skipped, where people leave for their inbox — is what tells you whether a system is adopted or merely mandatory.
Yes, and that is where a large share of our real estate engagements start. An org can be technically live and operationally dead — agents working around it, listing data nobody trusts, feeds that silently stopped, automations built for a process the firm no longer follows. We audit the architecture, the data and the actual usage, then rebuild the parts that are holding the brokerage back. Starting from a blank org is rarely necessary and almost never the cheapest route, because a rebuild throws away working integrations, migrated history and whatever adoption you still have.
Four layers: architecture and data model, including sharing and environments; data quality, covering duplicates, completeness, source consistency and key integrity; automation and customization inventory, including what still actually fires; and actual usage compared with what was built. We audit Propertybase and Salesforce setups and deliver written findings in five business days — what is working, what is broken, what it is costing, and what each fix takes, ordered by business impact. That document is yours regardless of what you do next, including taking it to another partner.
The test is whether the product still matches the firm's revenue model. If your business is listing-driven and the problems are data, process, adoption or monitoring, optimisation is almost always correct — those causes do not care which platform you are on and follow you to a new one. If the data model or sharing design cannot express how the firm now works but the platform still fits, that is a partial rebuild inside the same org. Replatforming is right only when requirements have genuinely moved off this product — for instance a firm whose revenue is no longer listing-driven. We will say which one plainly at the audit, and we do not resell either licence, so nothing about that answer costs us anything.
Not materially, because the work is delivered as sequenced workstreams rather than as a single release. Everything is built and tested in a sandbox, then released in an order chosen so each workstream delivers something visible on its own. Data remediation and feed repair are largely invisible to agents while being the most valuable. The two that do touch them — layout and flow simplification, and the role-based re-launch — come last and deliberately, because retraining people on a system that still fights them wastes both the training and the goodwill you need for it.
Usually not. In our experience the report is working correctly and faithfully reporting bad data — most often duplicated listings from a feed matched on address rather than on a stable identifier, sources stamped three different ways, or stages advanced days after the fact. The other common cause is a sharing model that no longer matches the org chart, which makes two people see legitimately different totals. Rebuilding the dashboard on top of any of that produces a wrong number delivered faster. That is why the audit profiles the data before anybody touches a chart.
It is the normal starting point, not an obstacle. We do not need institutional knowledge to audit an org — the org itself is the documentation, and read access plus a conversation with the people who actually use it is enough. Undocumented triggers, fields nobody can account for and automations whose author left are exactly what the inventory stage exists to surface. What we do need is one person on your side with the authority to decide which findings get acted on, because prioritisation is a business decision rather than a technical one and it is the single biggest predictor of whether a remediation programme finishes.
Four habits, and none of them is expensive. Monitoring on every feed and automation with alerts to a named owner, so failures announce themselves instead of being discovered by an agent. A sandbox kept on the package upgrade path with a runnable test set, so vendor releases stay routine rather than becoming a project. A data-quality report the operations team runs before month end. And a change process, so new requirements are designed rather than accumulated. Decay is not inevitable — it is what happens when every moving part is technically owned by nobody. Where a firm has no internal admin, that gap is worth closing explicitly through support and managed services rather than by default.
An org agents work around, listing data nobody trusts, feeds that stopped without telling anyone, or an implementation somebody else delivered and nobody now understands. We will tell you what is actually wrong, in writing, in five business days.
Salesforce architecture, Propertybase delivery & real estate operations
