Hvorfor din CPQ trenger narrativdata før du legger til AI

En språkmodell vet hva en lastebil er. Den vet bare ikke noe om dine lastebiler. Det er her de fleste stopper opp når de prøver å legge AI på toppen av en CPQ som bare forstår varenummer, attributter og regler. Svarene ser overbevisende ut, men resonnementet er tynt. Selgeren spør hvorfor systemet anbefalte sovekabin, og får ikke noe svar.

Jeg har sett dette i utallige workshops: Med en gang modellen får tydelig kontekst for hvorfor og når hvert valg er relevant, endrer samtalen seg. Systemet slutter å gjette og begynner å gi råd. Forskjellen er ikke AI-magi. Det er data med en fortelling.

Delen som mangler i dataene dine

Regeltabeller forteller systemet hva som er *gyldig*. De sier ingenting om hvorfor et valg er *smart*, når det gjelder, eller når det er en dårlig idé. Dette gapet flytter vurderingene tilbake til e-posttråder, regneark og stilltiende kunnskap som bare noen få sitter på. Så kaller vi det et adopsjonsproblem.

For at AI-en skal kunne resonnere, trenger den ikke flere kolonner i en tabell. Den trenger maskinlesbar **hensikt** rundt hvert produktvalg:

• Beskrivelser i klartekst som forklarer formålet, ikke bare spesifikasjonene
• Fordeler og ulemper som synliggjør avveininger
• Eksempler på når et valg er bra og når det bør unngås
• Konsekvenser for kostnad, leveringstid, service eller risiko

Dette endrer spillereglene: Innhold fra produktmarkedsføring er ikke lenger bare tekst til websiden. Det er input til konfigurasjonsmodellen. Når du strukturerer dette innholdet, kan AI-en bruke det til å resonnere. Uten strukturert innhold, hallusinerer den bare selvsikkert.

Fra PIM til kunnskapsbase

De fleste PIM-systemer og prisbøker er gode på identifikatorer, hierarkier og priser. Nyttig for å sikre at alt er korrekt, men svakt for å gi veiledning. For å støtte AI-assistert salg, må PIM-systemet ditt fungere mer som en **kunnskapsbase** en motor kan hente innsikt fra.

I praksis betyr dette to ting for CPQ:

• Behold de harde reglene i konfiguratoren slik at systemet aldri kan foreslå en ugyldig kombinasjon.
• Berik hvert produktvalg med korte, konsistente felt som beskriver hensikten, slik at AI-en kan svare på spørsmål, veie avveininger og generere anbefalinger som kan forklares.

Gjør du dette riktig, blir et chat-grensesnitt mer enn en gimmick. Det blir en lærevillig salgspartner som gjenspeiler hvordan produktene dine faktisk fungerer ute hos kunden.

Slik strukturerer du data for en AI

Hold det enkelt, kort og konsistent. Målet er ikke å skrive en roman, men å skape **pålitelige signaler** som AI-en kan gjenbruke.

Felt på modulnivå

• Modulens formål – To setninger om hva denne modulen gjør.
• Hjelp til valg – Når er denne modulen viktig, og hva driver valget?

Felt på variantnivå

• Kort beskrivelse – Én til to setninger i kundens språk.
• Fordeler – Maks tre punkter. Fordeler som gir reell verdi.
• Ulemper – Maks tre punkter. Reelle avveininger selgeren må kjenne til.
• Bruk når – Én til tre konkrete scenarioer.
• Unngå når – Én til tre konkrete scenarioer.
• Konsekvenser – Notater om kostnad, leveringstid, service, kompatibilitet.

Et konkret eksempel

Modul: Førerhus

• Formål: Sjåførens arbeidsmiljø og plass for hvile eller utstyr.
• Hjelp til valg: Kjøresyklus, lovpålagte pauser, overnatting, tilgang i bystrøk.

Variant: Sovekabin

• Beskrivelse: Utvidet førerhus med integrert køye for overnatting.
• Fordeler: Støtter langtransport; høyere sjåførkomfort; reduserer hotellkostnader.
• Ulemper: Høyere vekt og pris; kan redusere manøvrerbarhet i trange byområder.
• Bruk når: Ruter over 500 km; hyppige overnattinger; langtransport.
• Unngå når: Tett bydistribusjon; lave høydebegrensninger; korte skift.
• Konsekvenser: +2 uker leveringstid; passer best med 4x2 eller 6x2; ikke tilgjengelig med lavt chassis.

To erfaringer fra prosjekter:

• Skriv for en smart selger som ikke har sett produktet ditt før. Fagterminologi er greit, men den må forklares.
• Hold beskrivelsene for hver variant under 100 ord. Mer tekst vanner ut signalet og forvirrer AI-en.

Arkitekturen som får dette til å fungere

Beskrivende data fungerer bare når de kombineres med et solid regelverk. Mønsteret vi ser fungerer best, ser slik ut:

• Eksplisitt regelverk – Dine eksisterende CPQ-regler som sikrer korrekte og forutsigbare konfigurasjoner.
• Kunnskapsbase med fortellinger – Strukturerte, beskrivende felt som er søkbare og avgrenset til salgsrelevant innhold.
• Resonneringsgrensesnitt – Chat eller guidede skjemaer som stiller oppklarende spørsmål, siterer kilder og foreslår alternativer.
• Forklarbarhet – Systemet må vise hvilke regler og beskrivelser som ligger bak en anbefaling, slik at selgeren kan forsvare tilbudet.

AI er et lag *oppå* den eksisterende logikken, ikke en erstatning for den. Uten regler får du bare flytende gjetninger. Med regler og en kompakt kunnskapsbase får du veiledning som kan forklares og som er trygg å gi til selgerne.

Gode systemer skiller mellom korrekthet og fortelling. Regler holder deg trygg. Fortellinger gir deg fart.

Hva du kan gjøre allerede neste kvartal

Du trenger ikke å bytte ut hele plattformen for å komme i gang. Det du trenger, er et tettere samarbeid mellom de som eier produktet, marked og CPQ-systemet.

• Velg ut de ti vanligste salgsløpene – modulene og variantene som går igjen i de fleste tilbud dere vinner.
• Skriv formålet for hver modul – maks to setninger.
• Berik hver variant med beskrivelse, fordeler, ulemper, bruksområder og konsekvenser.
• Dokumenter negative anbefalinger – å vite når man *ikke* skal bruke noe, er ofte den mest verdifulle veiledningen.
• Sjekk at de harde reglene er på plass – sørg for at logikken i CPQ-systemet blokkerer ugyldige kombinasjoner, uavhengig av hva AI-en foreslår.
• Sett opp en søkbar base – bruk den innebygde kunnskapstjenesten i verktøyet deres eller en enkel vektorddatabase for disse beskrivelsene.
• Lag et enkelt grensesnitt – selv en pilot med chat eller et guidet skjema for én produktlinje vil gi rask læring.
• Mål effekten – mål tiden det tar for en selger å komme frem til en forsvarlig anbefaling og et ferdig priset tilbud, både før og etter endringen.

Hvis du allerede har en CPQ, ikke riv ut alt. Legg til de beskrivende feltene i de eksisterende produktdefinisjonene, og mat dem inn i et AI-lag som kan hente ut informasjonen. Hvis du ikke har en CPQ, start med fortellingene og noen få, viktige regler, og bygg videre derfra.

Fordelen som bare vokser

Team som investerer i å strukturere kunnskapen sin på denne måten, ser to fordeler som forsterker seg over tid:

• Raskere og mer forståelige anbefalinger – færre stopp i prosessen, mindre frem og tilbake med teknisk avdeling, og enklere å begrunne valgene overfor kunden.
• Bedre prisbeslutninger – scenarioene gjør det åpenbart hvorfor et premium-valg koster mer, og hvor totalkostnad trumfer en lavere startpris.

Og ja, dette er fullt mulig å vedlikeholde. Når et produkt endres, oppdaterer du to steder: den harde regelen som sikrer korrekthet, og den korte teksten som forklarer hensikten. Systemet forblir lærevillig fordi det er designet for å bli lest av både mennesker og maskiner.

Når systemet både kan resonnere og forklare, da taper endelig regnearket.

Jeg har brukt tjue år på å se team prøve å automatisere vurderinger de aldri skrev ned. Lærdommen er enkel: Hvis du vil at AI skal være til hjelp i CPQ, må du gi den noe verdt å resonnere med. Produktdataene dine trenger en fortelling. Hvem i ditt team får ansvaret for å skrive den?