Så gör du Bulk Merge av HubSpot-företag utan att förlora data

Att slå ihop företag i HubSpot innebär en direkt operativ risk. Eftersom företagssammanslagningar raderar sekundära post-ID permanent, sätter ihop aktivitetshistoriken på nytt och slår samman egenskaper, kan en ogenomtänkt sammanslagning tyst skriva över anpassade fält eller ändra primära affärskopplingar. 40 % av alla team skjuter upp städningen i sitt CRM av rädsla för att slå ihop fel data, förlora historik eller bryta kopplingar i systemet.

En säker massammanslagning kräver att du lämnar manuella parvisa granskningar och generiska CSV-exporter bakom dig och i stället fokuserar på deterministisk urvalslogik, regler för vilka fält som behålls och stegvis verifiering.

Matchning bortom exakta domäner

Inbyggd dubbletthantering bygger till stor del på exakta domänmatchningar (company.com = company.com). I praktiken ser 25 % av företagen att de inbyggda verktygen missar dubbletter på grund av små skillnader i format, skiljetecken eller stavning, och andra poster saknar domän helt. För att hitta dem krävs mer än filter som bara matchar exakt.

Matchning på domänrot

Att ta bort prefix (www.), ändelser och varianter av toppdomän (.com, .org, .co.uk) gör att matchning på domänrot kan gruppera regionala kontor och alternativa webbplatser. Då syns matchningar som inte är exakta i tid för granskning, innan någon automatisk sammanslagning körs.

Matcha på andra identifierande fält

När poster helt saknar domän kan matchningen köras mot andra viktiga fält i stället. Lägg till exakta eller ungefärliga företagsnamn, telefonnummer, organisationsnummer eller egna interna ID, så hittas även dubbletter utan domändata.

Ramverk för val av primärpost

Automatisk sammanslagning i bulk kräver tydliga resultat. Att utse primärpost slumpmässigt eller bara manuellt skapar allvarliga flaskhalsar.

En strukturerad strategi för primära poster bygger på tydlig systemlogik:

• Äldsta posten: Bevarar ursprunglig konverteringskälla, first touch-attribuering och historiska skapandedatum.
• Nyaste posten: Prioriterar konton med färsk säljaraktivitet och aktuell säljkommunikation.
• Senast uppdaterade posten: Kopplar primärstatus till poster som nyligen ändrats av integrerade verktyg eller manuell rensning.
• Mest fältdata: Väljer den post som har flest ifyllda fält, så att så lite information som möjligt går förlorad.
• Logik för anpassade fält: Låter administratörer välja vilket fält som helst på posten som kriterium för vilken post som blir primär.

Bevarade fält och konflikthantering

Dataförlust vid massammanslagningar sker fält för fält. När två poster har motstridiga värden riskerar en enda global regel för alla fält att skriva över viktig information om kontot.

Eftersom varje verksamhet hanterar data på sitt sätt beror det på sammanhanget vilka fält som ska bevaras. Hur du löser konflikter bör styras av hur teamet använder varje enskilt fält:

• Aktiva pipelinefält: Fält som kundansvarig, livscykelfas eller affärsstatus speglar pågående säljarbete. Vid konflikt ska värdet som speglar den aktiva verksamheten vinna, oavsett vilken post som är äldst.
• Beskrivande och kontextuella fält: För fält som företagsbeskrivningar, adresser eller interna anteckningar beror rätt val på innehållet. Team går igenom dem ett i taget och väljer det värde som har renare format eller mer detaljer.
• Fält från källsystemet: För basvärden där historisk konsekvens väger tyngst behåller du den primära postens värde, så att rapportering och attribution stämmer med det som redan finns.

Förhandsgranskning på fältnivå

En CSV-backup ses ofta som skyddsnätet vid massammanslagning, men kalkylblad sparar bara statiska egenskapsvärden. Innan ändringarna går ut i CRM-systemet ska en administratör kunna ställa in matchning på fältnivå och bestämma regler för den primära posten, så att vissa egenskapsvärden vinner utifrån egna kriterier. En skanning ger en förhandsgranskning på fältnivå av hur varje dubblettgrupp slås ihop. Ger en regel ett oväntat resultat justerar du matchningslogiken eller fältreglerna innan någon post uppdateras.

När reglerna på fältnivå är satta får du en snabb bekräftelse genom att testa logiken på ett urval av 50 dubblettgrupper. Granska de 50 sammanslagna posterna direkt i HubSpots gränssnitt och bekräfta att kopplade kontakter, affärer, ärenden, kommunikationshistorik och anpassade fält behållits som tänkt innan du kör resten av databasen.

Regler för sammanslagning ger förutsägbara resultat och skyddar kontots historik under stora rensningar. Matchning på domänrot i kombination med logik som bevarar egna fält ger teamet full kontroll över datan.

Vanliga frågor

Hur undviker du dubbletter av företag när kontakter använder regionala eller alternativa domäner (t.ex. .org, .com.mx, .mx)?

HubSpot skapar automatiskt en ny företagspost så snart en inkommande domänsträng inte matchar en befintlig primär domän exakt. Du kan inte stoppa det med HubSpots standardfunktioner, men du kan automatisera lösningen: använd Domain Root-matchning för att ta bort landsändelser och TLD-varianter i efterhand, tillämpa sedan reglerna för primär post och låt Auto Merge slå ihop dem till en primär post.

Hur hanterar man komplexa koncernstrukturer med separata varumärkesdomäner?

Det beror helt på hur din go-to-market är uppbyggd:

• Kontobaserad modell (ett konto): Använd matchning på domänrot för att skala bort prefix och suffix och slå ihop regionala poster till ett centralt primärkonto. Då samlas all affärshistorik, all kommunikation och alla underordnade kontakter under en global företagspost.
• Enhetsbaserad modell (separata dotterbolag): Begränsa domänmatchningen till exakta regionala varianter så att separata affärsenheter förblir egna poster, och använd över- och underordnade kopplingar i stället för att slå ihop dem.

När räcker HubSpots inbyggda dubbletthantering inte längre till?

Inbyggda verktyg stöter på strukturella gränser i fem specifika fall:

1. Anslutna webbverktyg och integrationer skapar nya poster för befintliga kunder i stället för att uppdatera de aktiva profilerna, och går förbi CRM:ets regler för exakta träffar.
2. När det finns 20, 30 eller 40+ dubbletter av ett och samma företag kräver de inbyggda verktygen tröttsam granskning post för post i stället för att lösa hela gruppen på en gång.
3. Stora databaser slår snabbt i de inbyggda verktygens visningstak (mellan 2 000 och 10 000 träffar beroende på prisnivå).
4. Inbyggda regler missar poster med andra domänändelser eller små stavfel och formatskillnader.
5. Din data bygger på anpassade fält som kräver villkorsstyrda regler så att sekundära fält inte skriver över primära.

Slå ihop dubbletter av företag i HubSpot är precis vad Dedupely är byggt för: matchning på rotdomän, egna regler för den primära posten och en förhandsgranskning på fältnivå innan en enda post ändras.

Börja gratis, koppla ditt CRM och se dina dubbletter innan du slår ihop något. Börja här.