Dublerede kunder: hvad du skal tjekke før sammenfletning

For at gennemgå duplikerede kunder skal du først sammenligne identitet og funktion for hver post; derefter beslutte, om det er nødvendigt at flette. En post i salg og en anden i fakturering kan være korrekte. Det, der måske mangler, er en pålidelig kobling mellem de to.

Problemet opstår, når administrationen finder to lignende historikker, og nogen foreslår at beholde den “mest komplette”. En post kan indeholde den aktuelle kontakt; den anden, referencer brugt af en integration. At vælge ud fra antal udfyldte felter løser ikke denne konflikt. Denne guide leverer en matrix og en beslutningslog til at gennemgå sagen, før den ændres.

Én post per værktøj kan være det rigtige

Skeln mellem den samme enhed repræsenteret i to systemer og to redundante poster inden for ét. Det første tilfælde kan kræve en oversigt over sammenhørende identifikatorer; det andet, en undersøgelse af duplikatets oprindelse. Ingen af delene giver ret til at slette en række ud fra dens navn.

Definer også, hvad hver post repræsenterer: organisation, kontaktperson, afdeling eller forretningskonto. En person, der arbejder i en virksomhed, er ikke en duplikat af denne virksomhed. To afdelinger bør heller ikke slås sammen, hvis din drift kræver, at de behandles separat.

Denne gennemgang passer ind i forberedelsen af en migration (på engelsk), men kan også bruges uden at skifte værktøj. Resultatet kan være at bevare to poster og forklare deres relation.

Bevar kilden, før du normaliserer

Arbejd på en kopi, der kun kan læses. For hver række skal du gemme system, arbejdsområde, posttype, original identifikator og udtræksdato. CRM / W1 / account / A17 identificerer noget andet end BILL / W1 / account / A17: at gentage nummeret beviser ikke, at det er den samme kunde.

Bevar de originale værdier og opret hjælpekolonner til at sammenligne mellemrum, store og små bogstaver eller kendte varianter af navnet. Fjern ikke suffikser, afdelinger eller referencer, der kan skelne enheder. Et tomt felt betyder “ingen data”, ikke “matcher et andet tomt felt”.

Noter, hvor hvert signal kommer fra. En fælles kode har større værdi, hvis du ved, hvem der tildelte den, og du har kontrolleret dens korrespondance. En kode kopieret i en forkert import kan sprede den samme fejl til begge poster. Datoen for seneste redigering gør heller ikke automatisk en værdi korrekt.

En matrix med tre resultater og fire tilfælde

Følgende eksempel er udelukkende fiktivt. Alle poster tilhører W1-området; koderne ORG og EV er øvelsesreferencer, ikke skatteidentifikatorer eller kundedata. De beskrevne beviser antages kun at være tilgængelige for at vise ræsonnementet.

Tildel ikke opfundne tillidsprocenter. “Sandsynligt” åbner for en gennemgang: det er ikke en godkendt fletning. “Tvetydigt” bevarer blokeringen og forklarer, hvad der mangler. Selv når du bekræfter identitet, skal det stadig besluttes, om noget skal ændres.

Fraværet af ordrer i en post beviser heller ikke, at den er overflødig: det kan være en ny oprettelse eller repræsentere en anden funktion. Klassificer med beviser, ikke med antallet af tomme felter.

Alias-kortet udfører ikke en fletning

Antag, at den ansvarlige løser det første tilfælde: A17 og B62 repræsenterer ORG-07, men begge værktøjer har brug for deres post. Beslutningen er at beholde dem og registrere deres korrespondance. På et separat ark kan ENTITY-F07 være din arbejdsreference:

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 kolonner er en selvstændig øvelsesskabelon, ikke et importformat fra Frihet eller en ordre til en connector. entity_key grupperer gennemgåede identiteter; source_id bevarer den originale reference. Et alias ændrer ikke værktøjerne, blot fordi det eksisterer på et ark.

Saml ikke personer, virksomheder og lokationer under samme nøgle. Og kombiner ikke transitivt uden at gennemgå: hvis A ligner B og B ligner C, har du endnu ikke bevist, at A og C er det samme.

Registrer en beslutning, som en anden kan gennemgå

Kopier denne post for hvert par. Bevar det tidligere forslag, når beslutningen ændres, og tilføj en ny version, der erstatter det.

Gennemgang: R-01 / version 1
Fuldstændige referencer: CRM/W1/account/A17; BILL/W1/account/B62
Bevis: EV-01; ORG-07 korrespondance bekræftet af ansvarlig
Konflikt: anden ansvarlig kontakt; gældende værdi bekræftet i EV-05
Beslutning: bevar begge poster og registrer korrespondance ENTITY-F07
Ansvarlig for gennemgang: ROLE-OPS
Handling i værktøjerne: ingen
Afventer: gennemgå hvordan connectoren bruger denne korrespondance
Erstatter: ingen tidligere gennemgang

Koderne er fiktive. I reel brug henvises til beviser, der er tilgængelige for den, der skal gennemgå dem, og undgå at kopiere unødvendige personlige data til arket. Hvis en ændring senere godkendes, skal udfører, tidspunkt, tidligere referencer og observeret resultat registreres separat. “Godkendt”, “udført” og “verificeret” er forskellige stadier.

Denne historik kan revideres, ikke en garanti for tilbageførsel. At rette en skriftlig beslutning genopbygger ikke automatisk de allerede ændrede data.

Hvad man skal tjekke hos udbyderen, før man fletter

Adfærden afhænger af produktet og posttypen. HubSpot dokumenterer, at en fletning ikke kan fortrydes, og at identifikatorer, egenskaber og associationer følger specifikke regler. Antag ikke, at det ID, du markerede som primært, altid overlever intakt.

Shopify advarer også om, at handlingen ikke er reversibel og udelukker visse profiler, såsom dem, der har eller har haft abonnementsaftaler. Disse eksempler beskriver ikke adfærden for Frihet eller din anden udbyder.

Før enhver irreversibel handling skal disse spørgsmål besvares:

• Er denne kombination af typer understøttet, og har du de passende tilladelser?
• Hvilke værdier bevares, hvilke kasseres, og hvilket ID får resultatet?
• Hvad sker der med historik, relationer og eksterne referencer?
• Hvad vil synkroniseringen gøre: genkende ændringen, genskabe en post eller fejle?
• Hvilken genoprettelse eksisterer reelt, og hvad dækker din kopi ikke?

Læs integrationernes omfang (på engelsk) og kontroller kontrakten for den anvendte connector. En læsefunktion beviser ikke, at den kan overføre sammenfletninger til andre systemer.

Afslut sagen ved også at kontrollere dens oprindelse

Hvis en fletning godkendes, skal du først aftale, hvordan dens effekter på de tilsluttede systemer skal begrænses. Test med syntetiske data i et kompatibelt testmiljø; hvis et sådant ikke findes, skal du bevare blokeringen, indtil du har løst usikkerhederne med udbyderen. En isoleret eksport beviser ikke, at du kan gendanne alt.

Efter en godkendt ændring skal du sammenligne felter og referencer med det forventede og gennemgå den næste synkronisering, før du behandler flere poster. Hvis resultatet er usikkert, skal du undersøge, før du gentager handlingen.

I Frihets kundestyring er eksport af listen som CSV tilgængelig. Dette kan tjene som input til en gennemgang; det forudsætter ikke import af denne skabelon eller automatisk fletning af kunder.

Afslut med at notere, hvorfor duplikatet opstod: manuel oprettelse, import eller connector-regel, hvis der er beviser. Hvis du stadig ikke ved det, skal du efterlade en ansvarlig og en afventende kontrol. To bevarede poster med en klar relation er et gyldigt resultat; en kortere liste uden en forklarbar historik er det ikke.

Kilder konsulteret den 14. september 2026. Gennemgå din udbyders gældende dokumentation, før du foretager ændringer.