Den tekniske utfordringen: Når nye kontrakter overskriver gamle
Mange SaaS-selskaper har relativt god kontroll på rapporteringen av nysalg. De vet hvor mange nye kunder som ligger i pipeline, hva kontraktene er verdt, og hvor stor sannsynlighet det er for at de blir vunnet.
Men når det kommer til oppsalg hos eksisterende kunder, er bildet ofte et annet.
Her finnes det gjerne betydelige vekstmuligheter, men overraskende få selskaper har en presis og strukturert rapportering av disse mulighetene. Resultatet er at ledelsen og styret får et ufullstendig bilde av forventet ARR-utvikling.
Utfordringen er at oppsalg ofte ikke behandles som en egen salgsprosess.
Det kan handle om flere ting:
- Eksisterende kunder som vurderer å kjøpe flere moduler.
- Økt bruk eller utvidelse av antall lisenser.
- Flere brukere, avdelinger eller geografiske markeder.
- Prisjusteringer og oppgradering til større avtaler.
- Utvidelser av eksisterende kontrakter gjennom nye behov hos kunden.
Mange av disse mulighetene fanges opp i kundedialogen, men blir ikke nødvendigvis registrert som konkrete salgsmuligheter i CRM-systemet.
Dermed oppstår det et gap mellom det selskapet tror det kan selge, og det som faktisk er dokumentert i pipeline.
Hvorfor er dette et problem?
For det første blir ARR-prognosene mindre presise. Hvis oppsalg ikke er systematisk registrert, blir forventet vekst ofte basert på historikk, magefølelse eller generelle antakelser om kundeutvikling.
For det andre blir ansvaret uklart. Er det Customer Success, Account Management eller salg som eier oppsalgsmulighetene? Når ansvaret ikke er tydelig, er det lett at mulighetene faller mellom flere stoler.
For det tredje blir styrets beslutningsgrunnlag svakere. Styret bør kunne skille mellom vekst fra nye kunder, vekst fra eksisterende kunder og prisjusteringer. Dette er ulike vekstdrivere med ulik risiko og ulik forutsigbarhet.
Den tekniske utfordringen: Når nye kontrakter overskriver gamle
Det finnes også en teknisk side av denne utfordringen som ofte blir undervurdert.
I mange SaaS-selskaper håndteres kontraktsendringer ved at en ny kontrakt erstatter eller overskriver den eksisterende. Det kan fungere greit for fakturering og administrasjon, men skaper problemer når man skal rapportere presis ARR-utvikling.
La oss si at en kunde har en eksisterende ARR på 500 000 kroner. Kunden kjøper deretter en ny modul til 100 000 kroner i ARR.
Hvis den nye kontrakten erstatter den gamle i systemet, kan man miste koblingen til den opprinnelige avtalen. Da blir det vanskelig å dokumentere at kunden faktisk har økt ARR med 100 000 kroner.
Det samme gjelder ved nedgraderinger, prisjusteringer, fornyelser og endringer i kontraktsomfang.
Konsekvensen kan bli at man ikke klarer å skille mellom:
- Opprinnelig kontraktsverdi.
- Nye moduler og utvidelser.
- Prisjusteringer.
- Reduksjoner i kontraktsverdi.
- Fornyelser og kontraktsforlengelser.
Dette er ikke bare et CRM-problem. Det er et spørsmål om hvordan selskapets kommersielle data er modellert.
Løsningen er å skille mellom kontraktens historikk og kontraktens nåværende status.
En god teknisk modell bør ha:
- Uforanderlig kontraktshistorikk: Opprinnelige avtaler og senere endringer må bevares. Nye avtaler skal ikke slette historikken.
- Versjonering: Hver kontraktsendring må registreres som en ny versjon med gyldig fra- og til-dato.
- Endringsårsaker: Hver endring må klassifiseres som New Business, Expansion, Price Increase, Contraction eller Churn.
- Kobling mellom avtaler: Nye ordre og tillegg må kunne kobles til den opprinnelige kundeavtalen, slik at man kan følge utviklingen over tid.
- Historisk ARR-snapshot: Selskapet må kunne rekonstruere ARR på en bestemt dato, ikke bare se hva kontraktene er verdt i dag.
Dette er avgjørende for å kunne bygge en korrekt ARR-bro. Hvis datagrunnlaget ikke bevarer historikken, hjelper det lite med gode rapporteringsrutiner og avanserte dashboards.
Hvordan etablere en presis ARR-bro og pipeline?
Det første steget er å skille mellom rapportering av faktisk ARR-utvikling og rapportering av fremtidige salgsmuligheter.
1. Etabler en strukturert ARR-bro
En ARR-bro bør forklare hele utviklingen fra inngående til utgående ARR.
Den bør som minimum inneholde:
- New Business: ARR fra nye kunder.
- Expansion og upsale: Oppsalg hos eksisterende kunder.
- Price Increase: ARR-økning fra prisjusteringer.
- Contraction: Reduksjon i eksisterende kontrakter.
- Churn: ARR som forsvinner når kunder avslutter.
Da får man et tydelig bilde av hva som faktisk driver veksten.
2. Opprett en egen pipeline for Expansion
Oppsalg må registreres som egne salgsmuligheter i CRM, på samme måte som nysalg.
Hver mulighet bør ha:
- Kunde og eksisterende ARR.
- Hva kunden vurderer å kjøpe.
- Forventet økning i ARR.
- Forventet beslutningsdato og kontraktsstart.
- Ansvarlig person.
- Salgsfase og sannsynlighet.
- Konkret neste aktivitet.
Det er viktig at man ikke registrerer hele kundens potensial som pipeline. Pipeline skal vise identifiserte og reelle salgsmuligheter, ikke hva man håper å selge på sikt.
3. Definer tydelige kriterier for salgsfasene
En kunde som har vist generell interesse, bør ikke ha samme status som en kunde som har bekreftet behov, budsjett og beslutningsprosess.
Etabler derfor tydelige kriterier for når en mulighet kan flyttes fra én fase til en annen.
Eksempelvis:
- Identifisert mulighet.
- Behov bekreftet.
- Løsning og omfang diskutert.
- Kommersiell dialog.
- Tilbud sendt.
- Muntlig aksept.
- Signert.
Dette gjør sannsynlighetsvurderingene mer sammenlignbare og reduserer faren for overoptimistisk rapportering.
4. Skill mellom pipeline og forecast
Dette er kanskje det viktigste skillet.
Pipeline viser alle identifiserte salgsmuligheter. Forecast viser hva selskapet faktisk forventer å lande innenfor en gitt periode.
En mulighet på 500 000 kroner i ARR er ikke automatisk 500 000 kroner i forventet vekst.
Forecast bør baseres på dokumentert fremdrift, kundens beslutningsprosess, forventet signering og historiske konverteringsrater.
5. Gjør Customer Success til en del av vekstmotoren
Customer Success bør ha en tydelig rolle i å identifisere vekstmuligheter, men det må være klart hvem som eier den kommersielle prosessen.
CS sitter ofte tettest på kundens bruk, behov og organisasjonsutvikling. Det gir et godt utgangspunkt for å identifisere muligheter før de blir synlige i en tradisjonell salgsprosess.
Men identifiserte muligheter må overføres til en strukturert kommersiell pipeline med tydelig eierskap.
Hva bør styret følge med på?
For styret og ledelsen bør rapporteringen gjøre det mulig å forstå både dagens ARR-utvikling og fremtidig vekstpotensial.
Noen sentrale målepunkter er:
- Expansion ARR: Hvor mye ARR kommer fra eksisterende kunder?
- Expansion Pipeline: Hvor mye identifisert oppsalg ligger i pipeline?
- Pipeline Coverage: Hvor stor pipeline har vi sammenlignet med vekstmålet?
- Win Rate: Hvor stor andel av oppsalgsmulighetene blir vunnet?
- Sales Cycle: Hvor lang tid tar det å realisere oppsalg?
- Net Revenue Retention (NRR): Hvor godt klarer vi å vokse eksisterende kundeportefølje etter churn og nedgraderinger?
Det er også viktig å følge utviklingen over tid. En stor pipeline er lite verdt dersom konverteringsgraden er lav eller mulighetene stadig skyves frem i tid.
Avslutning
Eksisterende kunder er ofte en av de viktigste vekstmotorene i et SaaS-selskap. Likevel er det nettopp her mange selskaper har svakest kontroll på pipeline og prognoser.
Utfordringen er både kommersiell og teknisk. Man må ha gode prosesser for å identifisere og følge opp salgsmuligheter, samtidig som systemene må bevare kontraktshistorikk og gjøre det mulig å dokumentere alle endringer i ARR.
Skal man bygge et mer forutsigbart SaaS-selskap, holder det ikke å ha kontroll på nysalget.
Man må også vite hvor veksten fra eksisterende kunder skal komme fra, hvilke muligheter som faktisk er identifisert, hvem som eier dem, og hvor sannsynlig det er at de blir realisert.
En presis ARR-bro forteller hva som har skjedd. En presis Expansion Pipeline gir innsikt i hva som kan skje videre. Begge deler er nødvendig for god styring av et SaaS-selskap.
