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 ...

Skalerbar CPQ: Fra ekspertflaskehalser til vekstmotor

CPQ That Scales: Turning Expert Bottlenecks Into a Growth Engine

«Vi kan sende tilbudet så snart Lars har sjekket konfigurasjonen.» Det er fredag. Kunden spurte på mandag. Lars er flink, men han sjonglerer tre prosjekter og to eskaleringer. Innen tilbudet går ut, har det gått for lang tid, og konkurrenten er allerede i dialog med innkjøpsavdelingen.

Jeg har sett dette mønsteret i årevis. Noen få helter holder skuta flytende, men de er også en bremsekloss for vekst. Ikke med vilje, selvfølgelig. Det er bare sånn systemet er skrudd sammen.

Se for deg noe annet: En helt vanlig selger skriver et kort notat på enkelt norsk, får opp to ferdigvaliderte alternativer på minutter og sender et ryddig tilbud samme dag. Ingen omveier. Ingen endeløse Slack-tråder. Ingen venting på Lars.

Hva er det som *egentlig* bremser salget?

Mange tror problemet er hastighet eller et dårlig brukergrensesnitt. Den virkelige utfordringen er at salgsprosessen blander sammen to helt forskjellige jobber: å forstå hva kunden trenger, og å bevise hva som faktisk er teknisk mulig. Når de to er filtret sammen, er det kun de aller beste ekspertene dine som klarer å drive et salg fremover. Det er der flaskehalsen ligger.

Løsningen er strukturell. Skill kundens intensjon fra de harde faktaene. La systemet tolke fritekst, e-poster og notater. La den formelle produktlogikken avgjøre hva som er gyldig, kompatibelt og leverbart. Når disse rollene er tydelig adskilt, blir arbeidet skalerbart.

Skill forståelse fra fakta. Hastighet uten trygghet er bare teater.

Dette er ikke teori. Det er sånn du bygger ekspertkunnskap inn i et system hele teamet kan bruke. Det reduserer også reell risiko. Unøyaktige tilbud i komplekse salg fører til inntektslekkasje, fakturakonflikter og brudd på regelverk – for eksempel knyttet til inntektsføring (ASC 606). Dette er ikke småtterier. Det er marginer og omdømme som forsvinner ut døra.

Hele poenget med CPQ er jo å forenkle det som er komplisert og øke treffsikkerheten for å selge mer, raskere. Det er lista vi må legge oss på. De fleste systemer klarer deler av dette. Få klarer alt på en gang.

Adopsjon er den eneste målingen som betyr noe.

Hvis selgerne ikke bruker systemet, har du ikke løst problemet. Du har bare flyttet det.

Designregler for en salgsprosess som skiller intensjon og fakta

Her er reglene jeg bruker for å gjøre om en menneskelig flaskehals til en pålitelig motor. De er enkle med vilje.

1) Skill jobbene: intensjon inn, fakta ut. Bruk naturlig språk til å fange opp hva kunden ber om. Bruk rigide produktregler til å validere og fullføre. Ikke la AI finne på tekniske begrensninger eller priser. Bruk AI til å lese og foreslå, ikke til å bestemme hva som er gyldig. Eksempel: En selger limer inn møtenotater. Systemet foreslår to gyldige konfigurasjoner med tydelige fordeler og ulemper, fordi produktlogikken vet hva som kan bygges.

2) Legg ekspertisen der den endrer seg saktest. Kod inn begrensninger, avhengigheter og kompatibilitet i en produktmodell med en «solver» i bunn. Hold kommersielle variabler som rabatter, tillegg og godkjenninger i et eget policy-lag. Ikke grav forretningslogikk ned i konfigurasjonsreglene. Eksempel: Spenningskompatibilitet hører hjemme i reglene. En kvartalsrabatt hører hjemme i policy. Det ene endrer seg sjelden, det andre kan endre seg ukentlig.

3) Hvert eneste valg må kunne forklares. Selgerne må se hvorfor et alternativ er låst eller hvorfor prisen endret seg. Hvis systemet ikke kan forklare seg selv, vil ingen stole på det, og adopsjonen stopper opp. Eksempel: «Alternativ B er deaktivert fordi motorstørrelsen overskrider rammens kapasitet. Velg ramme 3 eller reduser dreiemomentet.» Det er en forklaring som redder en kundedialog.

4) Bygg rekkverk, ikke stol på heltedåder. Bytt ut spontane godkjenninger med definerte grenser og automatiske eskaleringer. Hvis en konfigurasjon krysser en risikogrense, ruter systemet saken videre med all nødvendig kontekst. Ikke stol på at noen pinger den ene personen som kan dette. Eksempel: Hvis en konfigurasjon krever et ikke-standard materiale, utløses én enkelt teknisk gjennomgang med hele parameteroppsettet vedlagt, ikke en skattejakt etter informasjon.

5) Mål fart og korrekthet, ikke bare aktivitet. Mål tid til første gyldige konfigurasjon, andel omarbeidede tilbud, antall godkjenningsrunder og marginavvik fra mål. Du får det du måler. Dropp de overfladiske målingene.

Hver ny regel er en fremtidig vedlikeholdskostnad – sørg for at den er verdt det.

Anti-mønster: Heltenes stafett. Selgeren fyller ut et skjema. Det går til en ingeniør. Ingeniøren fikser det i Excel. Det går tilbake til selgeren. Så legger prisavdelingen til sin magi. Deretter oppdager juridisk avdeling en mangel i spesifikasjonen. Innen tilbudet er ferdig, har kunden gått videre. Dere hadde ikke en prosess. Dere hadde en stafett der alle mistet pinnen.

Når du skiller intensjon fra fakta og legger til forklaringer, blir stafetten til en rett linje. En vanlig selger kan produsere korrekte alternativer raskt. Ekspertene kan fokusere på unntakene og produktutvikling, ikke daglig brannslukking.

Gjør det til en realitet dette kvartalet

Ikke sikt mot perfeksjon. Sikt mot en fungerende løsning for et lite utvalg som beviser at systemet fortjener tillit. Her er en enkel plan du kan gjennomføre på 6–10 uker for én produktfamilie.

1) Velg en produktfamilie og samle inn reell kundeintensjon. Finn 20 nylige salgsmuligheter. Hent ut de faktiske notatene og e-postene, ikke oppryddede maler. Definer et lite vokabular av kundeønsker som gjenspeiler hvordan kjøpere faktisk snakker. Koble dette til CPQ-systemet slik at fritekst blir til et strukturert oppsett.

2) Kod inn de absolutte reglene. List opp de 30 viktigste begrensningene og kompatibilitetsreglene som forårsaker omarbeid i dag. Implementer kun disse først. Legg til klare forklaringer for hver regel, slik at selgerne forstår hvorfor, ikke bare hva.

3) Mål de viktigste KPI-ene fra dag én.

  • Tid til første gyldige konfigurasjon
  • Antall runder frem og tilbake per tilbud
  • Antall godkjenninger per salg
  • Marginavvik fra mål eller bunnpris

Etabler et nullpunkt basert på forrige kvartal. Målet er ikke å bli best i verden med en gang. Målet er å bli 30–50 prosent bedre enn dere var i går.

4) Fjern én «workaround» hver uke. Finn den verste nødløsningen teamet bruker for å få tilbudene ut døra. Erstatt den med en regel, en policy eller et guidet steg. Ikke la regneark leve videre parallelt. Hvis en nødløsning overlever, spør hvorfor systemet ikke gjorde jobben bedre.

5) Lag en kjapp sløyfe for endringer. Utnevn eiere for produktlogikk, prispolicy og salgsprosess. Gi dem en ukentlig gjennomgang, et testsett og myndighet til å levere. Riktig kadens er rask nok til å lære, men treg nok til å være trygg. Hvis hver endring krever en prosjektplan, vil selgerne finne veier rundt deg.

6) Koble resultatene til forretningsmål. Dere lager ikke bare tilbud raskere. Dere reduserer risiko og øker tryggheten. Knytt den nye flyten til målbare resultater: kortere salgssyklus, færre eskaleringer, bedre marginer, høyere vinnersjanse. Ledere bør se effekten på kvaliteten i salgspipelinen og måloppnåelse, ikke bare i fine skjermbilder.

Slutt å eksportere PDF-er. Begynn å levere validerte alternativer.

Hva skjer når du får til dette? Den vanlige selgeren slutter å vente på Lars. Seniorene jobber med produktutvikling. Prisavdelingen ser færre kriserabatter. Juridisk avdeling ser færre kontraktsendringer. Kundene får tydelige, sammenlignbare alternativer raskere. Salgsprosesser slutter å støve ned i innbokser.

Jeg har sett team redusere tilbudstiden sin fra dager til timer bare ved å skille intensjon og fakta. Ikke fordi de kjøpte flere funksjoner, men fordi de endret måten de jobbet på. Gevinstene kom stille og rolig: raskere førsteutkast, færre revisjoner, bedre marginer. Kulturen fulgte etter.

Når produktlogikken er eksplisitt og kan forklares, kan du også revidere beslutninger. Du kan se hvor reglene hjalp og hvor de skapte problemer. Du kan, basert på data, avgjøre om en ny regel er verdt vedlikeholdskostnaden. Det er slik du kontrollerer kompleksitet i stedet for å la den hope seg opp.

Poenget er ikke å gjøre salg robotisk. Det er å gi selgerne den samme tryggheten som din beste ekspert gir i hvert salg, samtidig som ekspertene kan fokusere på de virkelige utfordringene. Det er slik du fjerner flaskehalsen uten å senke listen.

Team som gjør denne endringen, bygger et forsprang. De lærer fortere fordi hvert tilbud gir data. De lager bedre prognoser fordi alternativene er konsistente. De beskytter marginer fordi rekkverkene er automatiske. Team som ikke gjør det, fortsetter å lappe sammen nødløsninger. Driften kollapser ikke. Den bare sklir sakte ut i irrelevans.

Neste kvartal kommer uansett. Bruk det til å designe en salgsprosess som setter fart på de riktige tingene og gjør de gale feilene umulige.

For å si det som det er: Den raskeste tilbudsprosessen er den selgerne stoler på.

Kommentarer

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...

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...

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...