Satış Gücü Otomasyonu

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.

1. 01

   Aday Bulma

   Reklam, etkinlik, web formu, sosyal medyadan yeni aday akışı.

2. 02

   Niteleme

   Adayla konuşup gerçekten potansiyeli olup olmadığını anlama.

3. 03

   Olgunlaştırma

   Teklif, görüşme, pazarlık; ilgiyi karara taşıma.

4. 04

   Kapanış

   Anlaşmanın kazanıldığı ya da kaybedildiği nokta.

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 ve 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) olur; bunlar üzerinden Anlaşmalar (Deals) yürütülür, anlaşma kapanınca gelir oluşur. 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.

1. 01Adayı seçip "Dönüştür"e tıklayın

   Bu eylem için kullanıcı profilinde "Adayları Dönüştür" yetkisi gerekir.

   Aday detay sayfasından dönüştürme ekranını açın.

2. 02Hesap/Kişi: yeni mi, mevcuda mı

   Sistem önce benzer kayıt arar; mükerrer Hesap/Kişi yaratmamak için.

   Benzer kayıt bulunursa "mevcuda ekle" seçeneği çıkar; bulunmazsa yeni kayıt oluşturulur.

3. 03İsterseniz yeni Anlaşma açın

   Her aday hemen anlaşmaya dönmeyebilir; bu adım isteğe bağlıdır.

   Anlaşma Adı, Kapanış Tarihi ve Aşama gibi zorunlu alanlar burada doldurulur.

4. 04Dönüştür

   Alan eşlemesi doğruysa veri doğru modüllere akar; notlar ve ekler de taşınır.

   Taşıma yalnızca hedefteki boş alanları doldurur; mevcut değerin üzerine yazmaz.

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.

Kişiler (Contacts)

Birey düzeyi: Soyadı (zorunlu), Hesap Adı, Unvan, Departman, Cep, E-posta ve iki ayrı adres (yazışma + diğer). Açıklama yine 32.000 karaktere kadar not alır.

Hesaplar (Accounts)

Kurum düzeyi: firma adı, sektör, yıllık ciro, çalışan sayısı, adres. Altına birden çok Kişi ve Anlaşma toplanır.

İ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

Aşamalar (Stages)

Niteleme, ihtiyaç analizi, pazarlık, Kazanıldı, Kaybedildi gibi adımlar. Kendi sürecinize özel aşama eklenir.

Olasılık (Probability)

Her aşamaya 0-100 arası değer. Beklenen Geliri (tutar × olasılık) bu oran besler.

Anlaşma Kategorisi

Aşamanın genel durumu: Açık, Kazanıldı, Kaybedildi.

Tahmin Kategorisi

Aşamanın tahmine nasıl sayılacağı: Pipeline, Kapandı, Hariç.

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.

Görevler (Tasks)

Tek seferlik işler: teklif hazırla, evrak gönder. Sahip ve son tarih atanır.

Aramalar (Calls)

Planlanan ve geçmiş aramalar; süre, sonuç ve notuyla birlikte kayıt altında.

Toplantılar (Meetings)

Yüz yüze ya da çevrimiçi görüşmeler; katılımcı ve hatırlatmalarıyla.

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.

KVKK ve açık rıza

Aday ve Kişi kaydında "rıza durumu" ve "veri saklama süresi" birer alan olarak yer almalı, erişim rolle sınırlanmalı. SFA'nın topladığı her aday, aynı zamanda bir kişisel veridir.

WhatsApp kaynağı

Adayların büyük kısmı WhatsApp'tan geldiği için bunu ayrı bir "Aday Kaynağı" değeri yapın; kanal performansını ancak böyle ölçersiniz.

e-Fatura/ödeme

Anlaşma kapandıktan sonraki fatura adımı CRM dışındadır; entegrasyonu baştan planlamak, kapanış ile faturalama arasındaki boşluğu kapatır.

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ı.