Which system should be your source of truth?

When one broker holds the context in their head, two systems can disagree and the work may still get done. Add a virtual assistant, loan processor, marketing coordinator or second broker, and the disagreement becomes operational.

The team needs to know where to look, and which record wins.

Trying to make one application authoritative for everything creates a different problem. A CRM is not necessarily the lodgement record. An aggregator is not necessarily the best place for marketing consent or referral follow-up. An accounting package is not the client conversation timeline.

Choose one authority for each domain.

Put information there when the team needs it to manage the relationship or the next action. That usually includes:

• contact identity and preferred communication;
• source and referral relationship;
• consent and suppression state;
• opportunities and pipeline milestones;
• current owner and next task;
• appointment and communication history;
• high-level scenario fields approved for the CRM;
• document-request status, not necessarily document contents;
• settlement and review dates; and
• links or IDs for authoritative records elsewhere.

Do not turn a marketing CRM into an uncontrolled copy of every payslip, identity document, tax return, lender note and application field. The product boundary for sensitive finance and identity data is an implementation question that must be settled before live use.

The answer should be written before the first integration is built.

1. Identify the field and domain

“Client details disagree” is too broad. Name the exact field: mobile number, loan amount, application status, settlement date, marketing consent or annual-review date.

2. Apply the authority rule

• current phone and contact preference: CRM, after client confirmation;
• submitted loan amount: the lodgement platform;
• settled date: the authoritative settlement or commission source defined by the brokerage;
• consent withdrawal: the consent record and suppression system;
• monthly recurring revenue: accounting or an approved reporting source, not opportunity value.

3. Check freshness and provenance

Record source, changed date and changed-by value where the system supports it. A more recent value from an unreliable import should not silently defeat an approved record.

4. Resolve through a person when risk is material

Identity, financial, consent and application conflicts require review. Do not build a two-way sync that repeatedly overwrites each system with the other.

5. Correct the cause

If a mismatch repeats, fix the mapping, workflow or ownership rule. Do not create a permanent weekly task to repair the same integration failure.

Connecting systems can be sensible when each has a clear job.

The weak version is an undocumented chain of API keys, personal accounts, spreadsheets and automation steps that nobody owns. The strong version has:

• a field map;
• a named owner;
• one direction of authority per field;
• error alerts;
• retry and duplicate rules;
• test records;
• a change log; and
• a manual fallback.

The broker should not need to become an integration developer. They do need a map of what the integration is allowed to do.

A database of client records is not a knowledge base.

The internal knowledge system explains how the team operates: how to create and progress an opportunity, how to request and verify documents, how to prepare a file for broker review, how to handle privacy, consent and opt-outs, how to escalate exceptions, how to use each core system, and how to recover when a workflow fails.

Do not use video alone

Screen recordings are useful for showing movement and judgement. They also become hard to search and easy to outdate.

Give every SOP:

• a direct title;
• purpose and scope;
• an owner;
• a last-reviewed date;
• a trigger;
• inputs and permissions;
• numbered actions;
• a completion condition;
• an exception and escalation path;
• a short video where movement matters;
• a transcript or written summary; and
• links to the current system screens and templates.

A course builder can present SOPs as structured lessons for staff. Keep the canonical text and ownership visible, so a course is not mistaken for an unchangeable archive.

Markdown is a strong portable source format. It is plain text, searchable, version-friendly and readable by many AI and documentation tools. It can make an internal reference easier to export, compare and update.

It is not mandatory for AI, and it is not a security control.

Create one register and make it part of onboarding. Replace the examples below with your actual systems and legal requirements.

“We can export” is not an exit plan until the export has been examined.

1. export a safe sample or approved backup;
2. confirm contacts, opportunities and required custom fields are present;
3. document what is absent, truncated or only available through another method;
4. test how records would be reconstructed;
5. protect the export with access, encryption and retention controls; and
6. delete superseded copies when they are no longer required.

HighLevel’s published contact export includes selected standard fields, tags and custom fields, but excludes some history and may truncate long notes. That is exactly why a vendor’s Export button should not be assumed to capture the whole operating record.

OAIC guidance treats inadequate backups as a possible form of information loss, while also requiring entities to consider destruction or de-identification when personal information is no longer needed. Backup and retention rules have to work together.

Reliable records can make a brokerage easier to understand during planning, finance, succession or due diligence.

They may help an adviser examine recurring commission or trail records, client and loan-book composition, revenue concentration, process dependence on the founder, data quality and consent, staff responsibilities, contractual and platform dependencies, and the cost and risk of transferring operations.

That does not prove the business will receive a higher valuation. Valuation depends on the quality, rights, risks, transferability and economics of the business, and should be handled by an appropriately qualified adviser.

The system’s job is to make the evidence inspectable, not to create a valuation claim.

1. List the ten records your team uses most.
2. Assign each record to a data domain.
3. Name the authoritative system and owner.
4. Decide how other systems may read or update it.
5. Write the conflict rule.
6. Document the core process as text, with a short video where it helps.
7. Test export and recovery with approved non-production or controlled data.
8. Train one staff member using only the documented method.
9. Fix every point where they still had to ask where the truth lives.

One authority per question.

Use the CRM as the operating spine, the aggregator as the application authority, accounting as the financial authority, and a governed knowledge base as the method authority.

The team can then scale the process without asking the founder to reconcile every screen.