«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:
- **Tegn opp organisasjonskartet.** Plasser regioner under konsernet og partnere under regionene. Skriv det ned på én side. Er det lengre, er det for komplisert.
- **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.
- **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
Legg inn en kommentar