TL;DR
- Granska ett övertaget CRM innan du slår ihop, tar bort eller ändrar något.
- Att lista varje verktyg som skriver till CRM visar varifrån dubbletter kommer.
- Fråga varje team vad en dubblett betyder för dem, eftersom definitionerna skiljer sig åt.
- Tidigare sammanslagningar, skript och postägare kan förklara mycket av det som ser fel ut.
- Dedupely visar hur många dubbletter ett övertaget CRM innehåller utan att ändra någon data.
Du har precis tagit över ett CRM. Kanske är du ny administratör, säljchef eller den första RevOps-anställda. Under din första vecka hittar du samma företag tre gånger, kontakter utan ägare och rapporter som ingen litar på.
Impulsen är att börja rätta. Men varje post du slår ihop eller raderar under första veckan är ett beslut fattat utan sammanhang, och många sammanslagningar kan inte ångras. Personen som byggde CRM:et gjorde val som du ännu inte kan se.
I det här inlägget ser du vad du bör titta på innan du rör något. Det handlar om källor, teamets definition av en dubblett, tidigare städningar och ägare. Du ser också hur du omvandlar dessa fynd till ett första, säkert steg.
Varför det lönar sig att titta innan du rättar
Börja med en inventering av källa, objekt, identifierande fält, ägare och senaste importdatum. Jämför till exempel kontakter från en eventimport med det befintliga kundsegmentet innan du ändrar något av dem. Då får den första rensningen en tydlig avgränsning.
Ett rörigt CRM ser ut som ett problem. Det är oftast flera, var och en med egen orsak, ägare och historik.
En del av det som ser fel ut gjordes med avsikt. Två poster för ett företag kan vara två filialer som olika säljare äger. Ett fält fullt av udda värden kan mata en rapport som någon på ekonomiavdelningen är beroende av.
En kort diagnos skyddar dig också. När någon frågar varför du slagit ihop deras konton har du ett svar, och du vet hur CRM:et såg ut innan du ändrade det.
Kontrollera vad som skriver till CRM:et
Dubbletter återkommer så länge källorna fortsätter köra. Innan du rensar, ta reda på var posterna kommer ifrån.
Integrationer och synkroniseringar
Lista alla anslutna appar: marknadsföringsverktyg, telefonisystem, supportsystem, fakturering, berikning och andra CRM. Notera vilka som skapar poster och vilka som bara uppdaterar dem.
Formulär och importer
Hitta formulären som skapar kontakter och listorna som importeras. Evenemangslistor och köpta listor kommer ofta in utan kontroll mot det som redan finns.
Migreringar och förvärv
Fråga om CRM:et någon gång har migrerats från ett annat system eller slagits ihop med ett annat företags. Poster från sådana flyttar delar ofta ett skapandedatum eller en importbatch, vilket hjälper dig att hitta dem.
Vårt inlägg om deduplicering över importer, migreringar och synkroniseringar förklarar hur varje källa skapar dubbletter.
Kontrollera hur ditt team definierar en dubblett
Vad som räknas som dubblett avgörs från fall till fall. Det ett team ser som dubblett kanske ett annat inte gör, och du har just gått med i ett företag med sitt eget svar.
Fråga försäljning, marknad och support var för sig. Försäljningen vill kanske ha en post per företag, inklusive filialer, medan marknadsavdelningen kanske vill att varje e-postadress behålls som en egen kontakt. Supporten bryr sig kanske mest om en person per inkorg.
Skriv ner svaren för varje objekt: kontakter, företag, leads och affärer. Där teamen är oense är det ett beslut att fatta före någon sammanslagning, och det är ofta det mest användbara fyndet under första veckan.
Kontrollera vad tidigare rensningar gjorde
Sammanslagningar och deras regler
Ta reda på om någon slagit ihop poster tidigare, med vilket verktyg och med vilka regler för vilket värde som vinner. En tidigare sammanslagning kan förklara varför vissa poster har konstiga ägare eller saknar historik.
Skript och automatiseringar
Leta efter arbetsflöden, skript eller schemalagda jobb som redigerar, slår ihop eller tar bort poster. Ett som fortfarande kör kan ångra ditt arbete eller skapa nya problem.
Matchar någon som redan avvisats
Om en tidigare administratör bestämde att två poster inte var dubletter kan beslutet fortfarande gälla. Fråga innan ni slår ihop poster som någon medvetet hållit isär.
Kontrollera vem som äger vad
Ägarskap är där många dublettkonflikter börjar, eftersom en sammanslagning avgör vilken säljare som behåller kunden. Innan du slår ihop, titta på:
- Ägare som har slutat: poster som fortfarande ägs av tidigare anställda.
- Platshållarägare: integrationsanvändare eller delade användare som äger tusentals poster.
- Delat ägarskap: samma företag ägt av två säljare under två poster.
Vårt inlägg om dubbletter av poster ur en försäljningschefs perspektiv förklarar varför ägarkonflikter börjar här.
Kontrollera vad som beror på posterna
Sammanslagning kan ändra post-ID:n och fältvärden. Innan du ändrar något, lista allt som förlitar sig på dem: rapporter ledningen läser, arbetsflöden, sekvenser och integrationer som lagrar post-ID:n.
Listan visar vilka sammanslagningar som kräver extra försiktighet och vem du bör informera innan du börjar. Spara en säkerhetskopia av de poster du planerar att slå ihop, enligt beskrivningen i hur du säkerhetskopierar ditt CRM före en stor sammanslagning.
| Kontrollera | Vad du ska leta efter | Varför det är viktigt |
|---|---|---|
| Vad skriver till CRM:et | Integrationer, formulär, importer, tidigare migreringar | Visar var dubbletter uppstår och vilka som kommer tillbaka |
| Så definierar teamet en dubblett | Varje teams svar, per objekt | Förhindrar sammanslagning av poster som någon behöver hållas isär |
| Tidigare rensningar | Sammanslagningar, regler, skript, avvisade träffar | Förklarar konstig data och undviker att upprepa misstag |
| Ägare | Tidigare anställda, platshållarägare, delat ägarskap | En sammanslagning avgör vem som behåller kunden |
| Vad som beror på posterna | Rapporter, arbetsflöden, integrationer som lagrar ID:n | Visar vilka sammanslagningar som kräver extra försiktighet |
| Hur många dubbletter | Antal per objekt och per källa | Uppskattar arbetet och sätter en utgångspunkt |
Mät hur många dubbletter som finns
När du vet källorna och definitionen, räkna. Mät varje objekt för sig och notera var dubletterna kom ifrån. Vårt inlägg om hur du tar reda på hur många dubbletter ditt CRM har går igenom det.
Det talet är din utgångspunkt. Det visar ledningen hur stort problemet är och senare hur mycket städningen förändrade.
Ta sedan ett första, säkert steg
När analysen är klar börjar du med de uppenbara dubbletterna: exakta träffar i fältet som identifierar varje post, till exempel e-post eller domän. De är minst benägna att vara fel, och de visar teamet att rensningen görs noggrant.
Skicka oklara matchningar till granskning och avvisa en matchning först när du är säker på att den inte är en dubblett. Vårt inlägg om var du ska börja med dublettrensning i CRM går igenom den första sammanslagningen mer i detalj.
Om ditt CRM är Salesforce, läs vårt inlägg om hur du städa upp en ärvd Salesforce-organisation behandlar den delen.
Så hjälper Dedupely dig att diagnostisera ett ärvt CRM
Att ansluta ditt CRM till Dedupely slår aldrig ihop, redigerar eller raderar något, så du kan titta innan du rör något. Förinställda dubblettsökningar är klara första gången du loggar in. Varje sökning visar antalet matchningar och antalet poster i dem.
Förstå CRM:et innan du ändrar det
En ärvd CRM bär på beslut från alla som använt den före dig. En del av röran är oavsiktlig och en del är avsiktlig, och utifrån ser de likadana ut.
Källor, definitioner, tidigare rensningar och ägare förvandlar ett oklart kaos till en lista med beslut. Då blir den första sammanslagningen något du kan förklara.
Vanliga frågor
Vad bör jag kontrollera först i ett ärvt CRM?
Börja med vad som skriver till den: integrationer, formulär, importer och tidigare migreringar. Fråga sedan varje team hur de definierar en dubblett, ta reda på vad tidigare rensningar och skript gjorde, och kontrollera postägare. Mät först dubbletterna och planera sedan den första sammanslagningen, med de uppenbara först.
Hur dokumenterar jag ett CRM som jag tagit över?
Håll ett kort dokument med CRM:ens källor, varje teams definition av en dubblett och tidigare städningar. Lägg till ägarskapsfrågor, antal dubbletter per objekt och vad som är beroende av posterna, som rapporter. Dokumentet blir också det underlag nästa ägare behöver.
Bör jag rensa ett övertaget CRM direkt?
Inte innan en kort diagnos. En del av det som ser fel ut gjordes med avsikt, som separata poster för filialer, och många sammanslagningar kan inte ångras. Lägg de första dagarna på att lära dig källor, definitioner och ägare, och börja sedan med exakta matchningar du är säker på.
Hur tar jag reda på hur rörigt mitt CRM är?
Mät dubbletter för varje objekt för sig, med början i exakta träffar på e-post för kontakter och domän för företag. Notera vilken källa varje uppsättning kommer från. Kontrollera också ägare, poster som saknar fältet som identifierar dem och vilka rapporter ledningen förlitar sig på.
Vem ska jag prata med när jag tar över ett CRM?
Prata med försäljning, marknad och support var för sig, eftersom var och en definierar dubblett olika. Om du kan, prata även med tidigare administratör eller den som ansvarat för tidigare upprensningar. Ekonomi eller ledning kan berätta vilka rapporter de förlitar sig på innan du ändrar något.
Eller registrera dig med Google
Pipedrive Marketplace 
