Two teams, two versions of the truth
Marketing reports leads, sales reports opportunities, and the two never reconcile. The same company exists four times under different spellings. A form field marketing depends on was renamed by someone in sales. Every pipeline review starts with an argument about whose number is right.
Making the record trustworthy
We design the objects and pipeline stages with both teams in the room, then enforce them: deduplication rules, required fields, validation on the forms that feed the CRM, and a written definition of every stage. It is unglamorous work and it is the thing that makes every report downstream believable.
What you get
Included as standard
- HubSpot, Salesforce, Pipedrive and ActiveCampaign implementations
- Object model and pipeline stages both teams have signed off
- Deduplication, validation and required-field rules that hold
- Forms and integrations writing clean, complete records
- Migration from whatever you are on now, without losing history
The chain
How the pieces connect
- Forms and sources
- Validation
- Dedupe and match
- CRM record
- Pipeline stage
- Reporting
Decide the object model before touching a single field
Most CRM projects begin in the wrong place. Someone opens the settings, starts creating custom properties, and six weeks later the instance reflects whoever happened to be in the room rather than how the business actually sells.
The default object model in HubSpot, Salesforce or Pipedrive assumes a shape: a contact belongs to a company, a company has deals, a deal has a value and a close date. That assumption breaks the moment your business does anything slightly unusual. If you sell to a group with twelve subsidiaries, "company" has to mean one of them and you have to decide which. If a single deal is invoiced across three budget years, a close date is a fiction. If procurement signs but a technical lead decides, the contact who owns the deal is not the contact who matters.
So we start with a session that produces a written object model: what a company is, what a contact is, when a deal is created and by whom, what the stages mean, and which of those definitions sales and marketing are both willing to sign. It usually takes a day and it prevents the eighteen months of drift that follow from skipping it.
Deduplication is a policy, not a button
Every CRM has a merge function and none of them can tell you what should have been merged. That is a judgement, and it has to be made once, deliberately, and then enforced.
The match key matters more than anything else. Matching on exact email address is safe and misses most duplicates, because the same person appears as a work address, a personal address and a typo. Matching on email domain is aggressive and will happily merge two unrelated people at a large company. Matching on normalised company name catches "Acme Ltd", "Acme Limited" and "ACME" but also merges genuinely separate entities that share a name.
Then there is survivorship: when two records disagree, which value wins. Newest wins is the common default and it is often wrong, because the newest value frequently came from a web form where someone typed their name in lowercase. Usually the right rule is source-based: values from the billing system beat values from a form, which beat values from an enrichment tool.
We write those rules down, run them against an export first so you can see exactly what would be merged before anything is, and only then apply them. After that, validation on the inbound forms stops the problem regenerating, which is the part most cleanup projects skip and why they get repeated every two years.
Sync direction has to be a decision, not a default
Bidirectional sync is the option everybody asks for and the one that causes the most damage. Two systems that can both write the same field will eventually disagree, and when they do, one of them silently overwrites the other on a schedule nobody remembers configuring.
The alternative is unglamorous and works: for every synced field, one system is the source of truth and the other is read-only. Lifecycle stage is owned by marketing automation. Deal stage is owned by the CRM. Billing status is owned by the billing system and nothing else may write it. Where a field genuinely needs to be writable in two places, it gets an explicit conflict rule and a timestamp comparison rather than a hope.
The deliverable is a field mapping table showing every synced field, its direction, its owner and its conflict rule. It is boring to produce and it is the document your team will actually use eighteen months from now when something looks wrong.
Migration without losing the history
Moving from one CRM to another, or consolidating several into one, is where deal history goes to die. The pattern is familiar: contacts and companies come across, deals come across, and everything that made those deals legible, the notes, the email threads, the stage change dates, the owner at the time, quietly does not.
The approach that survives is staged. Export and profile the source data first, so you know what you actually have rather than what you assume. Build the mapping document. Run a dry migration into a sandbox and have the people who use the system daily look for what is missing, because they will spot it and you will not. Keep a cross-reference table of old and new record IDs, which is what makes a rollback possible and what lets you reconcile afterwards.
Then cut over with a defined freeze window and a rollback plan you have actually tested. The freeze is usually shorter than people fear, but it has to be real: a migration running against a system still taking writes produces a result nobody can reconcile.
Before you ask
Questions we get
How long does a CRM integration take?
It depends almost entirely on how clean the starting data is, and that is knowable early. A straightforward connection between two systems with an agreed field mapping is a short piece of work. A consolidation of several instances with years of accumulated duplicates and a live sales team that cannot pause is a much longer one. We scope it after looking at an export rather than guessing from a description, and you get fixed steps and fixed dates before anything starts.
Do we have to stop using the tools we already have?
Usually not. Most of what looks like a tooling problem is a definitions problem, and replacing a platform rarely fixes it. If we do think a tool is genuinely the wrong fit we will say so, but we make money from the integration work, not from reselling licences, so there is no incentive here to recommend a migration you do not need.
Can you migrate our history, or do we start clean?
History can usually come across, including notes, activity and stage change dates, though the fidelity depends on what the source system exposes through its API. Some things do not survive, and we tell you which before the migration rather than after. Starting clean is occasionally the right call, but it should be a decision you make knowingly, not a consequence you discover.
We have a RevOps person already. Where do you fit?
Usually alongside them rather than instead of them. An in-house RevOps lead knows the business far better than we will, and what they typically lack is time and a second pair of hands for the build phase. We work well as the implementation half of that pairing, and we document what we do so it does not become knowledge only we hold.
Two of our systems both claim to be the source of truth. What happens?
That gets resolved in the object model session, before any code is written, because it is a business decision rather than a technical one. Someone has to decide which system wins for each field, and the useful thing an outsider brings is the willingness to make that question explicit rather than letting it stay unresolved and be settled by whichever integration ran most recently.
Scope, plainly
What this is not
Worth saying before you write, so nobody wastes a fortnight finding out.
- Ongoing CRM administration as a seat on your team. We build and hand over, then stay available through maintenance and support.
- Reselling licences. We do not take platform commission, which is why we can tell you when a cheaper tool would do.
- Sales methodology or team training. We make the system reflect how you sell; we do not tell you how to sell.
Rarely done alone
What this usually comes with
- Campaigns and automation Lifecycle flows read the records this creates, so the two are usually scoped together.
- Tracking and dashboards Attribution is only as good as the CRM record it lands on.
- Websites and landing pages Most bad CRM data enters through a form that was never validated.
Also on the chain
Nothing here works alone
Every one of these connects to the others. That is the point of the way we work.
Start with the gap
Tell us where the chain breaks.
One reply from the person who would do the work, not a sales desk.
Tell us about itor write straight to hello@dot-connectors.net