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: Slik fungerer CPQ-styring

Indirect Sales Without Chaos: How CPQ Governance Works

«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, men får helt ulike brukeropplevelser.

Den skjulte kostnaden ved delte systemer

Den vanligste fallgruven er «én felles tenant for alle partnere». Det starter som en snarvei. Ett miljø, ett sett med produkter. «Vi bare styrer innsynet med profiler og mapper.» Så oppdager du at en forhandler i Italia kan se en rabattmal ment for Sør-Korea. Det er ikke et datainnbrudd. Det er verre – det er tvetydig. Og tvetydighet rundt priser sprer seg fort.

Jeg har også sett team prøve det motsatte: å kopiere hele systemet for hver region. Det isolerer, men skaper kaos. Plutselig må du synkronisere produktendringer fem steder og forklare økonomiavdelingen hvorfor marginrapportene aldri stemmer. Du har ikke løst noe som helst, bare flyttet kompleksiteten ut av systemet.

Én felles partner-tenant er en datalekkasje i sakte film.

Det vanskelige med partnernettverk er ikke antallet partnere, men variasjonen i rettigheter og ansvar mellom dem. Et CPQ-system alene løser ikke dette. Men det gir deg et språk for å definere det tydelig: organisasjoner, roller og arv. Bruk det, ellers ender du opp med å drive brannslukking i stedet for å forme adferd.

Hvorfor kanalsalg trenger noe annet

Direkteselgerne dine jobber innenfor dine fire vegger. Partnere opererer på tvers av selskaper, valutaer og juridiske landskap. De trenger frihet til å betjene seg selv, og du trenger grenser du kan forsvare. Disse målene er ikke i konflikt. Konflikten oppstår når systemet ikke klarer å skille mellom «kan se», «kan gjøre» og «vil bli godkjent».

Derfor slår det ofte feil å bygge alt inn i CRM-systemet for partnere. På en 13-tommers laptop gidder ikke en partner å navigere gjennom interne faner og objekter. De trenger en guidet, redusert opplevelse som kun viser de handlingene du faktisk vil at de skal utføre. Alt annet bør være usynlig, ikke bare deaktivert.

Styring er ikke møter og manualer. Styring er designet av CPQ-systemet ditt. Hvis designet er riktig, følger adferden etter. Hvis designet er feil, vil du slukke de samme brannene hvert eneste kvartal.

Styringsmodellen: Organisasjoner, Roller, Arv

God partnerstyring i CPQ hviler på tre pilarer. Får du disse riktig, blir resten enklere.

  • Organisasjoner: Kartlegg virksomheten din i et tre: konsern, regioner, distributører, forhandlere. Dette er mer enn bare struktur; det er isolasjon. Partnere lever i sin egen organisasjon og kan ikke se hverandre. Konsernet ser alt. Slik stopper du utilsiktet innsyn uten manuell overvåking.
  • Roller: Definer hva folk kan *gjøre*, ikke bare hva de kan *se*. Roller styrer handlinger og arbeidsflyt: lage en konfigurasjon, be om rabatt, generere et tilbud, sende til godkjenning, konvertere til ordre. En partnerselger, en salgssjef hos partneren og din interne godkjenner skal ha ulike knapper og ulike stopp-punkter.
  • Arv: La produkter og priser flyte nedover i treet. La transaksjoner og innsikt flyte oppover. Konsernet publiserer produktversjoner og prislister ned til de ulike organisasjonene. Partnere jobber med det som er publisert til dem, ikke det som tilfeldigvis er ferskt fra R&D eller finans. Oppover ser du tilbud, godkjenninger og resultater – uten å forstyrre det daglige arbeidet deres.

Dette enkle mønsteret endrer adferd. Partnere leter ikke etter filer; de tar neste tillatte steg. Regionledere slutter å jakte på regneark; de åpner et samlet dashboard. Compliance-avdelingen trenger ikke frykte innsyn, fordi innsyn er en egenskap ved organisasjonstreet, ikke en liste med unntak.

Partnere trenger valgmuligheter. Du trenger kontrollpunkter.

Slik ser det ut i praksis

Her er tre scenarioer jeg har sett fungere godt.

Scenario 1: En distributør i Frankrike selger modulært utstyr. I sin organisasjon ser de kun prislister for EMEA og produktvarianter godkjent for dette markedet. De kan konfigurere, lagre og generere et tilbud. De kan be om rabatt innenfor en gitt ramme. Rabatter over en viss terskel sendes til regionens interne godkjenner. De kan ikke redigere prisen på en linje, ser aldri kostpris og ser aldri andre distributørers tilbud.

Scenario 2: En global produsent håndterer 200 forhandlere. Hovedkontoret publiserer nye produkt- og priskataloger månedlig. Forhandlerne jobber i det daglige uten å røre konsernets systemer. Hvert tilbud bruker publiserte priser, fryst i det øyeblikket tilbudet opprettes. Godkjenninger følger lokale terskler, men logges sentralt. Hvert kvartal analyserer konsernet partnernes resultater basert på data rett fra CPQ-systemet.

Scenario 3: En spesialist-VAR selger utstyr pluss tjenester. Innenfor sin organisasjon kan VAR-en legge til egne tjenestepakker. De kan ikke definere nye kjerneprodukter eller overstyre merkevarens priser. Rollekatalogen lar dem foreslå skreddersydde tjenester, men alle vilkår utenfor standard merker tilbudet med "krever juridisk gjennomgang". De får fart på det de tilfører av verdi, mens du beholder kontrollen over merkevarens risiko.

Disse oppsettene er ikke avanserte spesialfunksjoner. De er standardmønstre – men bare hvis du behandler styring som en del av designet, ikke som et etterpå-problem.

Regler for en sunn partnerkanal

Her er noen tommelfingerregler jeg bruker når jeg setter opp kanalsalg i CPQ.

Regel 1: Modeller organisasjonstreet før du modellerer rettighetene. Start med hvordan virksomheten faktisk segmenterer partnere, ikke hvordan programvaren sorterer mapper. Tegn treet på en tavle. Bestem hvem som kan publisere nedover og hvem som kan se oppover. Først da oversetter du det til systemet.

Regel 2: Roller styrer handlinger, ikke følelser. Hvis en rolle kun eksisterer for å «gi partnere en følelse av myndighet», vil du miste kontroll. Lag roller som representerer konkrete handlinger og kontrollpunkter. Eksempel: «Kan be om spesialvilkår» er tydelig. «Betrodd partner» er det ikke.

Regel 3: Publiser priser, ikke hent dem live. Partnere trenger stabile priser når de lager tilbud. Å hente priser direkte fra ERP-systemet skaper risiko for timingfeil og stille endringer. Publiser versjoner etter en fast plan. Frys prisene når et tilbud opprettes. Hvis finans endrer noe, blir det en del av neste versjon, ikke en retroaktiv overraskelse.

Regel 4: Godkjenningsløp er objekter, ikke e-poster. Hvis godkjenninger skjer i innboksen, er de usynlige og umulige å teste. Definer tydelige godkjenningsløp i CPQ med terskler per organisasjon og rolle. Tilbud som krysser en terskel, bør låses for endringer inntil en beslutning er tatt.

Regel 5: Navngi fallgruvene tidlig. Snakk åpent om «felles partner-tenant», «redigerbare prisfelt» og «manuell politikk» i designfasen. Hvis noen foreslår dem igjen senere, har du et bedre alternativ klart, ikke bare et nei.

Hva du kan gjøre dette kvartalet

Hvis du vil gå fra «vi administrerer partnere» til «systemet styrer seg selv», er dette en metode som fungerer.

Først, kartlegg organisasjonstreet ditt. Én side. Konsern på toppen, deretter regioner, så distributører og forhandlere. Merk av hvor hvert nivå kan publisere produkter eller priser nedover, og hvor de kan se transaksjoner oppover. Dette er ryggraden i styringsmodellen din.

For det andre, definer en rollekatalog. Fem til sju roller, ikke tjue. Tenk i verb: konfigurere, prise, tilby, rabattere, godkjenne, bestille. For hver rolle, lag en liste over tillatte handlinger og neste steg de kan utløse. Hold det kort nok til å kunne forklares på fem minutter.

For det tredje, sett faste punkter for publisering og låsing av priser. Bestem når priser blir gyldige i CPQ og når tallene i et tilbud fryses. Dokumenter hvem som kan gi unntak, ved hvilke terskler, og hvilke endringer som krever ny godkjenning. Gjør disse reglene synlige i brukergrensesnittet.

Til slutt, start en pilot med én region og én partnertype. Ikke prøv å dekke alle scenarioer med en gang. Sikt mot ett rent eksempel. Mål syklustid, andel godkjente tilbud og gjennomsnittlig rabatt før og etter. Kan du ikke måle det, kan du heller ikke forsvare det senere.

Hvis partneransvarlig bruker kveldene på å kontrollere rabatter, har du ikke god styring.

Analysebyråene har sagt det i årevis: partnerøkosystemer driver en uforholdsmessig stor andel av veksten for komplekse industribedrifter. Det stemmer med min erfaring. Vinnerne rekrutterer ikke bare partnere – de gir dem autonomi innenfor gitte rammer. CPQ er verktøyet som gjør denne autonomien operasjonell.

Fordelen som forsterker seg selv

Når du får dette til, skjer det noe som forsterker seg selv. Hver nye partner arver de gode vanene fra den forrige – de riktige produktene, korrekte priser, tydelige handlinger og fornuftige godkjenningsprosesser. Det interne teamet ditt kan slutte med å være politi og heller drive med støtte og opplæring. Finansavdelingen slutter å krangle om enkelttilfeller. Salgsledelsen stoler endelig på dashboardene.

Når du bommer, skjer det motsatte. Gode partnere finner sine egne løsninger utenfor systemet. Dårlige partnere lærer andre snarveiene. Rabattene sklir ut. Godkjenninger blir omgått «bare denne ene gangen». Du vil ikke se én dramatisk feil. Du vil se en jevn lekkasje av margin og en jevn økning i antall unntak.

Jeg har jobbet med nok partnerprogrammer til å si det rett ut: du trenger ikke flere regler. Du trenger klarere regler, bygget inn i systemet der arbeidet faktisk skjer. Partnerne dine vil takke deg for det, fordi klarhet er raskere enn improvisasjon.

La systemet ta seg av styringen. Så kan du komme deg ut av veien.

Kommentarer

Populære innlegg fra denne bloggen

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