SLA mellan marknad och sälj är sällan ett dokumentproblem – det är ett styrningsproblem. När RevOps får mandat att definiera vad som faktiskt ska mätas, när och av vem, minskar friktionen direkt eftersom diskussionen flyttas från åsikter till observerbara beteenden i processen.
För svenska försäljningschefer blir frågan extra konkret: utan en gemensam definition av ”bra lead”, ”tillräcklig aktivitet” och ”överlämnad affärsmöjlighet” hamnar du i en vardag där marknad optimerar för volym och sälj för sannolikhet. Resultatet blir missnöje, ad hoc-åtgärder och ett go-to-market som inte går att styra med samma precision som resten av verksamheten.
Det konfliktfria SLA:t är därför inte det som ”alla kan skriva under på”, utan det som gör intäktsstyrning möjlig: tydliga trösklar, spårbarhet mellan steg och en överenskommen mekanik för när ni ska ändra. Den logiken är enkel – men kräver disciplin.
Varför ett SLA ofta blir en konfliktkatalysator
De flesta SLA:er mellan marknad och sälj faller på samma punkt: de blandar ihop ansvar, kvalitet och utfall. Marknad lovar något som i praktiken beror på säljbeteenden (till exempel ”pipeline”) och sälj lovar något som beror på marknadens inflöde (till exempel ”mötesbokning”), utan att någon av parterna äger hela kedjan. Då blir SLA:t en arena för efterhandsförklaringar.
Konflikten förstärks av att mätetal ofta hämtas från olika system och olika logiker. Marknad tittar i första hand på kampanjdata och respons, sälj på CRM-statusar och aktivitet. Utan en gemensam datamodell, och utan en operativ rutin för att stämma av definitioner, blir siffror till argument snarare än underlag. Här blir sales operations och RevOps viktiga som neutral funktion: inte för att ”bestämma över” teamen, utan för att hålla ihop begrepp, system och beslutsforum.
RevOps som ramverk: från löften till styrbara mekanismer
Om du vill göra SLA:t mätbart behöver du formulera det i termer av mekanik, inte önskemål. Ett användbart sätt att tänka är att RevOps tar ansvar för tre saker: definition, mätning och eskalering. Definitionen handlar om exakt vilka kriterier som måste vara uppfyllda för att en överlämning ska anses korrekt. Mätningen handlar om var det loggas och vem som äger datakvaliteten. Eskaleringen handlar om vad som händer när ni inte når överenskommen nivå – och när det är legitimt att justera själva SLA:t.
Det gör också att SLA:t kan bli ett styrinstrument i ert go-to-market, inte bara en ”fredspakt”. När definitioner sitter kan du koppla överlämningen till kapacitetsplanering och prioritering: vilka segment ska få snabbast handläggning, vilka typer av affärer ska gå till vilket team, och vilka signaler ska trigga vilken typ av säljrörelse. Då blir SLA:t ett sätt att skapa konsekvens i hur ni går till marknaden, inte en diskussion om vem som gjorde fel förra veckan.
Välj KPI:er som går att påverka – och som hänger ihop
Ett mätbart SLA bygger på KPI:er som både marknad och sälj faktiskt kan påverka i sin del av kedjan. Det låter självklart, men i praktiken fastnar många i KPI:er som är för sena i flödet. Pipeline och intäkt är viktiga, men de är resultat av många steg där ansvar delas. Om du enbart mäter slutresultat får du en avtalskonstruktion där parterna i efterhand kan skylla på varandras ”del”.
Mer robust är att kombinera ett fåtal ledande mått och ett fåtal kvalitetsmått, och vara stenhård med definitionerna. Exempel på vad som brukar fungera i en B2B-kontext är: tid till första hantering efter överlämning, andel överlämningar som uppfyller kvalificeringskriterier, och andel som faktiskt får en nästa aktivitet i CRM inom en given tidsram. Det är inte glamorösa siffror, men de är styrbara och gör beteenden synliga.
Nyckeln är kopplingen mellan måtten. Om marknad optimerar för volym och sälj för svarstid kan du hamna i ett ”snabbt nej”-beteende. Därför behöver du alltid läsa KPI:er i paket: hastighet utan kvalitet är brus, kvalitet utan kapacitet är en flaskhals. En tydlig intäktsstyrning kräver att du accepterar den här spänningen och designar SLA:t så att det inte belönar genvägar.
Gör SLA:t konfliktfritt genom att definiera beslutscykeln, inte bara reglerna
Konfliktfrihet uppstår inte av att parterna ”förstår varandra”, utan av att det finns en överenskommen beslutsprocess när verkligheten förändras. Marknaden rör sig, prioriterade segment skiftar, produktens positionering ändras, och säljkapacitet varierar. Om SLA:t är statiskt kommer det bli fel – och när det blir fel kommer det bli personligt.
Lägg därför lika mycket vikt på hur ni reviderar SLA:t som på vad det innehåller. Vem äger att kalla till genomgång, vilka data ska alltid ligga på bordet, och vad krävs för att ändra definitionen av en kvalificerad överlämning? När beslutscykeln är tydlig blir diskussionen mer teknisk än politisk. Och när den är återkommande minskar behovet av brandkårsutryckningar.
Här har RevOps en naturlig roll som moderator och ägare av spelplanen, medan sales operations kan driva den praktiska uppföljningen i CRM och process. Poängen är inte fler möten – poängen är färre överraskningar.
SLA som en del av intäktsstyrning – inte ett separat avtal
Det mest mogna sättet att se på SLA är som en modul i er intäktsstyrning: ett sätt att göra överlämningar, prioriteringar och återkoppling styrbara över tid. När du kopplar SLA:t till planering (segment, kapacitet, mål) och uppföljning (utfall, avvikelser, justeringar) blir det en del av samma system som styr resten av verksamheten.
Det är också här du får den strategiska effekten: du kan testa förändringar i go-to-market utan att skapa kaos i gränssnittet mellan marknad och sälj. När ni till exempel skiftar fokus mot större affärer eller nya vertikaler kan SLA:t uppdateras så att rätt signaler prioriteras och fel signaler filtreras bort – och ni kan följa effekten utan att hamna i en ny definitionsdebatt varje vecka.
RevOps blir då inte ett ”projekt” utan ett sätt att bygga ett intäktssystem som tål förändring.
Nästa steg: boka en kort intern workshop där ni, med RevOps som facilitator, enas om 2-3 gemensamma definitioner och vilken data som ska vara källan till sanningen innan ni skriver en enda rad i själva SLA-dokumentet.
