TL;DR
- Dubblettkontroll vid inmatning stoppar vissa nya poster, oftast vid exakt matchning av e-post eller domän.
- Matchning vid inmatning missar ofta stavfel, andra e-postadresser och vissa importerade eller synkade poster.
- Att hitta och slå ihop enligt schema fångar närliggande matchningar och dubbletter som redan finns i CRM:et.
- Många CRM-team kombinerar inbyggd dublettkontroll vid registrering med schemalagd sökning och sammanslagning.
- Dedupely hittar och slår ihop de dubbletter som slinker förbi vid registrering, och nya poster är redo att matchas inom några minuter.
Det finns två tillfällen att hantera en dubblett. Du kan stoppa den när posten skapas, eller hitta den i efterhand och slå ihop den med posten den upprepar.
Team väljer ofta en metod och förväntar sig att den täcker allt. Matchning vid inmatning låter säkrare, eftersom inget dåligt släpps in.
Schemalagd städning låter mer grundlig eftersom den ser hela databasen. Var och en fångar en annan typ av dubblett, och var och en missar något.
I det här inlägget ser du vad varje metod gör, vad den släpper igenom och hur du kombinerar dem så att luckorna inte överlappar.
Vad det innebär att fånga dubbletter vid inmatning
Matchning vid inmatning körs när en post skapas eller redigeras. CRM:et jämför den nya posten med befintliga och avgör vad som ska göras innan den sparas.
Många CRM-system har någon form av det som inbyggd dubblettrensning. Hur det fungerar beror på CRM-systemet och hur posten kommer in.
Blockera, varna eller uppdatera
Inbyggd dubblettkontroll använder vanligtvis en av tre åtgärder. Den blockerar den nya posten, varnar användaren och låter denne spara ändå, eller uppdaterar den befintliga posten med de nya värdena.
I ett CRM blockeras inmatning av en kontakt med en e-postadress som redan finns. En formulärinskickning med samma e-post uppdaterar i stället den befintliga kontakten. I ett annat avgör en admin om en regel visar en varning eller blockerar sparandet.
Exakta och fuzzy-regler beror på CRM:et
Vissa kontroller vid inmatning använder exakta matchningar på e-post eller domän. Andra, inklusive konfigurerbara matchningskriterier i Salesforce, kan jämföra flera fält och använda fuzzy-metoder. Vad som stoppas beror på den aktiva regeln, objektet och om posten kommer via formulär, import, API eller manuell inmatning.
En blockeringsregel kräver noggrann testning eftersom den kan avvisa en giltig post. En varning kan låta användaren granska en möjlig matchning innan den sparas. Välj åtgärd och kriterier efter dina data; hur dubblettmatchning fungerar i ett CRM behandlar exakt och ungefärlig matchning.
Från oktober 2026, från HubSpots kunskapsbas: Deduplicering av poster, och Salesforce Help: Hindra användare från att skapa dubblettposter.
Vad matchning vid inmatning släpper igenom
Matchning vid inmatning gör sitt jobb för de dubbletter den byggdes för. Resten kommer in ändå, ofta av skäl som inte har något med hur väl den är konfigurerad att göra.
- Nära matchningar: ett stavfel i e-postadressen, ett smeknamn, "Acme Inc." bredvid "Acme". Exakt matchning läser dessa som olika poster.
- En andra e-postadress: samma person registrerar sig med en privat e-post efter att ha köpt med en jobbadress. Inget i nyckelfältet matchar.
- Poster utan nyckelfält: en kontakt som angetts med bara namn och telefon, eller en importrad utan e-post. Det finns inget att jämföra med.
- Importer och integrationer: vissa ingångar följer olika regler. I ett CRM matchas företag som skapats via API:et inte alls på domän.
- Varningar som användare klickar bort: en upptagen säljare ser en varning, antar att den är fel och sparar posten ändå.
- Dubbletter som redan finns i databasen: matchning vid inmatning tittar bara på posten som sparas. Den granskar aldrig dubbletter du redan har.
Blockering har en andra kostnad som är lätt att missa. I ett CRM får poster från dataimporter och API:et ingen varning när en regel blockerar dem, och de sparas inte. Om ingen kontrollerar vad som avvisades är uppgifterna borta från inläsningen.
Från oktober 2026, från HubSpots kunskapsbas: Deduplicering av poster, och Salesforce Help: Saker att känna till om dubblettregler.
Vad schemalagd sökning och sammanslagning fångar
Schemalagd dubblettrensning körs efter att poster har sparats. Ett verktyg eller en person går igenom hela databasen, grupperar poster som hör ihop och slår ihop dem.
En schemalagd sökning kan samla osäkra kandidater för granskning innan något ändras. Beroende på verktyget kan den jämföra stavfel, likaljudande namn, företagsdomäner och flera fält tillsammans. Bekräfta identiteten innan kandidaterna blir sammanslagningar.
Nära matchningar och grupper
Om du söker i hela den sparade databasen hittar du dubletter som de konfigurerade inmatningsreglerna missade. Dessa kan omfatta något olika e-postadresser eller en person som använder två adresser. Det hittar också grupper, till exempel en kund som registrerats av flera källor. Vissa inmatningsregler fångar även nära matchningar; den schemalagda sökningen ger ett extra tillfälle att granska.
Dubbletterna du redan har
En schemalagd körning omfattar även äldre poster. Det gäller dubbletter från innan någon inbyggd dubblettkontroll slogs på, från migreringar och från integrationer som hoppade över inmatningsreglerna.
Granska innan något ändras
Ingenting blockeras eller försvinner när en post kommer in. Osäkra matchningar kan vänta tills en person tittar på dem, och resultatet av sammanslagningen kan kontrolleras innan den genomförs.
Avvägningen är tid. En dubblett finns en tid innan den slås ihop, och under den tiden kan den samla på sig aktiviteter eller nå en sekvens. Hur lång den perioden bör vara beror på dina källor, vilket vi går igenom i hur ofta du bör rensa dubbletter i ditt CRM.
Inträde kontra schema i korthet
| Fånga upp vid inmatning | Hitta och slå ihop enligt schema | |
|---|---|---|
| När den körs | När en post skapas eller redigeras | Efter att poster sparats, över hela databasen |
| Vad den jämför | Exakt eller ungefärlig, beroende på CRM och aktiv regel | Flera fält, inklusive nära matchningar |
| Det den fångar bäst | Exakta upprepningar från personer och formulär | Stavfel, extra e-postadresser, grupper och gamla dubbletter |
| Vad den missar | Nära matchningar, poster utan nyckelfält, vissa importer och integrationer | Dubbletter som uppstår mellan körningar |
| Vem bestämmer | Regeln, eller en användare som får en varning | Regler du testat, plus granskning för oklara uppsättningar |
| Största risk | Blockerade poster som inte sparas, eller varningar som ignorerats | Lös matchning som slår samman poster som inte är dubbletter |
Varför många team behöver båda
Varje metod täcker den andras blinda fläck. Matchning vid inmatning stoppar de enkla upprepningarna innan de sprider sig. En schemalagd körning hittar de nära matchningarna och de gamla dubbletter som inmatningen aldrig ser.
Balansen mellan dem beror på din data. Vad som räknas som dubblett avgörs från fall till fall, och det ett team anser vara en dubblett kanske inte gör för ett annat. Skriv ner din definition innan du konfigurerar något av dem.
Låt inmatningen hantera exakta upprepningar
Aktivera den inbyggda dubblettkontrollen i ert CRM för fältet som identifierar varje post. Håll reglerna snäva, så att användarna litar på varningarna i stället för att klicka förbi dem.
Om en regel blockerar importer eller API-poster, kontrollera vad den avvisade efter varje inläsning. Lagren runt den tas upp i hur man förhindrar dubblerade kontakter i snabbt växande säljteam.
Låt schemat hantera resten
Börja med de uppenbara dubbletterna, till exempel exakta träffar på e-post eller domän som kommit in via en annan kanal. Gå sedan vidare till nära matchningar på namn med företag eller telefon, och skicka oklara uppsättningar till granskning.
När reglerna är testade kan du slå ihop de dubletter du är säker på, till exempel exakta e-postmatchningar, automatiskt enligt schema. Behåll allt som är mindre säkert för granskning.
Håll koll på varifrån dubbletter fortfarande kommer
Varje dubblett som schemat hittar pekar tillbaka på en källa som den posten missade. Vissa källor, som webbformulär som skapar nya kontakter, är enklare att åtgärda en gång än att slå ihop om och om igen.
Så fångar Dedupely dubbletterna som tar sig förbi inmatningen
Dedupely fungerar efter att poster skapats och upptäcker nya poster inom 1 till 5 minuter. Du bygger duplicate searches som tar hänsyn till stavfel, likljudande namn och delade domäner, anger regler för vilket värde som vinner och förhandsgranskar varje sammanslagning. När reglerna är testade kan du automatiskt slå ihop nya dubbletter du är säker på, till exempel exakta e-postträffar, enligt schema.
Två tillfällen, en definition av en dubblett
Matchning vid inmatning och schemalagd dubblettrensning löser samma problem vid olika tidpunkter. Regler vid inmatning kan använda exakta eller ungefärliga kriterier, men täcker bara de objekt och inmatningsvägar som är konfigurerade för dem. Schemalagda sökningar granskar den lagrade databasen, med tid för personer att granska osäkra matchningar.
Tillsammans täcker de varandras luckor. Det som gör dem effektiva är en gemensam definition av en dubblett. Då letar regeln vid ingången och sökningen bakom den efter samma sak.
Vanliga frågor
Är det bättre att blockera dubbletter vid inmatning eller slå samman dem senare?
Många team behöver båda: blockering vid inmatning stoppar exakta upprepningar, till exempel samma e-postadress, innan de sprids. Sammanslagning i efterhand fångar liknande matchningar, andra e-postadresser och gamla dubbletter som matchning vid inmatning aldrig ser. Använd inmatningsregler för de exakta fallen och en schemalagd sökning för allt annat, med granskning av oklara grupper.
Varför skapar mitt CRM fortfarande dubbletter när deduplicering är aktiverad?
Det inbyggda beteendet beror på CRM och konfigurerade regler. En exakt e-postkontroll missar en andra adress eller ett stavfel, medan en regel över flera fält eller en fuzzy-regel kan fånga det. Vissa importer och integrationer använder andra regler, användare kan avfärda varningar, och inmatningsregler skannar inte hela den befintliga databasen.
Kan regler för CRM-dubbletter leda till dataförlust?
De kan det, när en regel blockerar poster som ingen granskar. I vissa CRM-system avvisar en blockeringsregel matchande rader från importer och API-inläsningar utan att visa något larm, och dessa rader sparas inte. Kontrollera vad varje inläsning avvisade och begränsa blockeringsregler till matchningar du är säker på.
Hur ofta bör dubbletter slås samman efter registrering?
Det beror på hur snabbt dina källor lägger till poster. Med stadiga formulär och integrationer slår team ofta ihop säkra matchningar automatiskt enligt schema och granskar resten regelbundet. Team som främst importerar listor kan kontrollera efter varje import och sikta på att slå ihop innan dubbletter når rapporter och sekvenser.
Vad är dubblettmatchning vid registrering?
Matchning sker när en post skapas eller redigeras. Beroende på CRM, regel och ingångsväg kan jämförelsen vara exakt eller oskarp. Systemet kan blockera, varna eller uppdatera en befintlig post. Testa varje väg i stället för att anta att en regel täcker alla nya poster.
Eller registrera dig med Google
