TL;DR
- RevOps often owns CRM deduplication because it runs the tools that create records.
- Owning deduplication means owning the whole process, from merge rules to duplicate reporting.
- Learning how each team uses records helps prevent merges that break other teams' work.
- What counts as a duplicate is case by case, so agree on it with each team.
- Dedupely helps RevOps find and merge duplicates safely, with onboarding support for each team.
Duplicates land on RevOps sooner or later. Sales complains about ownership, marketing about attribution, customer success about missing history, and the CRM sits in the middle.
RevOps runs the forms, syncs, imports and integrations that create records, so it's often the natural owner of the fix. Owning it takes two things: running the process, and understanding what each team does with the records you're about to merge.
In this post, you'll see why both matter and what each team needs from a merge. You'll also see how to set the rules, cadence and reporting.
Why deduplication needs one owner
When nobody owns duplicates, everyone fixes them a little. A rep merges two contacts by hand, a marketer deletes a record that looked wrong, and someone else imports the same list again.
Each fix makes sense alone, and together they make the data less predictable. One owner means one set of rules for what gets merged, how and when.
RevOps fits that role because it sees the whole system. It knows which tools write to the CRM, which fields reports depend on, and which changes reach other teams. For the wider policy around it, see our data governance guide.
Learn what each team does with records
A merge that looks clean to RevOps can break someone else's work. The surviving record keeps one owner, one lifecycle stage and one source, and every team reads those fields differently.
Before you set rules, sit with each team and ask what they do with the records. Ask which fields they report on, which automations they run, and what would hurt if it changed overnight.
| Team | What they use records for | What a careless merge can break |
|---|---|---|
| Sales | Ownership, territories, pipeline and commissions | The account owner, and who gets credit for a deal |
| Marketing | Attribution, segments, scoring and email sends | The original source, subscription status and list membership |
| Customer success | Customer history, renewals and health | Notes, tickets and the link between a contact and its account |
| Finance and billing | Invoices, contracts and customer counts | Billing contacts and IDs that other systems store |
| Support | Tickets and conversations | Which contact a ticket belongs to |
The answers become your merge rules. They also tell you who to warn before a large cleanup.
Agree on what counts as a duplicate
What counts as a duplicate is case by case. What one team considers a duplicate, another may not.
- A contact with a work and a personal email: sales may want one record, while marketing sends different emails to each address.
- Two company records for one parent and its branch: finance may bill them separately, while sales sees one account.
- A trial user and a paying customer: growth may keep them apart to measure conversion, while success wants one history.
Write down the decision for each case. Then start with the obvious duplicates, such as exact matches on email or company domain, where teams are least likely to disagree. What a duplicate is covers the definitions in more depth.
Own the process: rules, cadence and reporting
Once you know how teams use records, the process has three parts. Each one needs a written decision and a person who keeps it current.
Rules
Rules say which records match and which value wins in each field. Keep them per object, since contacts, companies and deals need different criteria. Which fields to match on depends on the object and the data you trust.
Also decide who may merge. Some teams let only RevOps merge, and others let reps merge obvious duplicates while RevOps handles the rest.
Cadence
Cadence covers the first cleanup and the checks after it. It depends on how much new data comes in and from where, which we cover in how often to deduplicate your CRM.
Reporting
Reporting shows whether the process works. Track duplicates per object, where new ones come from, how many were merged and how many matches were rejected.
Share the numbers with the teams you spoke to. A falling duplicate count helps rebuild trust in the CRM. To get a starting count, see how to find out how many duplicates your CRM has.
Make merges safe enough to keep going
Cleanups often stall when people are afraid of what a merge will do. That fear is reasonable, since merges in many CRMs can't be undone.
A few habits keep the work moving:
- Merge the duplicates you're surest of first, and review near matches before deciding.
- Preview the result of each merge before running it in bulk.
- Keep a record of the original values, and back up the CRM before a large merge.
- Reject a match only when you're certain it isn't a duplicate, since it won't come back in searches.
- Check which integrations and reports store record IDs, because merging can change them.
A RevOps deduplication plan on one page
| Part | What to decide | Who to involve |
|---|---|---|
| Definition | What counts as a duplicate for each object | Sales, marketing, success, finance |
| Rules | Match criteria and which value wins per field | The teams that report on those fields |
| Permissions | Who may merge, and what needs review | Team leads |
| Cadence | First cleanup, then recurring checks | RevOps |
| Reporting | Duplicates per object, sources, merges and rejections | Everyone who uses the CRM |
How Dedupely helps RevOps own deduplication across teams
Dedupely lets RevOps build searches for supported objects, set rules for which value wins and preview each merge. Its Customer Success team offers onboarding and support by call, chat and email, helping the teams agree on a process they can maintain.
Owning deduplication starts with listening
RevOps is in a good position to own deduplication because it runs the systems that create duplicates. Owning it well means the rules, the cadence and the reporting live in one place, with one person keeping them current.
The rules only hold if they reflect how sales, marketing, success and finance use the records. Learn that first, and each merge protects someone's work instead of surprising them.
Frequently asked questions
Who should own CRM deduplication?
Often RevOps or the CRM admin, since they run the forms, imports and integrations that create records. The owner sets the merge rules, the review cadence and the reporting. Other teams still decide what counts as a duplicate for the records they use, so the owner needs their input before merging.
What does a RevOps deduplication process include?
It includes a definition of a duplicate per object, plus rules for matching and for which value wins. It also covers who may merge, a cadence for checks and a report on results. Each part needs a written decision and an owner, so the process keeps running when people change roles.
How do you get sales and marketing to agree on duplicates?
Ask each team what they use the records for and which fields they report on. Bring real examples, such as a contact with a work and a personal email, and decide each case together. Write the decisions down, then start with exact matches, where teams are least likely to disagree.
Which duplicate metrics should RevOps track?
Track the number of duplicates per object, where new duplicates come from, how many sets were merged and how many matches were rejected. Watch how the count changes after each cleanup and after new integrations. Sharing these numbers with other teams helps rebuild trust in the CRM.
Why do CRM cleanups stall?
Cleanups often stall when teams fear losing data or breaking connected systems. Merges in many CRMs can't be undone, and some integrations store record IDs. Merging the most certain duplicates first, previewing each merge and keeping the original values make it easier to keep going.
Or sign up with Google
