HubSpot Kurulumu Nasıl Planlanır? B2B Şirketler İçin Veri Modeli, Pipeline ve Devreye Alma Rehberi

HubSpot kurulumu bir yazılım kurulumu değil, şirketin satış ve pazarlama süreçlerinin yazıya dökülmesidir. Lisans alındıktan sonra ekranları açıp “önce bir kullanalım, sonra düzeltiriz” demek, çoğu projede altı ay sonra temizlenmesi gereken bir veri yığını üretir. Kurulum öncesinde cevaplanması gereken sorular aslında teknik değil: Kimi kayıt altına alıyoruz? Fırsat ne zaman doğar? Hangi alanı kim doldurur? Bir aşamadan diğerine geçiş kararını kim verir?

Bu rehber, HubSpot’a geçiş kararını yöneten pazarlama ve satış operasyonu sorumluları için yazıldı. Amaç, kurulum düğmesine basmadan önce elinizde yazılı bir kurulum planı olması: veri modeli, pipeline aşamaları, zorunlu alanlar, sahiplikler ve devreye alma sırası. Planın kendisi birkaç sayfalık bir dokümandır. Kurulum sırasında bu dokümanı referans alırsınız, kurulumdan sonra ise “neden böyle kurmuştuk” sorusunun cevabı burada durur.

Mochatouch olarak HubSpot ajansı tarafında yaptığımız iş tam olarak bu: hedefleri konuşup doğru soruları sorarak CRM yazılımını şirketin süreçlerine göre şekillendirmek ve üçüncü parti uygulamaları da dahil ederek silo yapılarının önüne geçmek. Aşağıdaki çerçeve, o konuşmalarda hangi kararların masada olması gerektiğini gösteriyor. Daha geniş CRM bağlamı için CRM yazılarımıza, HubSpot’a özgü diğer içerikler için HubSpot kategorimize bakabilirsiniz.

Kurulum planı neden önce yazılır?

HubSpot’un iyi tarafı hızlı başlatılabilmesidir. Kötü tarafı da aynı şey: hiçbir karar vermeden ilk kaydı oluşturabilirsiniz. İlk üç ayda bu zararsız görünür. Dördüncü ayda yönetim “kaç fırsatımız var” diye sorduğunda tablo şöyle olur: iki satış temsilcisi aynı şirketi iki ayrı kayıt olarak açmıştır, bir kısım fırsatın kapanış tarihi geçmiştir ama aşaması hâlâ “Teklif”, pazarlamanın gönderdiği 40 formun kaçının gerçekten değerlendirildiği bilinmez çünkü kimse kaynak alanını doldurmamıştır.

Bu sorunların hiçbiri yazılım hatası değil. Hepsi, kurulum öncesinde verilmeyen kararların sonucudur. Yazılı plan şu dört işi yapar:

Tanımları sabitler. “Fırsat” kelimesi pazarlama ve satış için aynı şeyi ifade etmiyorsa raporlar tartışma üretir. Planın içinde her nesne ve her aşama için tek cümlelik bir tanım bulunur.

Zorunluluğun bedelini görünür kılar. Her zorunlu alan, bir satış temsilcisinin gününden saniye çalar. Planı yazarken “bu alanı neden zorunlu yapıyoruz ve bu veriyi hangi raporda kullanacağız” sorusuna cevap veremiyorsanız, alan zorunlu olmamalıdır.

Sahiplik boşluklarını erken gösterir. Kimin hangi nesnede hangi yetkiyle çalıştığı yazılmadığında, devreye alma sonrası ilk çatışma kayıt sahipliği üzerinden çıkar.

Devreye alma sırasını belirler. Her şeyi aynı anda kurmaya çalışmak, en sık görülen tıkanma nedenidir. Bunu e-posta pazarlaması tarafında da gözlemledik: izin ve veri temeli düzeltilmeden kurulan her akış, bozuk veri üzerine inşa edilmiş oluyor (B2B E-Posta Pazarlama Rehberi). CRM kurulumunda da aynı mantık geçerli: veri modeli oturmadan otomasyon kurmayın.

Plan uzun olmak zorunda değil. Beş bölümü olan, her bölümü yarım sayfayı geçmeyen bir doküman yeterli: veri modeli, pipeline, alanlar, sahiplik ve roller, devreye alma takvimi.

Veri modeli: kişi, şirket, fırsat ve aralarındaki ilişki

HubSpot’un temel nesneleri kişi (contact), şirket (company) ve fırsat (deal). Bunlara bilet (ticket) ve kullandığınız sürüme göre özel nesneler eklenebilir. Kurulum planının ilk kararı, bu nesnelerin sizin işinizde neyi temsil ettiğidir.

Nesneleri işinize göre tanımlayın

B2B’de en sık yapılan hata, kişi merkezli düşünmektir. Pazarlama otomasyonu alışkanlığı kişiyi merkeze koyar; oysa B2B satın alma kararı çoğu zaman tek kişinin kararı değildir. Bir teknoloji veya karmaşık hizmet alımında pazarlama, satış, finans, operasyon ve üst yönetimden farklı kişiler aynı karara farklı açılardan dahil olur (Başarı tanımı yoksa metrikler nasıl değerlendirilmeli). Bu, veri modeli için şu anlama gelir: raporlamanın ağırlık merkezi şirket ve fırsat olmalı, kişi ise satın alma komitesindeki rolüyle birlikte kaydedilmelidir.

Pratikte dört tanımı yazın:

Bu tabloyu şablon olarak değil, kendi cümlelerinizle doldurulacak bir form olarak kullanın. Tanımlardaki en kritik olanı fırsattır, çünkü pipeline raporlarınızın tamamı bu tanıma dayanır.

Fırsat ne zaman doğar?

Bu soruya verilecek cevap, kurulumun en çok tartışılan maddesidir. Üç yaygın yaklaşım var:

İlk nitelikli temasta açılır. Satış, keşif görüşmesini yaptıktan ve bütçe/ihtiyaç sinyali gördükten sonra fırsat oluşturur. Pipeline daha temiz kalır, ama pazarlamanın ürettiği ilginin ne kadarının fırsata döndüğünü görmek için ayrı bir ara katman gerekir.

Her kabul edilen talepte açılır. Satışın kabul ettiği her başvuru fırsat olur. Dönüşüm hunisi uçtan uca tek nesnede izlenir, ama erken aşamalar şişer ve ortalama fırsat değeri anlamsızlaşır.

Hesap bazlı açılır. ABM yürütüyorsanız, hedef hesap aktif hale geldiğinde fırsat açılır, kişiler bu fırsata bağlanır. Hesap bazlı raporlama kolaylaşır, ama aynı hesapta birden fazla paralel satış konusu varsa ayrıştırma zorlaşır.

Hangisini seçeceğiniz satış döngünüzün uzunluğuna ve pazarlamanın raporlama ihtiyacına bağlı. Uzun döngülü kurumsal satışta birinci yaklaşım genellikle daha okunabilir pipeline üretir; pazarlamanın katkısını görmek için de MQL ve SQL durumlarını kişi/şirket üzerinde ayrıca tutmak gerekir. Önemli olan, hangi yaklaşımı seçerseniz seçin kararı plana yazmak ve istisna üretmemektir.

İlişkileri ve çoklamayı baştan düşünün

İki pratik karar daha:

Birincisi, bir kişinin birden fazla şirkete bağlanabilmesi. Danışman, bayi veya grup şirketi yapılarında bu gerçekten olur. Varsayılan davranışı bilerek seçin, sonradan değiştirmek veri taşıma işi çıkarır.

İkincisi, yinelenen kayıt (duplicate) politikası. HubSpot kişileri e-posta adresine göre tekilleştirir; şirketlerde ise alan adı (domain) temel ayırıcıdır. Serbest e-posta adresleriyle (gmail, outlook) gelen formlar ve alan adı olmayan şirket kayıtları bu mekanizmanın dışında kalır. Plana şu satırı yazın: “Alan adı olmayan şirket kaydı açılmaz; serbest e-posta ile gelen form kişisi, şirketle manuel eşleştirilir ve haftalık kontrol edilir.”

Taşınacak veriyi kurulum planının parçası sayın

Mevcut CRM’den veya Excel’den veri taşıyacaksanız, taşıma kuralları veri modeli bölümünün içinde yer almalıdır. Üç soruyu yazın: Hangi kayıtlar taşınacak (örneğin son 24 ayda temas edilmişler), hangi alanlar eşleşecek, hangi kayıtlar bilerek dışarıda bırakılacak? Eski sistemdeki her alanı taşımak, yeni sistemi kurulduğu gün kirletmenin en hızlı yoludur. İzin durumu belirsiz olan e-posta listelerini taşımadan önce İYS uyumunu netleştirin.

Pipeline: aşamalar, geçiş kriterleri ve kapanış

Pipeline’ın işi, bir fırsatın nerede olduğunu ve ilerleyip ilerlemediğini göstermektir. İyi kurulmuş bir pipeline’da her aşamanın cevabı tek bir soruya bağlanır: bu aşamadan çıkmak için ne olmalı?

Aşama sayısı ve adlandırma

Beş ile yedi aşama çoğu B2B satış süreci için yeterlidir. Daha azı, satış döngüsünün uzun olduğu işlerde ilerlemeyi görünmez kılar; daha fazlası, temsilcinin kaydı güncellemeyi bırakmasına yol açar. Bu bir kural değil, başlangıç önerisi. Aşama sayısını artıracak şey şudur: iki aşama arasında, haftalarca süren ve ayrı bir çalışma gerektiren bir faz varsa (örneğin güvenlik incelemesi veya PoC), o faz kendi aşaması olmayı hak eder.

Adlandırmada satışın yaptığı işi değil, müşterinin bulunduğu durumu yazın. “Teklif gönderildi” bizim eylemimizdir ve müşteri teklifi okumamış olabilir. “Teklif değerlendiriliyor” ise müşteri tarafındaki durumu anlatır ve bir sonraki adımı daha net gösterir.

Her aşamaya çıkış kriteri yazın

Aşama tanımı olmayan pipeline, temsilciye göre değişen bir tahmin aracına dönüşür. Örnek bir çerçeve:

Bu tablo örnektir, kendi sürecinize göre yeniden yazılmalıdır. Dikkat edilecek nokta, kriterlerin gözlemlenebilir olmasıdır. “Müşteri ilgili görünüyor” kriter değildir; “bütçe sahibi görüşmeye katıldı” kriterdir.

Kapanış, kayıp nedeni ve bayat fırsatlar

Üç küçük karar, pipeline raporlarının güvenilirliğini belirler:

Kayıp nedeni zorunlu olsun. Sabit bir liste kullanın (fiyat, zamanlama, rakip, iç karar değişikliği, yanıt alınamadı, uygun değil) ve serbest metin alanını açıklama için ayrı tutun. Bu alan, pazarlamanın hangi kampanyadan gelen taleplerin neden ilerlemediğini görmesini sağlar. Pazarlama ve satışın aynı başvuru grubundaki ret nedenlerini birlikte incelemesi, “lead sayısı arttı ama satış memnun değil” tartışmasını veriyle çözen tek yoldur.

Kapanış tarihi disiplinini tanımlayın. Kapanış tarihi geçmiş ve hâlâ açık duran fırsat, tahmin raporunu bozar. Plana şunu yazın: kapanış tarihi geçen fırsatlar haftalık gözden geçirmede ya ileri tarihe alınır ya kapatılır.

Bayatlama eşiği koyun. Örneğin 30 gün hareket görmeyen fırsat için otomatik hatırlatma. Eşik sayısı sizin satış döngünüze bağlıdır; uzun döngülü kurumsal satışta 30 gün erken olabilir. Önemli olan, eşiğin yazılı olması ve bir sahibinin bulunması.

Birden fazla pipeline ne zaman gerekir?

Yeni satış ve yenileme aynı pipeline’da takip edilemez, çünkü aşamaları ve kazanma olasılıkları farklıdır. Benzer şekilde, farklı ürün hatları tamamen farklı satış süreçlerine sahipse ayrı pipeline mantıklıdır. Ama her segment için ayrı pipeline açmak raporlamayı parçalar. Ölçüt şu: aşamalar farklıysa ayrı pipeline, sadece müşteri profili farklıysa aynı pipeline içinde bir ayırıcı alan.

Zorunlu alanlar ve veri kalitesi

Alan tasarımı, kurulumun en kolay şişen bölümüdür. Herkes bir şey ister, hepsi eklenir, altı ay sonra kayıtların yarısı boş kalır.

Alan eklemeden önce sorulacak soru

Her yeni özel alan için üç satır yazın: bu alan hangi raporda veya hangi otomasyonda kullanılacak, kim dolduracak, doldurulmazsa ne olur. Üçüncü sorunun cevabı “bir şey olmaz” ise alan zorunlu değildir, hatta muhtemelen gerekli de değildir.

Veri toplama iştahını sınırlamanın bir başka nedeni de form tarafında ortaya çıkar: form alanlarını ve giriş noktası etiketlerini elden geçirmek, kurulumun ilk adımlarından biridir. Formda sorduğunuz her alan dönüşüm oranından bir şey götürür; CRM’de zorunlu tuttuğunuz her alan satış temsilcisinin zamanından bir şey götürür.

Minimum veri seti

Başlangıç için yeterli olan çekirdek şöyle kurulabilir:

Kişide: ad soyad, e-posta, şirket bağlantısı, rol/unvan, satın alma komitesindeki rol (karar verici, etkileyen, teknik değerlendirici, kullanıcı), iletişim izni durumu, ilk kaynak.

Şirkette: şirket adı, alan adı, sektör, çalışan sayısı aralığı, ICP uygunluğu (uygun / kısmen / uygun değil), hesap sahibi.

Fırsatta: fırsat adı, bağlı şirket, tutar, kapanış tarihi, aşama, kaynak, kayıp nedeni (kapanışta zorunlu), bir sonraki adım.

Bu listeyi uzatmadan önce mevcut raporlama ihtiyacınızı kontrol edin. Aylık kanal raporunun iskeleti beş sütunla yeterli olabiliyor: harcama, lead, MQL, SQL, kapanan müşteri. Sütun sayısı arttıkça rapor okunmaz hale gelir (B2B Lead Generation Rehberi). Aynı sadelik tercihi alan tasarımı için de geçerli: veri modelinin işi rapor üretmek, arşiv tutmak değil.

Kaynak ve atıf alanları

Atıf konusunda dürüst olmak gerekir: son tıklama modeli uzun B2B yolculuğunun yalnızca son adımını ödüllendirir ve huninin üst katmanına yapılan yatırımı sistematik biçimde cezalandırır. Pratik düzeltme, forma “bizi nereden duydunuz” alanı eklemektir; bu beyana dayalı veri, analitik araçların göremediği kanalları (tavsiye, topluluk, yapay zekâ asistanı) görünür kılar. Model verisiyle beyan verisini yan yana okumak, tek başına ikisinden de daha doğru karar verdirir.

Kurulum planı açısından bu, iki ayrı alan demektir: sistemin otomatik doldurduğu kaynak alanı ve kullanıcının beyan ettiği kaynak alanı. İkisini tek alanda birleştirmeyin, birbirinin üzerine yazarlar.

Değer listelerini kilitleyin

Serbest metin alanı, raporlanamayan alandır. Sektör, ülke, kayıp nedeni, satın alma rolü gibi her alanı açılır liste yapın. Liste değerlerini kim değiştirebilir, bunu da yazın. Değer listesini herkese açtığınızda altı ay içinde “Finans”, “finans”, “Finans Sektörü” ve “Fin.” aynı raporda dört ayrı satır olarak görünür.

Sahiplik, roller ve ekipler

Veri modeli ve pipeline doğru olsa bile, kimin neyi yapacağı belirsizse sistem bozulur. Sahiplik bölümünde üç ayrı şeyi karıştırmadan yazın.

Kayıt sahipliği. Bir şirketin, kişinin veya fırsatın sahibi kimdir, nasıl atanır (manuel, bölge bazlı, round robin), ne zaman değişir. En çok tartışma, pazarlamadan gelen bir talebin mevcut bir hesaba ait olduğu durumlarda çıkar. Kural basit olmalı: hesap sahibi varsa talep ona gider, yoksa atama kuralı çalışır.

Sistem yetkisi. Kim alan ekleyebilir, kim pipeline aşaması değiştirebilir, kim kayıt silebilir, kim rapor oluşturabilir. HubSpot’ta süper yönetici sayısını sınırlı tutun. Alan ekleme yetkisini tek bir sahibe bağlamak, altı ay sonraki alan enflasyonunu önleyen en ucuz tedbirdir.

Süreç sahipliği. Veri modelinin bakımından kim sorumlu, haftalık veri kalitesi kontrolünü kim yapar, yeni alan talepleri kime gelir. Bu rol çoğu B2B şirkette pazarlama veya satış operasyonunda durur. Tek kişiye bağımlı akış kırılgandır; süreç sahibinin yedeği ve kararların yazılı olduğu yer plana eklenmelidir (B2B İçerik Takvimi Nasıl Kurulur).

Bir de MQL/SQL devir noktası var. Pazarlamanın hangi koşulda kaydı satışa devrettiği, satışın kabul veya ret için kaç gün süresi olduğu ve reddedilen kaydın nereye döneceği yazılmalıdır. Bu üç cümle yazılmadığında, dört ay sonra “pazarlama kalitesiz lead gönderiyor” ve “satış gelen talepleri aramıyor” tartışması aynı anda başlar ve ikisini de çözecek veri yoktur.

Devreye alma: sıra, pilot ve geçiş

Kurulum planının son bölümü takvimdir. Burada tek bir ilke işe yarar: veri temelinden başlayıp otomasyona doğru ilerleyin, aradaki her adımda gerçek kullanıcıyla test edin.

Önerilen sıralama

1. Veri modeli ve alanlar. Nesne tanımları, özel alanlar, değer listeleri, zorunluluk kuralları. Henüz veri yok, otomasyon yok.

2. Kullanıcılar, ekipler ve yetkiler. Roller tanımlanır, atama kuralları kurulur. Bu adımı veri taşımadan önce yapın; sahipsiz kayıt yığını oluşmasın.

3. Pipeline ve aşamalar. Aşamalar, çıkış kriterleri açıklama alanlarına yazılır, kayıp nedeni listesi tanımlanır.

4. Veri taşıma ve temizlik. Seçilen kayıtlar aktarılır, yinelenenler birleştirilir, alan adı olmayan şirketler gözden geçirilir. Taşımadan sonra en az bir tam kontrol turu yapın.

5. Form, izleme ve giriş noktaları. Web sitesi formları, izleme kodu, kaynak etiketleri. Bu adım veri modelinden sonra gelmelidir, çünkü formun hangi alanı hangi CRM alanına yazacağı ancak alanlar tanımlıyken belirlenebilir.

6. Raporlar ve gösterge panoları. Haftalık operasyon panosu, aylık kanal raporu, pipeline görünümü.

7. Otomasyon ve e-posta akışları. En son. Bir otomasyon, ancak doğru alanlar ve doğru aşama tanımları üzerine kurulduğunda işe yarar. Veri sisteme akıyor olması, sürecin optimize olduğu anlamına gelmez; her akışın tetikleyicisi ve çıkış koşulu ayrıca doğrulanmalıdır.

Bu sıralama bir şablondur. Mevcut sisteminizden acil taşınması gereken bir süreç varsa sıra değişebilir, ama 7. maddenin 1. maddeden önce gelmemesi iyi bir kuraldır.

Pilot ile başlayın

Tüm satış ekibiyle aynı gün başlamak yerine, iki hafta boyunca küçük bir grupla (örneğin iki satış temsilcisi ve bir pazarlama sorumlusu) gerçek fırsatlar üzerinden çalışın. Pilotun amacı mükemmel kurulum değil, süreçteki gerçek darboğazı görmektir. Pilot sonunda üç soruyu cevaplayın: hangi zorunlu alan gereksiz yere yavaşlattı, hangi aşama kriteri tartışma yarattı, hangi kayıt tipini kimse nereye koyacağını bilemedi.

Varsayımsal bir pilot bulgusu

Diyelim ki iki haftalık pilotta 18 fırsat açıldı. Bunların 11’i “Keşif” aşamasında kaldı, 5’i “Çözüm doğrulama”ya geçti, 2’si teklife ulaştı. Kayıtlara bakıldığında, keşifte kalan 11 fırsatın 7’sinde “bir sonraki adım” alanı boş. Temsilcilerle konuşulduğunda nedeni çıkıyor: alan zorunlu değil ve pipeline görünümünde gösterilmiyor, dolayısıyla kimse doldurmuyor.

Bu bulgudan çıkacak aksiyon, alanı zorunlu yapmak değil. Önce alanın pipeline kart görünümünde görünür hale getirilmesi, iki hafta daha gözlenmesi ve hâlâ boş kalıyorsa zorunluluk tartışılması daha doğru. Zorunlu alan, davranışı düzeltmeyen bir çözümse sadece doldurulmuş görünen çöp veri üretir.

Bu rakamlar öğretme amaçlı uydurulmuş örneklerdir, gerçek bir müşteri sonucu veya sektör ortalaması değildir. Aktarılması gereken şey sayılar değil, muhakeme biçimi: gözlem, nedenin araştırılması, en küçük müdahalenin denenmesi.

Benimsenme olmadan kurulum tamamlanmış sayılmaz

Devreye alma takviminin son maddesi eğitim ve takip olmalı. Üç pratik başlık:

Eğitim, ekran turu değil senaryo üzerinden yapılmalı. “Şu müşteriden şu talep geldi, kaydı nasıl açarsınız” formatı, menü tanıtımından daha hızlı öğretir.

İlk ay haftalık veri kalitesi kontrolü yapın: sahipsiz kayıtlar, boş zorunlu alanlar, kapanış tarihi geçmiş fırsatlar, yinelenen şirket kayıtları. Bu kontrolü bir kişiye bağlayın.

Benimsenmeyi ayrı ölçün. Süreç metrikleri ve sonuç metriklerini karıştırmayın. Kaç fırsat kazanıldığı sonuç metriğidir ve ilk aylarda kurulumla ilgili bir şey söylemez. Buna karşılık güncellenen kayıt oranı, aşama geçişlerinin ortalama gecikmesi ve boş bırakılan zorunlu alan sayısı, kurulumun çalışıp çalışmadığını doğrudan gösterir.

İlgili okuma: Kurumsal Web Sitesi Yenileme Projesi Nasıl Planlanır? Kapsam, İçerik Envanteri ve Geçiş Kontrol Listesi

İlk 90 günde beklenti nasıl yönetilir?

Yönetim katı CRM yatırımının karşılığını hızlı görmek ister. Beklentiyi baştan yazılı hale getirmek, “ikinci ayda neden satışlar artmadı” konuşmasını daha yaşanmadan çözer. Talep yaratma tarafında kullandığımız yaklaşım burada da işe yarar: planı yazılı bir beklenti sözleşmesine çevirmek, hangi metriğin hangi tarihte hangi eşikte değerlendirileceğini belirlemek.

CRM kurulumunda bu sözleşme şöyle kurulabilir:

İlk 30 gün: kurulum ve pilot. Ölçülen şey kurulumun tamamlanma derecesi ve pilot bulgularıdır. Satış sonucu beklenmez.

30-60 gün: benimsenme. Tüm ekip sistemde çalışıyor mu, kayıtlar güncelleniyor mu, zorunlu alanlar doluyor mu. Bu dönemde pipeline rakamları hâlâ eksik olacaktır, çünkü eski fırsatların bir kısmı sisteme tam girmemiş olur.

60-90 gün: ilk anlamlı pipeline görünümü. Artık aşama dağılımına, geçiş sürelerine ve kayıp nedenlerine bakılabilir. Yine de bu ilk tabloyu bir performans değerlendirmesi değil, temel çizgi (baseline) olarak okuyun.

Üç ayın sonunda yapılacak gözden geçirme, kurulum planının ilk revizyonudur. Hangi alanlar boş kaldı, hangi aşama hiç kullanılmadı, hangi kural istisnaya dönüştü? Bu soruların cevabı, planın ikinci sürümünü yazar.

Kurulum planının tek sayfalık özeti

Elinizdeki dokümanın sonunda şu kontrol listesi yer alsın. Hepsinin cevabı yazılıysa kurulum başlayabilir:

• Kişi, şirket, fırsat ve bilet nesnelerinin işinizdeki tanımı yazıldı mı?
• Fırsat hangi anda açılır, bu kararın istisnası var mı?
• Pipeline aşamaları ve her aşamanın çıkış kriteri tanımlandı mı?
• Kayıp nedeni listesi sabitlendi ve kapanışta zorunlu hale getirildi mi?
• Zorunlu alanların her biri için “hangi raporda kullanılacak” sorusu cevaplandı mı?
• Kaynak için biri otomatik biri beyana dayalı iki alan var mı?
• Kayıt sahipliği, sistem yetkisi ve süreç sahipliği ayrı ayrı yazıldı mı?
• MQL/SQL devir kuralı, kabul süresi ve ret akışı tanımlandı mı?
• Veri taşımasında hangi kayıtların taşınmayacağı belirlendi mi?
• Devreye alma sırası yazıldı ve otomasyon en sona bırakıldı mı?
• Pilot grubu, süresi ve pilot sonunda sorulacak sorular belli mi?
• İlk 90 günde hangi metriğin ne zaman değerlendirileceği paydaşlarla paylaşıldı mı?

Bu liste kurulum sırasında işaretlenen bir form değil, kurulum öncesinde eksikleri gösteren bir ayna. İşaretlenemeyen her madde, devreye alma sonrasında birinin canlı sistemde çözmek zorunda kalacağı bir karardır.

Sıkça Sorulan Sorular

HubSpot kurulum planı ne kadar ayrıntılı olmalı?

Beş bölümden oluşan, her bölümü yarım sayfayı geçmeyen bir doküman çoğu B2B şirket için yeterlidir: veri modeli, pipeline, alanlar, sahiplik, devreye alma takvimi. Belgenin uzunluğu değil, her kararın tek cümlelik gerekçesinin yazılmış olması önemlidir. Gerekçesi yazılamayan karar genellikle gereksiz karardır.

Fırsat kaydını ne zaman açmalıyız?

Üç yaygın yaklaşım var: ilk nitelikli temasta, satışın kabul ettiği her talepte veya hesap aktif hale geldiğinde. Uzun döngülü kurumsal satışta ilk yaklaşım genellikle daha okunabilir bir pipeline üretir, ancak pazarlamanın katkısını görmek için MQL/SQL durumlarını kişi veya şirket üzerinde ayrıca tutmak gerekir. Önemli olan, seçilen kuralı yazmak ve istisna üretmemektir.

Kaç pipeline aşaması olmalı?

Beş ile yedi aşama çoğu B2B süreci için başlangıç noktası olarak çalışır. Aşama sayısını artırma gerekçesi şudur: iki aşama arasında haftalar süren ve ayrı bir çalışma gerektiren bir faz varsa (güvenlik incelemesi, PoC gibi), o faz kendi aşamasını hak eder. Fazla aşama, temsilcinin kaydı güncellemeyi bırakmasına yol açar.

Hangi alanları zorunlu yapmalıyız?

Her zorunlu alan için üç soruyu cevaplayın: hangi raporda veya otomasyonda kullanılacak, kim dolduracak, doldurulmazsa ne olur. Üçüncü sorunun cevabı “bir şey olmaz” ise alan zorunlu olmamalıdır. Çekirdek set genellikle fırsat tarafında tutar, kapanış tarihi, aşama, kaynak ve kapanışta kayıp nedeninden oluşur.

Eski CRM’deki her şeyi taşımalı mıyız?

Hayır. Üç soruyu önceden cevaplayın: hangi kayıtlar taşınacak (örneğin son 24 ayda temas edilmişler), hangi alanlar eşleşecek, hangi kayıtlar bilerek dışarıda bırakılacak. Eski sistemdeki her alanı taşımak, yeni sistemi kurulduğu gün kirletmenin en hızlı yoludur. İzin durumu belirsiz e-posta listelerini taşımadan önce İYS uyumunu netleştirin.

Kurulumun başarılı olduğunu nasıl anlarız?

İlk aylarda satış sonucuna bakmayın; o dönemde kurulumla ilgili bir şey söylemez. Bunun yerine benimsenme göstergelerini izleyin: güncellenen kayıt oranı, aşama geçişlerinin ortalama gecikmesi, boş bırakılan zorunlu alan sayısı, sahipsiz kayıt sayısı. Anlamlı bir pipeline görünümü genellikle 60-90 gün sonra oluşur ve bu ilk tablo bir performans değerlendirmesi değil, sonraki dönemlerle karşılaştırılacak temel çizgidir.