Räkna på din admin-kostnad

Tolv timmar i veckan. Det är vad en SME-VD jag pratade med häromveckan uppskattade att hen själv lägger på admin. 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. Oftast inte. 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 vi brukar göra ä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 SME-VD med kanske tjugo till femtio anställda ser det ofta ut såhär. 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. Det landar runt nio till tretton timmar i veckan beroende på 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, vi 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 dramatisk. Automatisering ger dig kanske 60 procent tidsbesparing på en uppgift. Design ger dig 100 procent och tar dessutom bort kognitiv belastning, för du behöver inte längre tänka på att uppgiften 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. Tjugo minuter sparade per vecka, 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. Återbetalningstid blir vanligtvis sex till fjorton månader på den här typen av projekt om du gör det ordentligt. Det är en siffra styrelsen förstår.

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 faktiskt ligger under huven när vi bygger den här typen av lösningar: det är sällan rocket science. En typisk stack för en SME 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.

Den vanligaste frågan vi får är om man behöver bygga eget eller köpa färdig SaaS. Svaret är som vanligt: 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 sex till tio veckors arbete, 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.

Om siffran är under 200 000 per år, lägg projektet åt sidan. Det är inte värt komplexiteten att rota i flödet. Om den ligger mellan 400 000 och en miljon, då 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.

På Kapaciti gör vi mycket av det här. Hör av dig om du sitter med ett liknande problem.