Tilbudsgivning automatiseres med AI ved at koble kundedata, produktinformation, prisregler, tidligere godkendte formuleringer og godkendelsesflows til et system, der kan udarbejde forslag til tilbud. AI bør gøre processen hurtigere og mere ensartet, men pris, leverance, forbehold og endelig afsendelse kræver menneskelig kontrol.
Tilbudsgivning kan automatiseres med AI, når kundedata, produktinformation, prisregler og godkendelsesflows kobles til et kontrolleret tilbudssystem. AI kan udarbejde udkast, finde relevante kilder og markere mangler, men pris, scope, forbehold og afsendelse bør godkendes af mennesker.
Hvad betyder automatisering af tilbudsgivning med AI?
Automatisering af tilbudsgivning med AI betyder, at kunstig intelligens hjælper med at indsamle oplysninger, fortolke kundens behov, foreslå produkter eller ydelser, udarbejde tilbudstekst, kontrollere mangler og samle et udkast til godkendelse. Det kan ske i et CRM-system, et CPQ-værktøj, et ERP-system eller en intern salgsportal.
Den afgørende pointe er, at tilbudsgivning ikke kun er tekstproduktion. Et tilbud indeholder pris, scope, leveringsforudsætninger, forbehold, betalingsvilkår, ansvar, tidsplan og ofte tekniske specifikationer. AI kan støtte mange af de trin, men den bør ikke alene afgøre, hvad virksomheden binder sig til.
En god løsning skelner mellem forslag og beslutning. AI kan foreslå en struktur, finde relevante produktdata og skrive et første udkast. En sælger, fagperson eller tilbudsansvarlig bør kontrollere, om løsningen matcher kundens behov, om prisen følger reglerne, og om vilkårene kan accepteres.
Hvilke dele af tilbudsarbejdet kan automatiseres?
AI egner sig bedst til tilbudsopgaver, hvor der findes gentagelse, dokumenterede data og tydelige regler. Det kan være at opsummere kundens henvendelse, udtrække krav fra en e-mail, foreslå relevante produkter, finde lignende tidligere tilbud, generere tekstudkast og markere manglende oplysninger.
Automatiseringen kan også bruges efter tilbuddet er sendt. AI kan sammenholde svar, ændringsønsker og vundet/tabt-data, så næste tilbud bliver mere præcist. Det gør arbejdet nært beslægtet med AI i B2B-salgsprocesser, hvor leadkvalitet, kundebehov og salgsprioritering bliver behandlet som en samlet dataproces.
| Trin | AI-bidrag | Kontrolpunkt |
|---|---|---|
| Behovsafklaring | Opsummerer kundens krav og finder uklare punkter. | Kontrollér om kunden faktisk har bekræftet behovet. |
| Produktmatch | Foreslår produkter, ydelser eller pakker ud fra katalogdata. | Kontrollér kompatibilitet, levering og begrænsninger. |
| Prisudkast | Anvender prisregler eller markerer prisgrundlag. | Godkend rabat, margin og afvigelser fra standard. |
| Tilbudstekst | Udarbejder et struktureret udkast med standardafsnit. | Kontrollér formuleringer, forbehold og bindende vilkår. |
Hvilke data skal være klar før AI bruges?
AI i tilbudsgivning kræver mere end adgang til tidligere dokumenter. De vigtigste datakilder er typisk produktkatalog, prisbog, rabatregler, lager- eller kapacitetsdata, leveringsbetingelser, standardtekster, kundedata, tidligere tilbud og registrerede årsager til, at tilbud blev vundet eller tabt.
Dataene bør være opdelt efter funktion. Produktdata skal fortælle, hvad der kan leveres. Prisdata skal fortælle, hvad det må koste. Kundedata skal fortælle, hvem tilbuddet vedrører. Standardtekster skal fortælle, hvordan virksomheden normalt formulerer sig. Hvis de datatyper blandes uden struktur, kan AI give et udkast, der lyder korrekt, men bygger på forkert grundlag.
Før du automatiserer, bør du også afgøre, hvilke data AI ikke må bruge. Gamle specialaftaler, uaktuelle priser, interne marginnoter, personfølsomme oplysninger og uafklarede klager bør ikke frit kunne indgå i et tilbudsudkast. Automatisering bliver først stabil, når datakilderne er både relevante og afgrænsede.
Hvordan bruges grounding og RAG i tilbud?
Grounding betyder, at AI-svaret bindes til konkrete kilder i stedet for kun at bygge på modellens generelle sproglige mønstre. I tilbudsgivning kan det være produktark, prislister, godkendte vilkår, tekniske datablad, branchekrav eller tidligere accepterede formuleringer. Det gør outputtet lettere at kontrollere.
Retrieval augmented generation, ofte forkortet RAG, bruges til at hente relevante dokumentudsnit, før modellen skriver svaret. Microsoft beskriver RAG i Azure AI Search som et mønster, der grounder sprogmodeloutput i proprietært indhold og samtidig kræver opmærksomhed på datakilder, adgangsstyring, relevans og governance. Det passer godt til tilbud, hvor svaret bør bygge på virksomhedens egne, aktuelle kilder.
Den praktiske værdi ligger i, at AI kan finde netop den produktbeskrivelse, servicepakke eller leveringsregel, der passer til kundens behov. Men RAG fjerner ikke risikoen for misforståelser. Modellen kan stadig vælge forkert kilde, mislæse sammenhængen eller kombinere gamle og nye oplysninger. Derfor bør tilbudsudkast vise kilder, så en medarbejder kan kontrollere dem. Det samme princip behandles bredere i grounding af AI-modeller og retrieval augmented generation.
Hvordan styres priser, rabatter og forbehold?
Pris er normalt det mest følsomme punkt i automatiseret tilbudsgivning. AI bør ikke selv opfinde priser, rabatter eller betalingsvilkår. Systemet bør i stedet hente priser fra en godkendt prisbog, anvende klare rabatregler og markere afvigelser til godkendelse.
En robust prisproces kan have faste regler for minimumsmargin, rabattrin, godkendelsesgrænser, udløbsdato, valuta, moms, levering, tillæg og betingelser. AI kan forklare, hvorfor en pris foreslås, men selve reglen bør ligge i et kontrolleret system. Hvis prisen er beregnet ud fra usikre inputs, bør tilbuddet ikke kunne sendes automatisk.
Forbehold skal også styres som data. Hvis leverance afhænger af kundens materiale, teknisk adgang, volumen, integrationer eller godkendelser, skal det stå tydeligt. AI kan foreslå relevante forbehold ud fra en tjekliste, men en ansvarlig person bør afgøre, om forbeholdet er dækkende for den konkrete leverance.
Hvordan kvalitetssikres et AI-genereret tilbud?
Kvalitetssikring bør ske før tilbuddet sendes, ikke først når kunden opdager en fejl. Et AI-genereret tilbud bør kontrolleres for fem forhold: kundens behov, produkt- eller ydelsesmatch, pris og rabat, leveringsforudsætninger samt sproglige eller faktuelle påstande.
NIST beskriver blandt andet risikoen for, at generativ AI kan producere fejlagtigt eller opdigtet indhold, selv når formuleringen virker sikker. I tilbudsgivning kan det blive dyrt, fordi en enkelt upræcis sætning kan ændre kundens forventning til funktion, omfang, leveringstid eller ansvar.
Et praktisk kvalitetstjek kan være en fast godkendelsesliste:
- Matcher tilbuddet den seneste version af kundens krav?
- Er alle priser hentet fra godkendte prisdata?
- Er rabatter og specialvilkår godkendt efter reglerne?
- Er tekniske begrænsninger, afhængigheder og leveringsforbehold tydelige?
- Er AI-genererede formuleringer renset for overdrivelser og udokumenterede løfter?
Hvordan fordeles ansvar mellem sælger, fagperson og AI?
AI bør have en tydelig rolle i tilbudsprocessen. Den kan være assistent, kontrollant eller datagenerator, men den bør ikke være den ansvarlige afsender. Ansvar bør placeres hos de personer, der kan vurdere kundebehov, kommerciel risiko, teknisk gennemførlighed og endelige vilkår.
En enkel rollefordeling kan være, at sælgeren ejer kundekonteksten, fagpersonen ejer løsningens realisme, økonomiansvarlig ejer pris- og rabatregler, og ledelsen ejer undtagelser. AI kan samle udkastet, finde uoverensstemmelser og foreslå forbedringer, men den skal ikke skjule, hvor oplysningerne kommer fra.
For større organisationer hænger dette sammen med AI-governance. Governance betyder i praksis, at det er dokumenteret, hvem der må ændre regler, hvilke systemer der må bruge hvilke data, hvordan fejl rapporteres, og hvornår et tilbud kræver ekstra godkendelse.
Hvordan håndteres kundedata og fortrolige oplysninger?
Tilbudsgivning kan indeholde følsomme forretningsoplysninger, persondata og fortrolige dokumenter. Det kan være kundens budget, kontaktpersoner, tekniske tegninger, driftsdata, interne beslutningsprocesser eller konkurrenceudsatte krav. Den type oplysninger bør ikke sendes ukritisk til et AI-værktøj.
GDPR er relevant, når tilbudsprocessen behandler personoplysninger om kontaktpersoner, beslutningstagere eller brugere. Det praktiske krav er at kende formål, adgang, opbevaring, sletning og eventuelle fravalg. Kundedata bør også holdes adskilt fra træningsdata, testdata og generelle vidensbaser, medmindre der findes et klart og dokumenteret grundlag.
Adgangskontrol er særlig vigtig ved RAG og filbaserede løsninger. OpenAI beskriver fil-/vidensbasesøgning som en mulighed for, at modeller kan hente information fra uploadede filer gennem semantisk og keyword-baseret søgning. I tilbudsgivning betyder det, at du skal styre, hvilke filer der er tilgængelige, hvem de gælder for, og om modellen kan hente dokumenter, som brugeren ikke selv burde se.
Hvordan passer AI ind i CRM, ERP og CPQ?
AI giver størst værdi, når den ikke står uden for de systemer, hvor tilbudsdata allerede findes. CRM kan indeholde kunde, kontaktperson, pipeline og samtalenoter. ERP kan indeholde priser, lager, fakturering og leveringsdata. CPQ kan styre konfiguration, pris og tilbudsregler. AI bør lægge sig omkring disse systemer som et arbejdsflow, ikke som en løs tekstgenerator.
En typisk arkitektur er, at AI læser kundens behov fra CRM, henter produkt- og prisdata fra godkendte kilder, bruger RAG til relevante dokumenter og sender et tilbudsudkast til et godkendelsesflow. Når tilbuddet er godkendt, kan systemet gemme version, kilder, prisgrundlag og afsendelsestidspunkt.
I større virksomheder er dette et eksempel på enterprise AI, hvor værdien ikke kun kommer fra modellen, men fra integrationer, adgangsstyring, datakvalitet, logning og drift. En isoleret AI-chat kan give hurtige udkast, men den kan sjældent sikre korrekt pris, aktuel kapacitet eller versionsstyring alene.
Hvordan måles effekten af automatiseret tilbudsgivning?
Effekten bør måles på både hastighed og kvalitet. Kortere svartid er værdifuldt, men ikke hvis tilbuddene bliver mindre præcise, marginen falder eller sælgere bruger mere tid på at rette fejl. Automatisering bør derfor måles på hele tilbudsprocessen, ikke kun på tid til første udkast.
Relevante målepunkter kan være tid fra lead til tilbud, andel af tilbud der kræver genberegning, fejl i pris eller scope, godkendelsestid, vundet/tabt-rate, gennemsnitlig rabat, margin, kundespørgsmål efter afsendelse og antal manuelle rettelser. Det bør også registreres, hvor ofte AI-forslag afvises og hvorfor.
AI kan hjælpe med at analysere vundet/tabt-data, men forklaringer skal behandles som hypoteser. Hvis systemet skriver, at en bestemt formulering øgede sandsynligheden for accept, kræver det sammenlignelige data og kontrol for pris, timing, kundegruppe og konkurrerende tilbud.
Hvilke fejl opstår typisk?
Den mest almindelige fejl er at automatisere teksten før datagrundlaget. Et flot tilbudsudkast er ikke meget værd, hvis prislisten er gammel, produktkataloget er uklart, eller kundens krav ikke er korrekt forstået. Derfor bør datakvalitet komme før fuld automatisering.
En anden fejl er at lade tidligere tilbud styre for meget. Historiske tilbud kan indeholde specialaftaler, gamle rabatter, forældede formuleringer eller usynlige kompromiser. AI kan genbruge mønstre fra dem, men bør ikke behandle dem som standard, medmindre de er renset og godkendt til genbrug.
En tredje fejl er at gøre godkendelsesflowet uklart. Hvis alle antager, at en anden har kontrolleret pris, scope eller vilkår, kan automatisering øge risikoen i stedet for at reducere den. Et godt system viser derfor status: hvad AI har foreslået, hvilke kilder der er brugt, hvilke regler der er anvendt, og hvem der har godkendt hvad.
Hvordan starter man sikkert i lille skala?
Den sikreste start er et afgrænset pilotforløb med lav risiko. Vælg én tilbudstype, ét produktområde og et begrænset sæt godkendte dokumenter. Lad AI udarbejde udkast, men kræv manuel kontrol før afsendelse. På den måde kan teamet måle tidsbesparelse og fejltyper uden at ændre hele salgsprocessen på én gang.
Piloten bør have klare regler for, hvad AI må og ikke må gøre. Den må for eksempel gerne opsummere kundens krav, foreslå standardafsnit og markere manglende oplysninger. Den må ikke ændre priser, give uautoriserede rabatter, tilføje nye vilkår eller sende tilbud uden godkendelse.
Efter pilotperioden bør du gennemgå både gevinster og afviste forslag. Spørg hvor AI faktisk sparede tid, hvor medarbejdere skulle rette mest, hvilke datakilder der manglede, og hvilke tilbud der krævede ekstra kontrol. Først derefter giver det mening at udvide til flere produkter, større kunder eller mere automatiserede godkendelsesflows.
Hvilke kilder ligger til grund?
Artiklen bruger Microsofts dokumentation om RAG i Azure AI Search til at underbygge afsnit om grounding, virksomhedsdata, adgangsstyring og governance. Den bruger også OpenAI-dokumentationen om file search som eksempel på, hvordan modeller kan hente information fra uploadede vidensbaser.
For risici ved generativ AI bygger artiklen på NISTs Generative AI Profile. Afsnit om kundedata og personoplysninger er holdt op mod GDPR-forordningen, mens den overordnede pointe om menneskelig kontrol og risikostyring er afstemt med EU AI Act.