Yeni B2B Talep Şelalesi

Bir süredir Pazarlama Operasyonları veya Gelir Operasyonları dünyasındaysanız, muhtemelen talep şelalelerine aşinasınızdır. Orijinal talep şelalesi, 2000'lerin başlarından ortalarına kadar SiriusDecisions (şimdi Forrester'ın bir parçası) tarafından yayınlandı. MQL'ler, SAL'ler ve SQL'ler gibi bir dizi yeni kavramı dünyaya tanıttı ve B2B markalarının büyük çoğunluğu tarafından benimsendi.

ABM popülerlik kazandıkça, orijinal talep şelalesi artık ABM'ye veya hibrit pazara açılma hareketlerine geçiş yapan birçok B2B markasının ihtiyaçlarını karşılamıyor. Bu nedenle, birkaç yıl önce SiriusDecisions, "Talep Birimi" kavramını tanıtan yeni bir sürüm yarattı. Şelalenin bu versiyonu orijinal versiyonu kadar başarılı olmadı, ancak bazı B2B markaları onu yakaladı.

Şimdi, geçen yıl Forrester markası altında piyasaya sürülen başka bir versiyon daha var. Bu yeni sürüm hakkında daha fazla bilgiyi burada görebilirsiniz .

Bu yeni sürüm, eski sürümden çok daha radikal bir şekilde ayrılıyor ve bunun nasıl uygulanacağı konusunda birçok soru ve endişe yarattı. Bu makalede, en büyük değişiklikleri, sizin için ne anlama geldiklerini ve bunların ortak teknoloji ekosistemlerinde nasıl uygulanacağına dair bazı stratejileri inceleyeceğiz.

Hadi dalalım…

Her Şey Dahil Fırsatlar

En büyük ve en çok endişeye neden olan değişiklik, Forrester tarafından önerilen yeni B2B talep şelalesinin %100 Fırsatlara dayalı olmasıdır.

NE?!?

Evet… artık Müşteri Adayları, Kişiler ve Hesaplar yok. Eh, tamamen gitmezler. Süreç için Fırsatlardan çok daha az önemlidirler. Bu yeni modelde, tüm gelir ekibi Fırsatlar etrafında hizalanmıştır. Forrester'ın bunu düşünme şekli aşağıdaki ekran görüntüsündedir.

Bunu biraz daha parçalayalım.

Fırsat Türü

Yukarıda göze çarpan bir şey, dört farklı Fırsat türüne sahip olma ihtiyacıdır; Edinme, Tutma/Yenileme, Yukarı Satış ve Çapraz Satış. Şu anda ekosisteminizde buna benzer bir şeye sahip olmalısınız, ancak yoksa, bu başlamak için oldukça kolay bir şeydir.

En azından, Fırsat alanında "Tür" veya "Fırsat Türü" adı verilen ve Fırsatı oluşturanın bu türlerden birini seçmesine olanak tanıyan bir seçim listesi içeren bir alana ihtiyacınız vardır. Daha karmaşık kuruluşlar, bunun yerine size daha fazla işlevsellik sağlayacak olan Fırsat Kayıt Türünü kullanmayı seçebilir, ancak şimdilik bunu basit tutalım.

Artık, şirketinizin ürünlerine ve ürün stratejisine bağlı olarak Upsell ve Cross-Sell için ayrı Fırsat Türlerine ihtiyacınız olmayabilir. Yani, dördü de gerekli değildir. Birincil amaç, farklı Fırsat türleri arasında ayrım yapabilmektir.

Fırsat Yaratma

Eski talep şelalesi tarzına alıştıysanız, SDR ekibinin MQL'yi doğruladığı ve Satışların SDR ekibinin gönderdiği müşteri adayını doğruladığı zaman arasında yaratılan Fırsata alışmışsınızdır. Farklı kuruluşlar, yolculuğun farklı noktalarında Opps oluşturur, ancak genellikle oralarda bir yerdedir.

Yukarıdaki grafiğe göre, Opp oluşturma yeni dünyada çarpıcı biçimde değişecek. Muhtemelen alışkın olduğunuzdan çok daha erken bir süreçte gerçekleşecek. Kesin “nerede” olsa da, bazı yorumlar için hala hazır. Bazı kuruluşlar için, bir hedef hesap belirlediğiniz anda Opp'yi oluşturmak isteyeceksiniz (yani, yukarıdaki dönüşüm hunisinin ilk satırı).

Diğer kuruluşlar için, Opp'yi daha sonra dönüşüm hunisinde "Hedeflenen Fırsat" veya "Etkileşimli" bölümünde oluşturmak isteyeceksiniz. Yine de burada biraz esneklik var.

Fırsatları kimin yarattığı hakkında da konuşmamız gerekiyor. Bu, yolculukta Opps'u yarattığınız zamana büyük ölçüde bağlı olacak. Ayrıca, Opp türüne de bağlı olabilir.

Opp'yi yolculuğun en başında oluşturuyorsanız, bu Opp oluşturma işlemi muhtemelen otomatikleştirilmeli veya Pazarlama tarafından oluşturulmalıdır. Opp'yi yolculuğun ilerleyen saatlerinde oluşturuyorsanız, Opp oluşturma işlemi, o etkileşim aşamasına sahip olan kişiye ait olmalıdır… ya SDR ya da Satış temsilcisi.

Bu, Edinme Fırsatı Türü için gerçekten iyi çalışıyor, peki ya diğerleri? Bunu otomatikleştirmenizi şiddetle tavsiye ederiz. Edinme Fırsatı Kapatıldığında Kazanıldı, Yenileme Opp'sinin oluşturulmasını otomatikleştirebilirsiniz (kapanış tarihi sözleşme süresine ve tutar önceki Opp tutarına göre). Bu Opp Türlerini kullandığınız sürece, Upsell Opp ve Cross-Sell Opp'yi de oluşturabilirsiniz. Bu Opps'un mülkiyeti, mevcut Müşteriler için kuruluşta bu hareketlerden birincil olarak sorumlu olan kişiye dayanmalıdır.

Liderlere Ne Olur?

Bu, birçok kuruluş için büyük bir değişiklik olabilir, ancak Lead nesnesini kullanmaktan uzaklaşan birçok kuruluş da gördük. Bu geçişi zaten yaptıysanız, muhtemelen zaten bir çözümünüz vardır.

Yine de Lead nesnesini tamamen terk edemezsiniz. Bunun nedeni, Pazarlama Otomasyon Platformlarının (MAP'ler) büyük çoğunluğunun yalnızca CRM'de Müşteri Adayları oluşturmasıdır. Şimdi, bazıları Müşteri Adayı dönüşümü yapabilir, ancak bunu idealden daha az bir şekilde yaparlar ve bu da çok sayıda yinelenen kaydın (Kişiler ve Hesaplar) oluşturulmasına yol açar. O yüzden hiç tavsiye etmiyoruz. Bunu sizin için yapmak için bir müşteri adayı (L2A) eşleştirme aracı kullanmanızı öneririz. Bizim favorimiz LeanData , ancak piyasada başkaları da var.

Bunu düzgün bir şekilde ayarlamak için, MAP'nizin CRM'nizde Lead'ler oluşturmasını istiyorsunuz. Ardından, LeanData'nın (veya diğer L2A aracınızın) bu Müşteri Adayını mevcut bir Hesapla eşleştirmesini istiyorsunuz. Eşleşme belirlendikten sonra, L2A aracınız bu Müşteri Adayını bir İlgili Kişiye dönüştürecek ve bu Kişiyi eşleşen Hesapla ilişkilendirecektir.

Eşleşme olmazsa veya yepyeni bir Hesap olursa ne olur? L2A sisteminize iki farklı yaklaşımdan birini seçmesi talimatını verebilirsiniz. Seçenek 1, Müşteri Adayını dönüştürmek ve yeni bir Hesap oluşturmaktır. Seçenek 2, bir Gelir Operasyonları ekip üyesini eşleşme olmadığı konusunda uyarmak ve RevOps görevlisinin manuel dönüştürme ve Hesap oluşturma işlemi yapmasını sağlamaktır. 1. Seçenek tercih edilir, çünkü otomasyon neredeyse her zaman tercih edilir, ancak yeni Hesapların oluşturulmasına insan gözünün dahil olmasını istiyorsanız Seçenek 2 iyi çalışır.

Bu L2A eşleştirme işlemi sırasında (yolculukta Opps'lerinizi ne zaman yarattığınıza bağlı olarak) L2A aracının ayrıca Edinme Fırsatını oluşturmasını sağlayabilirsiniz. L2A araçlarının çoğu, dönüştürme işleminin bir parçası olarak bunu yapabilir.

Satın Alma Grupları/Komiteleri

Yeni B2B talep şelalesinin bir diğer önemli unsuru, satın alma gruplarının veya komitelerinin onaylanması, operasyonel hale getirilmesi ve önemidir. B2B'deki çoğumuzun bildiği gibi, çoğu zaman satın alma kararları veren bir grup insan vardır. Etkileyenler, karar vericiler, imzalayanlar ve dahil olan diğer kişiler var. Eski talep şelaleleri grup satın almakla pek ilgilenmezdi ama yenisi… büyük zaman alıyor.

Bunun düzgün çalışması için, satın alma grup(lar)ımızdaki kişilerin kim olduğunu belirlememiz gerekir. Çünkü bir Hesap içinde birden fazla Fırsata yol açan birkaç satın alma grubunuz olabilir. Ve bireysel kişiler, çoklu satın alma gruplarında bir rol –bazen farklı bir rol– oynayabilir. Bu nedenle, yarattığımız Fırsatlarda kilit oyuncuların kim olduğunu belirlememiz gerekiyor.

Bunu, Fırsat İletişim Rolü (OCR) aracılığıyla yaparız. Ve yeni talep şelalesinde daha da büyük bir önem kazanıyor.

Satın alma gruplarımızın OCR aracılığıyla Fırsatlarımıza eklenmesi gerekiyor. Bu, birkaç yöntemden biriyle yapılmalıdır.

Gelen Tanımlama

Yeni bir Müşteri Adayı geldiğinde ve eşleşen Hesaba dönüştürüldüğünde, bu kişinin yeni bir Opp veya mevcut bir Opp için satın alma grubunun bir parçası olup olmadığını değerlendirmemiz gerekir. Bunu anladıktan sonra, o kişiyi OCR aracılığıyla Opp'ye manuel olarak ekliyoruz.

Bu, bir istisna dışında, çoğunuzun aşina olduğu geleneksel talep oluşturma sürecine benzer. Bu istisna, muhtemelen bu yeni kişiyi mevcut bir Opp ile eşleştirme sürecidir.

Araştırmaya Dayalı Tanımlama

Bu yeni talep şelalesinin ABM ile oldukça uyumlu olduğu ABM kullanıyorsanız, bu yaklaşım çok iyidir. Ayrıca, Opp'yi yolculuğun en başında oluşturuyorsanız, gerçekten iyi çalışır.

Bu metodolojide, Pazarlama, Geliştirme ve Satış ekipleriniz, satın alma grubuna dahil olacak tüm oyuncuları, unvanlarının ve rollerinin ne olabileceğini veya ne olması gerektiğini belirlemek için işbirliği yapacaktır. Ardından, o satın alma grubunu oluşturan gerçek kişileri bulmak için LinkedIn Sales Navigator, ZoomInfo veya Clearbit gibi bir araç kullanacaksınız. Onları bulduğunuzda, bilgilerini CRM'nize aktaracak ve OCR aracılığıyla Opp'lerine manuel olarak eşleyeceksiniz.

Bu, üç takımın da (Pazarlama, Satış Geliştirme ve Satış) Fırsatı bitiş çizgisine getirmeye yardımcı olabilecek kişileri belirlemesine, hedeflemesine ve etkileşime geçmesine yardımcı olan oldukça proaktif bir metodolojidir.

Müşteri Adayı Puanlaması, satın alma yolculuğunun herhangi bir aşamasında sosyal yardım çabalarımızın etkinliğini ölçmek için bu metodolojiyle birlikte kullanılabilir. Herhangi bir ilerleme kaydedip kaydetmediğimizi görmek için toplu müşteri adayı puanlarına veya bireysel müşteri adayı puanlarına bakabiliriz. Satın alma grubunun diğerlerine göre daha az meşgul olan ve onları daha fazla hedef alan üye olup olmadığını görebiliriz.

Bu çok verimli bir metodolojidir, ancak biraz zaman alıcıdır ve biraz manuel çaba gerektirir.

Müşteri Bazlı Tanımlama

Bu muhtemelen satın alma grubunuzu belirlemenin en kolay ve en etkili yoludur. Ve genellikle yalnızca mevcut müşterilerle ilgili Opps'ta kullanılır.

Çoğu durumda, satın alan grubun kim olduğunu zaten biliyor olabiliriz. Bunu yaptığımızda, mümkün olan en erken aşamada Opp'ye sahip olan kişinin, müşteri şirket hakkındaki bilgilerine dayanarak bu kişileri OCR aracılığıyla Opp'ye eklemesi önemlidir.

Satın Alma Gruplarında Yapılan Değişiklikler

Satın alma gruplarının değişebilmesi mümkündür… insanlar rollerine, şirketteki durumlarına, Opp türüne vb. göre gelip gidebilirler. Ve Opp'deki satın alma gruplarımız bunu yansıtmalıdır. Satın alma grubu üyelerimizin kimler olduğu ve oynadıkları roller hakkında daha fazla bilgi edindiğimiz için süreç boyunca satın alma grubuna kişi ekleyip çıkarmamamız için hiçbir neden yok. Bunu ne kadar güncel tutarsak, o kadar iyi durumdayız.

Fırsat Aşamaları

Yukarıdaki grafikte, Forrester'ın satın alma sürecindeki birkaç aşamayı özetlediğini fark edeceksiniz. Ancak bunlar sizin ve kuruluşunuz için geçerli olmayabilir. Veya Opp'yi, o resimde belirtilenden daha sonra alıcı yolculuğunda oluşturmayı seçebilirsiniz. Ayrıca, şüphesiz, yolculukta mevcut Aşamalarınızdan daha erken olan yeni Opp Aşamalarına sahip olacaksınız. Dolayısıyla, CRM'nizde Opp Aşamalarınızı yeniden tasarlamanız gerekecek, çünkü her türlü dönüşüm izlemeyi bu şekilde yapacaksınız.

Bu alıştırmayı, oluşturacağımız her Fırsat Türü için aşamaları olan bir huni oluşturduğumuz bir LucidChart kullanarak yaptık. Ardından, yolculuğun pazarlama parçasına hangi aşama(lar)ın, yolculuğun Satış Geliştirme parçasına hangi aşama(lar)ın, yolculuğun Satış parçasına hangi aşama(lar)ın uyumlu olduğunu buluruz. Müşteri Opp Türleri ayrıca, Müşteri Başarısı/Destek ile hangi aşamaların uyumlu olduğunu belirlememiz gerekir.

Bu süreçten geçtikten sonra, aşamalara isim vermeli ve geçiş kurallarını ve bir Opp'nin bir aşamadan diğerine nasıl geçeceğini belirlemeliyiz. Bunların hepsi çok açık bir şekilde ana hatlarıyla belirtilmelidir, çünkü bunlardan bazılarını otomatikleştirmek isteyeceksiniz. Örneğin, bir müşteri için, Satın Alma Grubunun bir üyesinin 100 puanın üzerinde bir Müşteri Puanına (talep genine benzer) sahip olmasına dayalı olarak, nihai Pazarlama aşamasından SDR aşamasına geçiş sürecini otomatikleştirdik. Bu, kuruluşunuz için işe yarayabilir veya çalışmayabilir.

Bu sürecin bir diğer kilit unsuru, sürecin bir parçası olarak gerçekleşen tüm aktarmaların –ya da daha iyisi, el sıkışmaların– ana hatlarını belirleme ihtiyacıdır. Talep şelalesinin önceki örneğinde, bunlar genellikle elden çıkarmalardı. Bu devirler neredeyse her zaman verimsiz, tembeldi ve hunideki en büyük sızıntı kaynaklarından biriydi. Bu nedenle, bir el sıkışmadan çok bir el sıkışma öneriyoruz. Bu el sıkışmanın nasıl olacağını açıkça belirtmek istiyorsunuz. RACI neye benziyor, kimin hangi yönlere sahip olduğu, bir sonraki adıma kimin sahip olduğu, bir sonraki adımın ne olduğu ve her adım için SLA'lar dikkate alınması gereken şeylerdir.

Bu aynı zamanda bu yeni talep şelalesinin size yardımcı olacağı yer… ve bu raporlama ile olur.

Raporlama

SFDC'yi lanetlediyseniz ve Lider ve İlgili Kişi ayrımında raporlamayla ilgili sorunlar varsa lütfen elinizi kaldırın. Eliniz çatınıza bir delik açtıysa, yalnız değilsiniz. Hepimiz seninleyiz.

Ancak bu yeni talep şelalesi bunu çözüyor. Çünkü artık aşamalar, dönüşümler, yaşlanma ve hız için tüm raporlamalarınız tek bir nesne üzerinden yapılıyor… Fırsat nesnesi. VE, Opps'lerinizi farklı türlere ayırdığınız için, hakkında rapor oluşturabileceğiniz birkaç farklı huni türüne sahip olacaksınız… her Opp Türü için bir tane.

Bu, raporlamanızı çok daha kolay ve çok daha verimli hale getirir. Ancak bunu yapmak için yalnızca geleneksel Fırsat raporlamasına güvenemezsiniz. Bunu yaparsanız, masaya çok fazla raporlama değeri bırakacaksınız.

Her Fırsat Türü için her Fırsat Aşaması için bir tarih alanı oluşturmanızı öneririz.

Not: Fırsat nesnesini tonlarca alanla karıştırmamak için, yalnızca Opp Türü alanı yerine Fırsat Kayıt Türü'nü kullanmanın yararlı olduğu yer burasıdır.

Tarih alanları yerindeyken, Opp'nin bu yeni aşamaya geçiş tarihini damgalamak için otomasyona ihtiyacınız var. Bu alanlara bir kez tarihleri ​​damgaladığınızda, aşamalı dönüşümler hakkında rapor verme olanağınız gerçekten sınırsızdır.

Bazılarınız bu tarih damgalama olayının biraz abartı olduğunu düşünüyor olabilir çünkü SFDC zaten sahne geçişlerini izliyor. Ve bazı yönlerden haklısın. Ancak, bunun çözdüğü birkaç sorun var.

İlk olarak, yalnızca SFDC'nin kullanıma hazır aşama takibine güveniyorsanız (Geçmiş İzlemeyi kullanarak), kullanabileceğiniz tek bir rapor türüyle sınırlısınız ve bu, Fırsat Geçmişi rapor türüdür. Bu rapor türü, Opp raporlamanızı diğer nesnelerle ilişkilendirme yeteneğinizi sınırlar. Ürünler, Kampanyalar veya İlişkilendirme nesneleri gibi nesneleri düşünüyorum.

İkincisi, kullanıma hazır aşama takibine güveniyorsanız, SFDC'nin raporlamasını kullanmanız gerekecek. Bu verileri Tableau veya Power BI gibi bir BI aracına çok iyi aktaramazsınız.

Üçüncüsü, kullanıma hazır aşama izlemeye güveniyorsanız, SFDC'deki raporlama hala biraz eksik. Gerçek alanlara damgalanmış tarihleriniz varsa, hız ve yaşlanma raporları almayı denemeyi daha zor hale getirir.

Kapanış

“Bunu nasıl uygularım” sorusuna verilen yanıtların çoğu, her kuruluş için biraz farklı olacağı yönündedir. Bu, herkese uyan tek beden veya hatta çoğu kişiye uyan tek beden önermesi değildir.

Bu yeni talep şelalesine geçiş yapacaksanız – ve bunun bazı avantajları var – pazara nasıl gideceğinizi yeniden tasarlamak için çok çalışmanız gerekecek. Gelir sürecine dahil olan tüm ekiplerinizin bu değişiklik için aynı sayfada olması gerekecek. Bir takım gemideyse, bu değişikliği yapamazsınız. Ancak bu, bu modele geçmenin en büyük kazançlarından biri. Pazarlama, Satış Geliştirme, Satış ve Müşteri Başarısı, bu model uygulandıktan sonra çok daha uyumlu hale gelmelidir. Ve bu ekipler bir kez hizalandığında, satış sürecinizde çok daha az sürtüşme ve daha az sızıntı olacaktır.