Hver gründer har et regneark de helst ikke ville vist til CRM-leverandøren sin.
Arket heter sannsynligvis noe i samme gate som Pipeline_v4, Fornyelser_Q3 eller Styretall_ENDELIG. Det ligger på skrivebordet til én person, oppdateres manuelt en søndag kveld, og det er den versjonen av sannheten som ledergruppen faktisk stoler og lener seg på.
Instinktet er å behandle dette som et disiplinproblem. Teamet oppdaterer ikke CRM-systemet ordentlig, vi trenger bedre rutiner, vi må håndheve dataregistrering nøye. Dette er nesten alltid feil. Det er ingen som holder liv i et regneark bare for gøy. Når et slikt regneark eksisterer gjør det noe ingen andre systemer i selskapet gjør, og det gjør det til det mest ærlige diagnoseverktøyet du har.
Spørsmålet er altså ikke hvordan du blir kvitt det, men heller hva det forteller deg. Det finnes tre mulige svar, de har nesten ingenting til felles, og ett av dem handler egentlig ikke om CRM-et ditt i det hele tatt.
Vi begynner med det billigste: dataene ligger i CRM-et, de vil bare ikke ut
Kjør denne testen først: «Hvis regnearket ditt ble slettet i natt, kunne du bygget det opp igjen i morgen tidlig kun fra CRM-et, uten å spørre en eneste kollega?»
Er svaret ja, har du det billigste av de tre problemene. Alt du trenger ligger allerede i systemet og regnearket inneholder ingen ny informasjon i det hele tatt, bare en visuell fremstilling.
Det typiske tilfellet: du vil se månedlig gjentakende inntekt fordelt på hvem som vant kunden, med oppsagte kunder trukket ut. Hver enkelt av de opplysningene ligger i CRM-et, men rapportbyggeren gir deg avtaleverdi per selger, ikke gjentakende inntekt per selger over tid. Så du eksporterer to lister, kobler dem på kundenavn, legger til en månedskolonne og lager en pivottabell. Neste måned gjør du alt det der en gang til.
Dette tar ikke bare et par timer, det spiser en hel dag i måneden. Heldigvis er dette ikke en feil i CRM-et, bare en rapporteringsendring. Bruk en time med noen som jobber i CRM-selskapet og spør om rapporten rett og slett kan bygges. Ofte kan den det, men det er bare ingen som har spurt enda. Dette er det ene tilfellet der svaret ikke er et helt nytt CRM-system.
Når regnearket bærer det CRM-et ikke kan
Kunne du ikke bygget regnearket opp igjen fra CRM-et alene, må du se på de kolonnene CRM-et ikke har et hjem for. Dette er det vanligste problemet til selskaper som har vokst ut av et generisk CRM. Systemet kan holde en versjon av prosessen deres, men ikke hele.
Symptomene er gjenkjennelige når du først vet hva du skal se etter:
- En nedtrekksliste brukt til noe annet enn navnet sitt, fordi teamet ditt tok den i bruk til noe annet.
- Et notatfelt som gjør ekte strukturelt arbeid, fordi det ikke finnes noe annet sted å plassere det som avgjør hva som skjer videre.
- Et steg i den virkelige prosessen som ikke har noen motsvarighet i systemet, så det lever i en regnearkkolonne og i hodet til den som eier det.
- Nyansatte som trenger en person, ikke dokumentasjon, for å forstå hvordan pipelinen egentlig fungerer.
Det viser seg også i selve formen på forretningen.
«Vi har sett en rekke eksempler gjennom årene der CRM-et bare passet én spesifikk type avtale, eller bare deler av det selskapet faktisk selger, så alt det andre måtte håndteres i Excel», sier Andreas Lundmark, COO i DealJourney. «Det finnes også selskaper der visse avtaler aldri blir lagt inn i det hele tatt. Noen legger dem bare inn i regnearket for hånd ved slutten av hver måned.»
Uansett årsak er konsekvensene de samme tre hver gang. Å rette dataene for hånd tar tid du ikke burde bruke. Sporbarheten forsvinner, fordi begrunnelsen bak et tall ligger i en fil kun én person eier. Dette går direkte utover målbarheten.
Det siste er det farlige. En langsom prosess er synlig, og noen kommer til slutt til å klage på den. En trygg beslutning bygget på tre fjerdedeler av hele bildet og beslutningsgrunnlaget er ikke synlig i det hele tatt, og ingen klager, fordi alle tror på tallet.
Det finnes en enda verre versjon av alt dette, og det er når systemet ikke kan tilpasses selv om du betaler for det. Leadway, et norsk callsenter, ba den tidligere CRM-leverandøren sin om en endring i SMS-oppsettet og fikk en prislapp på 40 000 kroner. «Da var det gjort. Vi begynte å se oss om etter noe annet samme uka», sier Tønnes Klungland, daglig leder og partner i Leadway.
Testen: lagrer du informasjon CRM-et ikke har et felt for, og ingen mulighet til å opprette et? Da konfigurerer du deg ikke ut av det. Enten tilpasser verktøyet seg dere, eller så fortsetter dere å betale avgiften for et utilpasset system.
Når regnearket er der systemene avstemmes
Den tredje diagnosen ser annerledes ut. Regnearket bærer ikke informasjon CRM-et mangler. Det bærer informasjon fra fire systemer samtidig.
Tegnet er hvor kolonnene kommer fra. Avtaleverdi fra CRM-et. Leveransestatus fra prosjektverktøyet. Åpne saker fra helpdesken. Fakturert beløp fra regnskapssystemet. Noen henter hver av dem, stiller dem opp etter kundenavn, og lager den eneste oversikten som viser hva som faktisk skjer med en kunde, og det i Excel.
Denne personen er integrasjonslaget deres. Et menneske, som kobler data for hånd, etter en plan, med den feilraten du kan forvente fra et menneske som må hente ut og sortere data fra fire systemer.
I Salesforce sin syvende State of Sales-rapport, en undersøkelse blant 4 050 selgere i 22 land, blant dem Norge, Sverige og Danmark, bruker en gjennomsnittlig selger 40 % av tiden på faktisk salg. Resten av tiden går et annet sted, og en god del av den går til å sette sammen data fra mange systemer.
Dette er også den diagnosen gründere oftest forveksler med den forrige vi snakket om. Du går ut og leter etter et bedre CRM, mens CRM-et ditt kanskje er helt greit. Problemet ligger ikke inne i noe enkelt system. Det ligger i rommet mellom dem og mangel på integrasjoner.
Ingen bestemte seg for å ha fem systemer
Det har aldri vært noen som bestemte seg for å ha flere systemer. Salg trengte en pipeline, så noen valgte et CRM. Support druknet i e-post, så noen valgte en helpdesk. Leveranse trengte å holde styr på arbeidet, så noen valgte et prosjektverktøy. Økonomi trengte fakturering. Hver av dem var et fornuftig valg, tatt av en dyktig person, som løste et reelt problem på et tidspunkt da selskapet hadde større ting å bekymre seg for.
Ingenting gikk galt, og likevel finnes den samme kunden nå fem ganger, og de fem kopiene er motstridende. Selskapsnavnet er stavet på to måter. Fornyelsesdatoen i CRM-et er fra før kontrakten ble forlenget. Support vet ikke at denne kunden fornyer om tre uker. Salg vet ikke at de har fire åpne saker. Det er den virkelige kostnaden, ikke lisensavgiftene, selv om de også legger seg oppå det hele.
Dette er ikke et marginalt problem. I 2026 Database Strategies and Contact Acquisition Benchmark Survey oppgir omtrent halvparten av organisasjonene nå at de har én sannhetskilde for salgs- og markedsdata. Det er den gode nyheten. Det betyr også at den andre halvparten ikke har det. To år tidligere svarte 57 % at kundedataene deres lå i manuelle Excel-ark, ved siden av CRM-et, analyseverktøyet og markedsplattformen.
I samme Salesforce-undersøkelse sa 51 % av salgslederne som bruker AI at frakoblede systemer bremset AI-initiativene deres. Håper du at AI etter hvert skal ta noe av administrasjonen fra teamet, er fragmenterte data det som står i veien. En modell som ser en fjerdedel av kunden, gir deg svar om en fjerdedel av kunden.
Spørsmålet du bør stille om hvert system dere har
Å samle alt er et for enkelt svar. Noe separasjon kan være riktig. En bedre test er denne:
«Trenger dette systemet å vite hvem kunden er og hva de betaler?»
Er svaret ja, bør det sannsynligvis ikke være et eget system. Support trenger å vite det, fordi om en kunde betaler 200 euro i måneden eller 4 000 endrer hvordan du svarer på saken. Fornyelser trenger det. Onboarding trenger det. Fakturering trenger det åpenbart. Ja, det er ganske mye som bør snakke sammen og derav også samles i ett system.
Kodebasen deres trenger det ikke, designverktøyet gjør det ikke. En intern tavle som følger deres eget veikart gjør det ikke. De kan ligge der teamet vil ha dem.
For abonnementsbedrifter skjærer testen uvanlig skarpt, fordi alt som betyr noe kretser rundt ett objekt: abonnementet. Hva det koster, når det fornyes, hvordan det har endret seg, hvem som bruker det, om de er fornøyde. Salg, onboarding, support, fornyelser og fakturering er ikke fem emner. De er fem blikk på samme emne på ulike tidspunkt.
Når separate systemer er det riktige svaret
Det finnes tilfeller der «best of breed» faktisk vinner. Har én funksjon krav som er dype nok til at et spesialisert verktøy er merkbart bedre, og den funksjonen ikke trenger å kobles til kundekortet kontinuerlig, bør du beholde det spesialiserte verktøyet. Et supportteam som håndterer titusenvis av saker med kompleks ruting og svartidsregler får mer ut av en spesialisert helpdesk enn av en generell.
Den ærlige versjonen av konsolidering er altså ikke ett system for alt. Det er ett system for kunden, med spesialiserte verktøy rundt for arbeid som faktisk er en annen disiplin.
Det koster også noe reelt å bytte. Migrering tar tid, folk må lære seg ting på nytt, og gevinsten kommer ikke i uke én. Den som sier noe annet, selger.
Regnearket er ikke nødvendigvis hovedproblemet. Det er det mest nyttige beviset du har på hva systemene deres ikke får gjort, og dette svaret har ligget på skrivebordet til én person hele tiden.
Åpne det. Se på kolonnene. Spør hvor hver av dem kom fra.
Selvdiagnose: hvilken av dem har du?
Tre spørsmål, i denne rekkefølgen.
- Hvis regnearket forsvant i natt, kunne du bygget det opp igjen i morgen kun fra CRM-et?
Ja: du har et rapportproblem, ikke et systemproblem. - Hvis nei: bærer regnearket informasjon CRM-et ikke har felt for?
Ja: systemet kan ikke modellere prosessen deres. Enten tilpasser det seg, eller så fortsetter dere å betale. - Hvis nei: kommer kolonnene fra mer enn ett system?
Ja: et menneske gjør integrasjonen deres for hånd. Løsningen er ikke et bedre CRM, men færre steder for kunden å bo.
Her passer DealJourney inn
Dette er problemet vi bygget DealJourney rundt. Salg, abonnementer, fakturering, support og prosjektleveranse kjører i ett system, mot ett kundekort. Ikke fem kopier som stille er uenige, og ingen person i midten som kobler dataene for hånd hver måned.
Vi legger fortsatt til funksjoner etter samme prinsipp. Hver del av livssyklusen som trenger å vite hvem kunden er og hva de betaler, hører hjemme på samme sted som kunden.
Én kunde, ett system, fra første samtale til faktura. Se hvordan DealJourney fungerer.
Kilder
- Salesforce, State of Sales report, syvende utgave, 3. februar 2026. Undersøkelse blant 4 050 selgere, august til september 2025. https://www.salesforce.com/news/stories/state-of-sales-report-announcement-2026/
- Demand Gen Report, The Dawn of the Unified Data Strategy: Breaking Down Silos in 2026, med henvisning til 2026 Database Strategies and Contact Acquisition Benchmark Survey. https://www.demandgenreport.com/blog/the-dawn-of-the-unified-data-strategy-breaking-down-silos-in-2026/51565/
Benjamin Sagen
CMO hos DealJourney


