GTM Temelleri - GTM Tech Stack: Altı Katman, Seçim Kriterleri ve Entegrasyon Desenleri
Çoğu GTM stack’i tasarlanmaz, birikir. Acil bir sorunu çözmek için bir araç alınır, işe yarar ve üç yıl sonra kimse lead yönlendirmenin neden iki sistemde yapıldığını ya da şirket büyüklüğü için dört kaynaktan hangisinin geçerli olduğunu açıklayamaz.
Çözüm, logolarla düşünmeyi bırakıp katmanlarla düşünmeye başlamaktır. Bu sayfa bir gelir stack’inin ihtiyaç duyduğu altı katmanı, her birine neyin ait olduğunu, kendinizi kilitlemeden araç seçmenin yolunu ve halihazırda yayılmış bir stack’i nasıl denetleyip sadeleştireceğinizi ortaya koyuyor.
6 dk okuma5 bölümGTM Temelleri
Bu sayfadan çıkaracaklarınız
- Altı katman: kayıt sistemi, veri, etkileşim, zekâ, orkestrasyon, raporlama. Çoğu stack etkileşime aşırı yatırım yapar ve orkestrasyonu tamamen eksiktir.
- Önce CRM’i seçin ve bunu bir satın alma değil mimari karar olarak ele alın. Sonraki her şey onun nesne modelini devralır.
- Raporlamayı CRM üzerine değil veri ambarı üzerine kurun. CRM’ler geçmişin üzerine yazar, ambarlar saklar.
- Değerin yaratıldığı ya da kaybedildiği yer entegrasyon katmanıdır. Kimse sahiplenmiyorsa, o iş buna gönüllü olmamış biri tarafından elle yapılıyordur.
Altı katman
İşleyen her gelir stack’inde bu altı katman vardır; kimse adını koymuş olmasa da. Adını koymak boşlukları görünür kılar.
- 1. Kayıt sistemi
- CRM. Nesne modelini tanımlar — hesabın ne olduğunu, fırsatın ne olduğunu, nasıl ilişkilendiklerini. Tek sistem, tek sahip. Önümüzdeki beş yıl inşa edeceğiniz her şeyi kısıtlayan tek karar.
- 2. Veri ve zenginleştirme
- Firmografik ve teknografik zenginleştirme, form doldurmalar ile ürün kayıtları arasında kimlik çözümleme, tekilleştirme ve CRM’in üzerine yazdığı geçmişi tutan bir veri ambarı. Veri kalitesinin ya oluştuğu ya da kalıcı olarak kaybolduğu katman.
- 3. Etkileşim
- Pazarlama otomasyonu, e-posta dizileme, arama, randevu, sohbet. Alıcıya dokunan katman. Hazır araçlarla iyi karşılanır ve şirketlerin ilk ve en çok satın aldığı katmandır.
- 4. Zekâ
- Ürün analitiği, görüşme zekâsı, niyet verisi, yapay zekâ ile niteliklendirme. Ham davranışı, bir insanın ya da kuralın üzerine hareket edebileceği sinyallere çevirir. Ancak altındaki 2. katman kadar iyidir.
- 5. Orkestrasyon
- Lead yönlendirme, skorlama, yaşam döngüsü otomasyonu, uyarılar, SLA uygulama, veri hijyeni işleri. Diğerlerinin tek bir sistem gibi davranmasını sağlayan katman. Neredeyse her zaman kısmen eksiktir ve manuel işin sürmesinin nedenidir.
- 6. Raporlama
- CRM üzerine değil ambar üzerine kurulu BI; böylece bir alan adı değişikliği ya da pipeline yeniden tasarımı geçen yılın analizini geçersiz kılmaz. KPI çerçevenizden gelen otomatik metrik tanımlarını içerir.
Teşhisi yapın: araçlarınızı listeleyip her birini bir katmana atayın. 3. katmanda dört giriş varken 2. ve 5. katman ince ya da boşsa, ekibinizin sabahlarını neden manuel veri işine harcadığının nedenini bulmuşsunuz demektir.
Kayıt sistemini seçmek
CRM kararı mimaridir. Özellik satın almıyorsunuz; sonraki her sistemin devralacağı bir nesne modelini benimsiyorsunuz. Özellik karşılaştırmasından daha çok önemli üç kriter var.
- Nesne modeli uyumu
- Yerleşik model gerçekte nasıl sattığınıza uyuyor mu? Çok ürünlü, kullanım tabanlı, iş ortağı kaynaklı ve önce küçük satıp büyütme mekanizmaları standart hesap-kişi-fırsat modelini zorlar. Uyumsuzluğu zorlamak, sonradan alacağınız her entegrasyonu bozan özel nesneler üretir.
- API kalitesi ve hız sınırları
- Beklediğinizden fazla entegrasyon yapacaksınız. Toplu okuma ve yazma kapasitesini, olay webhook’larını, sandbox erişimini ve şema değişikliklerinin nasıl sürümlendiğini kontrol edin. Zayıf API’li bir CRM, inşa edebileceğiniz her şeyi sessizce sınırlar.
- Çıkış maliyeti
- Beş-yedi yıl içinde göç edeceğinizi varsayın. Alan düzeyindeki değişiklik kayıtları dahil geçmiş ne kadar dışa aktarılabilir? Kendi denetim izini dışa aktaramayan bir sistem, analizinizi rehin tutuyordur.
Herhangi bir GTM aracı nasıl değerlendirilir
Bir zenginleştirme sağlayıcısı da alsanız bir görüşme zekâsı aracı da, aynı beş soru geçerlidir. Özellik kontrol listeleri, bir tedarikçi değerlendirmesinin en az işe yarayan kısmıdır.
Hangi katmana ait ve o katman boş mu?
Katman zaten doluysa ya bir şeyin yerine geçiyorsunuz ya da bir örtüşme yaratıyorsunuz. Çelişkili veriler örtüşmelerden gelir.
Kayıt sistemine geri yazabiliyor mu?
Yalnızca okuyan bir araç ikinci bir doğruluk kaynağı yaratır. Çift yönlü senkronizasyonda ısrar edin ve çakışmada ne olduğunu kontrol edin — iki sistem arasında “son yazan kazanır”, veriyi sessizce bozar.
Hata durumu nedir?
Entegrasyon gece ikide bozulduğunda kuyruk yeniden dener mi, yoksa kayıtlar sessizce mi düşer? Tedarikçiye doğrudan sorun. Yanıt, ciddi bir ürünü bir demodan ayırır.
Altı ay sonra kim sahiplenecek?
Her araç, yapılandırmasını anlayan bir sahip ister. Sahipsiz bir araç kimsenin açıklayamadığı bir duruma kayar ve kuralları yine de çalışmaya devam eder.
Kaldırmak neye benziyor?
Mantık tamamen tedarikçinin arayüzünde yaşıyorsa kaldırmak sıfırdan yeniden kurmak demektir. Kritik mantığın kodda ya da kendi veritabanınızda yaşamasına izin veren araçları tercih edin.
Ayakta kalan entegrasyon desenleri
Sistemlerin nasıl bağlandığı, hangi sistemler olduğundan daha önemlidir. Dört desen hemen her durumu kapsar ve bunları dikkatsizce karıştırmak, stack’leri bakımı imkânsız hale getirir.
| Desen | Şu durumda kullanın | Dikkat edilecek |
|---|---|---|
| Yerleşik entegrasyon | Her iki tedarikçi de destekliyor ve alan eşlemesi modelinize uyuyor | Sınırlı alan kontrolü; çoğu zaman çakışma yönetimi ve hata görünürlüğü yok |
| iPaaS / iş akışı aracı | Düşük hacim, basit eşlemeler, kritik olmayan zamanlama | Maliyet hacimle büyür; görsel editördeki karmaşık mantık denetlenemez hale gelir |
| Ambar öncelikli, ters ETL ile | Birçok sistem genelinde tek bir doğruluk tanımına ihtiyacınız var | Bir ambar ve modelleri sahiplenen biri gerekir — kabaca 10 M€ ARR üzerinde doğru cevap budur |
| Özel servis | İş açısından kritik mantık, yüksek hacim ya da sürüm kontrolü ve test gerektiren mantık | Mühendislik sahipliği ister; o olmadan kimsenin bakamayacağı bir şey inşa etmiş olursunuz |
Pratik kural: yönlendirmeyi, skorlamayı ve gelire dokunan her mantığı testleri ve sürüm geçmişi olan kodda tutun. Gerçekten basit alan senkronizasyonlarını en ucuz araçta bırakın. Sorunlar, iş açısından kritik mantığın yalnızca bir kişinin anladığı ve kimsenin gözden geçirmediği görsel bir iş akışında son bulmasıyla başlar.
Mevcut bir stack’i denetlemek ve sadeleştirmek
Bunu okuyan çoğu ekibin önünde boş bir sayfa yok — on iki araç ve dördünün örtüştüğüne dair bir şüphe var. Bu denetim bir hafta sürer ve genellikle kendini hemen çıkarır.
Her aracı maliyet, sahip ve katmanla envanterleyin
Birinin kişisel kartındakileri de dahil edin. Adı konmuş sahibi olmayan araçlar ilk kaldırma adaylarıdır ve her zaman beklenenden fazladır.
Veri akışlarını haritalayın
Önemli her alan için — şirket büyüklüğü, sektör, yaşam döngüsü aşaması, sahip — hangi sistemlerin hangi sırayla yazdığını izleyin. Çelişkili yazmalar ilk düzeltmenizdir ve genellikle raporlama uyuşmazlıklarının nedenidir.
Manuel köprüleri bulun
Her CSV dışa aktarımı, her kopyala-yapıştır ve her “bunu pazartesileri kontrol ediyorum” eksik bir entegrasyondur. Bunları tükettikleri saatlerle listeleyin; bu liste fiyatlanmış otomasyon backlog’unuzdur.
Örtüşmeleri belirleyin
İki zenginleştirme sağlayıcısı, iki dizileyici, üç yerde yönlendirme. Katman başına birini seçip kalanını devre dışı bırakın — lisans tasarrufu, çelişkili verinin azalmasının yanında ikincildir.
Orkestrasyon boşluğunu doldurun
Manuel köprüler listesinde ne varsa, 5. katmanın yapması gereken şey odur. Tüm denetimdeki en büyük tekil getiri normalde buradadır.
Bir inceleme ritmi belirleyin
Envanteri altı ayda bir tekrarlayın. Stack’ler varsayılan olarak yayılır ve planlı bir inceleme, yeniden kurmaktan çok daha ucuzdur.
Sık sorulan sorular
Bir GTM tech stack’inde hangi araçlar bulunur?
- Eksiksiz bir stack altı katmanı kapsar: kayıt sistemi olarak bir CRM, ambarı olan bir veri ve zenginleştirme katmanı, alıcıyla temas için etkileşim araçları, davranışsal sinyaller için bir zekâ katmanı, yönlendirme ve otomasyon için bir orkestrasyon katmanı ve ambar üzerine kurulu raporlama. Hangi tedarikçi olduğu, hiçbir katmanın eksik olmamasından daha az önemlidir.
Kaç GTM aracımız olmalı?
- Sahip olduğunuzdan az. Doğru sayı, katman başına bir tane artı mekanizmanızın gerçekten gerektirdiği kadarıdır. Uyarı işareti araç sayısı değil, aralarındaki manuel köprü sayısıdır — her CSV dışa aktarımı eksik bir entegrasyondur.
Raporlama CRM üzerinde mi veri ambarı üzerinde mi çalışmalı?
- Veri ambarı üzerinde. CRM’ler geçmişin üzerine yazar: bir alan tanımını değiştirin ya da bir pipeline aşamasını yeniden tasarlayın, geçen yılın raporları yorumlanamaz hale gelir. Ambar anlık görüntüler saklar ve kohort ile trend analizini mümkün kılan şey budur.
GTM için veri ambarına ne zaman ihtiyacımız olur?
- Müşteri verisi tutan kabaca üçten fazla sisteminiz olduğunda ya da biri bu çeyreği geçen yılın aynı çeyreğiyle karşılaştırmayı gerektiren bir soru sorduğu anda. Pratikte çoğu B2B şirketi 5–10 M€ ARR arasında bir ambara ihtiyaç duyar.
iPaaS yeterli mi, yoksa özel entegrasyonlara mı ihtiyacımız var?
- iPaaS basit ve düşük hacimli alan senkronizasyonlarını iyi yönetir. İş açısından kritik mantık — yönlendirme, skorlama, bir anlaşmada kimin çalışacağına karar veren her şey — testleri ve sürüm geçmişi olan koda aittir; çünkü bu mantık, şaşırtıcı bir sonuç ürettiğinde denetlenebilir ve gözden geçirilebilir olmalıdır.
Çoğu stack’te orkestrasyon katmanı eksik
Bir araç yığınının tek bir sistem gibi davranmasını sağlayan entegrasyonları, yönlendirme mantığını ve veri hatlarını kuruyoruz — mantık görsel bir editörde değil sürüm kontrolünde.