blog single

Why your website and CRM need one data model

Published on:

March 14, 2024

TAG:

SOFTWARE DEVELOPMENT

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

Most companies have a website and a CRM. Fewer have a shared definition of a lead. The website captures a form, the CRM creates a contact, the sales team adds a note and the marketing report counts something else. The result is a weekly reconciliation ritual and numbers nobody fully trusts.

The record is the handoff

A form submission is an event. A lead is a record that changes over time. Teams often treat the form as the source of truth and copy its fields into the CRM. That works until the same person submits twice, a salesperson edits a phone number, or a campaign changes the source field. Now two systems hold different versions of the same person.

The fix is to decide which system owns which field. The CRM usually owns the person, the company, the owner and the sales stage. The website owns the session, the page, the campaign parameters and the consent record for that visit. Both systems need a stable identifier so they can refer to the same record without guessing from an email address.

Email addresses are a useful matching signal, but they are not identifiers. People change jobs, share inboxes and submit with different capitalization. Store a generated contact ID in both systems, and keep the email as an attribute that can change.

What a shared model contains

A shared model does not need to be elaborate. It needs to define the entities both systems care about, the fields each one owns and the rules for creating, updating and closing a record. Write it down in a table and keep it with the integration code.

Contact: name, email, phone, company and a stable internal ID.
Company: domain, industry, size and account owner.
Lead source: first touch, last touch, campaign and landing page.
Consent: what the person agreed to, when and through which form.
Activity: form submissions, calls, meetings and email engagement.
Lifecycle stage: the shared definition of new, qualified, customer and closed.

The lifecycle definitions matter more than the field names. If marketing calls a record qualified when it has an email and sales calls it qualified when there is a budget, the reports will disagree forever. Define the stages in one document and use the same rules in both systems.

Choose a sync direction for each field

Every field needs one owner and one direction. The website writes campaign data and consent to the CRM. The CRM writes the owner, stage and sales notes back to the reporting layer. If both sides can write the same field, the last save wins and the history disappears.

Real time sync is useful for new leads and opt outs. Batch sync is fine for reports and enrichment. Trying to make everything real time adds failure modes without improving the decision. A five minute delay on a report rarely matters; a five minute delay on an unsubscribe request does.

Keep an audit trail. When a field changes, record the source, the previous value and the time. Without that history, a wrong number can travel through three systems before anyone notices.

Team reviewing data flows across laptops — A shared data model is a short document, not a platform migration. The hard part is agreeing on ownership.

Duplicates are a process problem

Duplicate records usually come from duplicate entry points. A newsletter form, a contact form, a webinar platform and a chat widget each create a contact. If each integration creates a new record, deduplication becomes a permanent job.

Route every entry point through the same service. That service normalizes the email, checks for an existing contact, merges the new activity and writes the result to the CRM. A queue between the website and the CRM protects both systems when one is slow or unavailable.

Merging is sensitive because it can combine two people with the same name. Use email as the primary match, company domain as a secondary signal and a manual review step for ambiguous cases. Automate the obvious merges and keep an undo path for the rest.

Consent and attribution belong in the model

Consent is a record of what the person agreed to, when and through which interface. Store the exact wording, the timestamp and the source. When someone withdraws consent, propagate that change to every system that sends messages.

Attribution has the same problem. If the website sends only the last page a person visited, the CRM cannot show which campaign started the relationship. Capture first touch and last touch separately, and keep the campaign parameters as structured fields rather than a single text note.

This is also a privacy decision. Collect only what you will use, document the retention period and delete records when the period ends. A clean model makes deletion possible because you know where each copy lives.

A rollout plan that does not stop the business

Start with one form and one CRM pipeline. Map the fields, pick the identifier, build the integration and watch it for two weeks. Then add the next entry point. A narrow first release produces evidence and limits the number of records affected by a mistake.

Build a reconciliation report before launch. It should show records that exist in one system but not the other, fields that changed in both systems and messages that failed to send. Run it daily for the first month and weekly after that. Most integration problems are visible in the report before a customer notices.

The first reports worth building

Once the model holds, reporting becomes a query instead of an argument. Start with three reports: where enquiries come from, how long they take to reach an owner, and which stage they stall at. Each one points to a decision someone can make this week. A dashboard of forty charts is usually a sign that nobody agreed on the questions.

The source report tells you which channels produce records that actually progress. A channel with high volume and low progression is often a targeting problem, not a sales problem. The response time report shows whether leads wait in a queue before anyone touches them. The stage report shows where deals stop, which is where the process needs attention.

Keep the reports close to the data model. If a report needs its own copy of the customer, it will drift from the source within a quarter. Read from the same tables the website and CRM write to, and when a definition changes, update it in one place.

Give each report an owner and a review date. A report without an owner becomes a dashboard nobody trusts. A short monthly review where someone explains the movement in the numbers keeps the definitions honest and retires the charts that stopped informing a decision.

Name an owner for the data model and an owner for each integration.
Define the identifier before the first record is created.
Write the sync direction for every field.
Log every change with a source and a timestamp.
Test failures, not just the happy path.
Review the reconciliation report on a fixed schedule.

The goal is one version of the customer that the website, sales and finance can all use without a meeting. A perfect CRM is a different project.
Edgeless Team

We build website to CRM integrations with a documented data model, an audit trail and a reconciliation report your team can maintain.

Explore software development

Treat the data model as part of the website, not as a reporting afterthought. The teams that do spend less time cleaning records and more time acting on them, and their reports start to agree.

CRM

Integrations

Data

Why your website and CRM need one data model

Let's Talk About Your Project