A customer changes their delivery address, billing contact or preferred communication method. One system is updated, another is missed, and a third still contains the old information.
Nothing has necessarily failed technically. The website works, the accounting platform works and the service application works. Yet staff may send documents to the wrong contact, deliver to an outdated address or spend time checking which record is correct.
This is data drift: the gradual divergence of information between systems that are meant to describe the same customer.
For a growing Australian SME, the important question is not simply, “How do we synchronise our systems?” It is:
Which system should be trusted for each type of customer information, and what should happen when records disagree?
Why data drift is an operational problem
Customer data is often created and changed in several places:
- A website captures an enquiry or account registration.
- An accounting system stores billing details.
- A booking or service platform holds operational information.
- An email marketing tool stores communication preferences.
- Staff update records during phone calls or service interactions.
Each application may be suitable for its own job. The problem appears when the business assumes they all own the same data.
For example, a customer’s legal billing name may belong in the accounting system, while a delivery instruction may be maintained in the service platform. If staff manually copy both values into every application, the business creates an ongoing reconciliation task. If an integration overwrites changes automatically, it may replace a legitimate update with an older value.
The result can include duplicated customer records, inconsistent communications, incorrect documents and time-consuming internal checking.
Start with data ownership, not synchronisation
A reliable integration begins by deciding where each field is authoritative.
This does not always mean choosing one application as the master for everything. A more practical approach is to assign ownership by data type.
For example:
| Information | Possible source of truth | |---|---| | Legal entity and billing details | Accounting platform | | Delivery instructions | Operations or service application | | Marketing consent | Marketing platform | | Customer login details | Website or customer portal | | Contact history | Customer service application |
The appropriate arrangement depends on the business process. The important point is that ownership is explicit.
Without this decision, an integration can create a technical illusion of consistency while moving incorrect information more efficiently.
Use a stable customer identity
Names and email addresses are not always reliable identifiers. Customers may share an email address, change their trading name or use different spelling across systems.
A stable internal customer identifier can help systems recognise that records refer to the same entity. Where an existing identifier is not available, an integration may need a controlled matching process using several fields, followed by human review for uncertain matches.
This is especially important during the initial connection of systems. A poor first-time data match can create duplicate accounts and make later synchronisation harder.
A good implementation should distinguish between:
- Confirmed matches that can be linked automatically.
- Possible matches that require review.
- Records that should remain separate.
The goal is not to force every record into one combined profile. It is to avoid making an incorrect assumption about identity.
Decide how conflicts are handled
Even with clear ownership, conflicts will occur. A staff member may edit a phone number in one application while a customer updates it through a portal. An import may contain older information. A system may be temporarily unavailable while another accepts changes.
The integration needs a defined conflict policy. Options may include:
- The owning system always wins.
- The newest verified change wins.
- Certain fields require manual review.
- Changes are accepted only after validation.
- Conflicting values are retained in an exception queue.
The right choice depends on the risk of being wrong. A minor preference may be resolved automatically, while a billing or delivery change may deserve review.
Importantly, the system should not hide conflicts. If a value is rejected or held for review, the relevant staff member should be able to see what happened and why.
Make synchronisation observable
A synchronisation process that runs in the background can be difficult to trust unless the business can see its status.
Useful operational controls may include:
- A record of each change sent and received.
- Clear timestamps showing when a value was updated.
- Warnings for rejected or incomplete updates.
- A queue for records requiring review.
- Alerts when synchronisation falls behind.
- A way to retry safe failures without creating duplicates.
This is different from treating every technical error as an emergency. The business needs prioritised visibility. A temporary connection issue may resolve automatically, while a rejected address change may require prompt action.
Support staff should also be able to trace a customer record across the connected systems. This can reduce investigation time when someone asks why two applications show different information.
Protect the first release from unnecessary complexity
A business does not need to synchronise every field immediately. A safer first release may focus on the small set of information that causes the most operational problems.
For example, the initial integration might:
- Match existing customer records.
- Synchronise approved contact details.
- Record conflicting changes.
- Provide a review screen for exceptions.
- Leave lower-risk fields unchanged until the process is proven.
This staged approach makes testing more manageable and gives staff a chance to validate the workflow. It also avoids building a complex integration around assumptions that have not been tested in daily operations.
The business lesson
Connected systems do not automatically create consistent data. They can also spread errors, overwrite legitimate changes or make disagreements harder to notice.
A reliable customer-data integration needs more than API connections. It needs defined ownership, stable identity matching, conflict rules, audit visibility and a practical exception process.
For an Australian SME, the best solution may be a focused integration between existing applications rather than a replacement project. Melbourne Digital Solutions can help assess where customer data is drifting, define a workable ownership model and build or support an integration that makes changes visible and manageable.
