Tolv timmar i veckan. Det är siffran jag utgår från när jag räknar på vad admin kostar en VD i ett mindre bolag, och den är ett antagande jag sätter själv, inte en mätning från ett verkligt bolag. Inte strategi, inte kundmöten, inte produktutveckling. Admin. Mejl som ska vidarebefordras till rätt person, kvitton som ska kategoriseras, statusuppdateringar som ska sammanställas inför måndagsmötet, fakturor som ska matchas mot ordrar, leverantörer som ska påminnas. Det låter banalt och det är banalt. Och det är just därför det är dyrt.
Det jag är trött på är att den här typen av timmar nästan alltid bokförs som "personalbrist". Vi behöver anställa någon till. Vi behöver en assistent. Vi behöver en till ekonom. Ibland stämmer det. Jag tror att det oftast inte gör det. Tolv timmars admin per vecka hos en VD är sällan en bemanningsfråga. Det är en designfråga. Skillnaden är inte semantisk, den avgör vad du ska räkna på och vad du ska göra åt saken.
Hur tolv timmar faktiskt ser ut
När jag ber folk beskriva sin admin-vecka blir det nästan alltid lite vagt. "Jaa, det är ju lite mejl, lite uppföljning, lite Excel". Det räcker inte. Du måste ner på flödesnivå. Det som fungerar är att gå igenom en typvecka måndag till fredag och sätta klockslag och uppgifter mot varandra. Då börjar bilden bli konkret.
För en VD i ett bolag med kanske tjugo till femtio anställda kan en sådan vecka se ut såhär. Talen är mina antaganden, inte hämtade ur något bolags tidrapporter. Måndag morgon: en timme att gå igenom helgens mejl och vidarebefordra till säljchef, ekonomi, produktion. Tisdag: fyrtio minuter att stämma av status på de tre största kundprojekten genom att läsa tre olika Slack-kanaler eller Teams-trådar och sätta ihop en mental bild. Onsdag: nittio minuter med ekonomichefen för att gå igenom likviditet, fakturapåminnelser, kundkredit. Torsdag: en timme på leverantörsmejl, en timme på rekrytering. Fredag: två timmar att skriva veckorapporten till styrelsen baserad på data du själv plockat fram från fyra system.
Räkna ihop. De fasta punkterna landar på drygt sju timmar i veckan, före allt som dyker upp mellan dem, och hur mycket det blir varierar med säsong och hur mycket som brinner. Klassiskt. Och det är bara VD:n. Säljchefen gör en parallell version, ekonomichefen en till, produktionschefen en till. Samma flöde, samma data, fyra personer som sammanställer den var för sig.
Räknemodellen som faktiskt funkar
Här blir folk ofta för försiktiga. De räknar i timpris och stannar där. En VD-timme kostar säg 800 kronor i pålagd lönekostnad, tolv timmar i veckan, fyrtiotvå arbetsveckor. Det blir ungefär 400 000 kronor per år bara på VD-tid som går till admin. Det är pengar, men det är inte hela bilden.
Hela bilden är: timpris gånger veckor gånger antal roller som rör samma underliggande flöde. Om VD, säljchef, ekonomichef och en assistent alla är inblandade i samma månadsrapportering, samma kunduppföljning, samma fakturamatchning, så ska du multiplicera. Fyra roller, snittpris pålagt 600 kronor, snitt åtta timmar i veckan på överlappande admin, fyrtiotvå veckor. Det landar på över 800 000 kronor per år. Och då har vi inte räknat alternativkostnaden, alltså vad de hade kunnat göra istället.
Min teori är att alternativkostnaden är minst lika stor som lönekostnaden, ofta större. En VD som får tillbaka tio timmar i veckan lägger dem inte på golf. Hen lägger dem på kundbesök, på rekrytering, på att tänka igenom prissättning. Det är timmar som direkt påverkar topplinjen. Sätt en försiktig multiplikator där, säg 1.5, och du är uppe i 1.2 miljoner i samlad årlig kostnad för en grej som från utsidan ser ut som "lite admin".
Automatisera bort versus designa bort
Det här är distinktionen som de flesta missar och som avgör om projektet blir lyckat eller inte. Att automatisera bort en uppgift betyder att du tar en befintlig manuell process och låter en maskin göra den istället. VD:n vidarebefordrar mejl till säljchefen, du bygger en LLM-router som läser inkommande mejl, klassificerar dem, och skickar vidare automatiskt. Klar. Tolv minuter per dag sparat. Snyggt på pappret.
Att designa bort en uppgift är något annat. Då frågar du varför uppgiften ens finns. Varför vidarebefordrar VD:n mejl överhuvudtaget? För att kunder mejlar till en allmän VD-adress eller direkt till hen. Varför gör de det? För att det är så de fick kontakt första gången. Vad händer om kunden istället hade en dedikerad kontaktyta från start, kanske ett kundportal-flöde där deras ärenden direkt routas till rätt team utan att passera VD:n? Då försvinner uppgiften helt. Inte automatiserad, borta.
Skillnaden i värde är stor. Automatisering kapar en del av tiden för en uppgift, hur mycket beror på uppgiften. Omdesign tar bort hela uppgiften och dessutom den kognitiva belastningen, för du behöver inte längre tänka på att den finns. Jag fattar fortfarande inte varför så många konsulter hoppar direkt till automatisering. Det är förmodligen för att det är lättare att sälja. "Vi automatiserar din mejl-hantering" låter konkret. "Vi designar om hur dina kunder kommer in i ditt företag" låter dyrt och flummigt. Men det är där pengarna ligger.
Var de flesta börjar fel
Den klassiska fällan är att börja med dashboarden. Någon på styrelsen säger "vi måste få bättre överblick" och plötsligt sitter man och pratar om Power BI, Looker, Metabase, vilken visualisering som ska visa vad. Det är fel ände. Dashboarden är konsumtionspunkten, inte källan till problemet.
Källan till problemet är att data är spridd över system som inte pratar med varandra och att människor manuellt sammanställer data till rapporter som ingen egentligen läser. Bygg dashboarden först och du har bara flyttat tidsåtgången. Någon måste fortfarande mata den, validera den, förklara avvikelser. Du har bytt en Excel-fil mot en Looker-rapport. Kvar blir en liten tidsvinst, kanske.
Vad du istället ska göra är att kartlägga flödet. Var uppstår datat? Vem rör vid det? Vilka beslut fattas baserat på det? När du har den kartan ser du oftast att problemet är någonstans i mitten. En försäljningsorder skapas i ett system, måste manuellt läggas in i ekonomisystemet, måste sedan stämmas av mot lagersystemet, måste rapporteras till produktion. Fyra system, tre manuella steg, ingen sanningskälla. Lös det och dashboarden blir en biprodukt, inte ett projekt.
Det här är en av få saker där jag tycker att tekniken faktiskt är den enkla biten. Att koppla ihop system med en automatiseringsplattform som n8n, eller bygga en skräddarsydd middleware med FastAPI och Postgres, eller använda LiteLLM för att routa olika typer av ärenden till olika modeller, det är hantverk. Det är gjort förut, det finns mönster. Det svåra är att förstå flödet och våga skära i det.
Vad innan-vs-efter-bilden ska visa styrelsen
När du ska sälja in det här internt eller till en styrelse är det frestande att visa en arkitekturbild med pilar och boxar. Gör inte det. Styrelsen vill se två saker: vad det kostar idag och vad det kostar efter.
Innan-bilden ska vara konkret. En tabell med roll, antal timmar per vecka på admin, pålagd lönekostnad, kostnad per år. Längst ner: total summa. Nästa rad: alternativkostnad, alltså vad timmarna hade kunnat producera om de gått till sälj eller kundvård. Den raden är estimerad och du ska säga det. Försiktig multiplikator, kanske 1.3 till 1.5. Total samlad årlig kostnad för det här flödet.
Efter-bilden är samma tabell men med två kolumner: tid kvar efter automation och tid kvar efter omdesign. Notera att den andra kolumnen är ofta noll på flera rader, för uppgiften finns inte längre. Sedan en rad för engångskostnaden för bygget och en rad för löpande drift. Återbetalningstiden räknar du fram ur dina egna tal och skriver som ett intervall du kan stå för. Det är en siffra styrelsen förstår, förutsatt att du kan visa hur du kommit fram till den.
Vad du ska undvika är att lova mer än du kan stå för. Säg inte att VD får tillbaka tolv timmar i veckan. Säg att vi tror på sex till nio och att det kommer beta sig på tolv månader. Mät efter sex månader och justera. Om du säger tolv och levererar sju är du en lögnare. Om du säger sju och levererar nio är du en hjälte. Samma resultat, väldigt olika berättelse.
Den tekniska sidan, kort
För dig som vill veta vad som ligger under huven i en sådan lösning är svaret att det sällan är särskilt avancerat. En typisk stack för ett mindre bolag som vill rensa i admin-flödet är något i stil med en orkestreringsmotor, ofta n8n eller LangGraph beroende på komplexitet, en LLM för klassificering och extraktion, gärna Claude eller en lokal Llama 3.1 70B om datat är känsligt, en vektordatabas i Postgres med pgvector för dokumentsökning, och kopplingar till de befintliga systemen via deras API:er. Inget av det är magi. Det handlar om att sätta ihop bitarna rätt och skriva prompts som inte hallucinerar.
Frågan som alltid kommer är om man behöver bygga eget eller köpa färdig SaaS. Svaret är att det beror på. Om ditt flöde är generiskt, kör SaaS. Om det innehåller domänspecifika regler, branschtermer eller integrationer mot system som ingen SaaS-leverantör stöder, då bygg. Det är oftast billigare än folk tror när man bryter ut det till ett avgränsat bygge, och du äger sedan en tillgång istället för att betala licens i evighet.
Räkna själv innan du ringer någon
Innan du tar in en konsult, gör räkneövningen själv. Sätt dig en eftermiddag, helst med ekonomichefen, och gå igenom en typvecka. Skriv ner roller, uppgifter, timmar, pålagd kostnad. Lägg på alternativkostnad med försiktig multiplikator. Du får en siffra. Den siffran är din golvkostnad för status quo.
Mina egna gränser, och de är mina och inte någon branschstandard, ser ut så här. Är siffran under 200 000 per år lägger jag projektet åt sidan, det är inte värt komplexiteten att rota i flödet. Ligger den mellan 400 000 och en miljon har du ett affärscase. Om den är över en miljon och du ändå inte gjort något åt det, då måste vi prata om varför. Oftast handlar det om att ingen i organisationen har mandat eller tid att driva en omdesign. Det är inte en teknikfråga, det är en organisationsfråga, och den måste lösas först.
Det jag vill att du tar med dig är att admin-kostnaden är räknebar och att den nästan alltid är högre än folk tror. Och att lösningen sällan är att anställa en till. Det är att stanna upp och titta på flödet, inte på personen som råkar springa det just nu.
Det här är den typen av räkneövning jag gärna sitter ner med någon och gör. Hör av dig om du sitter med ett liknande problem.