İletişime Geç

GTM Mühendisliği & Operasyonları - Gelir Operasyonları: Neyi Sahiplenir ve Fonksiyon Nasıl Kurulur

Gelir operasyonları, bir gelir ekibinin sayılarının onları okuyan herkes için aynı anlama gelmesini sağlayan fonksiyondur. Süreci, tanımları, tahmin metodolojisini, bölge ve prim tasarımını ve tüm bunların üzerinde çalıştığı sistemlerin sağlığını sahiplenir.

Aynı zamanda işe alınıp ardından işini yapması yapısal olarak engellenen fonksiyondur. Bu sayfa RevOps’un gerçekte neyi sahiplendiğini, ihtiyaç duyduğu yetkiyi, kendinizi konumlandıracağınız bir olgunluk modelini ve çoğu şirketin sonunda elde ettiği raporlama masasını yeniden yaratmadan fonksiyonu nasıl kuracağınızı ele alıyor.

5 dk okuma5 bölümGTM Mühendisliği & Operasyonları

Bu sayfadan çıkaracaklarınız

  • RevOps; pazarlama, satış ve müşteri başarısı genelinde süreci ve tanımları sahiplenir — yalnızca satış idaresini değil.
  • Bir araç alımını engelleme ya da bir süreç değişikliğini reddetme yetkisi yoksa RevOps, unvanı farklı bir raporlama analistidir.
  • Dört olgunluk aşaması: tepkisel, standartlaşmış, otomatikleşmiş ve öngörücü. Çoğu şirket ilk ikisi arasında sıkışmıştır.
  • RevOps tasarlar; GTM mühendisliği inşa eder. İkisini birleştirmek, kimsenin üzerinde çalışmaya vakit bulamadığı bir tasarım backlog’u üretir.

Gelir operasyonları gerçekte neyi sahiplenir

Kapsam, satış operasyonlarından geniş, “gelir ekibinin yaptığı her şey”den dardır. Şu altı alan çekirdektir ve tek kişilik bir fonksiyonda bile her birinin adı konmuş bir sahibi olmalıdır.

Tanımlar ve veri sözlüğü
Nitelikli lead, fırsat, aktif müşteri ve churn neyi ifade eder. Yazılı, sürümlenmiş ve eğitim oturumlarıyla değil zorunlu alanlar ile doğrulama kurallarıyla uygulanan.
Tüm funnel boyunca süreç tasarımı
Çıkış kriterli aşama tanımları, sahibi ve SLA’sı olan devir teslim noktaları, yükseltme yolları. Açıkça pazarlama, satış ve müşteri başarısını kapsar — bunu RevOps yapan şey çapraz fonksiyonel kapsamdır.
Tahmin metodolojisi
Tahminin nasıl kurulduğu, hangi sinyallerin beslediği, taahhüt ve en iyi durumun nasıl tanımlandığı ve doğruluğun sonradan nasıl ölçüldüğü. Yöntemi RevOps, sayıyı satış lideri sahiplenir.
Bölge, kota ve prim tasarımı
Pazarın nasıl bölündüğü, hedeflerin nasıl konduğu ve davranışın nasıl teşvik edildiği. Prim tasarımı, stratejinin davranışa dönüştüğü yerdir ve düzenli olarak destekleyici veri olmadan yapılır.
Sistem mimarisi ve araç yönetişimi
Hangi araçların var olduğu, her birinin ne için geçerli olduğu, nasıl bağlandıkları ve yenisini kimin alabileceği. Bu olmadan katman örtüşmesi ve çelişkili veri garantidir.
Raporlama ve analitik altyapısı
Metrik tanımları, ambar modelleri ve panolar. Herkes aynı soruya, kimseye sormadan aynı yanıtı alabilmeli.

Yetki sorunu

RevOps, beceri eksikliğinden çok yetki eksikliğinden başarısız olur. Fonksiyon, kendisine bağlı olmayan ekipler arasında tutarlılıktan sorumludur; bu ancak bir şeye hayır diyebiliyorsa işler.

Farkı üç somut yetki yaratır. Birincisi, mevcut bir katmanı yineleyen bir araç alımını engelleyebilme ya da geciktirebilme. İkincisi, raporlama sürekliliğini bozan bir süreç veya aşama değişikliğini reddedebilme. Üçüncüsü, veri modelinin sahipliği: kimse RevOps olmadan zorunlu alan oluşturmaz ya da seçim listesi değiştirmez.

RevOps olgunluk modeli

Dört aşama. Modelin değeri kendinizi dürüstçe konumlandırmaktır; çünkü her aşamanın belirli bir sonraki eylemi vardır ve atlamak işe yaramaz.

Tablo 01
Mevcut aşamanızı bulun, sonra son duruma değil bir sonraki eyleme çalışın.
AşamaNasıl görünürSonraki eylem
TepkiselTablolar, manuel raporlama, ekipten ekibe değişen tanımlar, pazarlığa dönüşen tahminTanımları yazın ve onaylatın. Bu yapılmadan başka hiçbir şey işe yaramaz.
StandartlaşmışOrtak tanımlar, tek CRM, tutarlı aşamalar, ekipler arası uyumlu raporlamaUygulamayı otomatikleştirin — zorunlu alanlar, doğrulama kuralları, alışkanlıkta değil kodda yönlendirme
OtomatikleşmişYönlendirme, zenginleştirme, skorlama ve hijyen insan müdahalesi olmadan çalışır; SLA’lar izlenirTrend ve kohort analizini mümkün kılan ambarı ve tarihsel anlık görüntüleri kurun
ÖngörücüTarihsel örüntülerden tahminler, erken görünen churn riski, senaryo modellemesiTitizlikle sürdürün. Bu aşama en hızlı çürür; çünkü modeller işle birlikte sessizce kayar.

Çoğu şirket tepkisel ile standartlaşmış arasındadır ve doğrudan öngörücüye atlamaya çalışır; çünkü araç pazarının sattığı budur. Tutarsız tanımlar üzerine kurulu öngörücü modeller, kimsenin ayıklayamayacağı biçimde yanlış olan kendinden emin tahminler üretir.

Fonksiyon nasıl kurulur

İlk RevOps işe alımınız da olsa yeniden kurulum da olsa aynı sıra geçerlidir. İlk üç adım dokümantasyon ve mutabakattır; bu yüzden atlanır ve bu yüzden atlamak başarısız olur.

  1. Hiçbir şeyi değiştirmeden mevcut durumu denetleyin

    Mevcut tanımları, aşamaları, araçları, raporları ve manuel süreçleri tam olduğu gibi belgeleyin. İki hafta. Çıktısını okumak rahatsız edicidir ve fonksiyonun ilk yılında üreteceği en değerli belgedir.

  2. Tanımları yazılı olarak mutabık kılın

    Tek belge: ICP, yaşam döngüsü aşamaları, niteliklendirme kriterleri, çıkış kriterli fırsat aşamaları, churn tanımı. Pazarlama, satış ve müşteri başarısı liderliğince onaylanmış. Sözlü mutabakat mutabakat değildir.

  3. Yönetişim kurallarını belirleyin

    Kim alan oluşturabilir, araç alımlarını kim onaylar, süreç değişiklikleri nasıl önerilir ve incelenir. Sıkıcıdır ve tanımların iki çeyrek içinde kaymasını önleyen şey budur.

  4. Veri modelini tanımlara göre yeniden kurun

    Zorunlu alanlar, doğrulama kuralları, seçim listesi standardizasyonu, nesne ilişkileri. Bu mühendislik işidir — ya RevOps’ta bu kapasite vardır ya da bir inşa ortağı gerekir.

  5. Funnel’ı uçtan uca ölçün

    Aşama geçiş zaman damgaları, değişmez kaynak atfı, devir teslim kaydı. Bu olmadan üçüncü adımdan sonrası tahmin yürütmektir.

  6. Uygulamayı otomatikleştirin

    Yönlendirme, zenginleştirme, hijyen işleri, SLA uyarıları. Hatırlatmalarla değil sistemlerle uygulama, bir süreçle bir öneri arasındaki farktır.

  7. Raporlamayı ambar üzerine kurun

    Sürüm kontrolündeki metrik tanımları, ambardan beslenen panolar, korunan anlık görüntüler. Artık sayılar bir pipeline yeniden tasarımını atlatır.

  8. Çeyreklik inceleme ritmi kurun

    Tanımlar, aşamalar, prim tasarımı ve stack her çeyrek incelensin. RevOps çıktısı varsayılan olarak çürür; planlı bakım, üçüncü aşamanın birinciye geri kaymasını önler.

RevOps’u etkisiz kılan hatalar

RevOps’u satış operasyonu işine almak
Görev kotalar, bölgeler ve temsilciler için CRM yönetimiyse bu satış operasyonudur. Pazarlama ve müşteri başarısı verisi, kimse sahiplenmediği için bozulmaya devam eder.
RevOps’u finansın altına koymak
Doğru, geriye dönük ve gelir ekibinin işleyişini değiştirmeye yapısal olarak muktedir olmayan bir yapıya dönüşür. Fonksiyona işleyiş yetkisi veren şey, gelir liderine bağlı olmasıdır.
Tasarım ile inşayı tek kişiden beklemek
İnşa backlog’u her zaman mevcut haftayı aşar; o noktada tasarım durur. Rolleri ayırın ya da bir RevOps tasarımcısını dış mühendislik kapasitesiyle eşleştirin.
Tanımlar netleşmeden araç almak
Tanımsız bir sürece göre yapılandırılan bir araç, belirsizliği kalıcı olarak kodlar ve sonradan düzeltmeyi pahalılaştırır.
Fonksiyonu raporlama birimi gibi görmek
RevOps haftasının çoğunu talep üzerine rapor üretmekle geçiriyorsa bir hizmet masasına dönüşmüştür. Raporları otomatikleştirin ve zamanı sürece ve sistemlere yatırın.

Sık sorulan sorular

Gelir operasyonları nedir?

Gelir operasyonları; pazarlama, satış ve müşteri başarısı genelinde süreci, tanımları, tahmin metodolojisini, bölge ve prim tasarımını ve sistem mimarisini sahiplenen fonksiyondur. Amacı, gelir mekanizmasını uçtan uca tutarlı ve ölçülebilir kılmaktır.

RevOps ile satış operasyonları arasındaki fark nedir?

Satış operasyonları özellikle satış ekibini destekler — kotalar, bölgeler, temsilciler için CRM yönetimi. RevOps ise pazarlama ve müşteri başarısı dahil tüm gelir mekanizmasında süreci ve veriyi sahiplenir. Onu ayıran şey çapraz fonksiyonel görevidir.

RevOps kime bağlı olmalı?

Gelir liderine — CRO’ya, CRO olmayan şirketlerde CEO’ya — müşteriye dönük tüm fonksiyonlar üzerinde yetkiyle. Finansa bağlanmak onu geriye dönük bir raporlama fonksiyonuna çevirir; satışa bağlanmak pazarlama ve müşteri başarısı veri kalitesini bozar.

İlk RevOps çalışanımızı ne zaman işe almalıyız?

Kimse bir tablo açmadan bir pipeline sorusunu yanıtlayamadığında ya da iki ekip aynı metrik için farklı sayılar raporladığında. Pratikte bu genellikle gelir organizasyonunda on beş ile otuz kişi arasındadır.

RevOps, GTM mühendisliğinin yerini alır mı?

Hayır. RevOps süreci tasarlar ve sistemlerin ne yapması gerektiğini tanımlar. GTM mühendisliği bu sistemleri kurar ve sürdürür. Tek kişi ikisini kısa süre yapabilir ama inşa backlog’u tasarım işinden hızlı büyür ve önce tasarım durur.
Tasarımın inşa kapasitesine ihtiyacı var

Bir RevOps yol haritası ancak yayına çıktığında sayılır

Mühendislik yarısını biz sağlıyoruz: veri modeli yeniden kurulumları, uygulama otomasyonu, ambar ve raporlama altyapısı — RevOps tasarımınız backlog değil sistem olsun diye.