Gelir Operasyonları (RevOps)
Gelir operasyonları (RevOps), satış, pazarlama ve müşteri başarısını ortak veri, süreç ve teknoloji etrafında hizalayarak öngörülebilir gelir büyümesi sağlama pratiğidir.
Önemli noktalar
- Tek bir nesne modeli ve tek yaşam döngüsü, işlevsel olarak ayrı üç işletim modelinin yerini alır.
- Birleştirmenin değeri, gelir akışının içerdiği devir sayısıyla orantılı olarak büyür.
- Tek bir üst yönetim sahibi olmazsa ortak tanımlar kalıcı bir pazarlığa dönüşür.
- Tartışmalı tek bir metriği uzlaştırmak, birleşik pano kurmaktan daha iyi bir başlangıçtır.
- İşlevler farklı ödüllendiriliyorsa ortak veri hizalanmayı tek başına çözemez.
Derinlemesine
RevOps, üç ayrı işletim modelini tek bir modelde birleştirerek çalışır. Tek bir nesne modeli vardır; böylece kişi, hesap ve fırsat kayıtları pazarlama, satış ya da müşteri başarısı hangisi bakarsa baksın aynı anlama gelir. İlk temastan yenileme ve genişlemeye uzanan tek bir yaşam döngüsü kurulur ve her aşama geçişine bir sahip ile bir giriş kuralı atanır. Tanımlar ekip ekip pazarlık edilmek yerine merkezî olarak karara bağlanır; sistemler de bir yerde yazılan alanın diğerlerinde okunabileceği şekilde bağlanır.
Kazanç, gelir akışındaki devir sayısıyla birlikte büyür. Pazarlamanın satışa, satışın kuruluma ve kurulumun yenileme sahibine devrettiği bir işte veri kaybedilebilecek üç dikiş yeri vardır ve bunları birleştirmek karşılığını verir. Denge, merkezileşme ile yerel hız arasındadır: her talep için tek bir kuyruk tutarlılık getirir ama bu hafta bir test başlatmak isteyen pazarlama ekibini yavaşlatır. RevOps'un ayrıca net biçimde tek bir üst yönetim sahibine ihtiyacı vardır; böyle bir sahip yoksa ortak tanımlar hiç bitmeyen sürekli bir pazarlığa döner.
Çoğu ekip dar bir yerden başlar: üç işlevin farklı raporladığı tek bir metriği uzlaştırır ve ardından aynı toplantıda herkesin kullandığı tek bir sayı yayımlar. Yaşam döngüsü aşamaları ve devirlerin ölçümlenmesi bunu izler. Bir skorkart hunisi varsa RevOps, kademe, kaynak ve tek tek yanıtların kayıtla birlikte CRM'e ve oradan satış sonrası sisteme taşınmasını sağlar; böylece genişleme ve müşteri kaybı örüntüleri, alıcının daha ilk görüşme yapılmadan önce kendisi hakkında söylediği yanıtlara kadar geriye doğru izlenebilir hale gelir.
Devir olmayan yerde bu modelin sunacağı çok az şey vardır. Kendi satış ekibi bulunmayan, tamamen self-servis bir üründe zaten tek bir kayıt sistemi ve tek bir ekip vardır; ortak bir işlev böyle bir yerde tek bir dikişi bile ortadan kaldırmadan yalnızca ek koordinasyon maliyeti ekler. Teşvikler çatışmayı sürdürdüğünde birleşik veri de hizalanma üretemez: pazarlama yalnızca aday hacmine, satış ise yalnızca kapanan gelire göre ödeniyorsa, ortak bir pano mevcut anlaşmazlığı yalnızca eskisinden daha yüksek bir çözünürlükte belgelemiş olur.
Pratikte örnek
Nasıl ölçülür
Huniyi üç ayrı parça olarak değil tek bir zincir olarak ölçün: satış sonrası aşamalar dahil her yaşam döngüsü aşamasından bir sonrakine dönüşüm ve her aşamada geçen medyan süre. RevOps'a özgü sinyal devirlerdeki kaçaktır; bir aşamaya giren ve beklenen süre içinde ne ilerleyen ne de resmen elenen kayıtları sayın. Net gelir tutundurma ise döngüyü kapatır, çünkü kazanılan müşterilerin kazanmaya değer olup olmadığını gösterir.
Veriye duyulan güven kendi sinyallerini hak eder. Kazanılan fırsatların geçerli bir orijinal kaynak taşıyan payını, bir hesap kaydıyla eşleşen kişilerin payını ve temel bir metriğin hâlâ dolaşımda olan kaç rakip tanımı bulunduğunu izleyin. Tahmin doğruluğu ise bütün bunların üzerinde durur: alttaki tanımlar sessizce kaydığında, buna yol açan veri sorununu henüz kimse fark etmemişken tahmin çoktan bozulmaya başlamış olur.
Sık yapılan hatalar
En yaygın başarısızlık bir isim değişikliğidir. Satış operasyonlarına yeni bir unvan verilir; pazarlama ve müşteri başarısı kendi sistemlerini ve tanımlarını korur, organizasyon şeması dışında yapısal hiçbir şey değişmez. Bunu somut olarak test edin: üç işlevden de bir kaydın ne zaman nitelikli sayıldığını ve o anda kime ait olduğunu yazılı olarak isteyin. Yanıtlar farklıysa henüz birleşme olmamıştır ve raporlama aynı huninin üç sürümünü üretmeye devam eder.
İkinci hata, altındaki tanımlar oturmadan birleşik panoyu kurmaktır. Herkes toplantıya gelir, tanımadığı bir sayı görür ve süreyi işi konuşmak yerine sorgunun nasıl yazıldığını tartışarak geçirir. Önce her yaşam döngüsü aşamasının tanımını netleştirin, bu tanımları tüm şirketin okuyabileceği ortak bir yere yazın ve raporu ancak ondan sonra kurmaya başlayın. İnsanların kendi başlarına yeniden üretemediği sayılar, sonunda üzerine hiçbir zaman hareket etmeyecekleri sayılar olarak kalır.
Sıkça sorulan sorular
RevOps hangi sorunu çözer?
RevOps; satış, pazarlama ve müşteri başarısının çelişen metriklerle silolar halinde çalışmasından doğan hizasızlığı ve veri parçalanmasını çözer. Süreçleri, verileri ve araçları birleştirerek gelir yaşam döngüsüne dair tek ve hesap verebilir bir görünüm oluşturur ve devirlerdeki kaybı azaltır.
RevOps yalnızca yeniden adlandırılmış satış operasyonları mı?
Hayır. Sales Ops özellikle satış ekibini desteklerken, RevOps pazarlama, satış ve müşteri başarısını tek bir işletim modeli olarak kapsar. RevOps kapsam olarak daha geniştir ve tek bir departmanın hattı yerine baştan sona gelire odaklanır.
Bir şirketin RevOps'a ihtiyacı olduğu nasıl anlaşılır?
Belirtiler arasında departmanlar arası çelişen sayılar, dağınık aday devirleri, düşük tahmin doğruluğu ve kaynaktan gelire belirsiz atıf yer alır. Bu sorunlar birden fazla ekibi kapsadığında, birleşik bir RevOps işlevi genellikle kendini amorti eder.
Gelir operasyonları ekibi pratikte ne yapar?
Ortak veri modelinin, yaşam döngüsü tanımlarının, pazarlama ile satış ve satış sonrası araçlar arasındaki entegrasyonun ve üç işlevin birlikte incelediği raporlamanın sahibidir. Günlük işte bu; tanımları karara bağlamak, devirleri ölçülebilir kılmak, kayıtları tutarlı tutan entegrasyonları sürdürmek ve hedefleri işlev bazında değil tüm gelir akışı üzerinden koyan planlama sürecini yürütmek demektir.
RevOps satış operasyonlarından nasıl ayrılır?
Kapsamla. Satış operasyonları satış organizasyonunu iyileştirir: bölgeler, kotalar, CRM hijyeni ve tahminleme. RevOps ise talep yaratma ve tutundurma dahil tüm gelir yaşam döngüsünü üstlenir; yani tek bir işlevin içini değil işlevler arasındaki dikişleri sahiplenir. Satış operasyonları temsilcilerin nasıl daha hızlı kapattığını sorar, RevOps gelirin ekipler arasında nerede sızdığını.
Gelir operasyonları kime bağlı çalışmalı?
İdeal olarak, hizmet ettiği üç ekip üzerinde de yetkisi olsun diye gelirden sorumlu tek bir yöneticiye, örneğin bir CRO'ya. Yalnızca satışa bağlanması onu genelde geniş unvanlı bir satış operasyonuna dönüştürür; çünkü her öncelik çakışmasını satış kazanır. Böyle birleşik bir rol yoksa, genel müdüre veya finans yöneticisine doğrudan bağlanmak uygulanabilir bir alternatiftir.
Ayrı operasyon ekiplerinden RevOps'a ne zaman geçilmeli?
Aynı soru hangi ekibe sorulduğuna göre üç farklı yanıt almaya başladığında ve pazarlama, satış ile başarı arasındaki devirler gözle görülür biçimde kayıt kaybettiğinde. Şirket büyüklüğü, bir müşterinin geçtiği sistem ve ekip sayısı kadar belirleyici değildir. Bu noktadan önce ayrı uzmanlar genellikle birleştirilmiş bir işlevden daha hızlı hareket eder.
Bir RevOps teknoloji yığını neye benzer?
Kayıt sistemi olarak bir CRM, bir pazarlama otomasyonu, bir müşteri başarısı veya destek platformu ve bunları uzlaştıran bir katman: ister veri ambarı ister entegrasyon katmanı. Hacim büyüdükçe ambarın önemi artar; çünkü üç platform arasındaki noktadan noktaya entegrasyonlar çoğu ekibin beklediğinden daha hızlı kırılgan hale gelir.
Yeni bir RevOps lideri ilk olarak ne yapmalı?
Bir kaydın ilk temastan yenilemeye kadar gerçekte nasıl yol aldığını haritalamalı; girdiği her sistemi ve bir insanın bir şeyi yeniden yazdığı her noktayı listelemeli. Bu harita genellikle raporlama tartışmalarının çoğuna yol açan iki üç kırılmayı açığa çıkarır. Araçlara veya organizasyona dokunmadan önce bunları düzeltmek, sonraki zor tanım tartışmaları için güven kazandırır.