Your Clients Are Never Leads, and Why That Has to Be Architecture, Not Policy
Savology does two distinct things, and every advisor evaluating us eventually asks the same sharp question about them. We provide a financial planning platform that firms run their own clients and prospects through. We also run Advisor Prospects, our marketplace, where advisors choose the households they want to serve. The question: if I put my book on your platform, can my clients end up in your marketplace?
No, not unless you open that door yourself, and the interesting part is why the answer holds. It is not a policy. It is the architecture.
Policy is a promise. Architecture is a fact.
Plenty of platforms will promise not to market to your clients. A promise lives in a contract, survives exactly as long as the incentives behind it, and gets tested every time the company behind it needs revenue. If your compliance team has been around, they have watched some version of that promise age badly somewhere.
An architectural guarantee is different in kind. At Savology, the marketplace runs on its own database with its own credentials, separate from the platform where organizations’ plans live. A household is copied into it only if they arrived through one of Savology’s own funnels (our ads, our marketing, our free report card) or through an organization that has it switched on for its people. The test happens on the way in. A client who arrived through your firm is never written into the marketplace unless your firm has turned that on.
The distinction matters more than it may first appear: there is no hidden copy of your book waiting on the other side of a policy. Unless your firm switches it on, the data is simply not there. We could not sell what we do not have, and we built it so we do not have it.
Who is in the marketplace, and who decides
The choice belongs to the organization that brought the household in. Clients who joined through an advisory firm’s link are outside the marketplace by default, no matter how engaged they are or what their report card shows. People who joined through an employer’s benefit or a plan sponsor are in it only where that organization has it switched on.
A firm can open one narrow door, so a household outside its ideal client profile can join the marketplace and be picked by an advisor or coach who suits them better. It covers only what the firm says it covers, and nothing moves until the firm turns it on. Working with us also never requires uploading a client list or connecting a CRM, so there is no ingestion path to worry about in the first place.
And the boundary is audited on an ongoing basis: every account the marketplace can see is tested against organization membership and that organization’s choice, so a violation would surface as an exception rather than sit unnoticed.
Where the marketplace households actually come from
The Advisor Prospects marketplace is fed by households Savology finds through its own marketing, plus the people of organizations that include it. Either way, each one built a free report card whose grades show a real need and a good fit. They consented to joining the marketplace in terms that say so plainly, and consent is rechecked at the moment an advisor picks them.
That sourcing is why the two businesses can coexist without tension. The platform serves your households. The Advisor Prospects marketplace is fed by ours, and by organizations that choose to take part. The first group is never the source of the second unless you decide it should be, and the data separation page documents the full enforcement picture, including the questions compliance teams actually ask, answered in the order they ask them.
The question to ask any platform
If you take one thing from this piece, make it the question rather than our answer: “Is your separation a policy or an architecture, and how would I verify which?” Any vendor can say the first words. The follow-up is where the answers diverge, and your book deserves the follow-up.
More detail, including how the boundary is enforced and audited: savology.com/data-separation.