Dubbla kunder: vad du ska kontrollera före sammanslagning

För att granska duplicerade kunder, jämför först identitet och funktion för varje post; bestäm sedan om det är nödvändigt att slå ihop dem. En post i försäljning och en annan i fakturering kan vara korrekta. Det som kanske saknas är en tillförlitlig koppling mellan dem.

Problemet uppstår när administrationen hittar två liknande historiker och någon föreslår att man ska behålla den “mest kompletta”. En post kan innehålla den nuvarande kontakten; den andra, referenserna som används av en integration. Att välja baserat på antalet ifyllda fält löser inte den konflikten. Denna guide tillhandahåller en matris och en beslutspost för att granska fallet innan det ändras.

En post per verktyg kan vara det rätta

Skilj på samma enhet representerad i två system och två redundanta poster inom ett. Det första fallet kan behöva en lista som kopplar ihop identifierarna; det andra, en utredning om hur dubbletten uppstod. Inget av dem ger tillåtelse att radera en rad baserat på dess namn.

Definiera också vad varje post representerar: organisation, kontaktperson, kontor eller företagskonto. En person som arbetar på ett företag är inte en duplicering av det företaget. Två kontor bör inte heller slås ihop om din verksamhet behöver hantera dem separat.

Denna granskning passar in i förberedelsen av en migrering (på engelska), men fungerar också utan att byta verktyg. Resultatet kan vara att behålla två poster och förklara deras relation.

Behåll ursprunget innan du normaliserar

Arbeta med en skrivskyddad kopia. För varje rad spara system, arbetsyta, posttyp, originalidentifierare och extraktionsdatum. CRM / W1 / account / A17 identifierar något annat än BILL / W1 / account / A17: att upprepa numret bevisar inte att det är samma kund.

Behåll originalvärdena och skapa hjälpkolumner för att jämföra mellanslag, stora och små bokstäver eller kända namnvarianter. Ta inte bort suffix, avdelningar eller referenser som kan skilja entiteter. Ett tomt fält betyder “inga uppgifter”, inte “matchar ett annat tomt fält”.

Anteckna varifrån varje signal kommer. En gemensam kod har större värde om du vet vem som tilldelade den och du har kontrollerat dess korrespondens. En kod som kopierats i en felaktig import kan sprida samma fel till båda posterna. Datumet för den senaste redigeringen gör inte heller automatiskt ett värde korrekt.

En matris med tre resultat och fyra fall

Följande exempel är helt fiktivt. Alla poster tillhör utrymmet W1; koderna ORG och EV är övningsreferenser, inte skatteidentifierare eller kunddata. De beskrivna bevisen antas vara tillgängliga enbart för att visa resonemanget.

Tilldela inte påhittade konfidensprocent. “Sannolik” öppnar för en granskning: det är inte en godkänd sammanslagning. “Tvetydigt” behåller blockeringen och förklarar vad som saknas. Även när du bekräftar identitet återstår det att besluta om något behöver ändras.

Avsaknaden av order i en post bevisar inte heller att den är överflödig: det kan vara en nyligen skapad post eller representera en annan funktion. Klassificera med bevis, inte med antalet tomma fält.

Alias-kartan utför inte en sammanslagning

Anta att den ansvarige löser det första fallet: A17 och B62 representerar ORG-07, men båda verktygen behöver sina poster. Beslutet är att behålla dem och registrera deras korrespondens. I ett separat blad kan ENTITY-F07 vara din arbetsreferens:

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

Dessa kolumner är en egen mall, inte ett importformat från Frihet eller en order för en anslutning. entity_key grupperar granskade identiteter; source_id bevarar den ursprungliga referensen. Ett alias modifierar inte verktygen bara för att det finns på ett blad.

Slå inte samman personer, företag och kontor under samma nyckel. Och kombinera inte genom transitivitet utan att granska: om A liknar B och B liknar C har du ännu inte bevisat att A och C är samma sak.

Registrera ett beslut som en annan person kan granska

Kopiera denna post för varje par. Behåll det tidigare förslaget när beslutet ändras, med en ny version som ersätter det.

Granskning: R-01 / version 1
Fullständiga referenser: CRM/W1/account/A17; BILL/W1/account/B62
Bevis: EV-01; korrespondens ORG-07 bekräftad av ansvarig
Konflikt: annan ansvarig kontaktperson; gällande värde bekräftat i EV-05
Beslut: behålla båda posterna och registrera korrespondens ENTITY-F07
Ansvarig för granskning: ROLE-OPS
Åtgärd i verktygen: ingen
Återstår: granska hur kopplingen använder denna korrespondens
Ersätter: ingen tidigare granskning

Koderna är fiktiva. Vid verklig användning, referera till bevis som är tillgängliga för den som ska granska det och undvik att kopiera onödiga personuppgifter till arket. Om en ändring senare godkänns, registrera separat utförare, tidpunkt, tidigare referenser och observerat resultat. “Godkänd”, “utförd” och “verifierad” är olika tillstånd.

Denna historik kan revideras, inte en garanti för återgång. Att korrigera ett skriftligt beslut återställer inte automatiskt redan ändrade data.

Vad du ska kontrollera med leverantören innan du slår ihop

Beteendet beror på produkten och posttypen. HubSpot dokumenterar att en sammanslagning inte kan ångras och att identifierare, egenskaper och associationer följer specifika regler. Anta inte att det ID du markerade som primärt alltid överlever intakt.

Shopify varnar också att operationen inte är reversibel och exkluderar vissa profiler, som de som har eller har haft prenumerationsavtal. Dessa exempel beskriver inte beteendet hos Frihet eller din andra leverantör.

Innan någon oåterkallelig åtgärd, se till att dessa frågor har besvarats:

• Stöds denna kombination av typer och har du rätt behörigheter?
• Vilka värden bevaras, vilka kasseras och vilket ID kommer resultatet att ha?
• Vad händer med historik, relationer och externa referenser?
• Vad kommer synkroniseringen att göra: känna igen ändringen, återskapa en post eller misslyckas?
• Vilken återställning finns verkligen och vad täcker inte din kopia?

Läs integrationernas omfattning (på engelska) och kontrollera avtalet för den använda kopplingen. En läsfunktion bevisar inte att den kan föra över sammanslagningar till andra system.

Avsluta fallet genom att också kontrollera dess ursprung

Om en sammanslagning godkänns, kom först överens om hur dess effekter på anslutna system ska begränsas. Testa med syntetiska data i en kompatibel testmiljö; om en sådan inte finns, behåll blockeringen tills du har löst oklarheterna med leverantören. En isolerad export bevisar inte att du kan återställa allt.

Efter en godkänd ändring, jämför fält och referenser med vad som förväntades och granska nästa synkronisering innan du behandlar fler poster. Om resultatet är osäkert, utred innan du upprepar åtgärden.

I Frihets kundhantering finns möjligheten att exportera listan som CSV. Det kan fungera som underlag för en granskning; det förutsätter inte import av denna mall eller automatisk sammanslagning av kunder.

Avsluta med att notera varför dubbletten uppstod: manuell registrering, import eller anslutningsregel, om det finns bevis. Om du fortfarande inte vet, lämna en ansvarig och en återstående kontroll. Två bevarade poster med en tydlig relation är ett giltigt resultat; en kortare lista utan förklarbar historik är det inte.

Källor konsulterade den 14 september 2026. Granska din leverantörs gällande dokumentation innan du utför åtgärder.