GTM Temelleri - GTM Ekip Yapısı: Aşamanıza Uygun Modeli Seçmek
GTM yapısı üzerine çoğu konuşma bir organizasyon şemasıyla başlar ve bir işe alım planıyla biter. Bu sıra terstir. Yapı iki şeyin sonucudur: seçtiğiniz mekanizma ve peşinde olduğunuz anlaşmanın büyüklüğü. Bunlar doğruysa organizasyon şeması büyük ölçüde kendini çizer.
Bu sayfa, pratikte ayakta kalan üç yapısal modeli, her birinin içinde raporlama hatlarının nasıl işlemesi gerektiğini, mevcut biçiminizi aştığınıza dair somut sinyalleri ve geçişi bir çeyrek kaybetmeden nasıl yürüteceğinizi ele alıyor.
7 dk okuma7 bölümGTM Temelleri
Bu sayfadan çıkaracaklarınız
- Yapı, mekanizmayı ve anlaşma büyüklüğünü izler. 5.000 €’luk self-servis bir ürünle 250.000 €’luk bir kurumsal anlaşma aynı şemayı paylaşamaz.
- Merkezî RevOps küçükler dahil her modele aittir — kapsam değişir, ihtiyaç değişmez.
- Pod modeli kabaca 2–20 M€ ARR arasında en yüksek getirili yapıdır ve en sık yanlış uygulanandır.
- Geçişler, sıralanmak yerine duyurulduğunda başarısız olur. Önce tanımları ve veriyi taşıyın, sonra insanları.
Yapınızı gerçekte ne belirler
Bir model seçmeden önce dört girdi konusunda dürüst olun. Her biri, herhangi bir organizasyon felsefesinden daha fazla biçimi kısıtlar.
- Ortalama sözleşme değeri
- Yılda kabaca 5.000 €’nun altında insan odaklı satış kendini nadiren çıkarır; yapı ürüne ve pazarlamaya yaslanmalıdır. 50.000 €’nun üstünde keşif, teknik doğrulama ve çok kanallı ilişki gerekir — yani uzmanlaşmış roller.
- Satış döngüsü uzunluğu
- İki haftalık bir döngüyü tek kişi uçtan uca yürütebilir. Satın alma aşaması ve güvenlik incelemesi olan dokuz aylık bir döngü devir teslim gerektirir; devir teslimler de bunu atlatmak için bir operasyon fonksiyonu ister.
- Satın alma komitesinin büyüklüğü
- Tek karar verici, tek ilişki demektir. Finans, BT, güvenlik ve iş biriminden altı paydaş ise bu dillerin her birini konuşabilen insanlara ihtiyacınız olduğu anlamına gelir.
- Birincil mekanizma
- Gelen, giden, ürün odaklı ve iş ortağı odaklı; her biri farklı bir ağırlık merkezi ister. İkisini aynı anda ciddi biçimde yürütmek koordinasyon yükünü kabaca ikiye katlar — bu bir kadro maliyeti değil, yapı maliyetidir.
Kutuları çizmeden önce bu dördünü yazın. Bu adımı atlayan ekipler genellikle kendilerinden üç aşama ileride bir şirketin şemasını kopyalar ve sonra koordinasyonun haftalarını neden yediğine şaşırır.
Model 1: kurucu odaklı
Kabaca 1–2 M€ ARR’a kadar GTM ekibi kuruculardır. Bu, hızla düzeltilmesi gereken bir eksiklik değil; neyin inşa edileceğine karar veren kişinin aynı zamanda her satış görüşmesinde bulunduğu tek dönemdir ve bu geri besleme döngüsü, yerine koyabileceğiniz herhangi bir süreçten daha değerlidir.
Hata modeli modelin kendisi değil, o dönemde yapılmayanlardır. Kurucular sezgiyle satar, sunumu anlık uyarlar ve her şeyi hatırlar. Bunların hiçbiri devredilemez. İlk satış çalışanı geldiğinde, ona yalnızca birinin kafasında var olan bir mekanizma teslim edilir.
- Kim ne yapar
- Bir kurucu keşfi, fiyatlamayı ve kapanışı sahiplenir. Genelci bir pazarlamacı içerik, web sitesi ve etkinlikleri kapsar. Operasyonel her şey manueldir ve bu hacimde bu kabul edilebilir.
- Yine de inşa edilmesi gerekenler
- Yazılı bir ICP, kaydedilmiş görüşmeler, dürüst aşama tanımları olan tek bir CRM ve satış görüşmesini anlatan bir belge. İlk işe alımı aylar önce üretken kılan iki günlük iş.
- Ne zaman çıkmalı
- Kurucunun takvim zamanı pipeline üzerindeki bağlayıcı kısıt olduğunda ya da kurucu artık iyi hizmet veremeyeceği anlaşmaları kapattığında. İkisi de genellikle biri harekete geçmeden bir çeyrek önce görünür.
Model 2: podlar ve squad’lar
Kabaca 2–20 M€ ARR arasında pod modeli alternatifleri istikrarlı biçimde geçer. Bir pod; genellikle talep yaratma, bir SDR, bir-iki account executive ve bir müşteri başarısı temasından oluşan, bir segmenti, bölgeyi ya da ürün hattını uçtan uca sahiplenen küçük ve çapraz fonksiyonlu bir gruptur.
İşe yaramasının nedeni sahipliktir. Aynı dört kişi bir segmentte ilk temastan yenilemeye kadar tüm yoldan sorumlu olduğunda, devir teslim sorunu büyük ölçüde ortadan kalkar; çünkü bağlamın kaybolacağı bir organizasyon sınırı yoktur.
| Rol | Sayı | Sahiplendiği |
|---|---|---|
| Account executive | 2 | Segment için keşiften kapanışa |
| SDR / BDR | 1 | Bu AE’lere giden ve gelen niteliklendirme |
| Talep yaratma | 0,5–1 | Segmente özgü kampanyalar ve içerik |
| Müşteri başarısı | 1 | Podun kapattığı hesaplarda devreye alma, benimseme ve yenileme |
| RevOps (merkezî, paylaşımlı) | — | Tüm podlar genelinde tanımlar, veri, raporlama, araçlar |
Podların yanlış uygulanmasının iki yolu: her poda kendi sürecini vermek, ki bu iş genelinde karşılaştırılabilirliği yok eder; ve RevOps’u merkezî yerine bir podun içine koymak, ki bu durumda tutarlılığı kimse sahiplenmez. Süreç merkezî, sahiplik yerel kalsın.
Model 3: uzmanlaşmış fonksiyonel yapı
Kabaca 20 M€ ARR üzerinde derinlik genişliği geçmeye başlar. Kurumsal anlaşmalar adanmış çözüm mühendisleri, iş ortaklıkları gerçek bir fonksiyon ister; talep yaratma ise ücretli, içerik, yaşam döngüsü ve saha olarak bölünür. Yapı, bir CRO altında fonksiyonel ekiplere; RevOps ve GTM mühendisliği ise merkezî paylaşılan hizmetlere dönüşür.
Bedeli dikiş yerleridir. Eklediğiniz her uzmanlaşma, bir anlaşmanın ivme kaybedebileceği yeni bir sınır yaratır ve bunu yaşanabilir kılan tek şey, süreç ve veri üzerinde gerçek yetkisi olan güçlü bir operasyon katmanıdır.
- Raporlama hatları
- Pazarlama, satış ve müşteri başarısı tek bir gelir liderine bağlı. RevOps da aynı lidere — finansa değil; orada işleyiş fonksiyonu olmaktan çıkıp raporlama fonksiyonuna dönüşür.
- GTM mühendisliğinin yeri
- RevOps içinde ya da eşdüzey bir ekip olarak; asla ürün mühendisliği backlog’una gömülü değil. GTM mühendisliği öncelik için müşteriye dönük özelliklerle yarışırsa her çeyrek kaybeder ve gelir araçları hiç yayına çıkmaz.
- Merkezî kalması gerekenler
- Tanımlar, veri modeli, tahmin metodolojisi ve araç stack’i. Fonksiyonlar taktiklerini sahiplensin; kendi gerçek versiyonlarını değil.
RevOps nerede durur — ve neden genelde yanlış yerde durur
Gelir operasyonları, işleyen her yapıda bulunan tek fonksiyon ve en sık yanlış konumlandırılan fonksiyondur. Üç yerleşim yaygındır; yalnızca biri iyi çalışır.
Finans altında RevOps bir raporlama fonksiyonuna dönüşür: doğru, geriye dönük ve gelir ekibinin işleyişini değiştirmeye yapısal olarak muktedir olmayan. Satış içinde satış operasyonuna dönüşür ve pazarlama verisi sessizce çürür. Müşteriye dönük tüm fonksiyonlar üzerinde yetkiyle gelir liderine bağlanmak, gerçekten sonuç veren yerleşimdir.
Mevcut yapınızı aştığınızın sinyalleri
Yapısal değişim yeterince sarsıcı olduğu için çoğu ekip fazla bekler. Harekete geçmeye değer sinyaller, kabaca ortaya çıkış sırasıyla şunlardır.
- Tahmin bir pazarlığa dönüşmüş
- Yönetim, temsilcilerin verdiği sayıyı rutin olarak düzeltiyorsa aşama tanımları anlamını yitirmiştir ve yetkili bir merkezî operasyon fonksiyonuna ihtiyacınız var.
- Aynı soru üç farklı yanıt alıyor
- Üç kişiye geçen çeyreğin kazanma oranını sorun. Üç farklı sayı, veri modelinizin yönetişiminizi aştığı anlamına gelir.
- Devir teslimlerin peşinden koşan biri gerekiyor
- Biri her gününün bir kısmını leadlerin doğru temsilciye ulaştığından emin olmaya harcıyorsa yönlendirme kod olmalı ve yapının bunun için bir sahibi bulunmalı.
- Temsilciler her şeyi satıyor
- AE’ler her segmenti, büyüklüğü ve kullanım senaryosunu kapsadığında kazanma oranları düzleşir ve kimse derinleşmez. Bu, podlara segmentlemenin tetikleyicisidir.
- Podlar birbirinden ayrışmış
- Aynı metriği farklı raporlayan iki pod, süreci merkezîleştirip sahipliği yerel bırakma sinyalidir — pod modelinden vazgeçme sinyali değil.
Bir çeyrek kaybetmeden yeniden yapılanma nasıl yürütülür
Yeniden yapılanmalar öngörülebilir bir nedenle başarısız olur: bir organizasyon değişikliği olarak duyurulurlar, oysa asıl iş bir veri ve tanım değişikliğidir. Şu sırayla yürütüldüğünde aksama sınırlı kalır.
Mevcut durumu dondurun ve belgeleyin
Bugünkü aşama tanımlarını, yönlendirme kurallarını, sahiplikleri ve raporlamayı ne kadar kusurlu olursa olsun yazın. Bir referans noktası olmadan değişikliğin işe yarayıp yaramadığını ölçemezsiniz; ayrıca yazma eylemi genellikle hâlâ çalıştığını kimsenin bilmediği iki-üç kuralı ortaya çıkarır.
Yeni kutulardan önce yeni tanımlarda anlaşın
Çıkış kriterli aşama tanımları, niteliklendirme eşikleri, segment sınırları ve devir teslim SLA’ları. Bunları, üzerinden ölçülecek kişilerle yazılı olarak onaylayın.
Veri modelini buna göre yeniden kurun
Segment alanları, bölge ataması, sahiplik kuralları ve raporlama nesneleri, kimse yer değiştirmeden önce CRM’de güncellensin. Mühendislik zamanı gerektiren ve ekiplerin atlamaya çalıştığı adım budur.
Pipeline’ı açıkça devredin
Geçiş tarihinde neyin kime ait olduğuna hesap hesap karar verin. Buradaki belirsizlik, tam olarak yeniden yapılanmayı bir hata gibi gösteren düşen anlaşmaları üretir.
İnsanları taşıyın, sonra bir çeyrek sabit kalın
Yapıyı, altındaki sistem onu taşıyabildiğinde duyurun. Ardından en az bir çeyrek yeniden değiştirmeye direnin — işe yarayıp yaramadığını bilmek için temiz bir ölçüm dönemine ihtiyacınız var.
Referans noktasına göre değerlendirin
Aşama dönüşümünü, döngü uzunluğunu ve devir teslim SLA uyumunu dondurulmuş referansla karşılaştırın. Sayılar kıpırdamadıysa sorun yapısal değildi — bu da değerli bir bilgidir.
Sık sorulan sorular
İdeal GTM ekip yapısı nedir?
- Tek bir ideal yoktur. Doğru yapı; ortalama sözleşme değeriniz, satış döngüsü uzunluğunuz, satın alma komitesi büyüklüğünüz ve birincil mekanizmanızla belirlenir. Pratikte: kabaca 2 M€ ARR’a kadar kurucu odaklı, 2–20 M€ arasında çapraz fonksiyonlu podlar, üzerinde bir CRO altında uzmanlaşmış fonksiyonlar.
RevOps satışa mı finansa mı bağlı olmalı?
- Hiçbirine. RevOps, pazarlama, satış ve müşteri başarısı üzerinde yetkiyle gelir liderine bağlı olmalıdır. Finans altında geriye dönük bir raporlama fonksiyonuna dönüşür; satış altında pazarlama ve CS veri kalitesi bozulur.
Bir GTM podunda kaç kişi olmalı?
- Dört-altı uygulanabilir aralıktır: bir-iki account executive, bir SDR, paylaşılan bir talep yaratma kaynağı ve bir müşteri başarısı teması. Daha büyük podlar iç koordinasyon gerektirmeye başlar; bu da modelin kaçınmak için var olduğu yüktür.
GTM mühendisliği fonksiyonunu ne zaman eklemeliyiz?
- Entegrasyon ve otomasyon talepleri ürün yol haritasının arkasında sıraya girdiğinde ya da RevOps’taki biri haftasının çoğunu manuel veri işine harcadığında. Bu genellikle 3–10 M€ ARR arasındadır.
GTM yapısı ne sıklıkla değişmeli?
- Nadiren ve asla çeyrek ortasında değil. Çoğu şirket gelirdeki her büyüklük sıçramasında bir yapısal değişikliğe ihtiyaç duyar. Yıllıktan sık değiştirmek, genellikle bir tanım ya da veri sorununun yapısal sorun sanıldığına işaret eder.
Yeni bir organizasyon şeması bozuk bir veri modelini düzeltmez
Bir yeniden yapılanmanın dayandığı CRM mimarisini, yönlendirme mantığını ve raporlama katmanını yeniden kuruyoruz — yeni yapı üçüncü çeyrekte değil ilk günden çalışsın diye.