The three Margarets: where contact data falls apart

There is a person in your database. Call her Margaret Okafor. Your email platform knows her as Margaret Okafor, subscribed since 2023. Your ticketing tool’s export says M. Okafor, two tickets to the spring gala. The donor spreadsheet — maintained by the volunteer who has known her for twenty years — says Peggy Okafor, reliable annual gift.

Three records. One human being. And exactly one member of staff who knows that, holding the mapping in their head.

How the drift actually happens

Nobody decides to fracture their data. It happens through mechanisms so ordinary that no single one feels like a problem:

• Re-keying. A person signs up at an event, and someone types them into the CRM later — from handwriting, from memory, with a nickname.
• Partial updates. Margaret moves house and tells you once. Her address changes in whichever system took the call; the other two keep the old one.
• Exports as glue. The monthly CSV from the ticketing tool gets imported into the email platform. Every import is a fresh chance for a near-match to become a duplicate.
• Syncs that drift. Even with integrations, fields map imperfectly, one side wins conflicts silently, and a connector that broke on a Tuesday is discovered in March.

None of this is carelessness. It is the structural consequence of storing the same person in several places at once.

What the inconsistency costs

The damage is rarely dramatic; it is a steady tax. Reports disagree with each other, so every board number needs an asterisk and an afternoon of reconciliation. Margaret gets a “we miss you!” email a week after she bought tickets, because the email tool cannot see the ticketing tool. Her opt-out, honoured meticulously in one system, is invisible to the other two — which is not just embarrassing but a real compliance exposure. And her donation receipt goes to the address she left two years ago.

Worst of all: the fix is a person. The administrator becomes the working integration layer, spending hours a month doing robotic reconciliation that no software vendor will ever list as a feature of their product.

One record, shared — not five records, synced

Mercleo’s answer is structural. There is one contact record, and every product reads and writes the same one. The ticket buyer, the course participant, the donor and the newsletter subscriber are one row — not four rows and a matching problem.

That is what makes the full, accurate view of a contact possible:

• Everything attaches to the same spine. Tickets, enrolments, gifts and email history land on one record as they happen, so the timeline you see is the whole relationship, in order, without an import step.
• Identity resolves backwards, too. When an anonymous website visitor fills in a form and becomes a contact, up to ninety days of their earlier visits attach to the new record retroactively — the view is complete from the first day you know who they are.
• Consent lives on the record, not in a tool. An unsubscribe is a fact about the person, honoured everywhere at once, because there is no second system for it to fail to reach.
• Receipts and reports draw from the source. A donation receipt is issued from the record the gift actually sits on, and a report is a query over the data — not a reconciliation of three exports.

There is no nightly sync in that list, and that is the point. A sync is a promise that two copies will agree; a shared record removes the second copy. The class of inconsistency disappears rather than being managed.

The three Margarets were always one person. Your software should have known that all along — and the platform we built starts from exactly that premise. If you want the longer story of why, it’s in Why we built Mercleo.