Gå til hovedinnhold

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 ...
Legg inn en kommentar

KI vil ikke fikse din CPQ. Det vil derimot denne hybridtilnærmingen.

AI Won't Fix Your CPQ. This Hybrid Approach Will.

AI i CPQ – fra teori til en løsning som fungerer

Dette kurset er for deg som jobber med CPQ, produkt eller salg og vil se hvordan AI kan brukes i produktkonfigurasjon – uten at det går på bekostning av korrekte data, kontroll eller investeringene dere allerede har gjort.

I stedet for å snakke om verktøy eller vage fremtidsløfter, viser vi en praktisk metode for å utvide dagens CPQ-system med AI. Nøkkelen er å skille tydelig mellom kontekst for beslutninger og regler for korrekthet. Dette skillet gjør at AI kan øke hastigheten og brukervennligheten, mens den eksisterende CPQ-logikken fortsatt garanterer gyldige konfigurasjoner og priser.

Formatet er bevisst kompakt – to halve dager – for å sikre fokus og fremdrift. Deltakerne jobber først med et konkret eksempel, før de bruker metoden på en liten del av sitt eget produkt. Målet er ikke en teoretisk demo, men et fungerende resultat som dere kan teste og vurdere internt.

Hva dette kurset er:

  • En strukturert innføring i AI-assistert logikk for CPQ
  • En praktisk øvelse i å hente inn og validere produktlogikk
  • En pragmatisk måte å utforske AI på, uten å måtte bytte ut dagens systemer

Hva dette kurset ikke er:

  • Et prosjekt for å erstatte CPQ-systemet
  • Et generisk kurs i AI eller «prompting»
  • Et teoretisk løp uten konkrete resultater

Etter lunsj på dag to vil deltakerne ha en felles forståelse for hvordan AI kan tas i bruk på en trygg måte i CPQ. Dere sitter også igjen med et fungerende og etterprøvbart eksempel basert på deres eget produkt.

Agenda for kurset (2 halve dager)

Kurset går over to fokuserte økter: ettermiddag dag 1 og formiddag dag 2, og vi avslutter med lunsj den siste dagen. Hele opplegget er praktisk, med korte moduler og pauser for å holde energien oppe.

Dag 1 — Ettermiddag (12:00–17:00)

  • 12:00–12:30 | Lunsj (valgfritt)
  • 12:30–12:50 | Introduksjon
    • Hvorfor AI og logikk er viktig for CPQ
    • Verktøy, arbeidsmodell og mål for de to dagene
  • 12:50–13:20 | Modul 2: Lastebil-eksempel (referanse-case)
    • Hva en språkmodell kan (og ikke kan) gjøre som konfigurator
    • Hvorfor absolutte regler er nødvendig for korrekthet og kontroll
  • 13:20–13:30 | Pause
  • 13:30–13:50 | Diskusjon: Hvor kan AI gi verdi i deres CPQ?
    • Kartlegg prioriteringer: hastighet, korrekthet, salgsstøtte, opplæring, support
    • Definer et realistisk produktområde vi skal jobbe med på dag 2
  • 13:50–14:20 | Modul 3: Legge inn et nytt produkt
    • Praktisk øvelse: hente inn produktdata og bygge prompts
    • Skrive effektive produktbeskrivelser; introdusere moduler og varianter
  • 14:20–14:30 | Pause
  • 14:30–15:10 | Modul 4: Justering av logikken
    • Praktisk finjustering av logikk og forklaringer
    • Teste dialogen med assistenten og forbedre output
  • 15:10–15:20 | Pause
  • 15:20–16:00 | Modul 5: Ende-til-ende-testing (tilbudsflyt)
    • Gjennomgang av scenarioer og diskusjon
    • Finne svakheter og definere hva «korrekt og etterprøvbart» betyr for dere
  • 16:00–16:30 | Modul 6: Oppsummering og refleksjon
    • Hva har vi lært, hvilke beslutninger er tatt og veien videre for dag 2
  • 16:30–17:00 | Briefing for utfordringen på dag 2
    • Repetisjon av metoden: Kontekst vs. Regler
    • Forklaring av oppgaven, suksesskriterier og klargjorte data
    • Deltakerne deles inn i team på to

Dag 2 — Formiddag (oppgavebasert, 09:00–12:30)

  • 09:00–11:00 | Team-oppgave: bygg og valider
    • Hvert team jobber praktisk med et klargjort produkt-datasett
    • Definere kontekst for resonnering (avveininger, scenarioer, forklaringer)
    • Implementere et lite sett med absolutte regler for korrekthet
    • Teste konfigurasjoner for å sikre etterprøvbarhet og gyldige resultater
  • 11:00–11:10 | Kort pause
  • 11:10–11:50 | Presentasjoner fra teamene
    • Hvert team presenterer sin løsning for gruppen
    • Gjennomgang av logikk, regler og endelig konfigurasjon
    • Felles diskusjon om forskjeller, innsikt og valg av modell
  • 11:50–12:00 | Oppsummering og avslutning
    • Hva lærte vi av oppgaven?
    • Diskusjon: hvordan kan dette brukes i deres reelle CPQ-miljø?
    • Neste steg og videre oppfølging
  • 12:00–12:30 | Lunsj
Etiketter:

Kommentarer

Legg inn en kommentar

Populære innlegg fra denne bloggen

Indirekte salg uten kaos: Slik fungerer CPQ-styring

«Partnerne våre trenger mer frihet.» «Jus-avdelingen krever strengere kontroll.» «Økonomi vil ha bedre innsyn.» Du har hørt alle tre i samme uka. Det har jeg også. Fristelsen er å kaste flere rettigheter på problemet og håpe det løser seg. Det er da de stille feilene begynner å hope seg opp. Jeg ser et mønster i partnerprogrammer: Den første partneren får det samme oppsettet som det interne salgsteamet. Den andre får noen justeringer. Når du har fem partnere, har du tre måter å gi rabatt på og fire ulike godkjenningsløp. Alt er halvveis dokumentert. Alle kan teknisk sett lage et tilbud. Ingen kan forklare hvorfor det siste ble godkjent. Frihet uten rammer er bare en raskere måte å ødelegge tillit på. Dette handler ikke om partneradministrasjon. Det er et problem med styring og struktur i CPQ-systemet – det vi kaller governance. Former du eierskap, innsyn og handlinger på en god måte, slutter kanalsalg å være en politisk kamp og blir et kontrollert system. Du bruker samme CPQ-modell, m...
Legg inn en kommentar
Les mer

Hva er en salgskonfigurator? (Og hvorfor det ikke bare er et tilbudsverktøy)

I alle bedrifter som selger komplekst utstyr, finnes det en «Sara». Hun kan produktet inn og ut. Hun kan gjøre et rotete kundebehov om til en ren, byggbar løsning mens andre fortsatt åpner regneark. Hun er en helt. Men hun er også en flaskehals. Jeg husker en global utrulling der hvert eneste store tilbud måtte innom én spesialist for godkjenning. Avtaler ble satt på vent. Godkjenninger hopet seg opp. Verktøyene var det ingenting i veien med. Trafikkmønsteret, derimot, var problemet. Når veksten avhenger av hodet til én person, har du ikke en salgsprosess. Du har en flaskehals med et navn. Vi trenger ikke en større kalkulator. Vi trenger en oversetter. Mange tror løsningen er et stort CPQ-prosjekt som koder ned alle tenkelige regler. Det høres trygt ut, men ender vanligvis opp med å bli tregt, dyrt og rigid. Du bruker måneder på å modellere unntak, bare for å oppdage at selgerne allerede har funnet opp nye. Det virkelige problemet er ikke regnestykket bak tilbudet. Det er oversettelse...
Legg inn en kommentar
Les mer

Tillit skalerer ikke med mindre du designer din CPQ for det

Den beste tekniske selgeren din har nettopp brukt ti timer på å bygge bunnsolid tillit hos en kunde. Behovene er avklart. Kompromissene er smarte. Alle nikker. Så kommer tilbudet: et 12-siders regneark med produktkoder. All fremdrift stopper opp. Jeg har sett det for mange ganger. Selgeren bygger tillit i møterommet, men så river verktøyene våre den ned etterpå. Tilbudet er teknisk korrekt, men kjøpsopplevelsen skaper nå mistillit. Tillit bygges i samtaler og rives ned i regneark. Dette handler ikke om dårlig opplæring. Det er et problem med systemdesign. Den skjulte kostnaden ved overleveringer De fleste ser på CPQ som et tilbudsverktøy. Det håndhever produktregler, beregner priser og lager et dokument. Det høres fornuftig ut, helt til du ser hva som skjer mellom behovsanalyse og kontrakt. Kunden forlater møtet med en krystallklar forståelse av hva de skal oppnå: «Vi trenger løsning X for å passe inn på Y plass, med Z kapasitet, og vi er mest opptatt av energikostnad og oppetid.» Dok...
Legg inn en kommentar
Les mer