TL;DR
- Ask for admin rights in the client's CRM before anything else is planned.
- Sync only the objects you'll clean first, usually contacts or companies.
- Look at the duplicates and their sources before a single record changes.
- Agree with the client on what counts as a duplicate, using real examples.
- Dedupely connects a client's CRM without changing it, then previews and tests every merge.
In your first week with a new client's CRM, get access, connect it and look at the data and its sources. Then agree on what a duplicate is and run a few test merges, before anything merges at scale.
The first week sets the pace for the whole project. Rush it, and you spend month two explaining a merge nobody expected.
In this post, you'll see what to do that week, in order. It runs from access and the first look at the data to defining duplicates, test merges and the client check-in.
Day one: get the right access
Ask for access on the first call, before you plan anything else. When you sign up as a partner, Dedupely turns your account into a partner account. You then connect each client's CRM separately, so you're the admin of that client's instance in Dedupely.
To connect a client's CRM, you need admin rights in it. Some CRMs accept narrower permissions, and connecting your CRM lists what each one needs.
Admin access can take days in a larger company, and sometimes IT or a security team reviews the tool first. Ask who approves it on day one.
If a review comes up, share Dedupely's Trust Center early. It has the documents security teams usually ask for.
Connect the CRM and choose the objects
Connecting and syncing never merge, edit or delete anything in the client's CRM. Tell the client that early, since connecting a new tool can sound risky.
Dedupely syncs whole objects, like all contacts or all companies. Turn on only the objects you'll clean first, since the records in every active object count toward your plan. In a partner account, the total adds up across all your clients, and you can set how much of the limit each client uses.
| Object | Turn it on first when | What to watch for |
|---|---|---|
| Contacts or people | Reps or marketing complain about the same person showing up twice | Shared inboxes and family members who share an email or phone |
| Companies or accounts | Reports count customers twice, or two reps work the same account | Branches and subsidiaries that share a domain |
| Leads | Many records arrive from forms and prospecting tools | Leads and contacts never match each other, since matching stays within one object |
Spreadsheets don't count toward the record limit. If the client also keeps lists outside the CRM, you can clean those in a spreadsheet workspace.
The first sync
The first sync depends on the size of each object. As a guide, it takes 2–15 minutes up to 50,000 records and 15–90 minutes up to 300,000, and longer for the largest databases.
Your CRM's API limits can make the first sync take longer, so start it before the kickoff call. After that, Dedupely refreshes every 10–30 minutes.
Look before you touch anything
Searching, scanning and changing match options never change the CRM, so you can explore freely. Use that to understand the data before you plan a single merge.
- Run the preset searches. Dedupely has preset duplicate searches for every object, ready the first time you log in.
- Write down the counts. Every search shows the number of matches and the records in them. Those are your "before" numbers for the client report.
- Open the largest sets. A set with dozens of records is usually a placeholder value or a shared inbox, rarely one customer.
- Check what's held back. Safety Settings keep risky matches, like sets of more than 20 records or test data, in the Excluded tab.
On contacts, companies and leads, Dedupely Intelligence also scans automatically and shows how many matches it found. For the wider checks on a CRM you didn't build, see what to check first when you inherit a messy CRM.
Find where the duplicates come from
A cleanup that ignores the sources ends with the same duplicates a month later. Ask the client for every tool and process that creates records.
- Web forms, scheduling links and phone apps.
- List imports, event lists, and prospecting or enrichment tools.
- Syncs with other systems, like billing, support or another CRM.
- Reps who create a record because they couldn't find the existing one.
Ask which of those tools store CRM record IDs, too. A merge can change or remove an ID, and you want that list before the first merge, not after.
Where the client is right now changes which source matters most. Our post on handling a client's duplicates at every CRM stage covers each situation.
Define what a duplicate is for this client
What counts as a duplicate is case by case. What one team considers a duplicate, another may not, so the definition comes from the client.
Write the answer down for each object you'll clean. A short list is enough:
- A few sets that are duplicates, taken from the client's own data.
- A few sets that look alike but aren't, like branches or family members.
- Records that should never merge, like key accounts or records synced to billing.
- The unclear cases, and who on the client's side decides them.
These known sets become your test for every search you build. To keep the answers on one page per client, see one CRM cleanup process for every client.
Start with the obvious duplicates
Start with the duplicates nobody would argue about. They're the quickest win, and they show the client the project is moving forward.
For contacts, that's usually the same first name, last name and email. For companies, it's the same domain and name. Matching on three or more fields keeps false matches low, and you can loosen one field at a time later.
- Reject the false matches. A rejected match stays out of current and future searches.
- Send unclear sets to Manual Review. They stay there until someone merges or removes them, so the client can decide later.
A common setup is to keep the strictest searches for merging and use looser ones only to find sets for review. The looser searches are where the client's input matters most.
Preview, then run your first test merges
Before the first merge, decide what the merged record keeps. The CRM's own merge logic can decide, or you can set Merge Rules for which record survives and which values win.
Then preview a handful of sets. The winning values show in bold, and the preview panel shows the final record. Check the owner, stage, email and phone, and that no blank value replaces real data.
Treat every merge in the client's CRM as permanent. So test small:
- Merge one or two sets you know well, ideally with notes and deals attached.
- Open them in the CRM the way the client's team would.
- Compare them with the original records in Merge History.
- Bulk merge one or two pages from the same search, and check again.
If something looks wrong, fix the rule, since it decides every merge after this one. The playbook for merging the wrong records covers how to restore values from the Merge History CSV.
Check in with the client before you scale
End the week with a short check-in. There's no formal sign-off to collect. The client confirms you're heading the right way before the bulk merges start.
- The counts per object, and the sources you'd fix first.
- Your written definitions, with a few real sets as examples.
- Two or three test merges, opened in the CRM.
- The unclear sets waiting in review.
If you want the client involved, you can add them to their company as an Admin or a User. Their login takes them into your partner account, where they see only their own company.
Week two is for bulk merging the obvious searches. Proving the work over the rest of the project is covered in CRM deduplication for consultants and agencies.
How Dedupely helps you through a new client's first week
With a Dedupely partner account, each new client is its own company, and connecting their CRM changes nothing until you merge. You build duplicate searches, reject false matches, send unclear sets to review and preview each merge, while Merge History keeps every original value. The Dedupely partner program explains how one account holds every client.
A first week that ends with a direction
A good first week leaves you with access, a clear look at the data and a written definition of a duplicate. It also leaves a few merges you've checked by hand.
When those are in place, the client has seen real examples and agreed on the direction. The bulk merges that follow are the part that should feel routine.
Frequently asked questions
How do I start cleaning a new client's CRM?
Get admin rights in the client's CRM, connect it and sync only the objects you'll clean first. Then look at the matches and their sources without changing anything, and agree with the client on what counts as a duplicate. Start with the obvious duplicates, and preview and test a few merges before any bulk merge.
What access do I need to deduplicate a client's CRM?
Usually admin rights in the client's CRM. Some CRMs accept narrower permissions, such as edit and merge or delete rights on the objects you'll clean. Ask on the first call, since approval can take days in a larger company and may involve IT or a security review.
How long does the first sync of a client's CRM take?
In Dedupely, it takes 2–15 minutes up to 50,000 records and 15–90 minutes up to 300,000, and longer for the largest databases. The CRM's API limits can also make it take longer, so start the sync well before your kickoff call.
Does a client need to sign off on every merge?
Usually not. Clients agree on what counts as a duplicate at the start, and a short check-in confirms the cleanup is heading the right way. Only unclear sets, like two offices of one company or family members, need someone on the client's side to decide before they merge.
How many test merges should I run before bulk merging?
Start with one or two sets you know well, ideally with notes and deals attached, and open them in the CRM. Then bulk merge one or two pages from the same search and check again. Once those look right, merge the rest of that search in larger batches.










