Dette er en lang tekst for de som vil vite detaljene om hvordan vi driver vårt selskap med AI dypt integrert i våre prosesser. Vi har brukt de siste 18 månedene på å bygge opp vår egen drift, prosess for prosess, og her går vi gjennom mye av det vi kjører i dag: hvordan konteksten er organisert, hvordan salg, økonomi, produksjon, marked og drift er satt opp, og hvor vi bevisst har latt være å automatisere. Målet er at du skal kunne kopiere det som passer deg.
Innhold
Hvorfor vi skriver dette ned
Det er lett å si at AI endrer måten man jobber på. Det er vanskeligere å vise hvordan, uten å ende i en lang demo. Vi mener bevisbyrden ligger hos den som selger, og at et byrå som anbefaler andre å endre arbeidsprosessene sine, bør ha gjort det selv først, så det har vi selvfølgelig gjort.
Vi bygger selskapet vårt så slim som mulig. Vi vil ansette færrest mulig folk og levere så mye verdi som mulig. Ikke fordi vi ikke liker folk eller at vi ikke ser verdien av å bygge organisasjon, tvert imot, men fordi et selskap som må ansette én person til for hver nye kunde, får kostnadene til å vokse like fort som inntektene. Da må prisene opp, og gode leveranser blir noe bare de største kundene har råd til. Vi vil heller ta veksten i systemer.
Når det kommer til hvilke modeller vi bruker, har vi fra start bestemt oss for å være så frie som mulig, vi er ikke låst til én AI-leverandør. Vårt oppsett er bygget slik at vi kan jobbe mot det samme systemet fra Microsoft Copilot, ChatGPT og Claude med flere.
Prosessene våre ligger som dokumenterte filer med steg, regler og prompter, ikke bare som innstillinger inne i ett verktøy, og registeret vårt har egne visninger per leverandør.
Bildeproduksjonen vår går i tillegg gjennom Google Gemini og ChatGPT, avhengig av hva vi skal produsere. Det betyr at samme arbeidsmåte kan kjøres der oppgaven faktisk hører hjemme.
Det er et bevisst valg, og det er primært to grunner til det. Kundene våre sitter på ulike plattformer, og en bedrift som allerede har Microsoft 365 i bunnen skal ikke måtte bytte hele oppsettet sitt for å få nytte av en prosess vi har laget. Landskapet endrer seg for fort til at det er lurt å bygge alt for én leverandør av AI-modeller. Verktøyet vi bruker mest i dag er ikke nødvendigvis det vi bruker mest neste år, og da vil vi at prosessene skal overleve overgangene mellom systemer.
Vi er langt fra ferdige med å sette opp våre interne prosesser, og finner stadig nye forbedringsmuligheter som vi tester så fort som mulig. Blir vel strengt tatt aldri ferdig med dette arbeidet.
Lag 1: konteksten
Den vanligste grunnen til at AI gir middelmådige svar i en bedrift, er ikke modellen. Det er at den ikke vet noe om bedriften og hva man prøver å lykkes med.
Vi løser det med én strukturert mappe på maskinen som er vår kilde til sannhet. Den inneholder selskapsinfo, operative regler, kunder, pågående oppdrag, en logg over hva som er endret og når, og en fast regel for hvor ferdige filer skal lagres. Alt AI-arbeid starter med å lese den.
Tre konkrete ting i den mappa er ekstra viktige:
Én kilde til sannhet. Samme regel skal aldri stå to steder. Står tonen i en skill, står den ikke også i prosjektinstruksjonen. Vi har en enkel arbeidsdeling: en skill sier hvordan noe gjøres, prosjektinstruksjonen sier når og hvor, og minnet holder på personlige preferanser som ikke passer noen av delene.
Datostempling på alt. Filnavn og notater får dato. Det høres banalt ut, men det er forskjellen på et arkiv og en rotete haug med materiale.
Navngitte roller. Vi har delt arbeidsstrømmene i roller med hver sitt ansvar, og hver rolle har en fil som beskriver hva den eier. Det gjør at en oppgave som starter et sted, havner riktig, i stedet for å bli et løst spørsmål i en tilfeldig samtale.
I tillegg har vi ulike former for minne som lever mellom ulike økter og verktøy. Beslutninger, begrunnelser og korreksjoner skrives ned der, slik at neste samtale ikke starter på null. Det er antakelig det enkelttiltaket som har hatt størst effekt.
Lag 2: prosessene som filer
En prompt er en instruksjon i én samtale. Den forsvinner. En skill er den samme instruksjonen skrevet ned som en fil, med steg, regler, eksempler og de fellene vi allerede har gått i.
Vi har flere titalls slike filer nå. Det viktige er ikke antallet, men hva det gjør med kvaliteten: samme oppgave løses likt uansett hvem som starter den, og forbedringer legges inn ett sted i stedet for å bo i hodet på den som gjorde det sist.
De beste filene våre har tre ting felles:
De inneholder feilene vi har gjort, ikke bare stegene. En av markedsføringsfilene våre bruker like mye plass på fallgruver i annonseverktøyet som på selve oppsettet, fordi det er der tiden går tapt.
De sier tydelig hva som ikke skal røres. Avtalefilen vår slår fast at juridisk tekst i malen aldri endres, uansett hva som skjer i samtalen.
De peker på hverandre i stedet for å kopiere. Artikkelfila vår inneholder ingen tone of voice. Den leser stemmen fra to andre filer hver gang. Endrer vi hvordan vi skriver, slår det gjennom overalt uten at noen må huske det.
Lag 3: systemene AI-en får røre
Per i dag er tretten systemer koblet direkte til AI-oppsettet vårt: Slack, Notion, Gmail, kalender, Google Drive, HubSpot, Tripletex, Harvest via eksport, Replit, Webflow, Canva, Miro og Meta.
Poenget med koblingene er at arbeidet skjer der dataene allerede ligger. Kopiering ut og inn av systemer er der feilene oppstår, og det er også der tiden går. En AI som kan lese fakturahistorikken direkte, tar en helt annen type oppgave enn en du må lime inn en tabell til.
Regelen vi har landet på er at lesetilgang gis raskt, og skrivetilgang gis per oppgave i starten, frem til vi forstår godt nok hva som skjer og ikke, så kan vi gradvis slippe opp og la modellene jobbe mer autonomt for oss.
Salg og kundeoppfølging
Tilbud
Et tilbud fra oss er et Word-dokument med forside, innholdssider og pristabell i vår visuelle profil. Den delen er ren produksjon, og den gjør AI-en fra en fil som kan malen. Vi skriver innholdet, systemet setter det opp.
Avtale fra tilbud
Går tilbudet gjennom, lages bistandsavtalen fra samme grunnlag. Her er regelen absolutt: kun det oppdragsspesifikke fylles inn, den juridiske teksten er godkjent og røres aldri. Det er et godt eksempel på at en god AI-prosess handler like mye om hva den ikke får lov til.
CRM
Vi har skrevet ned hvordan CRM-en skal brukes, ikke bare hvilke felter som finnes. Nye firmaer, kontakter, deals og oppgaver opprettes uten at noen må godkjenne på forhånd, og vi får i stedet en kort liste med lenker til gjennomgang etterpå. Endringer på eksisterende oppføringer og alt som sletter noe, krever bekreftelse først, med en tabell som viser gammel og ny verdi.
Filen inneholder også kjedelige, men verdifulle detaljer: at alle deal-navn starter med firmanavnet, og at fem felter må være avklart før en deal opprettes. Uten dem blir CRM-en et rot etter tre måneder.
Personalisert morgenbrief
Hver hverdagsmorgen får jeg en oppsummering som har lest gjennom e-post, Slack, CRM og kalender og svarer på to spørsmål: hvem venter på svar fra meg, og hvilke salgsprosesser har blitt stille. Den lager ingen filer og sender ingenting. Den er en melding, ikke en leveranse.
Den fanger opp den vanligste kommersielle feilen i et lite selskap, som ikke er dårlig salg, men oppfølging som blir liggende.
Kommandosenter
I tillegg holder vi en samlet oversikt over alt som venter på en beslutning fra meg, på tvers av kanaler. Den oppdaterer seg selv gjennom dagen og gjør det enkelt å sjekke status på oppgaver, mailer, møter og annet som krever forberedelse eller oppfølging.
Økonomi
Månedsfakturering
Ved månedsskifte hentes beløpene som skal faktureres fra en kombinasjon av prognosen vår, HubSpot og eksisterende ordre i Tripletex. Timebaserte kunder regnes ut fra faktisk førte timer ganger avtalt sats, fakturahistorikken sjekkes for å se hva som allerede er sendt eller klargjort, og det opprettes fakturautkast per kunde i regnskapssystemet.
Sperrene er det viktigste i den flyten:
Den lager kun ordre, aldri fakturaer. Et utkast kan slettes, en sendt faktura er en juridisk handling mot en kunde.
Den sjekker åpne ordre fra tidligere måneder også, fordi dobbeltfakturering er den verste feilen flyten kan gjøre.
Mangler timegrunnlaget, flagges kunden i stedet for at noe gjettes.
Avvik over en viss prosent mot forrige måned rapporteres tydelig for å gi meg muligheten til å sjekke manuelt.
Jeg får en oppsummering med beløp og lenker, og fakturerer selv etter at jeg har godkjent at ting stemmer.
Prognose
Prognosearket vårt ligger i Excel, og der er jeg gammeldags. Det er koblet mot faktiske tall fra regnskapet i Tripletex, i stedet for å være et estimat som forfaller. Det er ikke veldig fancy, men det funker.
Produksjon og leveranse
Dokumentstandard som kode
Vi hadde et klassisk problem: fargene og typografien vår lå kopiert inn i hver eneste dokumentmal, og en endring måtte gjøres fem steder.
Nå er dokumentstandarden et lite kodebibliotek som de andre malene bygger på. Tilbud, stillingsutlysninger og rapporter henter palett, typografi og tabelloppsett derfra i stedet for å ha hver sin kopi. Samme prinsipp som med tone of voice: én kilde, ett sted å endre.
Presentasjoner og illustrasjoner
Presentasjoner lages i vår egen visuelle identitet fra en fil som kan designreglene. Illustrasjonene til dem, og til artikler og innlegg, genereres i en fast merkevare-stil med et eget bildeoppsett, slik at det vi lager i mars ser ut som det vi lager i november.
Kursbevis
Når vi leverer kurs, produseres kursbevis som PDF med unik bevis-ID, verifikasjonskode og et felles register, slik at ekthet kan kontrolleres i ettertid. Det er bygget fordi dokumentasjon på AI-kompetanse er i ferd med å bli et krav etter EU AI Act.
Arkivering
Ferdige kundedokumenter skal ende i riktig mappe i prosjektverktøyet vårt Notion, under riktig kunde, med samme format for navngivning hver gang. Den prosessen har én konkret regel: den spør alltid før den laster opp noe, og laster aldri opp uten bekreftelse. Det er en bevisst brems, fordi feilplasserte kundedokumenter er mye verre enn mangel på dokumentasjon.
Marked og innhold
Skriving
Vi har skilt måten vi skriver på i tre filer: merkevarestemmen for offentlig innhold, en personlig skrivestil for det som sendes fra en person, og en artikkelfil som styrer struktur, SEO og publisering.
Den siste inneholder med vilje ingen tone of voice. Den leser de to andre hver gang. Denne artikkelen er skrevet gjennom det oppsettet.
Annonsering
For LinkedIn har vi en fil som bygger hele annonsesettet: riktig kampanjegruppe, riktig målgruppe, riktig format, budsjett som livstidsbudsjett og ikke daglig, og en liste over fellene i grensesnittet. Den kjenner også hva som har fungert i vår egen konto tidligere. Kort oppsummert: konkrete arbeidseksempler med et standpunkt gjør det klart best, mens innhold som først og fremst er markedsføring, leses som markedsføring.
For Meta har vi et tilsvarende oppsett for en fast annonsekunde, der alt som er likt mellom kampanjer er kodet fast: struktur, navngiving, plasseringer, sporing og logging.
Begge bygger alltid kampanjen som utkast eller pauset. Ingen annonse går live uten at et menneske skrur den på.
Analyse
Annonseresultater analyseres etter en fast struktur og lagres som rapport på riktig sted, med en kort oppsummering øverst. Det viktige der er ikke analysen i seg selv, men at den havner samme sted hver gang, slik at forrige periode alltid er lett å finne når neste skal vurderes.
Medieovervåking
Vi har en lyttepost som fanger opp relevante saker i norske medier, vurderer relevans og legger dem i en database med forslag til vinkling. Formålet er å kunne svare raskt når noe skjer i vår bransje, i stedet for å oppdage det tre uker senere.
Nettsiden
Nettsiden vår er bygget slik at vi kan endre den selv, samme dag. Artiklene ligger i en database, og vi holder på med et publiserings-API slik at en ferdig artikkel kan legges ut uten å åpne utviklingsverktøyet. Flyten er allerede bestemt: alltid kladd, alltid forhåndsvisning, alltid en bekreftelse fra et menneske før noe går live.
Drift av det vi har bygget
Når man bygger mange små løsninger, oppstår et nytt problem: å vite at de fortsatt virker.
Daglig sjekkes alle løsninger i produksjon for oppetid og responstid, og statusen oppdateres i en driftslogg. Er alt grønt, sier den ingenting. Er noe gult eller rødt, kommer én samlet melding med hva som er nede og hva det betyr for kunden. Sjekken tar høyde for at en tjeneste kan være treg første gang den vekkes, og varsler ikke før den har feilet flere ganger på rad. Falske alarmer er den raskeste veien til at ingen leser varslene.
Ukentlig går en grundigere gjennomgang over det samme: er noe endret uten å være publisert, ligger det gammel kode med sårbare avhengigheter, finnes det løsninger som burde vært ryddet bort, og hva er faktisk gjort på løpende avtaler denne uka. Den ender i en rapport med en kort oppsummering, og bare oppsummeringen deles internt.
Den viktigste regelen i begge: diagnose ja, inngrep nei. Ingenting endres, oppdateres eller avpubliseres automatisk. Det foreslås i rapporten som jeg tar stilling til.
Systemkapitalen
Alt over hadde vært verdiløst hvis det bare fantes på min maskin.
Derfor har vi en database i Notion der hver AI-prosess ligger som en rad: hva den gjør, hvilke steg den består av, hvilken prompt som brukes, hvilke verktøy den krever, hvilken versjon den er på, og selve fila til nedlasting. Den dekker alle leverandører vi bruker, ikke bare én, fordi ingen av oss tror at valget vi tok i fjor er valget vi tar neste år.
Vi har for eksempel også delte skills i Claude, men fordi vi jobber på tvers av systemer har vi landet på at Notion er et godt mellomledd for switching mellom verktøy.
Vi holder også en oppdatert oversikt over hvilke verktøy vi bruker til hva, og går gjennom den jevnlig. Ikke fordi listen er interessant i seg selv, men fordi den gjør det mulig å svare raskt på det spørsmålet vi får oftest: hva slags verktøy skal jeg egentlig bruke til dette?
Hva vi bevisst ikke gjør
Dette er kanskje den viktigste seksjonen, og den vi bruker mest tid på internt.
Ingenting som ikke kan angres, skjer uten et menneske. Penger ut, noe sendt til kunde, noe publisert offentlig. Fakturaen blir en ordre, annonsen blir et utkast, artikkelen blir en kladd. Det er det som gjør at vi tør å la systemene gjøre mye.
Kundedata behandles ikke løst. Vi kjører ikke kundens data gjennom systemer vi ikke har kontroll på, og vi deler ikke kundenavn, tall eller resultater fra oppdrag uten at kunden har sagt ja.
Vi lar ikke systemet gjette. Mangler grunnlaget, skal det flagges, ikke fylles ut med noe som ser riktig ut. Et tall som er nesten riktig, er farligere enn et tomt felt.
Vi automatiserer ikke noe vi ikke har gjort manuelt mange nok ganger. Du vet ikke hvor unntakene ligger før du har møtt dem.
Vi bruker det ikke til å erstatte skjønn. Prising, rådgivning, vanskelige samtaler og vurderingen av om noe er godt nok, gjøres av mennesker. AI-modellene lager underlaget som vi godkjenner.
Dette fungerer, og dette går galt
✅ Dette fungerer godt:
Start med oppgaven som gjentar seg mest, ikke den mest imponerende. Fakturering og tilbud er kjedelige og perfekte.
Skriv prosessen som en fil, ikke som en prompt. Da kan den forbedres, versjoneres og deles. Tips: la AI skrive filen for deg.
Ta med fellene, ikke bare stegene. Det er der verdien ligger etter gang nummer tre.
La systemet stoppe ett skritt før handling. Det senker terskelen for å tørre.
Koble AI-en til systemene der dataene ligger. Kopiering er der feilene skjer.
Én kilde til sannhet. Samme regel skal aldri stå to steder.
Bygg overvåking samtidig som du bygger løsningen. Ellers oppdager kunden nedetiden før deg.
Dokumentér ting samme dag. Prosessen du ikke skrev ned, finnes ikke om tre måneder.
❌ Vanlige feil å unngå:
Å starte med det mest synlige. Det som imponerer i en demo, er sjelden det som sparer tid.
Å la systemet gjette når grunnlaget mangler.
Å bygge på tall du ikke har verifisert. Ett feil beløp koster mer tillit enn all tiden du sparte.
Å gi skrivetilgang uten et tak. Lesetilgang kan gis raskt, skrivetilgang skal ha en grense.
Å samle alt i én stor prosess. Små, tydelige prosesser er lettere å reparere.
Å tro at det er ferdig. Vi rydder fortsatt hver måned.
Norsk kontekst
Norske små og mellomstore bedrifter har sjelden en egen AI-avdeling. De har en daglig leder som allerede jobber for mye, en markedsansvarlig som gjør fire jobber, og en økonomifunksjon som er kjøpt inn. Spørsmålet er ikke hva som er teknisk mulig, men hva dere klarer å innføre uten å stoppe driften.
Tre ting er verdt å ta med seg:
Systemene finnes allerede på norsk. Vårt eget oppsett bruker norske regnskaps- og timeføringssystemer, ikke amerikanske verktøy vi har måttet tilpasse. Det er en større fordel enn folk tror, fordi integrasjonen mot det som allerede er sannheten i selskapet er halve jobben.
Personvern handler om hvor grensen går. Kravet om at virksomheten selv skal ha oversikt over hva som behandles og hvorfor, er lettere å etterleve når hvert steg ender i noe et menneske ser på. Og ny regulering, som EU AI Act, gjør at dokumentasjon på kompetanse og prosess er noe man bør bygge inn nå, ikke etterpå.
Start smått nok til at det kommer i drift. Et lite verktøy som brukes hver uke slår et stort som aldri lanseres. En av de første prosessene vi satte opp var å lage tilbud raskere, ikke fordi det var visjonært, men fordi vi lager mange tilbud.
Vanlige spørsmål om AI-prosesser internt
Hvor lang tid tar det å bygge et slikt oppsett?
Den første nyttige prosessen kan stå ferdig på noen dager hvis den er avgrenset nok. Et helt oppsett med flere lag tar måneder, og blir aldri helt ferdig. Vi anbefaler å måle på hvor mange oppgaver som faktisk gjøres på den nye måten, ikke på hvor mye som er bygget.
Hva er forskjellen på en prompt og en skill?
En prompt er en instruksjon i én samtale. En skill er den samme instruksjonen skrevet ned som en fil, med steg, regler og kjente feller, som kan gjenbrukes og forbedres av flere. Overgangen mellom de to er der AI slutter å være et personlig triks og blir en arbeidsprosess.
Er det trygt å la AI røre regnskap og CRM?
Det avhenger av hvor grensen går. Hos oss oppretter AI-en fakturautkast, men fakturerer og sender aldri selv. I CRM-en kan den opprette nye oppføringer, men ikke endre eller slette uten bekreftelse. Med de grensene er verste utfall noe som må ryddes, ikke noe som må rettes opp mot en kunde.
Trenger man utviklere?
Ikke for de første stegene. Prosessene er tekstfiler, og koblingene til e-post, chat, prosjektverktøy og regnskap er ferdige integrasjoner. Skal dere bygge egne løsninger på toppen, som en kundeportal eller en nettside dere styrer selv, trengs mer teknisk hjelp.
Er oppsettet bundet til én AI-leverandør?
Nei. Vi kan jobbe mot det samme systemet fra Microsoft Copilot, ChatGPT og Claude, fordi prosessene ligger som dokumenterte filer og ikke som innstillinger inne i ett verktøy. Registeret vårt har egne visninger per leverandør, og bildeproduksjonen går gjennom Google Gemini eller ChatGPT, avhengig av hva vi produserer. Det gjør at en bedrift som allerede har for eksempel Microsoft 365 i bunnen kan bruke samme arbeidsmåte som vi har laget uten å bytte plattform.
Hva skjer når verktøyene endrer seg?
De endrer seg hele tiden, og det er nettopp derfor prosessene ligger i filer og ikke i hodene våre. Endres noe, oppdaterer vi alt på ett sted. Det er også grunnen til at vi holder en oversikt over hvilke verktøy vi bruker til hva, og går gjennom dette jevnlig.
Hvordan unngår dere at kundedata havner feil?
Ved at det er en regel, ikke en vurdering hver gang. Kundedokumenter arkiveres etter fast mønster og aldri uten bekreftelse, kundedata kjøres ikke gjennom systemer vi ikke kontrollerer, og publisering av noe som gjelder en kunde krever at kunden har sagt ja.
Oppsummering
Oppsettet vårt består av tre lag: konteksten selskapet lever i, prosessene skrevet som filer, og systemene AI-en får lov til å røre.
Prosessene dekker salg, økonomi, produksjon, marked, drift og dokumentasjon av oss selv.
Den bærende regelen er at ingenting som ikke kan angres, skjer uten et menneske.
Grensene er like viktige som mulighetene: juridisk tekst røres aldri, kundedata behandles ikke løst, og systemet skal flagge i stedet for å gjette.
Ingen prosess får leve kun i en samtale. Den skal alltid ligge skriftlig, versjonert og tilgjengelig for hele teamet.
Dette er en retning, ikke en ferdig tilstand. Vi finner fortsatt manuelle prosesser hos oss selv hver måned.
Vil du vite mer om hvordan dette kan fungere for din bedrift så er vi klare for å diskutere vår beste praksis med deg.
