Praktikfall

Från Excel-kaos till ett skräddarsytt CRM på åtta veckor: en fallstudie

En grossist med 14 anställda drev hela sin säljpipeline i ett enda delat kalkylblad som ingen riktigt litade på. Här är exakt hur vi ersatte det — vad vi byggde, vad vi medvetet lät bli, och vad som förändrades efteråt.

Have a nice dayHave a nice day13 min läsning
Från Excel-kaos till ett skräddarsytt CRM på åtta veckor: en fallstudie

Det finns en särskild sorts kalkylblad som tyst driver ett litet företag. Det började som en enkel kundlista, och under fem eller sex år växte det till den enskilt viktigaste — och farligaste — filen i verksamheten. Alla är beroende av den. Ingen litar på den. Och när den till slut går sönder brukar den gå sönder på sämsta tänkbara dag. Det här är berättelsen om ett sådant kalkylblad, det 14 personer stora företaget som levde inuti det, och de åtta veckor det tog att få ut dem ur det.

Vi arbetar med många småföretag, och det här fallet är anonymiserat — kunden bad oss att inte använda deras namn, och siffrorna här är avrundade och illustrativa snarare än reviderade tal. Men situationen är verklig, och om du driver ett företag på ett delat kalkylblad som långsamt håller på att bli en risk, kommer du förmodligen känna igen mer av det än du skulle vilja. Poängen med att skriva ner det är inte att skryta om ett projekt. Det är att visa de faktiska besluten — inklusive de där det uppenbara svaret var fel.

Genomgående har jag försökt vara ärlig om vad som var svårt, vad vi medvetet hoppade över och varifrån det verkliga värdet kom. Spoiler: det var inte den del någon väntade sig.

Situationen: en fil, fjorton personer, noll tillit

Kunden är en regional grossist — de köper varor i parti och säljer vidare till små återförsäljare och företagskunder. Fjorton personer: en handfull i sälj, ett par i lagret, en kontorschef, de två ägarna. En sund verksamhet, stadig tillväxt, den sortens företag som är för stort för att drivas på minnet och för litet för att någonsin ha köpt ”riktig” programvara.

Hela deras säljverksamhet levde i ett enda delat kalkylblad på en molndisk. Kunder, kontakter, orderhistoriken, vem-som-är-skyldig-vad, uppföljningsanteckningar, ett färgkodningssystem som bara kontorschefen helt förstod. Det hade ungefär fyrtio kolumner och långt över tusen rader. Tre eller fyra personer hade det öppet vid varje given tidpunkt.

Symtomen kan du gissa. Två personer redigerar samma rad, den ena skriver tyst över den andra. En säljare filtrerar bladet, glömmer att rensa filtret, och nästa person får panik för att ”hälften av kunderna är borta”. Ingen visste vilket telefonnummer som var det aktuella. Den månatliga intäktsrapporten tog kontorschefen nästan en hel dag att sätta ihop, för hand, och ägarna var inte helt säkra på att de trodde på den. Filen hade återställts från en säkerhetskopia två gånger på två år efter att någon raderat något de inte borde.

Det var inte att kalkylbladet var dåligt. Det var att fjorton personer tyst arbetade runt samma dussin problem, varje dag, och hade slutat märka kostnaden.
från anteckningarna vid vår första workshop

Här är det som är viktigt: ingen klagade högt. Det är fällan med ett kalkylblad som har växt ur sig självt. Smärtan sprids tunt över alla och varje dag, så den blir aldrig en kris — den blir bara vädret. Ägarna ringde oss inte på grund av en katastrof, utan för att de hade förlorat en bra kund till en uppföljning som hade glidit dem ur händerna, och det fick dem äntligen att fråga hur många fler det varit.

Ett överfullt kalkylblad på en skärm med dussintals kolumner och krockande färgkodade celler, flera klisterlappar fastsatta på skärmkanten, en frustrerad kontorsarbetare svagt speglad i glaset
Filen som drev företaget: fyrtio kolumner, tusen rader och en färgkod som bara en person förstod.

Varför inte bara köpa ett färdigt CRM?

Det är den första frågan alla ställer, och den är den rätta. Det finns dussintals bra, billiga CRM-produkter. Vi försökte verkligen övertala kunden att välja ett — det är nästan alltid det snabbare och billigare svaret, och vi förlorar hellre ett bygge än säljer ett som ingen behöver.

Så vi gjorde testet vi alltid gör: vi tog deras faktiska process och försökte kartlägga den mot två välkända CRM-verktyg. Ungefär 80 % passade fint. Det var de sista 20 % som dödade det. Deras prissättning byggde på kundspecifika nivåer och volymrabatter som inte passade in i något standardobjekt för ”affär”. Deras orderhistorik behövde länka till ett lagersystem de inte var villiga att ersätta. Och sättet de spårade återkommande företagskunder på — som beställer om i lösa cykler snarare än som engångsförsäljningar — fanns helt enkelt inte i standardmodellen för pipeline.

Vi hade kunnat tvinga deras verksamhet att passa verktyget. Många konsulter hade gjort det. Men att be fjorton personer ändra hur de prissätter och beställer om bara för att programvaran ska bli nöjd är ett utmärkt sätt att få alla att tyst återgå till kalkylbladet inom en månad. Hela anledningen till att den gamla filen överlevde så länge är att den böjde sig efter dem. Vad som än ersatte den måste göra detsamma.

Hur de åtta veckorna faktiskt såg ut

Åtta veckor låter snabbt för ”ett skräddarsytt CRM”, och det vore det — om vi hade försökt bygga ett skräddarsytt CRM. Det gjorde vi inte. Vi byggde den smala skiva av CRM som just det här företaget behövde, och lät medvetet bli allt de inte behövde. Disciplin kring omfattningen är hela anledningen till att tidslinjen höll.

Så här bröts veckorna ungefär ner. Det var inte så här prydligt i verkligheten — veckor flyter ihop — men formen är ärlig.

  1. 1
    Vecka 1–2: Iaktta, designa inte
    Vi satt med säljteamet och kontorschefen och såg dem arbeta med kalkylbladet på riktigt. Inte ett kravmöte — faktisk observation. Det är här vi hittade sakerna ingen tänker på att nämna, som färgkoden och de tre ”tillfälliga” sidobladen som blivit permanenta.
  2. 2
    Vecka 2–3: Städa datan, bestäm vad som är sant
    Innan något byggande redde vi ut själva kalkylbladet: dubbletter av kunder, döda kontakter, tre olika sätt att skriva samma företagsnamn. Smärtsamt, otacksamt, och den enskilt största tjänst vi gjorde dem. Du kan inte migrera en röra och förvänta dig ett rent system.
  3. 3
    Vecka 3–6: Bygg kärnan, i deras händer
    Kunder, kontakter, orderhistoriken, prisnivåerna och spårningen av återbeställningar som de färdiga verktygen inte klarade. Vi visade dem en fungerande version varje vecka och lät dem ha sönder den, istället för att presentera en färdig sak på slutet.
  4. 4
    Vecka 6–7: Koppla ihop lagret och rapporterna
    En skrivskyddad länk till deras befintliga lagersystem så att orderhistoriken fylldes i av sig själv, plus den enda rapport ägarna faktiskt brydde sig om — månadsintäkt per kund — genererad på begäran istället för för hand.
  5. 5
    Vecka 8: Migrera, utbilda, kör parallellt
    Vi flyttade över den städade datan, utbildade teamet i två korta pass och höll det gamla kalkylbladet öppet och skrivskyddat i ytterligare två veckor som skyddsnät. Ingen behövde det efter de första dagarna, men att ha det där fick bytet att kännas reversibelt — vilket var det som fick folk att förbinda sig till det.
Ett litet team samlat runt en bärbar dator på ett lagerkontor, en utvecklare pekar på en ren och enkel CRM-skärm på displayen, varmt naturligt ljus, alla lutar sig fram och är engagerade
Veckovisa visa-och-ha-sönder-pass: teamet såg systemet växa och formade det, istället för att få en färdig låda i handen.

Vad vi byggde — och vad vi lät bli

Det färdiga systemet är ärligt talat inte imponerande att titta på. Det var målet. Det gör ett litet antal saker på det sätt som det här företaget faktiskt arbetar, och inget annat. Disciplinen att låta saker bli är det som höll det användbart.

Vad som kom med: en ren kund- och kontaktpost med en enda sanningskälla för telefonnummer och adresser; orderhistoriken hämtad automatiskt från lagersystemet; deras verkliga prisnivåer och volymrabatter; en enkel vy över återbeställningscykeln så att säljare kan se vem som är på tur att köpa igen; uppföljningspåminnelser så att tysta kunder inte glider undan; och den månatliga intäktsrapporten, genererad med två klick.

  • Vad vi medvetet lät bli: en marknadsföringsmodul — de gör inga e-postkampanjer, så den hade varit dödvikt.
  • En mobilapp — säljteamet jobbar från skrivbord och lagret har surfplattor; en responsiv webbvy räckte.
  • En motor för ”lead scoring” eller prognoser — modernt, men de ville ha klarhet om befintliga kunder, inte förutsägelser.
  • Några AI-funktioner alls, vid lansering — det fanns inget språkformat problem att lösa ännu, så att lägga till AI hade varit dekoration.
  • Finkorniga behörighetsnivåer — fjorton betrodda personer behöver inte fjorton behörighetsnivåer; vi höll det enkelt.

Den sista kategorin spelar lika stor roll som den första. Varje funktion du lägger till är något att underhålla, förklara och göra fel. Ett småföretag behöver inte det CRM ett företag med 500 personer behöver, och att låtsas annorlunda är hur ett åttaveckorsprojekt blir ett åttamånadersprojekt. Vi lämnade tydligt utrymme att lägga till de saknade delarna senare — men bara om ett verkligt behov dök upp, inte för att en funktionslista såg tunn ut.

Den verkligt svåra delen var inte programvaran

Om du har läst så här långt och förväntat dig att svårigheten skulle vara teknisk, här är vändningen: bygget var den lätta biten. Det svåra var kalkylbladets dragningskraft. Folk hade års muskelminne i den filen. Vissa hade privata sidoblad de aldrig nämnt. En säljare, mycket artigt, ville inte bli ”spårad” av ett system efter år av att ha arbetat utifrån sina egna anteckningar.

Vi löste inte det med programvara. Vi löste det genom att göra det nya systemet genuint snabbare för honom redan dag ett — hans kunder, hans återbeställningslista, hans uppföljningar, mindre skrivande än förut — så att det blev den enklare vägen snarare än den påtvingade. De två parallella veckorna gjorde resten. När folk kan se att det gamla sättet fortfarande finns kvar om de behöver det, slutar de klamra sig fast vid det. Ta bort det för tidigt och de gräver ner sig.

Att ersätta kalkylbladet var ett mjukvarujobb. Att ersätta vanan vid kalkylbladet var det verkliga projektet — och det är den del de flesta byggen ignorerar.
det vi sa till ägarna vid överlämningen
En ren minimal CRM-instrumentpanel på en skrivbordsskärm som visar en prydlig kundlista och ett enda intäktsdiagram, lugn och ostökig, en stängd bärbar dator och en kaffe bredvid, det kaotiska kalkylbladet är borta
Ersättningen är, med flit, tråkig: några få saker gjorda på det sätt företaget faktiskt arbetar.

Vad som förändrades efteråt

Siffror först, med den ärliga reservationen att detta är kundens egna avrundade tal från månaderna efter lansering, inte en oberoende granskning — användbara som en färdriktning, inte en garanti för din verksamhet.

VadFöre (kalkylblad)Efter (skräddarsytt CRM)
Månatlig intäktsrapport~6 timmar, för handUngefär två klick
”Vilket är det aktuella telefonnumret?”En daglig gissningEn post, som man litar på
Skräck för dataförlust / överskrivningTvå gånger på två årInga hittills
Tysta kunder som glider bortIngen visste antaletSynlig återbeställningslista
Nyanställds upplärning i systemetVeckor av tyst kunskapUngefär en eftermiddag
Före och efter, enligt kundens egna grova uppskattningar.

Rapporttiden var den rubrik ägarna brydde sig om — att få tillbaka nästan en hel dag varje månad är riktiga pengar. Men förändringen de fortsatte nämna månader senare var tystare: de slutade oroa sig för filen. Den låga bakgrundsångesten ”är datan rätt, är den på väg att gå sönder” bara försvann. Det kan man ironiskt nog inte sätta i ett kalkylblad, men det var det som fick dem att kalla det väl använda pengar.

Återbeställningslistan lönade sig på ett sätt vi inte helt förutsåg. Inom ett par månader hade säljteamet återknutit kontakten med flera företagskunder som tyst hade somnat in — precis den sortens missar som hade utlöst projektet från början. Ett återvunnet kundkonto täckte mer än bygget. Det är inget löfte om att det händer för dig; det är ett exempel på var värdet brukar gömma sig när folk faktiskt kan se sina kunder.

Har kalkylbladet som driver din verksamhet vuxit ur sig?

Om dina sälj- eller kunddata lever i en enda delad fil som alla är beroende av och ingen litar på, är det oftast dags att prata. Vi tittar först på din faktiska process och säger ärligt om du ens behöver ett skräddarsytt CRM — eller om något färdigt skulle räcka.

Se hur vi bygger CRM för små företag

Vanliga frågor

Är åtta veckor realistiskt för ett skräddarsytt CRM?
Det är det — men bara för att vi byggde ett medvetet smalt system, inte ett fullständigt företags-CRM. Tidslinjen håller när du avgränsar hårt: definiera den specifika skiva verksamheten behöver, städa datan först och lämna allt oväsentligt. Ett uppdrag på ”gör allt” är vad som förvandlar åtta veckor till åtta månader. Disciplinen ligger i vad du väljer att inte bygga.
Bör vi laga kalkylbladet istället för att ersätta det?
Ibland, ja. Om problemet mest är röra — dubbletter, ingen struktur — kan en ordentlig städning och några regler köpa dig ett år eller två. Att ersätta är vettigt när problemen är strukturella: flera personer redigerar samtidigt, ingen riktig rapportering, inget granskningsspår, data du inte kan lita på. Om ditt kalkylblad har återställts från säkerhetskopia mer än en gång är du förbi lagningsstadiet.
Vad kostar ett sånt här projekt?
Vi kan inte sätta en siffra utan att se din process — det beror helt på hur mycket du faktiskt behöver kontra hur mycket du tror att du behöver. Men den ärliga hävstången på kostnaden är omfattningen, inte timpriser. En snävt avgränsad första version som löser den verkliga smärtan är långt billigare än en spretig ”framtidssäker” plattform, och den är också den som faktiskt används. Vi börjar alltid med att försöka göra omfattningen mindre.
Hur riskabelt är det att migrera års data ut ur ett kalkylblad?
Själva migreringen är lågrisk om du gör det tråkiga jobbet först: städa och avdubblera datan, enas om vad som räknas som sanningskälla, och håll originalfilen skrivskyddad som skyddsnät. Den verkliga risken är inte att förlora data — det är att migrera motsägelser och förvirring in i ett blankt nytt system. Det är därför städningen spelar större roll än själva flytten.
Kommer teamet faktiskt använda det, eller falla tillbaka i gamla vanor?
Det är den verkliga frågan, och den handlar om utrullning, inte om programvara. Folk faller tillbaka när det nya verktyget är långsammare för dem eller när det gamla rycks bort abrupt. Vi undviker båda: vi gör det nya systemet genuint snabbare redan dag ett för dem som använder det mest, och kör det gamla parallellt tills ingen tar till det. Påtvingad användning brukar kollapsa; förtjänad användning brukar hålla.
Have a nice day
Have a nice day
Redaktionen

Have a nice day är en mjukvarustudio som hjälper små och medelstora företag att bli digitala — automatisering, AI och skräddarsydd mjukvara som fungerar i vardagen, inte bara på slides.

Relevanta tjänster