Making the CRM the place people actually look

A record is only as good as what reaches it

Most CRM disappointment traces back to the same thing. The system is asked to hold the truth about customers while the truth keeps arriving somewhere else: a WhatsApp thread on a personal handset, an inbox nobody else can open, a spreadsheet named after the month it was started. The CRM ends up holding a partial copy, and partial copies lose every argument against whoever remembers the conversation.

So the opening question is about ownership rather than product. For each thing the business tracks, one system holds the truth and the others display it. Contacts might sit in the CRM. Invoices almost certainly sit in accounting. Conversations belong to the channel they happened on. Writing that down turns integration from a wish into a specification, and gives every argument about which number is right somewhere to be settled.

• One named system of record per object: contacts, companies, deals, invoices, tickets
• Everything else reads from that system instead of keeping a private version
• Every automated write records where the value came from and when it arrived
• A field nobody can trace back to a source is a field nobody should act on

Migration is a set of decisions, not a file transfer

Moving between CRMs gets quoted as a week and consumes a month. The export is trivial. What takes the time is deciding what deserves to arrive: which fields map to which, what to do with years of closed opportunities, whether the old owner assignments still mean anything, and which records are so thin that importing them only relocates the mess.

The safer shape is staged. Move a representative slice first, covering every awkward case anyone can remember, and let the team work in the new system against real data before the full load. Mapping mistakes surface while they are still cheap to fix, which is the entire point.

The read-only step at the end matters more than it sounds. Two live systems means two versions of the truth, and the older one usually wins, because it is the habit.

• A field map written before anything moves, including the fields deliberately left behind
• A rule for records below a minimum quality bar: enriched, archived or dropped on purpose
• Historic activity kept where it earns its storage and summarised where it does not
• A test load, checked by the people who will use it, before the real one
• An agreed cut-over moment, after which the old system is read-only rather than merely discouraged

Deduplication is a policy question before it is a technical one

Every CRM accumulates the same customer more than once. A form fill with a work email, a WhatsApp enquiry from a mobile number, a manual entry by somebody who did not search first. Merging them means deciding two things software cannot decide for you: what makes two records the same person, and which value survives when they disagree.

Phone numbers are usually the strongest match key in markets where people hand over a mobile number rather than an email address. They are also the easiest to break, because the same number gets stored as a local number with a leading zero, as an international number with a country code, with spaces, with dashes, and occasionally with a stray prefix from an old import. Normalising the format before matching turns a weak key into a reliable one.

Merging is destructive in a way people underestimate. Keep a record of what was merged into what, so a bad merge can be explained to the person who noticed and, where the platform allows it, undone.

• Match keys in priority order, normalised before comparison rather than after
• Survivorship rules set per field: most recent wins for status, most complete wins for address, and a manually corrected value is never overwritten by an import
• Ambiguous matches queued for a person instead of merged on a guess
• Deduplication running continuously, because a one-time clean-up starts decaying the day it finishes

Two-way sync, and the direction problem

Connecting a CRM to the rest of the stack sounds like plumbing and behaves like a design problem. One-way sync is easy to reason about and easy to trust: one system writes, the other displays. Two-way sync is where the interesting failures live, because both sides can change the same field between two runs of the same job.

Anything bidirectional needs three things settled in advance. Which side wins a conflict. How a change is recognised as new rather than as an echo of the last write. And what a deletion means. Deletion is the one that catches people out, because a record removed in one system and faithfully propagated to the other is the fastest known method of losing a customer list.

• A conflict rule per field, rather than one rule for the whole record
• Change tracking that can tell a genuine update apart from the echo of the last sync
• Deletions treated as an archive flag unless there is a deliberate reason otherwise
• Sync failures shown on a screen somebody reads, not left in a log nobody opens

A sync that fails loudly is an inconvenience. A sync that fails quietly is a data problem you hear about from a customer.

When the CRM stops being the right container

There is a point where things go into the CRM because the CRM is where things go, not because they fit. Field counts climb past what anyone will complete, workflows get chained around limitations, and half the fields exist only to make one report work. The clearest sign is custom objects being invented to describe something the business does that the CRM was never shaped for.

The answer is rarely a bigger CRM. It is moving that specific function into a system built for it and keeping the CRM for the relationship: who they are, what has been discussed, what has been agreed. Project delivery, inventory, scheduling and billing all have better homes, and a CRM that links out to them stays usable for the thing it is good at.

Where CRM automation is the wrong purchase

If nobody inside the business owns the data, automation produces a cleaner mess faster. Ownership means a named person who decides what a field means and who is allowed to say no to a new one. Without that role the field list grows every quarter and the meaning of each one drifts until reporting becomes a matter of opinion.

If the current system is disliked for reasons nobody has written down, migrating will reproduce the same complaints in a new interface at considerable expense. Ask for three specific things it cannot do before agreeing to move. Often enough the honest answer is a fortnight of configuration rather than a migration.

And if the reason for buying is that a report looks bad, expect the report to improve and nothing else to. The work only pays back when it changes what people do, which means it has to make somebody's day easier on the first morning.

What the automation refuses to do on its own

A CRM automation that merges two records because they look alike will eventually merge two real customers, and the person who finds out is whoever sends the wrong invoice. So the rule on this kind of build is that confident matches merge automatically and anything ambiguous waits for a person, in a queue somebody actually works rather than a report nobody opens. Deletion is never automatic. The system can flag, hide or archive a record. Removing it takes human approval.

The same line runs through the rest of it. Logging a call, updating a stage from an email, attaching a document: unattended. Changing a deal value, closing a deal, or writing to a customer in your name: drafted by the machine and signed off by a person. The label is agreed before the workflow goes live, so nobody discovers where the boundary sits in the middle of an argument.

Ibrahim owns build and workflows at Wobble, and his stated aim is narrow enough to hold him to: tools powerful enough to scale an operation and simple enough that a client team can be trained to run them without him. On a CRM that is the whole test, because a CRM nobody internal can adjust becomes the second place to check within a quarter.

Which is also the honest answer on whether to do this in-house. If you have an administrator who already builds views and automations, the sensible purchase is the migration and the deduplication policy. After that you train your team and take it from there. Wobble is answerable for what it installed and stays reachable month to month, but the point is not to remain necessary.

Common questions

What does CRM automation actually include?

Four things, mostly: getting data in without anyone typing it, keeping it clean once it is there, connecting the CRM to the systems that hold the rest of the truth, and triggering work when a record changes. Migration and deduplication usually take more of the effort than the automation itself, because automation is only as useful as the records it runs against.

How long does a CRM migration take?

The export is quick and the decisions are not. Field mapping, choosing which history to bring, agreeing survivorship rules for duplicates and running a test load with the people who will use the system are what set the timeline. A staged migration with a representative slice first looks slower on paper and is usually faster in practice, because the mapping mistakes surface while they are still cheap to fix.

How do you stop duplicate records in a CRM?

Normalise the match keys first, especially phone numbers, which arrive in several formats and match badly until they are standardised. Then set survivorship rules per field rather than per record, queue ambiguous matches for a person, and run deduplication continuously. A one-time clean-up begins decaying the day it finishes.

Should the CRM sync both ways with our other systems?

Only where both sides genuinely need to write. One-way sync is easier to trust and much easier to debug. If two-way is necessary, decide the conflict rule field by field, make sure a real change can be told apart from the echo of the last write, and treat deletions as archive flags rather than removals.

How do we know whether our CRM data can be trusted?

Take a handful of live records and trace each field back to where the value came from and when. Anything untraceable is decoration. Beyond that, three counts are worth reviewing monthly: records created without an owner, records with no activity since creation, and duplicate pairs found by the matching rules. All three rising means data is arriving faster than the discipline around it.

What happens when we outgrow our CRM?

The fix is usually narrower than replacing it. When custom objects and chained workflows are being invented to describe something the CRM was never shaped for, that function moves to a system built for it, such as project delivery, scheduling or billing, and the CRM keeps the relationship record and links out to it. Replacing the whole platform is the expensive version of the same conversation.