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

Indirekte salg uten kaos: CPQ-styring for partnernettverk

Indirect Sales Without Chaos: CPQ Governance for Partner Networks

«Vi ga forhandlerportalen alt. Nå bruker vi fredagene på å rydde opp i tilbud.» Det hører jeg ofte. Tanken er god: Gi partnere verktøyene de trenger for å bli selvgående og få fart på salget. Men når partnere får fri tilgang til å endre priser og vilkår, ender det ofte med tapte marginer og brudd på interne regler.

Partnere trenger autonomi. De trenger ikke innsyn i interne data eller frie tøyler på prising. Trikset er å la CPQ-systemet styre tilbudsprosessen som en autopilot, ikke å gi fra seg hele kontrollpanelet.

Partnere trenger frihet – ikke nøklene til hvelvet.

Paradokset med partner-frihet

Mange starter med å gi partnerne de samme verktøyene som interne selgere. Det virker rettferdig, men det er også der kaoset starter.

Resultatet ser du når rabattkravene eksploderer og tilbud endres etter godkjenning. Årsaken er nesten alltid den samme: uklart eierskap og mangel på klare stoppunkter i prosessen. CPQ handler ikke om automatisering i seg selv, men om *korrekthet*. Hvis eierskapet er uklart, skalerer du bare rotet.

Jeg har sett mange prøve å løse dette med mer opplæring eller flere datafelter. Det gjør bare prosessen tregere. Løsningen er å styre basert på *hvem som tar beslutninger*, ikke hvem som har tilgang til data. Definer hvem som kan opprette, sende inn, godkjenne og når et tilbud er låst. La CPQ-systemet håndheve dette med organisasjoner og roller.

Det eneste som teller, er at systemet blir tatt i bruk.

Samtidig ser vi et skifte i markedet. Tjenester og fornyelser utgjør en stadig større del av inntektene fra partnerkanalen. Som Dan Brown fra FinancialForce påpeker, er prosessen fra salgsmulighet til fornyelse kritisk for tjenestebaserte selskaper, men blir ofte oversett i produktfokuserte systemer. Her har partnere null rom for å improvisere på prising.

Og ja, AI blir en del av prisingen. Men AI erstatter ikke logikk – den er avhengig av den. Hvis partnerstyringen er svak, vil AI bare hjelpe deg å gjøre feil raskere.

Driftsmodellen: Organisasjoner, roller og arv

Dette er modellen jeg bruker for indirekte salg i CPQ. Den er ikke komplisert, men den krever disiplin.

**Organisasjoner** isolerer hvem som ser hva. **Roller** definerer hvem som gjør hva. **Arv** bestemmer hvordan data flyter.

Start med organisasjonskartet: Konsernet på toppen, deretter regioner, og så partnere under hver region. Dette er mer enn en sikkerhetsinnstilling – det er slik du definerer forretningsmessig eierskap. En partnerorganisasjon skal kun se:

  • Sine egne kunder og tilbud
  • Sitt tildelte produktsortiment og priser
  • Sine egne godkjenninger og oppgaver

Ledere i konsern og regioner skal kunne se rapporter og analyser på tvers av organisasjonene under seg, men aldri på sidenivå. Forhandlere skal aldri kunne se hverandre. Det alene fjerner 80 % av friksjonen i kanalen.

Deretter definerer du roller basert på *handlinger*, ikke datafelter. Kjernehandlingene er å konfigurere, lage tilbud, sende til godkjenning, generere forslag, sende forslag og legge inn ordre. Knytt hver handling til en rolle. En partner-selger kan kanskje konfigurere og lage et tilbud, men bare en partner-ansvarlig kan sende det til godkjenning.

Til slutt setter du opp arv. Produkter og priser flyter nedover. Transaksjoner og synlighet flyter oppover. Dette er steget mange hopper over. Hvis en prisliste endres, arver partnerne endringen ved neste «release», ikke midt i et åpent tilbud. Hvis en partner oppretter et tilbud, kan konsernet fortsatt rapportere på det uten å kunne redigere det.

Godkjenningsprosesser må designes som stier, ikke som enkelthendelser.

For eksempel: En produsent av anleggsmaskiner med 120 forhandlere globalt. Vi plasserte forhandlerne i egne organisasjoner under sin respektive region. Hver forhandler fikk et utvalg produkter de var sertifisert til å selge. Prislister ble versjonert og sluppet kvartalsvis. Partnerrollen kunne konfigurere, prise og be om en liten rabatt. Da tilbudet ble sendt inn, ble priskalkylen låst. Alle endringer opprettet en ny versjon. Forhandlerne så aldri interne kostnader, så aldri hverandre, og kunne ikke sende et forslag med en utløpt pris. Resultat: Ledelsen ser salgstrakten og vinnrater, godkjenner unntak og sover bedre om natten.

Spilleregler du kan innføre nå

Jeg holder meg til fem regler for indirekte salg i CPQ. De er enkle å forklare og lette å teste.

Regel 1: **Skill ut partnere i egne organisasjoner.** Ikke bland interne brukere og partnere i samme organisasjon for så å prøve å styre tilgang med rettigheter. Eksempel: En asiatisk distributør ligger under APAC-regionen og kan ikke se ressurser fra EMEA. Punktum.

Regel 2: **Bruk roller til å styre *handlinger*, ikke formler.** En rolle skal aktivere eller blokkere handlinger som «send inn», «endre prisliste» eller «send forslag». Ikke la rollen endre selve kalkyleringslogikken. Eksempel: En partner kan foreslå tilbehør i en pakke, men kan ikke endre prisversjon eller godkjenningsflyt.

Regel 3: **Frigi priser i versjoner, ikke hent live fra ERP.** Partnere gir ofte tilbud i møter med kunder. Hvis prisen avhenger av et live-kall mot ERP-systemet, går det ut over ytelse og sporbarhet. Bruk ERP som master for priser, men slipp versjonerte prislister til CPQ-systemet etter en fast plan.

Regel 4: **Bruk rabattnivåer med harde stopp.** Sett grenser per produktfamilie og partnernivå. Grensesnittet bør gjøre det umulig å gi mer rabatt enn tillatt uten en godkjenning. Eksempel: Bronsje-partnere kan be om opptil 5 % rabatt. Alt over utløser krav om begrunnelse og valg av godkjenner.

Regel 5: **Lås tilbudet ved innsending, og bruk versjonering ved endring.** Når en partner sender inn et tilbud, låses det. Hvis noe endres – produkt, antall, pris – lager CPQ en ny versjon. Her feiler mange godkjenningsprosesser, fordi tilbudet fortsetter å endre seg etter at det er signert. Eksempel: En revidert spesifikasjon lager v2, som kjører godkjenning på nytt basert på endringene.

Hver nye regel er en kostnad ved fremtidige endringer.

To feller du bør unngå:

  • **Fellen med én felles organisasjon:** Å plassere alle partnere i samme gruppe og prøve å styre innsyn med felt-rettigheter. Du vil garantert overse noe, og noen vil se en annens kunde.
  • **«Alt kan redigeres»-syndromet:** Å gjøre prisfelt redigerbare og håpe på at bedriftskulturen sørger for disiplin. Kulturen endrer seg med salgsmålene. Spillereglene i systemet gjør ikke det.

Hvor passer AI inn? Bruk AI som en dyktig lærling. La den hjelpe partnere med å forklare konfigurasjoner eller foreslå ferdig godkjente produktpakker. Men styringen må fortsatt komme fra roller, organisasjoner og prisversjoner.

Partnere som selger tjenester, er et spesialtilfelle. Hvis du selger serviceavtaler eller abonnementer gjennom partnere, må fornyelser behandles som egne objekter med egne låsepunkter, roller og pris-sykluser. Partneren kan se kundens utstyr og fornyelsesdatoer, men kan ikke finne på en ny pris midt i en avtaleperiode.

Trenger du en rask start? Gjør dette:

  1. **Tegn opp organisasjonskartet.** Plasser regioner under konsernet og partnere under regionene. Skriv det ned på én side. Er det lengre, er det for komplisert.
  2. **Definer hvem som eier handlingene.** For hvert steg – konfigurere, prise, sende inn, godkjenne, foreslå, bestille – navngi rollen som eier handlingen hos partner, region og konsern.
  3. **Lanser en prisbok.** Velg én produktfamilie med høyt volum. Lag en partner-prisversjon med gyldighetsdatoer og rabattgrenser. Test med tre partnere. Mål kun to ting: tid brukt på å lage tilbud og antall rabattforespørsler.

CPQ er autopiloten for tilbudsprosessen. Du flyr fortsatt flyet – men du slutter å gjøre det manuelt.

Jeg har gjort dette for produsenter, medtech-selskaper og tjenestebaserte virksomheter. Mønsteret er det samme. Når partnere føler seg effektive og trygge, slutter de å finne på egne løsninger. Når ledelsen har innsyn uten å måtte detaljstyre, blir ting gjort riktig.

Den enkle sannheten er denne: Partnere selger bedre når systemet håndhever spillereglene. Hvis dere fortsatt trenger en prosjektplan for hver minste endring, har dere ikke styring – dere har kaos.

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