Agents joining and leaving, a feed that stopped overnight, a package release to test, a commission run at month end, and a backlog of small changes nobody has time for. Twopir Consulting runs that layer for firms without a full-time Salesforce admin — and for the ones whose admin should be doing something more valuable. Named people, defined coverage, and a system that stops drifting.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose Propertybase orgs Twopir Consulting monitors, administers and keeps current between projects.
What We Cover
Most brokerages do not decide to leave their CRM unmanaged. It happens because the person who knew it had another job, and the work that keeps a system healthy has no deadline attached. Ownership is not a job title. It is a defined set of things somebody does every week.
The feed stopped on Saturday. Nobody found out until a buyer was told about a property that sold three weeks ago. Between those two moments, every listing decision the firm made was based on inventory that had quietly stopped updating.
Brokerages run on one capable operations manager who learned the org by necessity. When they are on leave, nothing changes; when they resign, nobody can explain why a routing rule exists — and the firm discovers its CRM was a single point of failure.
Agent turnover is constant in this industry and offboarding is nobody's specific job. Former agents retain access to client data for months, licences are paid for people who left, and new agents lose their first week to a permissions request.
Without a sandbox on the upgrade path, every vendor release is a risk rather than a routine. So it is postponed, and postponed, until the firm is several versions behind and the upgrade has become its own project with its own budget.
Twenty requests, each an hour of work, none of them urgent enough to interrupt anybody. Individually trivial; collectively the reason agents believe the system does not respond to them, which is where adoption starts leaking.
Commission runs, reconciliation questions and disbursement corrections all land in the same three days, on whoever is nearest. Predictable, recurring, and almost always absorbed by somebody whose actual job is something else entirely.
Propertybase managed services is a retained engagement covering the work a live org generates continuously: monitoring feeds, automation and data quality; responding to user issues and access requests; onboarding and offboarding agents; testing each package release in a sandbox before production takes it; and delivering the backlog of small changes that otherwise accumulates until adoption suffers. It is deliberately not a ticket desk. A queue that answers questions but owns nothing leaves the drift exactly where it was.
The distinction that matters commercially is between this and a remediation project. If your org is currently underperforming, a retainer will not fix it — you need a diagnosis and a rebuild first, which is Propertybase optimization. Managed services is what keeps a healthy org healthy afterwards, and what prevents the same engagement being necessary again in eighteen months. We will say which one you need before quoting either.
Who this is for: firms with no full-time Salesforce admin, firms whose admin is capable but stretched across too much, and firms who want architecture-level judgement available without carrying it as a salary. 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.
Three ways to cover the work, and what each one is genuinely good at
| Hire an in-house admin | A support desk | A retained team | |
|---|---|---|---|
| Strongest at | Availability, context and relationships inside the firm | Answering discrete user questions quickly and cheaply | Ownership across monitoring, releases, architecture and backlog |
| Weakest at | Depth on integration, Apex and architecture; and single-person risk | Anything nobody raised a ticket for — which is where drift lives | Being in the room; it needs a named internal owner to work with |
| Cost shape | A salary, plus recruitment, plus the cost of the gap when they leave | Low and predictable, but the work it does not cover accrues elsewhere | A retainer scaled to the org's size and change rate |
| We recommend it when | You are large enough to keep a good admin busy and to develop them | Your org is stable, simple, and genuinely only generates questions | You need admin cover plus architecture judgement without a second hire |
The first column is often the right answer, and we will say so. The combination we see working best at scale is an internal admin who owns the day-to-day relationship with a retained team behind them for integration, release testing and architecture — not one instead of the other.
Three shapes of retainer, cumulative rather than alternative. Most firms start at the first, and the ones growing fastest end up at the third within a year.
The safety net. Somebody is watching, somebody answers, and nothing critical goes unnoticed over a weekend. The minimum a live brokerage org should have behind it.
Everything in Cover, plus the recurring operational work that keeps an org from drifting — the things with no deadline, which is exactly why they never get done.
Everything in Run, plus a standing capacity for change. For firms adding offices, agents, markets or transaction types faster than a support arrangement can absorb.
A retainer is the wrong instrument for a broken org. If listings are duplicated, feeds are unreliable, automation contradicts itself and agents have stopped using the system, monthly support hours will be consumed entirely by the symptoms and the causes will still be there next year. That needs a diagnosis and a remediation project first — we will say so rather than sell you a retainer that quietly fails.
A retainer also cannot substitute for an internal owner. Somebody at the firm has to be able to decide what matters, approve changes and speak for the business, even where every hand on the org is ours. The engagements that work best pair a named internal owner with a named lead on our side; the ones that struggle are the ones where the brokerage hoped to outsource the decisions along with the work.
None of these has a deadline, which is precisely why they go undone in firms without a named owner. Each one is cheap to sustain and expensive to recover from.
Watching the things that fail silently. In a brokerage the expensive failures are not outages — they are feeds and jobs that keep reporting success while quietly doing less than they should.
Agent turnover is constant in this industry, and both ends of it carry real risk — a leaver keeping access to client data, and a joiner losing their first week to a permissions request.
Package releases and Salesforce seasonal releases both land whether you are ready or not. A sandbox on the upgrade path turns each of them from a risk into a scheduled half-day.
Data quality is not a project you finish; it is a rate you hold. Duplicates re-accumulate, sources drift, and the point at which people stop trusting the data is expensive to come back from.
The most predictable peak in a brokerage's calendar, and the one most often absorbed by somebody whose real job is something else. Planned for rather than survived.
The twenty small requests nobody has time for. Individually trivial, collectively the reason agents conclude the system does not respond to them — which is where adoption starts leaking.
Each of these has a monitor, a threshold and a named owner on a managed engagement. Without that, each of them is discovered by whoever is holding a deal that day.
Per board: did it run, did the volume look normal, and does the count reconcile against the source? Credentials expire and boards rename fields without notice, and neither event announces itself.
Listings still publishing outward, inquiries still arriving with a source stamped. A capture endpoint that silently stops looks exactly like a quiet week in the market until somebody checks.
Flows that error on records hitting a validation rule, and the subset of records skipped every day as a result. Usually the unusual records, which are usually the ones that mattered.
Whether sequences are actually sending. Propertybase email automation has operational steps of its own, and a correctly configured sequence can sit silent after a change nobody verified.
Whether closed transactions are posting and the ledger still agrees with the pipeline. Discrepancies here surface at month end under time pressure, which is the worst moment to find them.
Who has access that should not, which licences are assigned to people who left, and which integration credentials are approaching expiry. All three are quiet costs and quiet risks.
Not whether duplicates exist but whether they are increasing. A rising rate means a matching rule is wrong somewhere upstream, and cleaning without fixing that is a cycle you repeat forever.
Package versions, Salesforce seasonal releases and platform deprecations that will affect the build. Tracked ahead of time, so an upgrade is a scheduled task rather than an emergency.
Where monitoring surfaces something structural, the fix is a project rather than a support ticket — Propertybase optimization or integration.
Taking over an org we did not build is normal work, not an exception. What we need is read access, a named internal owner, and permission to say plainly what we find.
Before any coverage commitment, we look at what we would be taking on: architecture, feed health, automation inventory, data quality and the size of the existing backlog. If the honest finding is that a retainer would be spent entirely on symptoms, we say so and propose a remediation project instead.
What is in scope, what is out, who is named on each side, how issues are raised and escalated, and what reporting you get back. Every engagement has a named project lead with direct Slack and Zoom access, and response within 24 hours on active work — the rest is scoped to your org rather than to a template.
Monitoring stood up on every feed, job and automation that does not already have it, with thresholds and named owners. Runbooks written for the failures we expect. Where documentation does not exist — usually — we write it as we learn the org, and it stays yours.
Daily monitoring and response, a regular release of backlog changes, package and seasonal release testing on its own schedule, data-quality cycles, and month-end support at the peak. Predictable rhythm rather than reactive bursts, because the reactive version is what firms are escaping.
A periodic review of what broke, what changed and what should change next, with the documentation kept current throughout. If you hire an admin, we hand over cleanly and step back to architecture — a managed engagement that has made itself unnecessary has worked, not failed.
Two engagements, both real estate. Each one produced a system that then had to be kept working — monitored feeds, tested releases and a backlog that keeps moving. 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.
Health-check automation on every MLS feed, alerting the admin team before agents discover a failed sync.
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.
Month-end commission run moved off a three-day manual close and onto the deal record.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Every engagement has a named project lead with direct Slack and Zoom access, response within 24 hours on active work, and delivery from our India-based team with dedicated overlap hours for US EST, UK GMT and AEST.
Managed services staffed as a separate, cheaper tier is how a retainer becomes a queue that answers questions and owns nothing. The people covering your org are the ones who deliver our implementations, which is what makes architectural judgement available on a Tuesday.
Outages get noticed. What costs a brokerage money is a feed reporting success while moving half the records it should, and a Flow skipping the unusual ones every night. Those need thresholds and named owners, not a ticket form.
If you are big enough to keep a good admin busy and to develop them, that is usually the right answer, and we will say so. The strongest arrangement we see is an internal admin owning the day-to-day with a retained team behind them for integration, releases and architecture.
Inherited orgs with no documentation and departed authors are normal work here. The org itself is the documentation; we write down what we learn as we learn it, and that record stays yours whatever happens to the engagement.
Documentation kept current, runbooks your team can follow, and a clean handover if you hire. A managed engagement that has made itself unnecessary has worked — and it is a considerably better reference than one that made itself indispensable.
Six recurring areas. Monitoring and incident response across feeds, jobs and automation, including the failures that report success while doing less than they should. User support and the agent joiner and leaver lifecycle, which in this industry is continuous. Package and Salesforce seasonal release testing in a sandbox before production takes them. Data-quality maintenance, because duplicates re-accumulate and drift is a rate rather than a one-off. Month-end commission and reporting support at the peak. And delivery of the backlog of small changes that otherwise piles up until agents conclude the system does not respond to them.
Often yes, and we will say so. An in-house admin brings availability, context and relationships no external team can match. What they usually cannot bring alone is depth on integration, Apex and architecture, and they represent a single point of failure — when they are on leave nothing changes, and when they resign the org's history leaves with them. The arrangement we see working best at scale is an internal admin owning the day-to-day relationship with a retained team behind them for integration, release testing and architecture. Not one instead of the other. If you are large enough to keep a good admin busy and to develop them, hiring is the right first move.
Yes — inherited orgs are normal work rather than an exception. We do not need institutional knowledge or the original partner's documentation, because the org itself is the documentation: read access plus a conversation with the people who use it daily is enough to build an accurate picture. Undocumented triggers, fields nobody can account for and automations whose author left are exactly what the health-check stage exists to surface. What we do need is a named internal owner with authority to decide priorities, and permission to tell you plainly what we find, including where the previous build went wrong.
Every engagement has a named project lead with direct Slack and Zoom access, and response within 24 hours on active work. Delivery is managed from our India-based team with dedicated overlap hours for US EST, UK GMT and AEST, which is how firms in those markets get same-working-day contact rather than a queue. Beyond that baseline, severity-specific targets belong in the agreement rather than on a web page, because they should be set against your org's actual risk profile — a brokerage whose commission run is the critical path needs different month-end coverage from one whose MLS feed is. We would rather scope that with you than publish a number that fits nobody.
No, and we will not sell you one that quietly fails. If listings are duplicated, feeds are unreliable, automation contradicts itself and agents have stopped using the system, monthly support hours will be consumed entirely by symptoms while the causes stay exactly where they are. That needs a diagnosis and a remediation project first — a fixed-scope audit with written findings, then remediation in prioritised workstreams. A retainer is the right instrument afterwards, to keep a healthy org healthy and stop the same engagement being necessary again in eighteen months.
On a managed engagement, we do. A sandbox is kept on the package upgrade path with a runnable test set covering your customization and integrations, so each release is regression-tested before production takes it. Salesforce's own seasonal releases are reviewed the same way, along with platform deprecations that will affect the build — the retirement of older declarative tooling being the current example. This is the single habit that most reliably separates orgs that age well from orgs that fall several versions behind and turn an upgrade into its own project with its own budget.
We hand over and step back, usually to a smaller architecture-and-releases engagement. That is a good outcome rather than a lost account: documentation is kept current throughout precisely so a handover is possible at any point, and runbooks are written for your team to follow rather than for ours. A managed engagement that has made itself unnecessary has worked, and it is a considerably better reference than one that made itself indispensable. Most firms that hire keep us for package release testing, integration work and architecture review, because those are the things a single admin is least able to absorb.
No full-time admin, an admin stretched across too much, an org somebody else built and left, or a backlog that has not moved in a year. We will look at what we would be taking on and tell you whether a retainer is the right instrument at all.
Salesforce architecture, Propertybase delivery & real estate operations
