Running a CRM beside your broker management system
Nobody should replace a working BMS with a CRM. The useful question is what a CRM adds on top of one, and what running both actually costs you week to week.
Stated plainly up front. CovioIQ has no live integration with any broker management system, and none is in progress. Data comes in by CSV export and import. Everything below is written around that, because a page that implied live sync would be describing a product that does not exist.
Decide what lives where, once
Most of the pain of running two systems comes from never deciding this, so both systems hold half of everything and neither can be trusted.
| The thing | Where it lives |
|---|---|
| Policy of record, endorsements, certificates | Management system. Always. It is the system of record and a CRM record is a copy. |
| Carrier download and policy documents | Management system. No CRM replaces this. |
| Trust accounting, the general ledger, commission runs | Management system. |
| Who is chasing which renewal, and by when | CRM. This is the thing management systems are worst at. |
| Notes from a conversation, and when it happened | CRM, because the score and the reports read it. |
| Prospects who are not clients yet | CRM. They have no policy, so they do not belong in a BMS at all. |
| Retention and cross-sell prioritisation | CRM. |
The rule underneath: the management system owns the policy, the CRM owns the relationship and the work queue. When the two disagree about a policy detail, the management system is right.
How the data actually moves
Export clients and policies from your BMS as CSV, then import. Every Canadian system we know of can produce a CSV export, and that is the whole mechanism today. It is a real piece of work the first time and quick after that.
The practical consequence is that your CRM copy of a policy is a point-in-time copy. Endorse a policy in the BMS and the CRM does not know until the next import. That is fine for renewal and retention work, which runs on expiry dates and premiums, and it is not fine for anything that has to be current to the minute — which is why the policy of record stays in the BMS.
Re-import on a cadence that matches your renewal cycle rather than continuously. Monthly is enough for most books. CRM data cleanup covers matching on a stable identifier so a re-import updates records instead of duplicating them.
Design out the double entry, or adoption dies
The single most common reason a second system goes unused is that staff are asked to type the same thing twice. They will not, and they should not.
- Policy data is entered in the BMS and arrives in the CRM by import. Never typed twice.
- Conversation notes and next actions are written in the CRM only. They do not belong in a policy record.
- Prospects never touch the BMS until they buy something.
- If a field has to exist in both, name which one is authoritative and put that in writing.
Getting the team to use it goes further on this: adoption usually fails on double entry, not on training.
When this is the wrong idea
If your renewals are not getting missed and you can already answer which clients are at risk, a second system is overhead. Two systems is a real cost: another login, another import to remember, another place for data to be stale.
And if you do not have a management system at all, this is the wrong page — CRM versus broker management system covers which one you actually need first, and what an AMS does covers the category.
The integrations page lists every planned connection with its current status, all of them marked planned with no committed date.