Wealth Management CRM Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the household data model get settled last so often?

Because the requirements come from the people who use the current system daily, and what they describe is the friction they feel: too many clicks to log a note, a task list that does not sort properly, a meeting prep routine that takes forty five minutes. Those are real complaints and they are all interface complaints. So the project gets scoped as a better interface over the same shape of data, and the shape of the data is the actual problem.

The chief compliance officer and the operations director have the requirements that decide whether the build succeeds, and neither of them typically writes the brief. Their needs are structural. Show me every account where one person is trustee. Show me every household with a concentrated position held inside a trust with a beneficiary over eighteen. Give me three years of communications and account activity for one household by Friday. Those questions are answerable in seconds or they are projects, and which one they are was decided by the data model, months before anybody wrote a screen.

The fix is to settle the entity graph in week one, in a room with the compliance officer present. Households, people, legal entities, accounts, and typed relationships named explicitly: trustee, beneficiary, grantor, power of attorney, authorised signer. Write down the ten questions the firm most needs answered and prove the model answers each of them on a whiteboard before development starts. Interface improvements are cheap to make later. A data model is not.

What goes wrong migrating fifteen years of notes and activities?

The exports themselves are straightforward. What is inside them is not. A decade and a half of freeform notes contains meeting summaries, phone messages, internal reminders, pasted emails, and a fair amount of text that should never have been typed into a client record at all. None of it is structured, so it cannot be classified without either a great deal of manual reading or an automated pass with human review of the exceptions.

Three specific traps recur. Duplicate contacts, because the same person exists as an individual, as a trustee entry and as a joint account holder, and merging them wrongly attaches activity history to the wrong household. Orphaned activities, where a note references an account number that no longer exists in any system. And an acquired book, where the seller's tagging conventions bear no relationship to yours, so a tag meaning high priority in their firm meant something else entirely in yours.

The fix is to separate what must be structured from what must merely be preserved. Contacts, entities, accounts and relationships get mapped properly. Historic notes get migrated with their original text intact, indexed and searchable, attached to the right household, but not retrospectively classified. Then a cleanup pass runs on duplicates with a human confirming each merge above a similarity threshold. Budget two to four weeks inside a first release, and treat it as its own workstream with a named owner rather than a task at the end of the plan.

Why do custodian and portfolio integrations break after launch?

They break on the calendar more than on the code. Custodian data access runs through the custodian's own approval and testing process, and that process moves at its pace regardless of your project plan. Firms that assume a feed will be available when the sprint needs it discover that the approval was the schedule, not the development.

After launch the failure mode is quieter. Portfolio accounting and planning platform interfaces change periodically, and a nightly feed that has run untouched for months stops on a Tuesday with no visible symptom, because the client record still shows figures. They are just yesterday's figures, then last week's. An advisor walks into a review meeting with stale numbers and does not know it, which is a worse outcome than an obvious error because it damages confidence with the client rather than with the software.

The fix is to make freshness visible. Every ingested dataset carries a last successful load timestamp displayed on the screen that uses it, and any figure older than its expected refresh window is marked stale rather than shown as current. Add a daily reconciliation count per feed, and alert on a count that deviates from normal rather than only on an outright failure. Then plan custodian approval as a dated dependency at the start of the project, with the internal work sequenced so the team is not idle waiting for it.

What happens when supervision and retention are bolted on afterwards?

They cannot be bolted on, and that is the point. Supervision is a property of how records are written, not a report you add later. If notes can be edited in place with no history, no retrospective feature can tell a reviewer what the note said last month. If deletion is a hard delete, retention obligations are already breached before anybody notices. If there is no immutable record of who changed what, an examination response is an exercise in inference.

The visible cost arrives with a request for all communications and account activity involving one household over three years. In a firm without designed supervision, that means exporting notes, filtering activities, chasing archived email in a separate system and cross referencing account numbers by hand, and the assembly commonly runs to forty staff hours or more. The quarterly supervision cycle is worse because it never stops.

The other failure is the service calendar. A firm that promises quarterly reviews to a tier of households, an annual beneficiary confirmation and required minimum distribution outreach in the year a client reaches the qualifying age is making commitments that must be enforced by software rather than remembered by associates. A missed distribution is not embarrassment, it is a penalty for the client and a difficult call for the advisor.

The fix is to design the audit log, retention rules and review queues into the schema at the start, and to run the service calendar from rules on the entity graph so tasks create themselves and escalate when untouched. Both are cheap at design time and close to impossible to retrofit honestly.

Should you build custom or configure what you already own?

Under roughly ten advisors in a single office with a standard service model, do not build. Wealthbox is pleasant, quick to adopt and your staff already know it. Redtail is a reasonable choice if you are committed to the surrounding stack. Building because custom sounds serious is how firms acquire an unowned system and a maintenance bill.

Salesforce Financial Services Cloud can model a household with entities and relationships properly, and for firms that want a vendor supported platform with a large integration ecosystem it is a legitimate answer. What you are accepting is per seat licensing that grows with headcount, a substantial implementation, and an administrator on payroll permanently. If the implementation quote alone approaches what a custom build costs, the comparison is worth doing carefully rather than assuming the packaged option is the conservative one.

The signals that favour building are specific. You employ someone whose main function is moving data between systems or assembling reviews. Your service calendar cannot be expressed in the tool, so commitments get missed. You plan two or more acquisitions in the next three years and each one means merging an inconsistent database. Or your compliance officer spends a meaningful part of every quarter on work that is entirely mechanical. Above roughly twenty five advisors across multiple offices with manual supervision, we think the case is clear, and the right first phase is the entity model plus supervision rather than anything client facing.

How do hidden costs get into the quote?

The development estimate is rarely where a wealth management CRM budget breaks. These are.

• Custodian approval time. Calendar time you do not control, sitting in the middle of your critical path. Ask any developer how long approval took on their last project and listen for whether the answer includes waiting.
• Data cleanup. Two to four weeks on duplicates, orphaned activities and inconsistent tagging from acquired books, with a human confirming merges.
• Each additional integration. Portfolio accounting, planning software, risk tooling and email archiving are separate pieces of work, not one line called integrations.
• Parallel running. Firms run the old system alongside the new during rollout to protect operations, and that means duplicated effort for a period.
• Retention design. Audit logging and retention rules touch every table in the schema, so they are not a module that gets priced separately and added.
• Ongoing maintenance. Roughly 15 to 20 percent of build cost per year, weighted toward keeping custodian and portfolio interfaces current.

A proposal with a single figure and no dependency dates for custodian access has not been planned by anyone who has shipped one.

What separates a build that works from one that fails here?

Make a prospective developer draw the data model before you discuss screens. Ask how they would represent a household containing a trust, a family limited liability company and a power of attorney relationship. If the answer is contacts with tags or a generic accounts table, the pain you are trying to escape returns within eighteen months in a system you now own. You want typed entities and named relationships offered without hesitation.

Second, test compliance literacy directly rather than accepting a claim of experience. They should speak comfortably about books and records retention, append only audit logs, and how a deletion request interacts with a retention obligation. Ask to see an audit log design from a previous build. A team that has built a hundred customer relationship systems and none that survived an examination is not the same as a team that has built one that did.

Third, sequence the phases so compliance and the data model come first and the advisor facing improvements come second. It is counterintuitive because advisors are the loudest constituency, but a firm that ships meeting prep on a weak model spends the following year rebuilding. A firm that ships the entity graph and supervision first can add meeting prep in weeks.

Fourth, settle ownership before kickoff. Full source code in a repository you control, documentation another team could inherit, and no licensing terms that tie the system to the builder. A firm that resists that is describing year three, and in a business where the client record is the asset, that is the wrong trade at any price.