Why another platform will not fix your operations

Almost every firm we look at has already solved this once. There is a CRM that a vendor configured properly, a document system somebody chose carefully, a planning tool the advisors actually like, and a custodial platform nobody had a choice about. Each one was bought to fix a problem, and each one did.

The work is still taking too long. So the next assumption is that one of the platforms is wrong, and the firm starts looking at replacements. That is usually the most expensive wrong turn available.

Software is sold by the product, and work does not happen inside one product

A vendor is responsible for what happens inside their own edges. They will configure their stages, their required fields, their templates, and their reports, and they will do it well. What no vendor owns is the handoff out of their product and into the next one.

Open an account and watch where the information goes. It is entered in the CRM, entered again in the custodial platform, and the confirmation is filed by hand into the document system under whatever name the person filing it chose that day. Three systems each did their job. The firm still paid for the same fact three times, and now holds three versions of it that can disagree.

That gap is where the hours are. It does not appear in any vendor demo because no vendor is selling it, and it is the subject of its own post on why your tech stack does not talk to itself.

What a migration really costs

Replacing a platform is the most expensive project a firm of this size can take on, and the cost is rarely the licence. It is the months of parallel running, the records that do not map cleanly, and the staff learning a second way to do a job they already knew. Most of all it is the process debt that moves across untouched, because nobody wrote it down before the move. We put numbers around that in what a CRM migration actually costs.

No vendor is responsible for the space between their product and the next one, which is where most of your hours are.

What is missing

The thing no platform ships is the set of decisions about how they relate to each other. That is a short list, and it is boring, and it is the entire difference:

• Which system owns which record, so there is one authoritative copy and the others read from it
• What a document is called and where it lives, so somebody who did not file it can find it
• What happens automatically between systems, who owns each of those automations, and what it does when it hits something it cannot handle
• What is written down, and where it is written down, so the procedure sits inside the system where the work happens rather than in a manual nobody opens

None of that is a purchase. It is design work, and it has to be done against how your firm actually operates rather than how the software assumes you do. It is also most of what a build covers.

How to tell which problem you have

There is a straightforward test. Take one recurring process, onboarding is usually the clearest, and follow a single real case end to end. Write down every system it touches, every point where a person retypes something a machine already knows, and every point where it waits on somebody.

If the delays are inside one product, you may genuinely have the wrong product. If the delays are in the spaces between products, a new platform will reproduce the problem with a different logo on it.

In our experience it is almost always the second one, which is good news, because the second one is much cheaper to fix.