RevOps är ett organisationsproblem före det är ett verktygsprojekt

För ett B2B SaaS-bolag uppstår friktionen ofta mellan team: marknad rapporterar leads, sälj rapporterar möjligheter och Customer Success rapporterar expansion. Om definitionerna skiljer sig åt hjälper en ny dashboard bara till att visa oenigheten snabbare.

Revenue Operations samordnar processer, data och ansvar över kundresan. Salesforce beskriver RevOps som en funktion som knyter samman bland annat marknad, försäljning, service och ekonomi. En RevOps-partner ska därför kunna facilitera beslut, inte bara konfigurera CRM-fält.

• Typiska köpsignaler: motstridiga funnel-definitioner, dubbelregistrering, tappade överlämningar och opålitliga prognoser.
• Inte automatiskt RevOps: ett isolerat CRM-byte, en ny e-postautomation eller en engångsrapport.
• Intern sponsor: ofta CRO, kommersiell chef eller en gemensam ledningsgrupp med mandat över flera team.

Definiera problemet innan ni ber om offert

Samla ett litet tvärfunktionellt team och kartlägg hur en kontakt blir kund och hur expansion fångas. Rita nuläget med faktiska överlämningar, inte bara den process som finns i en presentation. Var försvinner ägarskap? Vilka fält krävs för att en möjlighet ska räknas? När tar Customer Success över?

Skicka kandidaterna en anonymiserad processkarta och en lista med de beslut som måste fattas. Låt dem beskriva hur de skulle genomföra en första diagnos och vilka roller som behöver delta.

• ICP, segment, ACV-spann och hur köpbeslut fattas – utan att exponera känsliga kunduppgifter.
• Lead lifecycle: ny kontakt, kvalificering, accepterat av sälj, opportunity och återföring.
• Pipeline-steg, forecast-kategorier och vem som får ändra dem.
• System: CRM, marketing automation, fakturering, produktdata och support – samt vilka integrationer som faktiskt används.

RevOps-partner eller CRM-implementatör?

En CRM-implementatör kan vara rätt om processerna redan är beslutade och uppgiften är teknisk: migrera, konfigurera, utbilda. En RevOps-partner behövs när affärsregler, ägarskap och KPI:er måste harmoniseras mellan team. Vissa leverantörer gör båda; kräv att offerten skiljer dem åt.

Har ni en tydlig CRM-upphandling snarare än ett tvärfunktionellt förändringsarbete? Jämför då även guiden för CRM-implementationspartner. Om utmaningen i stället gäller val av målbolag och buying groups kan ABM-guiden vara mer relevant.

• RevOps-leverabler: gemensamma definitioner, RACI, SLA mellan team, datamodell och beslutsforum.
• CRM-leverabler: fält, objekt, integrationer, behörigheter, migrering och utbildning.
• Be om både förändringsledning och teknisk kompetens om uppdraget omfattar båda.

Så bör ett uppdrag delas upp

Fas 1 är en diagnos med intervjuer, dataprofilering och en konkret lista över flaskhalsar. Fas 2 är design: godkända definitioner, ansvar, prioriterade användningsfall och en realistisk integrationsplan. Fas 3 är genomförande och acceptanstest, följt av förvaltning med tydlig intern ägare.

Undvik att beställa en stor automatisering innan ni har enats om vad en kvalificerad opportunity betyder. Annars automatiserar ni bara otydligheten.

• Acceptanstest: kan två team rapportera samma funnel med samma definitioner?
• Data-QA: hantering av dubbletter, saknade värden, historiska ändringar och sync-fel.
• Drift: vem äger dokumentation, integrationer och ändringshantering efter leverans?
• Utvärdering: följ exempelvis konvertering mellan steg, tid till uppföljning och andel möjligheter med komplett information – där datan tillåter.

Budget, upphandling och risker

Budgetera discovery, processarbete, teknik, utbildning och eftervård separat. Antal integrationer och graden av intern oenighet kan påverka arbetet mer än antalet licenser. En avgränsad första fas gör det möjligt att stoppa eller ändra riktning innan ett stort systemprojekt låses.

Fråga hur partnern hanterar personuppgifter, åtkomst, rollback och dokumentation. Inget seriöst upplägg kan lova en viss omsättningsökning enbart från RevOps. Det ni kan avtala om är leveranser, testbara funktioner och mätbar processkvalitet.

• Röd flagga: en demo säljs som lösning innan nuläget kartlagts.
• Röd flagga: ingen ägare för definitioner eller datakvalitet.
• Grönt tecken: byrån vågar rekommendera processförändringar utan nya verktyg.

Frågor som skiljer kandidaterna åt

Be om ett kort, skriftligt svar på följande: Vilka beslut måste ledningen fatta innan ni börjar? Hur förenar ni olika definitioner av MQL, SQL och opportunity? Vilka integrationer är mest riskfyllda? Hur mäter vi att överlämningar fungerar? Hur gör ni kunden oberoende av er efter projektet?

Ett bra svar bör innehålla antaganden och begränsningar. Om allt låter enkelt har leverantören förmodligen inte förstått var komplexiteten ligger.