What AI agents are actually worth: 80% less manual documentation work at CCOM
CCOM AS cut manual documentation work by 80% and improved quality at the same time. The return did not come from a clever model. It came from doing it in a structured way, one workflow at a time, on a platform built to run agents in production.
There is a kind of work that never shows up in a business case, because nobody ever decided to do it. Documents arrive. Someone reads them. Someone works out what matters. Someone keeps a register up to date. Someone chases a supplier for a missing piece of paper, and then chases again two weeks later.
It is not hard work, and that is exactly why it is expensive. It absorbs good people for hours every week, it never finishes, and it gets worse as the business grows.
What one customer got out of it
CCOM AS is a Norwegian maritime services company. They have been running a team of Symbi agents across that kind of process since the spring of 2026. Their own assessment:
Symbi-built agents have reduced manual documentation work by 80%, and strengthened quality at the same time. The platform makes it straightforward to operate the agents and keep oversight of them.
CCOM AS
Read the second half again, because it is the part that decides whether the first half lasts. Cutting the effort is easy to demo. Keeping quality while you cut it, and being able to show afterwards what was done and by whom, is what makes it something you can actually run a business on.
The return comes from the structure, not the model
Plenty of companies have tried AI on this kind of work and got very little back. Usually it is the same story. Someone pastes documents into a chat tool, gets good answers, and nothing changes, because the answers live in a chat window and the register still needs updating by hand. Or a developer writes a script, it works for a month, then the format changes and nobody owns it.
The difference is not the model. It is whether the work is set up as an operation.
That means a few unglamorous things. Each job runs on a schedule or on a trigger, without anyone remembering to start it. Its output goes into the systems the business already uses, not into a new place people have to check. Somebody can see what it did last week. And when it is wrong, there is a way to correct it that does not involve rewriting anything.
Start with one job, and let it prove itself
We do not begin with a platform rollout, and we do not recommend anyone else does either.
Pick the single worst job in the process. Automate that one. Let it run in production for a few weeks while people watch it. Then look again, because the next bottleneck is usually somewhere nobody predicted, and it is far cheaper to find that out by running than by planning.
The financial logic here is simple. If the first job does not pay for itself, you have spent a few weeks, not a year, and you stop. If it does pay, you have a working piece of the process and a much better idea of what the next one is worth. Every step after that is a smaller decision made with better information.
CCOM got to a full team of agents this way, one at a time, over about five months. At no point was there a big bet to approve.
Why several agents instead of one
The most common question we get is why not build one capable agent that does everything.
The reason is cost and control, and they pull in the same direction. Different steps deserve different treatment:
- Judging whether something is relevant is a decision. It should come with a written reason and a confidence score so a person can check the thinking, not just the answer.
- Sending an email to a customer or a supplier cannot be undone. A person approves it before it goes out, every time.
- Removing duplicates from a register is mechanical. It should simply run, with nobody watching.
- Writing the audit trail involves no judgement at all. It makes no AI call, so it costs nothing per run and can go as often as you like.
Put all of that in one agent and you have to choose one setting for the lot. Either you make a person approve the mechanical work, which throws away most of the saving, or you let the irreversible work run unsupervised, which is how organisations end up not trusting the system at all.
Where that line sits is a setting, not a rule we impose. You decide which kinds of action need a person and which should simply run, and you move the line as trust builds. Plenty of steps are better off fully automatic from day one, and paying someone to approve them would be the expensive mistake.
Splitting the work means each step is only as automatic as it deserves to be. It also means that when something goes wrong, and it will, you know which job to look at.
What the Symbi app actually does for you
An agent that works in a demo and an agent that is still running in month six are different products. Almost all of that difference is operational, and it is what the Symbi app is built around.
The agents work inside your systems. They read and write your spreadsheets, your SharePoint, your helpdesk. Your data stays where it already is. There is no shared pool and nothing is pooled across customers. If you stopped using Symbi tomorrow, your register would still be sitting where it always was, up to date.
You choose what waits for a person. By default anything irreversible does: outbound messages are drafted by an agent and appear in a queue for approval, with the text there to edit before it goes, and whoever approved it is recorded. Where a step does not warrant that, you set it to run on its own. Most teams start cautious and loosen it as they see the work.
Uncertainty is visible. When an agent is not sure, it marks the item as needing human review instead of guessing. That queue is a work list, not a hidden failure.
You can change how an agent works without a developer. Instructions are edited in the app and published as a new version. Publishing runs a check first and refuses the change if something is wrong, it makes you write down what you changed and why, and it records who published it.
Every run is logged, with its cost. You can see what each agent did, why, and what it spent. That matters more than people expect at approval time, because "it saved us time" is an argument and "here is what it did, and it cost this" is evidence.
That last point is why CCOM's assessment mentions oversight in the same breath as the 80%. The saving is what you buy. The oversight is what lets you keep it.
This is not really about maritime
The nouns change from business to business. Invoices instead of order lines, contracts instead of declarations, applications instead of components. The shape is the same everywhere: important, repetitive, document-heavy work that quietly takes up a day or more of somebody's week.
If that describes something in your back office, three things carry over from a project like CCOM's:
- Start with one workflow, not a platform. Take the worst job first.
- Split the work by how much control each step needs, not by how much one model could technically handle.
- Decide early where the evidence lives. The register is what you build. The proof is what you will be asked for, and it is the easiest thing to leave until it is too late to reconstruct.
If your back office has a queue that never empties, or a register that is only as current as the last thing someone remembered to type in, it is worth a conversation. Book a 30 minute Agent Audit and we will find the one workflow most worth handing over first. No obligation, and you stay in control the whole way.
Det finnes en type arbeid som aldri dukker opp i en business case, fordi ingen noen gang bestemte seg for å gjøre det. Dokumenter kommer inn. Noen leser dem. Noen finner ut hva som er relevant. Noen holder et register oppdatert. Noen purrer på en leverandør for et papir som mangler, og purrer igjen to uker senere.
Det er ikke vanskelig arbeid, og nettopp derfor er det dyrt. Det legger beslag på dyktige folk i timevis hver uke, det blir aldri ferdig, og det vokser i takt med virksomheten.
Hva én kunde fikk ut av det
CCOM AS er et norsk maritimt tjenesteselskap. De har kjørt et team av Symbi-agenter gjennom nettopp denne typen prosess siden våren 2026. Deres egen vurdering:
Symbi-utviklede agenter har redusert manuelle dokumentasjonsprosesser med 80 % og samtidig styrket kvaliteten. Plattformen gjør det enkelt å operere og overse agentene.
CCOM AS
Les den andre halvdelen en gang til, for det er den som avgjør om den første blir stående. Å kutte innsatsen er lett å demonstrere. Å beholde kvaliteten mens dere kutter, og i ettertid kunne vise hva som ble gjort og av hvem, er det som gjør at dere kan stole på løsningen i det daglige.
Gevinsten ligger i strukturen, ikke i modellen
Mange selskaper har prøvd AI på denne typen arbeid og fått lite igjen. Som regel er historien den samme. Noen limer dokumenter inn i et chatverktøy, får gode svar, og ingenting endrer seg, fordi svarene blir liggende i et chatvindu mens registeret fortsatt må oppdateres for hånd. Eller en utvikler skriver et skript, det virker i en måned, så endrer formatet seg og ingen eier det lenger.
Forskjellen ligger ikke i modellen. Den ligger i om arbeidet er satt i system.
Det handler om noen nokså udramatiske ting. Hver jobb starter av seg selv, enten etter en fast plan eller når noe skjer, uten at noen må huske å sette den i gang. Resultatet havner i systemene virksomheten allerede bruker, ikke på et nytt sted folk må sjekke. Noen kan se hva den gjorde forrige uke. Og når den tar feil, finnes det en måte å rette det på som ikke krever at noen skriver kode på nytt.
Start med én jobb, og la den bevise seg selv
Vi starter ikke med å rulle ut en plattform, og vi råder ingen andre til å gjøre det heller.
Plukk ut den aller verste jobben i prosessen. Automatiser den. La den kjøre i produksjon i noen uker mens folk følger med. Se deretter på prosessen på nytt, for neste flaskehals ligger som regel et sted ingen hadde forutsett, og det er langt billigere å oppdage det i drift enn å planlegge seg fram til det.
Den økonomiske logikken er enkel. Hvis den første jobben ikke betaler seg, har dere brukt noen uker og ikke et år, og dere stopper. Hvis den betaler seg, sitter dere igjen med en fungerende del av prosessen og et mye bedre bilde av hva den neste er verdt. Hvert steg etter det er en mindre beslutning tatt på bedre grunnlag.
CCOM endte opp med et helt team av agenter på denne måten, én om gangen, i løpet av omtrent fem måneder. Det var aldri en stor satsing som måtte godkjennes.
Hvorfor flere agenter i stedet for én
Det vanligste spørsmålet vi får, er hvorfor vi ikke bygger én dyktig agent som gjør alt.
Svaret handler om kostnad og kontroll, og de trekker i samme retning. Ulike steg fortjener ulik behandling:
- Å vurdere om noe er relevant er en beslutning. Den bør komme med en skriftlig begrunnelse og en konfidensscore, slik at et menneske kan etterprøve resonnementet og ikke bare svaret.
- Å sende e-post til en kunde eller en leverandør kan ikke gjøres om. Her vil de fleste ha en person inn før meldingen går ut.
- Å fjerne dubletter i et register er mekanisk. Det bør bare kjøre, uten at noen følger med.
- Å skrive revisjonssporet krever ingen vurdering i det hele tatt. Det gjør ingen AI-kall, koster dermed ingenting per kjøring, og kan gå så ofte man vil.
Legger dere alt dette i én agent, må dere velge én innstilling for alt sammen. Enten lar dere et menneske godkjenne det mekaniske arbeidet, og da forsvinner mesteparten av gevinsten, eller så lar dere det irreversible kjøre uten tilsyn, og det er slik organisasjoner mister tilliten til systemet.
Hvor grensen går, bestemmer dere selv. Den er en innstilling, ikke en regel vi pålegger dere, og den kan flyttes etter hvert som tilliten bygger seg opp. Mange steg er det riktig å la gå helt av seg selv fra første dag, og å betale noen for å godkjenne dem ville vært den dyre feilen.
Å dele opp arbeidet betyr at hvert steg bare er så automatisk som det fortjener. Det betyr også at når noe går galt, og det gjør det, vet dere hvilken jobb dere skal se på.
Hva Symbi-appen faktisk gjør for dere
En agent som virker i en demo og en agent som fortsatt går etter et halvt år er to ulike produkter. Nesten hele forskjellen er operasjonell, og det er dét Symbi-appen er bygd rundt.
Agentene jobber inne i deres egne systemer. De leser og skriver i regnearkene deres, i SharePoint og i kundeserviceløsningen. Dataene blir liggende der de allerede er. Det finnes ingen felles pool, og ingenting slås sammen på tvers av kunder. Sluttet dere med Symbi i morgen, ville registeret fortsatt ligge der det alltid har ligget, oppdatert.
Dere bestemmer hva som skal vente på et menneske. Som standard gjelder det alt som ikke kan gjøres om: utgående meldinger skrives av en agent og havner i en kø for godkjenning, med teksten klar til redigering før den går, og hvem som godkjente blir registrert. Der et steg ikke trenger det, setter dere det til å gå av seg selv. De fleste starter forsiktig og løsner på det etter hvert som de ser arbeidet.
Usikkerhet er synlig. Når en agent er i tvil, merkes saken som «trenger menneskelig gjennomgang» i stedet for at agenten gjetter. Den køen er en arbeidsliste, ikke en skjult feil.
Dere kan endre hvordan en agent jobber uten en utvikler. Instruksjonene redigeres i appen og publiseres som en ny versjon. Publiseringen kjører en kontroll først og stopper endringen hvis noe er galt, den krever at dere skriver hva dere endret og hvorfor, og den registrerer hvem som publiserte.
Alt som kjøres, blir logget med kostnaden. Dere kan se hva hver agent gjorde, hvorfor, og hva den brukte. Det betyr mer enn folk tror når noe skal godkjennes, for «det sparte oss tid» er en påstand, mens «her er hva den gjorde, og dette kostet det» er dokumentasjon.
Det siste punktet er grunnen til at CCOMs vurdering nevner oversikt i samme åndedrag som de 80 prosentene. Besparelsen er det dere kjøper. Oversikten er det som gjør at dere får beholde den.
Dette handler egentlig ikke om maritim næring
Substantivene endrer seg fra virksomhet til virksomhet. Fakturaer i stedet for ordrelinjer, kontrakter i stedet for erklæringer, søknader i stedet for komponenter. Formen er den samme overalt: viktig, repetitivt, dokumenttungt arbeid som stille legger beslag på en dag eller mer av noens uke.
Passer det på noe i administrasjonen deres, er det tre ting som følger med fra et prosjekt som CCOMs:
- Start med én arbeidsflyt, ikke en plattform. Ta den verste jobben først.
- Del opp arbeidet etter hvor mye kontroll hvert steg trenger, ikke etter hvor mye én modell teknisk sett kunne håndtert.
- Bestem tidlig hvor beviset ligger. Registeret er det dere bygger. Beviset er det dere blir bedt om, og det er det letteste å utsette til det er for sent å rekonstruere.
Har administrasjonen deres en kø som aldri tømmes, eller et register som bare er like oppdatert som det siste noen husket å taste inn, er det verdt en prat. Book en Agent Audit på 30 minutter, så finner vi den ene arbeidsflyten det er mest verdt å sette bort først. Helt uforpliktende, og dere har kontrollen hele veien.