Satış Gücü Otomasyonu

Satış Gücü Otomasyonu (Sales Force Automation, SFA), satış sürecindeki tekrar eden işleri sisteme devretme disiplinidir. Yaygın yanlış anlama, bunu "satışı otomatikleştirmek" sanmaktır. Satış otomatikleştirilemez; karar, ikna ve ilişki insana aittir. Otomatikleştirilebilen şey, bu işin etrafındaki angaryadır: kaydı tabloya yazmak, numarayı tabloda arayıp telefonu elle çevirmek, takip aramasını hatırlamaya çalışmak.

Bu angaryanın bedeli görünmez olduğu için küçümsenir. Oysa ölçülebilir: sektörel araştırmalar, bir satış temsilcisinin zamanının yalnızca üçte birine yakınını gerçek satışa ayırabildiğini, ciddi bir kısmının ise tablo ve e-posta gibi geri ofis işlerine gittiğini gösteriyor. Bu oran teknoloji geliştikçe bile yıllardır pek değişmedi; çünkü sorun aracın yokluğu değil, sürecin sisteme hiç kurulmamış olmasıdır.

SFA kurmadan önce yanıtlanması gereken soru "hangi modülü açalım" değil, "bizim satış döngümüz gerçekte nasıl işliyor"dur. Satış döngüsü, bir adayın gelir getiren müşteriye dönüşene kadar geçtiği aşamalar dizisidir. Her işletmenin döngüsü kendine özgüdür; bir e-ticaret günde binlerce aday alırken bir butik klinik iyi bir günde on-on beş aday alır. Hacim değişir, ama omurga benzerdir.

Bu dört aşama bir başlangıç çerçevesidir, sizin sürecinizin tanımı değildir. Bir estetik klinikte gerçek akış çoğunlukla şudur: Instagram/WhatsApp ilk teması → ön görüşme → fiyat → randevu → işlem → kontrol randevusu. Modülleri ve aşamaları bu adımlara eşleriz; adımları modüllere değil. Aşamaları "olması gerektiği gibi" değil, "gerçekte olduğu gibi" tanımlamak şarttır; yoksa kullanıcı kayıtları doğru aşamaya taşımaz ve tüm raporlar yanıltıcı olur.

Zoho CRM, satış verisini tek bir dev kayda yığmaz; bilgiyi modül, kayıt ve alan olarak katmanlar. Modül, aynı tür kayıtların kümesidir; kayıt, o modüldeki tek bir varlıktır; alan ise o kaydı oluşturan ad–değer çiftidir. Veriyi bölmenin sebebi estetik değil pratiktir: temsilcinin önündeki ilgili bilgiyi artırmak, modüller arası gezinmeyi azaltmak ve birçok kayıtta tekrarlanan veriyi bir kez tutmak.

Çekirdek satış (SFA) modülleri dörttür ve aralarındaki akış sabittir: Müşteri Adayları (Leads) → nitelenince → Kişiler (Contacts) ve Hesaplar (Accounts) → üzerinden yürütülen Anlaşmalar (Deals) → kapanınca gelir. Bu dört modül ile Görev, Arama ve Toplantı aktiviteleri, Free dahil her sürümde kutudan gelir; fark, üzerlerine kurabileceğiniz otomasyon ve raporlama katmanındadır.

Müşteri Adayları (Leads) modülü, gelen ham ilginin ilk durağıdır. Aday üç yolla oluşur: elle form doldurarak, CSV/tablo içe aktararak veya web formu ile site ziyaretçisini doğrudan modüle akıtarak. Buradaki kritik karar, modülün getirdiği zengin standart alan setini olduğu gibi açık bırakmak değil; sürecinizin gerçekten kullandığı alanları seçmektir. Her gereksiz alan, temsilcinin her gün doldurmamaya çalıştığı bir alandır.

Standart alanlar ve gerçek sınırları

Soyadı ve Firma sistemce zorunludur; ikisini boş bırakarak aday kaydedemezsiniz. Açıklama alanının 32.000 karakterlik genişliği, görüşme notlarını ayrı bir araca taşımanıza gerek bırakmaz. Standart alanların bir kısmı, organizasyonunuzun iş sürecine göre kullanıcıya görünmeyebilir veya düzenlenemez olabilir; bu, hata değil, layout düzeyindeki kasıtlı bir kısıtlamadır.

Bir adayla ciddi görüşme ihtimali doğduğunda kayıt dönüştürülür. Dönüşümde Zoho CRM aday verisinden bir Hesap ve bir Kişi oluşturur, isterseniz bir de Anlaşma açar; firma bilgisi Hesaba, kişisel bilgi Kişiye gider. Aday kaydı tek yönlü bir yolculuk olduğu için dönüşümden sonra kaybolur ve geri alınamaz. Bu yüzden dönüşüm, "ne olur ne olmaz" tıklanan değil, kararı verilmiş bir adım olmalıdır.

Benzer kayıt önce neyden aranır?

Bu mantığı bilmek, sonradan çıkan mükerrer kayıt karmaşasını baştan önler. Sıra nettir:

• Önce benzersiz alanlar (unique fields): telefon, web sitesi, TC/SSN gibi. Hesap veya Kişide böyle bir alan varsa, sistem benzer kaydı ilk olarak buradan arar.
• Sonra sistem alanları: benzersiz alanla eşleşme yoksa adayın e-postası, firma adı ve adından aranır. Ad, yalnızca e-posta ve firma boşsa devreye girer.
• Benzersiz alan hep önceliklidir. Hesap modülünde hiç benzersiz alan yoksa, dönüşümde tek seçenek yeni Hesap oluşturmaktır.

Alan eşlemesi: tip ve uzunluk uyumu

Standart alanlar hedef modüllerle varsayılan olarak eşlidir. Açtığınız özel alanları ise Kurulum > Özelleştirme > Modüller ve Alanlar > Aday Dönüştürme Eşlemesi üzerinden eşlersiniz. Tek kısıt: bir alanı yalnızca aynı tür ve aynı uzunluktaki bir alana eşleyebilirsiniz; metin alanını metne, aynı karakter sınırıyla.

Dönüşümden sonra iki kalıcı kaydınız olur: Kişiler bireyi, Hesaplar ise o bireyin bağlı olduğu kurumu temsil eder. Bu ayrımı "iki ayrı modül kalabalığı" sanmak yanlış olur; ayrımın tek bir pratik sebebi vardır: aynı firmada birden çok muhatabınız olabilir. Firma bilgisini bir Hesapta tutup altına birden fazla Kişi bağlamak hem tekrarı önler hem de kurumla ilişkinin geçmişini, bir kişi ayrılsa bile, bütün tutar.

İlişki yönü şudur: bir Kişi bir Hesaba bağlıdır; bir Anlaşma hem bir Hesaba hem bir Kişiye bağlanabilir. Doğru kurulan bu bağ, sonradan gelen "bu müşterinin tüm işlemlerini tek ekranda göremiyoruz" şikâyetini baştan engeller. Yanlış kurulan bağ ise aynı firmayı iki yerde kopyalar ve raporları tutarsız kılar.

Anlaşmalar (Deals), gerçek geliri üreten kayıtlardır ve görünürlük katmanının kalbidir. Bir anlaşma; döngüyü, tutarı, her aşamadaki kazanma olasılığını, kazanma/kaybetme nedenini ve dönem tahminini bir arada taşır. Modülün gücü tek tek alanlardan değil, aşamaların doğru kurgulanmasından gelir.

Aşama–Olasılık eşlemesinin dört bileşeni

Tahmin kategorisi, anlaşma kategorisiyle otomatik eşlenir; böylece satış tahmini tutarlı kalır:

Modülün iki görünümü vardır. Liste görünümü anlaşmaları satır satır, Aşama (Kanban) görünümü ise aşamaya göre gruplar; her kart Anlaşma Adı, Tutar, Hesap, Kapanış Tarihi ve açık aktiviteyi gösterir. Kazanılan aşamalar yeşil, kaybedilenler kırmızı baş-parmak ikonuyla işaretlenir; bir anlaşma Kazanıldı'ya alındığında "Detayları Doğrula" penceresi açılıp tutar, kapanış tarihi ve aşama teyit edilir.

Veri modüllere yerleştikten sonra asıl iş başlar: müşteriyle temas. Zoho CRM bunu üç standart aktivite türüyle yönetir ve üçünün de ortak gücü hatırlatma kurulabilmesidir. Hatırlatma olmadan, doğru kurulmuş bir veri modeli bile unutulan bir takip yüzünden anlaşma kaybettirir.

Aktivitelerin pratik değeri, ilgili kaydın içinden oluşturulup görülebilmesidir. Bir Kişi kartına girdiğinizde ona bağlı tüm arama, toplantı ve görevi tek ekranda görür, oradan yenisini açarsınız. Bu, "geçen sefer ne konuşmuştuk" sorusunu ortadan kaldırır. Bir klinikte kontrol randevusunu bir Görev + hatırlatma olarak kurmak, hastayı doğru zamanda geri çağırmanın en sade yoludur.

Otomasyon, kuruluma başlanacak yer değil, bitirileceği yerdir. Süreç netleşip görünürlük kurulduktan sonra "hangi adım insan yerine yapılabilir" sorusunu sorarız. Aşağıdaki adımlar otomasyona en açık olanlardır; hepsini birden değil, kolay kazandıracak basit olanlardan başlamanızı öneririz.

İş Akışı Kuralları (Workflow Rules) Free sürümde bile sınırlı eylemle bulunur; otomasyonun çoğu temel ihtiyacını bunlarla karşılarsınız. Puanlama, çoklu satış hattı ve gelişmiş otomasyon ise üst sürümlerde açılır. Otomasyon kararı, bu yüzden sürüm kararından bağımsız değildir.

Yurt dışı kaynaklı SFA rehberleri Türkiye'nin yasal ve operasyonel gerçeklerini içermez. Oysa bunlar veri modelini doğrudan etkiler; baştan kurgulanmazsa sonradan eklemek, mevcut tüm kayıtları gözden geçirmek demektir.

Sağlıklı bir SFA kurulumunun sırası

• Süreci tanıyın. Satış döngünüzün her adımını ve aşamasını gerçekte olduğu gibi çıkarın.
• Veri ve ilişkiyi kurun. Kişi–Hesap ayrımını ve lookup bağlarını alanlardan önce tasarlayın.
• Görünürlüğü açın. Aşama–olasılık eşlemesini ve temel raporları otomasyondan önce kurun.
• Sonra otomatikleştirin. Kolay kazandıran basit adımlardan başlayın, test edip yaygınlaştırın.
• Düzenli gözden geçirin. İşletme büyüdükçe yeni otomasyon alanları çıkar; kurgu sabit kalmamalı.