- AI-agenter
- Startside
- Arbeidsflyt
Slik har jeg bygget AI inn i arbeidshverdagen
Bli med inn i startsiden min. Her ser du hvordan møter, AI-agenter, faste regler og min egen vurdering henger sammen.
~7 min lesetid
Hallgeir Gustavsen
Når et kundemøte er ferdig, er mye av jobben fortsatt ugjort. Noen må finne ut hva vi faktisk ble enige om, hva som står åpent, og hvem som skal gjøre hva. Så skal det inn i CRM, og kunden skal få en oppfølging som stemmer med samtalen.
Det er en av arbeidsflytene jeg har bygget AI-agenter rundt. Jeg har også laget en egen startside som samler møter, oppfølging og arbeid som trenger oppmerksomhet. Bak den ligger en systemoversikt som viser hvordan jobbene henger sammen, hva som er planlagt, og hvilke kjøringer som er registrert.
Her vil jeg vise hvordan det er satt sammen. Både det agentene gjør, det vanlig kode gjør, og det jeg fortsatt må ta stilling til selv.
Filmene har norsk fortellerstemme og undertekster.

1. Startsiden begynner med det jeg må gjøre
På startsiden kan jeg se neste møte, oppgaver som trenger handling og etterarbeid som venter. Det er en ganske praktisk inngang: Hva må jeg ta tak i nå, og hvor finner jeg grunnlaget?
Ta en oppfølging etter et møte. Et sammendrag av samtalen er nyttig, men det forteller ikke alene om kunden har fått svar. Derfor trenger jeg å skille mellom at analysen er ferdig, at et utkast er klart, og at oppfølgingen faktisk er sendt.
De statusene betyr forskjellige ting. Hvis de blandes sammen, kan en pen oversikt få meg til å tro at en oppgave er løst, mens den fortsatt venter på meg.
Startsiden viser arbeidet på tvers av verktøyene. Selve analysen og opprettelsen av utkast skjer i andre deler av systemet. Et kort på skjermen er altså en inngang til arbeidet og statusen på det.

Se filmen: Startsiden min · 24 sekunder
2. La oss følge ett møte gjennom systemet
For å forstå oppsettet er det enklest å følge én arbeidsflyt. Her er det dokumenterte løpet for etterarbeid etter et salgsmøte.
Når en transkripsjon blir tilgjengelig i HubSpot, kan en webhook eller en regelmessig sjekk fange den opp. Systemet må først ha tilstrekkelig tekst å jobbe med. En tom eller for kort transkripsjon skal gi venting, ikke en ferdig analyse basert på gjetting.
Så lager Codex analysen. Den blir en del av grunnlaget for neste steg: å formulere oppfølgingen.
I denne flyten får Claude en avgrenset kildepakke og skriver strukturert tekst. Claude gjør ikke egne oppslag eller eksterne handlinger i dette steget. Vanlig kode håndterer oppslagene, sjekker om noe allerede finnes, og oppretter et usendt Gmail-utkast og et notat i HubSpot når kontrollene tillater det.
Etter opprettelsen leser koden innhold og status tilbake. Den sjekker blant annet mottakere og om e-posten fortsatt er et utkast. Notatet kontrolleres også mot innholdet og koblingene til firma og åpne deals.
Det gir meg noe konkret å gå gjennom. Jeg må fortsatt vurdere om oppfølgingen treffer det kunden mente, om et forbehold er bevart, og om neste steg er riktig. At tekst er lagret på riktig sted, gjør den ikke automatisk riktig.

Se filmen: Etter møtet · 25 sekunder
Se filmen: Fra transkripsjon til utkast · 29 sekunder
3. Agentene har forskjellige oppgaver
I møteflyten er arbeidsdelingen tydelig: Codex analyserer, Claude formulerer fra grunnlaget, og kode håndterer oppslag og levering. Jeg går gjennom resultatet og bestemmer hva som skal sendes.
Det er også en måte å feilsøke på. Hvis et utkast mangler, trenger jeg å vite hvor det stoppet. Var transkripsjonen tilgjengelig? Ble analysen ferdig? Var mottakeren entydig? Fantes det allerede et utkast som måtte vurderes?
Da hjelper det at stegene har hvert sitt ansvar og hver sin status. Analysen kan være ferdig selv om etterarbeidet står åpent.
Systemoversikten viser også en større sammenheng: hva som starter en jobb, hvilken kjører som utfører den, hvilket prosjekt den tilhører, og hvilke systemer den berører. Kjedevisningen viser forbindelser ut fra hvilke andre jobber en prompt omtaler. Den gir meg spor å følge; jeg må fortsatt undersøke om resultatet faktisk ble levert videre.
Dette er den delen av oppsettet jeg synes er særlig interessant å vise fram. Man kan følge forbindelsene mellom oppgavene, i stedet for å måtte lese en samling med løsrevne instrukser og gjette hvordan de passer sammen.

Se filmen: Hvem gjorde hva? · 25 sekunder
4. Døgnet viser hva som skulle skje, og hva som er registrert
Når flere jobber går til ulike tider, trenger jeg en oversikt over selve driften også. Den finner jeg i visningen som heter Døgnet.
Der har hver jobb sin egen rad. En strek viser planlagt kjøring, en prikk viser en registrert kjøring, og en firkant viser en feil. Jeg kan se etter forskjellen mellom planen og det systemet har registrert.
Det er en nyttig forskjell. At en jobb står på planen, forteller ikke at den har kjørt. Og at den har kjørt, forteller ikke alene at resultatet kan brukes.
Oversikten har dessuten grenser. Historikk og kjørelogger er ulikt tilgjengelige for de forskjellige kjørerne. En manglende prikk er derfor et sted å begynne undersøkelsen, ikke et sikkert bevis på at ingenting skjedde.
Jeg vil kunne gå videre til riktig jobb og se hva den faktisk rapporterte. Tidslinjen hjelper meg å finne hvor jeg skal lete.

Se filmen: Døgnet · 24 sekunder
5. Jeg bruker regler der regler holder
Alt i oppsettet er ikke AI. Dagsplanen kan samle informasjon og prioritere med faste regler. AI kan brukes til blant annet formuleringer og rekkefølge, men er en valgfri del av det løpet.
En regel kan for eksempel fange opp relevante møter og flagg som trenger oppmerksomhet. Det er en annen oppgave enn å tolke hva en kunde mente i en samtale.
Det er nyttig å holde dette fra hverandre når noe blir feil. En modell kan trekke en dårlig slutning. En regel kan være feil satt opp. Begge kan arbeide på gamle eller ufullstendige data. Jeg trenger å kunne se hvilke kilder som ligger bak, og hvor ferske de er.
Hvis en oversikt bygger på gårsdagens informasjon, må den behandles deretter. Et pent formulert svar gjør ikke datagrunnlaget ferskere.

Se filmen: Regler og AI · 25 sekunder
6. Feil og manglende grunnlag må få være synlige
Det finnes flere mulige utfall enn ferdig og ikke ferdig. En jobb kan vente på en transkripsjon. Den kan være blokkert fordi koblingen til riktig firma er uklar. Eller den kan ha laget analysen, men stoppet før utkastet ble opprettet.
Det endrer hva jeg skal gjøre videre. Manglende grunnlag må hentes eller avklares. Et eksisterende utkast må vurderes. En teknisk feil må undersøkes før jeg eventuelt prøver igjen.
Jeg vil ikke at systemet skal dekke over disse forskjellene for å se ryddigere ut. Varsler om gamle data og jobber som trenger et blikk, hører hjemme i oversikten.
Det er også derfor jeg viser de delene her. En gjennomgang av hvordan jeg bruker AI må ha plass til det som stopper opp, og til hvordan jeg oppdager det.

Se filmen: Når en jobb stopper · 24 sekunder
7. Oppfølgingen blir fortsatt min handling
I den beskrevne møteflyten klargjør systemet et utkast. Det sender ikke oppfølgingen automatisk, endrer ikke kalenderen og flytter ikke en deal til en ny fase.
Jeg må åpne utkastet, gå gjennom det og velge hva som skal skje. Det kommersielle ansvaret forsvinner ikke fordi en modell har skrevet et forslag.
For at den gjennomgangen skal være nyttig, trenger jeg tilgang til grunnlaget og det som fortsatt er usikkert. Ellers blir godkjenningen fort bare et klikk på en tekst som ser overbevisende ut.
Dette er et prinsipp jeg tar med meg når jeg vurderer AI for bedrifter: Bestem hvilken jobb systemet skal gjøre, og hva et menneske må kunne se for å ta ansvar for neste handling.
Se filmen: Tilganger og ansvar · 26 sekunder
8. Hva kan du ta med deg fra dette?
Du trenger ikke å bygge min startside for å bruke arbeidsmåten. Begynn med en oppgave som allerede går igjen, og følg den helt fram til den faktisk er løst.
Et møte er et godt eksempel. Hvor kommer grunnlaget fra? Hva skal analyseres? Hvor skal oppfølgingen ligge? Hvem sjekker den, og hvordan vet dere at den er sendt?
Da blir det mulig å velge hvor AI kan bidra, hvor en fast regel holder, og hvor et menneske må bestemme. Du får også noe konkret å kontrollere når arbeidsflyten stopper.
For meg henger startsiden og agentene sammen gjennom nettopp disse overgangene. Jeg vil kunne se arbeidet, forstå statusen og finne neste handling. Det er det systemet er bygget rundt.
Hvis dette ligner noe dere prøver å få orden på, kan du lese mer om digital arbeidsflyt og HubSpot. Eller ta kontakt med én konkret arbeidsflyt dere vil forbedre.
Ett sted å begynne
Ta med én arbeidsflyt som trenger å bli bedre.