När ett CRM-projekt beskrivs som en datamigrering är risken stor att organisationen gör om samma misstag i ett nytt system. Den här case study om HubSpot-migrering visar vad som händer när flytten i stället behandlas som ett kommersiellt förändringsprojekt: processer rensas, ansvar skärps och data får ett tydligt jobb att göra.
Caset bygger på ett representativt B2B-scenario från en komplex säljorganisation med internationell tillväxtambition. Kunduppgifter och interna detaljer är anonymiserade, men problemen, prioriteringarna och arbetssättet är hämtade från den typ av CRM-arbete som avgör om en migrering blir en hävstång eller ännu ett kostsamt systembyte.
Bolaget hade vuxit snabbare än sin kommersiella infrastruktur. Marknad arbetade i ett system för kampanjer och formulär, säljavdelningen hade ett annat CRM och kundteamet förde viktiga uppgifter i kalkylark. Det fanns ingen tillförlitlig bild av vilka konton som bearbetades, vilka leads som faktiskt nådde sälj eller var i pipelinen affärer stannade.
Problemet var inte främst brist på data. Problemet var att samma företag förekom på flera ställen, med olika ägare och olika status. Ett lead kunde vara kvalificerat enligt marknad men helt osynligt i säljsystemet. En affär kunde rapporteras som vunnen utan att man visste vilket ursprungligt initiativ som skapat den. När ledningen frågade om konvertering, säljcykler eller kanalernas kvalitet blev svaret ofta en blandning av manuella uttag och kvalificerade gissningar.
Ambitionen med HubSpot var därför större än att ersätta verktyg. Bolaget ville bygga en gemensam intäktsmotor där marknad, sälj och kundteam arbetade på samma grunddata och där rapporteringen kunde användas för beslut, inte för efterarbete inför ledningsmötet.
Den första frestelsen i ett sådant läge är att flytta allt. Alla kontakter, gamla aktiviteter, historiska affärer och fält som någon en gång skapat. Det ger en snabb känsla av trygghet, men skapar sällan ett användbart CRM.
I det här caset var utgångspunkten den motsatta: bara data som stödde en framtida process skulle flyttas. Historik som behövdes för analys kunde arkiveras, men den skulle inte belasta säljarens vardag. Ett CRM är inte ett museum. Det är ett operativt system för att skapa och driva intäkter.
Projektet definierades utifrån fyra affärsfrågor, inte utifrån funktioner i plattformen. Vilka målgrupper och konton ska prioriteras? När är ett lead redo för säljkontakt? Hur ska säljprocessen spegla verkliga beslutssteg? Och vilka mått måste ledningen kunna lita på varje vecka?
Det låter grundläggande, men många migreringar startar innan dessa frågor är besvarade. Resultatet blir ett CRM med standardfält, generiska pipelinesteg och automatiseringar som ingen riktigt äger. Tekniken fungerar, men den förändrar inte arbetssättet.
Här sattes ett fåtal principer tidigt. En kontakt skulle ha en tydlig relation till rätt företag. Ett konto skulle ha en namngiven ägare när aktiv bearbetning pågick. Ett affärssteg skulle motsvara ett verkligt kommersiellt framsteg, inte en säljares magkänsla. Och varje obligatoriskt fält behövde motiveras av ett beslut, en automatisering eller en rapport.
Arbetet delades upp i tydliga faser, men projektet drevs nära verksamheten. Det är avgörande. En CRM-ansvarig kan konfigurera objekt och fält, men kan inte ensam avgöra vad som krävs för att kvalificera en affär eller hantera flera beslutsfattare i ett enterprise-case.
Teamet började med att inventera befintliga datakällor. Kontakter, företag, affärer, aktiviteter, formulärsvar, samtycken och ägarinformation granskades. Dubbletter identifierades, fält jämfördes och data klassades som nödvändig, värdefull eller överflödig.
Samtidigt kartlades den faktiska säljprocessen genom samtal med säljare, marknad och kundansvariga. Det var en viktig kontrast mot den process som fanns dokumenterad. I praktiken användes olika definitioner av kvalificerat lead, olika säljsteg för olika marknader och olika sätt att registrera nästa aktivitet. Det var dessa variationer som först behövde hanteras.
Målet var inte att tvinga alla affärer genom samma mall. En kortare transaktionell affär och en längre affär med inköp, juridik och flera beslutsfattare behöver olika struktur. Däremot behövde kärnlogiken vara gemensam: samma definitioner, samma ansvar och samma kriterier för när en affär går vidare.
I HubSpot byggdes en struktur kring företag, kontakter, affärer och tydliga livscykelsteg. Bolagets segmentering förenklades så att den gick att använda i både rapportering och dagligt arbete. I stället för ett stort antal fält för bransch, marknad, potential och status skapades en begränsad uppsättning som faktiskt kunde hållas uppdaterad.
För affärer definierades steg utifrån verifierbara händelser. Ett steg krävde exempelvis bekräftat problem, identifierad beslutsprocess eller planerat nästa möte. Det gjorde pipeline-data mer tillförlitlig och gav säljarna ett tydligare sätt att prioritera.
Lead scoring infördes inte som en svart låda. Först byggdes en enkel modell där rätt företagsprofil och rätt beteendesignaler vägde tyngre än volym. Ett lead från ett prioriterat konto med tydligt intresse för en relevant lösning hanterades annorlunda än en anonym formulärnedladdning. Modellen kunde sedan justeras när teamet hade tillräckligt med utfall att analysera.
Data flyttades i kontrollerade omgångar, inte i ett enda stort svep. Varje import validerades mot regler för format, ägarskap, dubbletter och koppling mellan kontakt och företag. Ett urval av poster kontrollerades manuellt av användare som kände kundbilden, eftersom automatiska kontroller inte fångar affärsmässig relevans.
Parallellt testades de centrala flödena: formulär till kontakt, kvalificering till sälj, skapande av affär, överlämning till kundteam och rapportering till ledning. När ett flöde brast justerades processen eller konfigurationen innan nästa datamängd flyttades.
Det tog mer tid än en ren teknisk import. Men alternativet hade varit att upptäcka felaktiga ägare, trasiga automationer och missvisande rapporter efter lansering, när förtroendet för det nya systemet redan hunnit sjunka.
Den tydligaste förbättringen var inte en enskild dashboard. Det var att kommersiella samtal blev mer konkreta. Marknad kunde se vilka aktiviteter som skapade möten med rätt konton, inte bara formulärsvar. Sälj kunde prioritera utifrån kontopotential, köpsignaler och definierade nästa steg. Ledningen kunde följa pipeline-kvalitet utan att varje vecka behöva begära manuella sammanställningar.
Arbetsflöden tog också bort friktion i handoffs. När ett lead nådde överenskomna kriterier skapades rätt uppgift, rätt ägare fick en notifiering och uppföljning kunde mätas. Det gav inte automatiskt bättre säljresultat, men det gjorde bristerna synliga. Om kvalificerade leads inte följdes upp inom avtalad tid gick det att se. Om en viss marknad gav mycket aktivitet men få affärer gick det att undersöka orsaken.
Det är en väsentlig skillnad. CRM ska inte dölja en svag process bakom snygga rapporter. Det ska göra flaskhalsarna tydliga nog att åtgärda.
För det första migrerades inte all historik. Genom att sätta regler för vad som var relevant behöll teamet ett CRM som gick att arbeta i från dag ett. För det andra byggdes pipelinen runt kundens beslutsprocess, inte kring interna önskemål om fler statusar. För det tredje fick varje automatisering en ansvarig och ett affärssyfte. Automation utan ägarskap blir snabbt osynlig och svår att förvalta.
Det finns också en viktig avvägning kring detaljnivå. För lite struktur ger dålig data. För mycket struktur får säljteamet att kringgå systemet. Rätt nivå beror på affärens komplexitet, antal marknader och hur moget arbetssättet redan är. Därför bör ett B2B-bolag börja med det som krävs för styrning och utförande, sedan förfina när användningen är etablerad.
Lanseringsdagen är inte slutpunkten. När CRM används på riktigt uppstår nya frågor: Vilka fält lämnas tomma? Var fastnar affärer? Vilka signaler förutsäger ett bra möte? Vilka segment ska få annan bearbetning? Det är där värdet av en gemensam datamodell börjar växa.
Den mest användbara nästa åtgärden är ofta enkel: välj ett fåtal mått som kopplar aktivitet till intäkt, granska dem återkommande och justera processerna när data visar ett verkligt problem. Ett bättre CRM skapas inte av fler objekt eller fler automationer. Det skapas när teamet konsekvent kan fatta bättre kommersiella beslut än veckan före.