Dupliserte kunder: hva du bør sjekke før sammenslåing

For å gjennomgå dupliserte kunder, sammenlign først identiteten og funksjonen til hver post; deretter bestem om sammenslåing er nødvendig. En post i salg og en annen i fakturering kan begge være nødvendige. Det som kanskje mangler, er en pålitelig kobling mellom dem.

Problemet oppstår når administrasjonen finner to lignende historikker og noen foreslår å beholde «den mest komplette». En post kan inneholde den nåværende kontakten; den andre, referansene brukt av en integrasjon. Å velge basert på antall utfylte felt løser ikke denne konflikten. Denne guiden gir en matrise og en beslutningslogg for å gjennomgå saken før den endres.

Én post per verktøy kan være det riktige

Skill den samme enheten representert i to systemer fra to redundante poster innenfor ett. Det første tilfellet kan kreve et samsvarskart; det andre, en undersøkelse av duplikatets opprinnelse. Ingen av delene gir rett til å slette en rad basert på navn.

Definer også hva hver post representerer: organisasjon, kontaktperson, avdeling eller forretningskonto. En person som jobber i et selskap er ikke et duplikat av det selskapet. To avdelinger bør heller ikke slås sammen hvis driften din krever at de behandles separat.

Denne gjennomgangen passer inn i forberedelsen av en migrering (på engelsk), men er også nyttig uten å bytte verktøy. Resultatet kan være å beholde to poster og forklare deres forhold.

Bevar opprinnelsen før normalisering

Arbeid med en skrivebeskyttet kopi. For hver rad lagrer du system, arbeidsområde, posttype, original identifikator og uttrekkingsdato. CRM / W1 / account / A17 identifiserer noe annet enn BILL / W1 / account / A17: å gjenta nummeret beviser ikke at det er samme kunde.

Behold de originale verdiene og opprett hjelpekolonner for å sammenligne mellomrom, store og små bokstaver eller kjente varianter av navnet. Ikke fjern suffikser, avdelinger eller referanser som kan skille enheter. Et tomt felt betyr «ingen data», ikke «samsvarer med et annet tomt felt».

Noter hvor hvert signal kommer fra. En felles kode har større verdi hvis du vet hvem som tildelte den og du har bekreftet dens korrespondanse. En kode kopiert i en feilaktig import kan spre den samme feilen til begge postene. Datoen for siste redigering gjør heller ikke automatisk en verdi korrekt.

En matrise med tre resultater og fire tilfeller

Det følgende eksemplet er utelukkende fiktivt. Alle postene tilhører W1-området; kodene ORG og EV er referanser for øvelsen, ikke skatteidentifikatorer eller kundedata. De beskrevne bevisene antas å være tilgjengelige kun for å vise resonnementet.

Ikke tilordne oppfunne tillitsprosenter. «Sannsynlig» åpner for en gjennomgang: det er ikke en godkjent sammenslåing. «Tvetydig» opprettholder blokkeringen og forklarer hva som mangler. Selv når du bekrefter identitet, gjenstår det å bestemme om noe må endres.

Fraværet av bestillinger i en post beviser heller ikke at den er overflødig: det kan være en nylig registrering eller representere en annen funksjon. Klassifiser med bevis, ikke med antall tomme felt.

Alias-kartet utfører ikke en sammenslåing

Anta at den ansvarlige løser det første tilfellet: A17 og B62 representerer ORG-07, men begge verktøyene trenger sin post. Beslutningen er å beholde dem og registrere deres korrespondanse. På et eget ark kan ENTITY-F07 være din arbeidsreferanse:

system,workspace,record_type,source_id,entity_key,review_id
CRM,W1,account,A17,ENTITY-F07,R-01
BILL,W1,account,B62,ENTITY-F07,R-01

Disse kolonnene er en egen mal, ikke et importformat fra Frihet eller en ordre for en kobling. entity_key grupperer kontrollerte identiteter; source_id bevarer den originale referansen. Et alias endrer ikke verktøyene bare ved å eksistere på et ark.

Ikke flat ut personer, selskaper og avdelinger under samme nøkkel. Og ikke kombiner ved transitivitet uten å sjekke: hvis A ligner på B og B ligner på C, har du ennå ikke bevist at A og C er det samme.

Registrer en beslutning som en annen person kan gjennomgå

Kopier denne posten for hvert par. Behold forrige forslag når beslutningen endres, med en ny versjon som erstatter den.

Gjennomgang: R-01 / versjon 1
Fullstendige referanser: CRM/W1/account/A17; BILL/W1/account/B62
Bevis: EV-01; ORG-07-korrespondanse bekreftet av ansvarlig
Konflikt: ansvarlig kontakt forskjellig; gjeldende verdi bekreftet i EV-05
Beslutning: behold begge poster og registrer korrespondanse ENTITY-F07
Ansvarlig for gjennomgang: ROLE-OPS
Handling i verktøyene: ingen
Gjenstår: gjennomgå hvordan koblingen bruker denne korrespondansen
Erstatter: ingen tidligere gjennomgang

Kodene er fiktive. I faktisk bruk, referer til bevis som er tilgjengelig for den som skal gjennomgå det, og unngå å kopiere unødvendige personlige data på arket. Hvis en endring senere autoriseres, registrer separat utfører, tidspunkt, tidligere referanser og observert resultat. «Godkjent», «utført» og «verifisert» er forskjellige tilstander.

Denne historikken kan revideres, ikke en garanti for reversering. Å korrigere en skriftlig beslutning gjenoppbygger ikke automatisk de allerede endrede dataene.

Hva du må sjekke hos leverandøren før du slår sammen

Oppførselen avhenger av produktet og posttypen. HubSpot dokumenterer at en sammenslåing ikke kan angres og at identifikatorer, egenskaper og assosiasjoner følger spesifikke regler. Ikke anta at ID-en du markerte som primær alltid overlever intakt.

Shopify advarer også om at operasjonen ikke er reversibel og ekskluderer visse profiler, for eksempel de som har eller har hatt abonnementskontrakter. Disse eksemplene beskriver ikke oppførselen til Frihet eller din andre leverandør.

Før en irreversibel handling, sørg for at disse spørsmålene er besvart:

• Støttes denne kombinasjonen av typer, og har du de riktige tillatelsene?
• Hvilke verdier bevares, hvilke forkastes, og hvilken ID vil resultatet ha?
• Hva skjer med historikk, relasjoner og eksterne referanser?
• Hva vil synkroniseringen gjøre: gjenkjenne endringen, gjenskape en post eller feile?
• Hvilken gjenoppretting finnes egentlig, og hva dekker ikke kopien din?

Les integrasjonenes omfang (på engelsk) og sjekk kontrakten for den brukte koblingen. En lesefunksjon beviser ikke at den kan overføre sammenslåinger til andre systemer.

Avslutt saken ved også å sjekke dens opprinnelse

Hvis en sammenslåing autoriseres, avtal først hvordan effektene på de tilkoblede systemene skal begrenses. Test med syntetiske data i et kompatibelt testmiljø; hvis dette ikke finnes, oppretthold blokkeringen til du har løst uklarhetene med leverandøren. En isolert eksport beviser ikke at du kan gjenopprette alt.

Etter en autorisert endring, sammenlign felt og referanser med det forventede og gjennomgå neste synkronisering før du behandler flere poster. Hvis resultatet er usikkert, undersøk før du gjentar handlingen.

I kundehåndteringen til Frihet er eksport av listen som CSV tilgjengelig. Dette kan tjene som et grunnlag for en gjennomgang; det forutsetter ikke import av denne malen eller automatisk sammenslåing av kunder.

Avslutt med å notere hvorfor duplikatet dukket opp: manuell registrering, import eller koblingsregel, hvis det finnes bevis. Hvis du fortsatt ikke vet, utpek en ansvarlig og noter hvilken sjekk som gjenstår. To bevarte poster med et klart forhold er et gyldig resultat; en kortere liste uten forklarbar historikk er det ikke.

Kilder konsultert 14. september 2026. Gjennomgå din leverandørs gjeldende dokumentasjon før du utfører endringer.