# Getting sales, marketing and support to agree on duplicates > Sales, marketing and support use the same records in different ways. Agree on what a duplicate is, write it down and decide which values win per field. - URL: https://dedupe.ly/blog/agree-on-what-counts-as-duplicate - Section: blog - Published: 2026-10-19 - Site index: https://dedupe.ly/llms.txt - Any page: append `.md` to its URL for this plain-text form --- [Blog](https://dedupe.ly/blog) Team Collaboration ## Getting sales, marketing and support to agree on duplicates By [Gaby Salinas](https://www.linkedin.com/in/gbyslns) Updated October 19, 2026 # min read TL;DR - What counts as a duplicate is case by case, and teams often answer differently. - Sales, marketing and support each rely on different fields of the same record. - Agreement comes faster when teams decide real record sets, one at a time. - A written definition per object should also say which values win in each field. - Dedupely turns a team's agreed definition into duplicate searches and rules for which value wins. Ask three teams whether two records are duplicates, and you may get three answers. Sales sees one account, marketing sees two contacts with different subscriptions. Support sees the person who opened last week's ticket. None of them is wrong. Each team uses the record for a different job, so each one notices different things when two records become one. In this post, you'll see why teams disagree and how to run the conversation that settles it. You'll also see how to write the definition down, including which values win in each field, so every merge follows it. ### Why teams disagree about duplicates What counts as a duplicate is case by case. What one team considers a duplicate, another may not, and both can have good reasons. The disagreement usually comes from what each team does with the record: | Team | What it relies on | What makes it nervous about a merge | | --- | --- | --- | | Sales | Owner, account, open deals, stage | Losing an account to another rep, or a customer dropping back to lead | | Marketing | Email, subscription status, original source, list membership | A lost unsubscribe or a campaign losing credit for a lead | | Support | Tickets, conversations, the contact behind each case | A ticket history split across records, or attached to the wrong person | A merge can serve one team and hurt another. So the definition has two halves: which records are the same, and what the merged record keeps. ### The cases where teams split Most records are easy. Two contacts with the same email and name are one person for everyone. The arguments happen in a few recurring cases. - **Work and personal email:** sales wants one contact, while marketing may treat two addresses as two audiences. - **A customer who also exists as a lead:** sales and support want one record, so nobody prospects a paying customer. - **Branches and subsidiaries:** finance may bill them apart, while sales calls them one account. - **Shared inboxes and households:** one email or phone number can belong to several people. - **One company in several relationships:** a customer of one brand can be a prospect of another, or also a partner. For people who hold several roles at once, see [is a person with several roles a duplicate record?](https://dedupe.ly/blog/one-person-several-roles-duplicate) Example A business runs three brands in one CRM. One company is a customer of one brand and a prospect of the others. The team agrees they're the same company, so the merged record keeps every brand and a customer record always wins. ### Run the conversation with real records Abstract questions get abstract answers. "Is a duplicate the same person?" sounds settled until two people share an inbox. Bring real record sets instead. Pull ten or fifteen pairs from your CRM that cover the cases above, and show each team the fields it cares about. - Show each set and ask: same person or company, yes or no? - Where teams agree, write the answer down and move on. - Where they disagree, ask what would break for each team if the records merged. - Decide who has the final say for each object, so open questions don't stall the cleanup. Keep the meeting short and the sets concrete. One session per object usually covers it, and the sets you used become test cases for your searches later. ### Start with the duplicates nobody argues about You don't need agreement on every case to start. Begin with the obvious duplicates, like exact matches on email for contacts or on domain for companies. Those merges are the easiest to agree on, and they show every team what a merge does to the records they use. That builds trust for the harder cases. The disputed cases can wait in a review list. A person decides them later, set by set, while the clear ones keep moving. ### Decide which values win, field by field Agreeing that two records are the same is half the work. The other half is deciding what the merged record keeps, and that's where each team protects its own fields. Give each important field an owner: the team that reports on it decides its rule. | Field | Team that decides | A common rule | | --- | --- | --- | | Record owner | Sales | The owner of the active account, never a former employee | | Lifecycle or lead stage | Sales and marketing | The most advanced stage, so a customer never drops back to lead | | Email subscription status | Marketing | Keep an unsubscribe if any record has one | | Original source | Marketing | The value from the oldest record | | Primary email | Sales and support | The most recent, with the other kept where the CRM allows | | Deal or customer status | Sales and success | Customer wins over prospect, so the person leaves prospecting; won wins over open, and open over lost | Blank values should never overwrite filled ones. For the mechanics of each choice, see [merging CRM records without losing data](https://dedupe.ly/blog/merge-crm-records-without-losing-data). Note Some teams keep every active customer out of the first cleanup. They merge leads and prospects first, and handle customer records once the rules have proven themselves. ### Write the definition down An agreement that lives in a meeting doesn't survive the next hire. Write a short definition for each object, in plain words, where every team can find it. - **What counts as a duplicate:** the fields that must agree, like email, or name plus company plus phone. - **What doesn't:** the known exceptions, like branches with their own billing or shared inboxes. - **What the merged record keeps:** the surviving record and the rule for each important field. - **Who decides open cases:** one name per object. - **Test sets:** the record sets from your meeting, with the agreed answer for each. Our post on [what a duplicate is](https://dedupe.ly/blog/what-is-a-duplicate) covers the general definitions. Your written version is the one that applies to your CRM. ### Revisit it when the business changes A new brand, a new market or a new tool can change what a duplicate means. So can a team that starts using a field the others ignore. Review the definition when one of those happens, and when a merge surprises someone. A surprise usually means a case the definition didn't cover yet. ### How Dedupely puts a shared definition into practice In Dedupely, you build duplicate searches that match your written definition for each object and test them on the sets your teams agreed on. You set rules for which value wins field by field, including owner fields, and preview each merge before it runs. Matches your teams agree aren't duplicates can be rejected, and disputed sets can go to review, as our [page for RevOps teams](https://dedupe.ly/solutions/revops) describes. [Turn your duplicate definition into searches](https://v2.app.dedupe.ly/signup) ### One definition, every team behind it Teams disagree about duplicates because they use the same records for different jobs. The fix is to decide real cases together and write the answers down. A good definition says which records are the same and what the merged record keeps, field by field. Once every team has shaped it, a merge stops being a risk to someone's work and becomes routine. ### Frequently asked questions #### What counts as a duplicate record in a CRM? It depends on the business. Two records are usually duplicates when they describe the same person or company, often shown by a matching email or domain. Shared inboxes, households and branches can make records look the same when they aren't, so each company needs its own written definition per object. #### Why do sales and marketing disagree about duplicates? They use different fields: sales relies on owner, account and stage, while marketing relies on email, subscription status and source. A merge that keeps the right owner can still lose a campaign's credit or an unsubscribe. Each team judges a merge by its own fields. #### How do you create a duplicate definition for your CRM? Pull real record sets that cover your tricky cases and decide each one with every team that uses the records. Write down the fields that must agree, the known exceptions, which values win in each field and who decides open cases. Keep the sets as test cases. #### Who decides which value wins when records are merged? The team that reports on each field. Sales usually decides owner and stage, marketing decides subscription status and source, and support weighs in on the contact behind tickets. One person per object should have the final say, so disputed merges don't wait indefinitely. #### Should customers be merged with leads? Often yes, when they're the same person, so nobody prospects a paying customer. The merged record should keep the customer status and the most advanced stage. Some teams leave active customers out of the first cleanup and merge them once their rules are tested. Behind the article ### Gaby Salinas Marketing Assistant at Dedupely Gaby Salinas came to CRM data from marketing and advertising, so she looks at duplicates from two sides: the match and merge logic behind them, and what they do to the people using the CRM, like the rep who calls a customer twice, the admin who gets blamed and the cleanup nobody wants to start. As Marketing Assistant at Dedupely, she follows how RevOps teams, end users, consultants and technical teams actually work with their data: the records they stop trusting, the workarounds they build and the moment they finally decide to clean up. What she finds shapes most of what Dedupely publishes. [Connect with Gaby on LinkedIn](https://www.linkedin.com/in/gbyslns) ### Contact us We’d be happy to help you get this set up. #### Write us a message We probably know the answer to your question already help@dedupe.ly Email copied to your clipboard! [Book a Zoom Whether you’re getting started or getting intense. Get in touch! Book a zoom](https://meetings.dedupe.ly/meetings/gaby-salinas/dedupely-zoom-scheduler) ### Discover Related Blog Posts Stay updated with our latest articles and insights. [CRM Organization What is a duplicate? How to define what a duplicate is from your CRM’s fields, usage and logic, before you merge anything. Gaby Salinas September 29, 2025](https://dedupe.ly/blog/what-is-a-duplicate) [CRM Organization A RevOps plan for owning CRM deduplication RevOps should own CRM deduplication: the rules, the cadence and the reporting. Start by learning how each team uses records, then merge safely. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/crm-deduplication-revops) [CRM Organization Is a person with several roles a duplicate record? A customer who's also a job applicant, or an advisor at two companies: one record or two? How to decide, case by case, and keep intended pairs apart. Gaby Salinas October 19, 2026](https://dedupe.ly/blog/one-person-several-roles-duplicate) ### Get started for free 20 free trial merges and as much free support as you need to get your duplicates under control. [Talk to sales](https://meetings.dedupe.ly/meetings/gaby-salinas/talk-to-sales)[Try for free](https://v2.app.dedupe.ly/signup) [Or sign up with Google](https://v2.app.dedupe.ly/signup/google) Running CRM cleanup for clients? [See the Partner Program](https://dedupe.ly/become-a-partner) Skip to content