Bu rehberi okuduğunuzda, "hangi otomasyon aracını kullanmalıyım" sorusuna değil, "bu işi insandan almaya gerçekten hazır mıyım" sorusuna cevap verebileceksiniz. Çünkü iş akışı otomasyonunda yaşanan sorunların çoğu otomasyon sorunu değildir; netleşmemiş bir süreç ya da kötü kurulmuş bir veri modeli, kurala bağlandığı anda hatayı yavaşlatmaz, hızlandırır. Aşağıda iş akışı kurallarından atama mantığına, puanlamadan yanıt-temelli takip dizilerine kadar Zoho CRM otomasyonunun bileşenlerini; gerçek sürüm sınırları, eylem limitleri ve çalışma sırasıyla birlikte ele alıyoruz. Sıralamamız manifestomuzun omurgasını izler: otomasyon en sona gelir, çünkü en sona aittir.
Otomasyon ne zaman doğru karardır
Bir butik estetik klinikte gün içinde Instagram, web formu ve telefondan onlarca randevu talebi düşer. Bunları elle danışmanlara dağıtmak, "aradınız mı" diye kovalamak, ilgilenmeyenleri ayıklamak günün yarısını yer. Otomasyonun çözdüğü şey bu görünmez iş yüküdür. Ama bir uyarı ile başlıyoruz: aynı klinikte "kim hangi adımdan sorumlu, bir talep hangi durumdan hangisine geçer" tanımlı değilse, otomasyon bu belirsizliği gizler, çözmez.
Manifestomuzun değişmez sırası vardır ve otomasyon bu sıranın altıncı basamağıdır. Bir süreç ölçülemiyorsa yönetilemez; yönetilemeyen bir sürece kural kurmak, yanlış işi daha hızlı yaptırmaktan başka işe yaramaz.
İlişki
Veri kiminle bağlı? Lookup'lar otomasyonun zeminidir.
Görünürlük
Yönetici neyi ölçüyor? Önce raporlanabilir olun.
Otomasyon
Hangi iş insandan alınabilir? Sıra şimdi geldi.
Arayüz
Kullanıcı ne görecek? En sona kalan adım.
Zoho CRM otomasyonu tek bir özellik değil, birbirini tamamlayan bir araç ailesidir: iş akışı kuralları, atama kuralları, onay süreçleri, puanlama kuralları, Cadence ve zamanlamalar. Bunları seçmek değil, doğru olanı doğru probleme eşlemek belirleyicidir.
İş akışı kuralının anatomisi
İş akışı kuralı (Workflow Rule), belirlenen koşullar sağlandığında devreye giren eylemler bütünüdür. Tek başına kural bir şey yapmaz; gücünü kendisine bağladığınız e-posta bildirimi, görev, alan güncelleme, webhook ve fonksiyon gibi eylemlerden alır. Bir kural dört parçadan oluşur. Aşağıda bir danışmanlık firmasının "nitelikli teklif" akışıyla bu parçaları somutlaştırıyoruz.
Temel bilgiler
Modülü (örneğin Anlaşmalar), kural adını ve açıklamayı girin. Açıklamayı boş geçmeyin; altı ay sonra "bu kural neyi yapıyordu" sorusuna tek cevabınız o olur.
Tetikleyici
Kayıt eylemi, tarih alanı, kayıt puanı, not, öneri ya da rakip anılması. Kritik kısıt: oluşturma anında seçilen tetikleyici tipi sonradan değiştirilemez.
Koşullar
"Tüm kayıtlar", "koşulu karşılayanlar" ya da ikinci koşuldan itibaren "yukarıdakilere uymayanlar". Mantıksal operatörlerle (ve/veya) gelişmiş filtre kurulur.
Eylemler
Anında ya da gecikmeli (planlı) eylemler. Senaryoda: aşama "Teklif Gönderildi" olunca yöneticiye e-posta gider, beş gün sonra danışmana takip görevi açılır.
Bir kuraldaki koşul sayısı sürüme bağlıdır ve bu, sürüm kararının otomasyonu doğrudan kısıtladığı yerlerden biridir:
| Sürüm | Bir kuraldaki azami koşul |
|---|---|
| Standard / Professional | 5 |
| Enterprise / Ultimate | 10 |
İş akışı kurallarını yalnızca Müşteri Adayları ya da Anlaşmalardan değil; Çağrılar, Randevular, E-posta ve hatta Facebook/Twitter etkileşimlerinden de tetikleyebilirsiniz. Cevapsız çağrıda yöneticiye uyarı düşürmek ya da müşteri direkt mesajla ürün sorduğunda otomatik teşekkür yollamak bu kapsamdadır.
İş akışı döngüleri (bir kuralın tetiklediği işlemin aynı kuralı yeniden tetiklemesi) sonsuza gitmesin diye üç çalıştırma sonrası otomatik durur. Silinen kayıt Geri Dönüşüm Kutusu'ndan tamamen silindiğinde "Silme" tetikleyicili kural çalışmaz; ayrıca Silme tetikleyicisi yalnızca e-posta bildirimi, fonksiyon ve webhook eylemlerini destekler.
Tetikleyiciyi doğru seçmek
Tetikleyici, otomasyonun kalbidir. Yanlış seçilen bir tetikleyici ya kuralı hiç çalıştırmaz ya da gereğinden fazla çalıştırıp gürültü üretir. Zoho CRM'in başlıca tetikleyici tipleri şunlardır:
Kayıt eylemine göre
Oluşturma, düzenleme, oluşturma-veya-düzenleme, silme. Düzenlemede "herhangi bir alan", "belirli alanlar" ya da "belirli bölümler" değişince diye daraltabilirsiniz.
Tarih alanına göre
Oluşturma zamanı, son etkinlik zamanı gibi alanlara göre gün/hafta/ay öncesi-sonrası. 10 dakikada en fazla 5.000 kayıt tetiklenir; büyük hacimde bu pencere planlamayı belirler.
Kayıt puanına göre
Puan arttığında, azaldığında veya güncellendiğinde devreye girer. Puanlama kurallarıyla birleşince güçlü bir önceliklendirme zinciri olur.
Not / öneri / rakip
Not eklenmesi, Zia öneri tarihi ya da e-posta yazışmasında bir rakibin (duygu durumuyla birlikte) anılması üzerine tetiklenir.
E-posta tetikleyicileri ve gerçek kör noktalar
IMAP ile bağlı herhangi bir e-posta hesabı (Zoho Mail, Outlook, Yahoo) iş akışı tetikleyebilir. Gelen e-postada alındı, yanıtlanmadı, açıldı-ama-yanıtlanmadı; giden e-postada gönderildi, sektü (bounced), açıldı, tıklandı, yanıtlandı, belirli sürede yanıtlandı aşamalarına göre kural kurarsınız. Bilinmeyen (CRM'de kayıtlı olmayan) gönderici için yalnızca webhook, fonksiyon ve kayıt oluşturma eylemleri açıktır; gönderici kayıt olduktan sonra diğer eylemler de devreye girer.
Gmail'in gizlilik politikası gereği Gmail API üzerinden gelen/giden e-postalar Zoho sunucusunda saklanmadığından, Gmail API entegrasyonlarında e-posta iş akışları desteklenmez. Ayrıca e-posta iş akışları henüz Sandbox'ta çalışmaz; test stratejinizi buna göre kurun.
Eylemler ve çalışma sırası
Eylemler, kuralların gerçek işi yaptırdığı yerdir. Modül bazında tanımlanır ve aynı eylem birden çok iş akışına, hatta Blueprint ve onay süreçlerine bağlanabilir. Bir eylemi düzenlediğinizde değişiklik onu kullanan tüm otomasyonlara yansır; bu yüzden ortak bir e-posta şablonunu değiştirmeden önce nerede kullanıldığını kontrol etmek şarttır.
E-posta bildirimi
Tek e-posta ya da tek toplu e-posta olarak gider. Toplu gönderimde alıcı sınırları: Kime 100, CC 50, BCC 50. Toplu e-posta izlenmez; açılma/tıklama verisi tutulmaz.
Görev
"Atanan kişi" boşsa görev kayıt sahibine düşer; atanan pasif/onaysızsa kayıt sahibine, gerekirse süper yöneticiye yönlenir. Konu satırı # ile birleştirme alanı destekler.
Alan güncelleme
Bir eyleme en fazla 3 alan güncellemesi bağlanır. Kayıt sahibini de değiştirebilir; üst (parent) kaydın alanını bile güncelleyebilir (örn. Kişi'den bağlı Firma'yı).
Webhook
Belirli olayda üçüncü taraf uygulamaya anlık HTTP bildirimi yollar: anlaşma kapanınca Zoho Books'a fatura verisi, ya da Creator'da komisyon hesabı tetikleme.
Fonksiyon
Deluge betikleriyle CRM içinde ya da dışında veri günceller. En esnek eylemdir; standart araçlarla çözülemeyen iş kurallarını burada yazarız.
Kayıt oluştur / dönüştür
Kayıt oluşturma Professional ve üzeri sürümlerde gelir. Adayı Kişi-Firma-Anlaşmaya dönüştürür; etiketler de taşınabilir.
Bir kuraldaki eylem limitleri
| Eylem tipi | Anında (azami) | Planlı blok başına |
|---|---|---|
| E-posta bildirimi | 5 | 5 |
| Görev | 5 | 5 |
| Alan güncelleme | 5 | 5 |
| Fonksiyon | 1 | 5 |
| Webhook | 1 | 5 |
| Kayıt oluşturma | 1 | — |
Planlı eylemler dakika, saat ya da gün gecikmeyle çalışır; bir kuralda en fazla 5 planlı blok tanımlanır. Enterprise sürümünde Zia'nın "en iyi iletişim zamanı" önerisi bu bloklarda kullanılabilir.
Webhook alan sınırları
| Alan | Sınır |
|---|---|
| Ad | 100 karakter (alfanümerik) |
| Açıklama | 200 karakter |
| Bildirilecek URL | 300 karakter; ${Modül.Alan} birleştirme alanını destekler |
| Başlık (header) | en fazla 10 parametre |
| Gövde (raw) | 15.000 karakter |
Bir kural tetiklendiğinde eylemler şu sırayla işler: alan güncellemeleri ve etiketler önce (sıralı), ardından e-postalar, görevler, Slack/Cliq bildirimleri, webhook'lar, fonksiyonlar ve kayıt oluşturma (paralel), en son dönüştürme. Bunu bilmek, "neden alan güncellenmeden e-posta gitti" tipi sürprizleri baştan engeller. Otomasyonlar arası sıra ise şudur: Atama Kuralı → İnceleme Süreci → Puanlama → İş Akışı Kuralı → Onay Süreci → Blueprint.
Atama: kayıt doğru ele gitsin
Adayları rastgele dağıtmak yerine bölge, ürün ya da kaynak gibi kriterlere göre doğru temsilciye yönlendirmek dönüşümü doğrudan etkiler. Atama kuralları (Assignment Rules) bunu otomatikleştirir: bir parfüm üreticisinde yurtiçi talepler bir ekibe, ihracat talepleri başka bir ekibe; bir klinikte saç ekimi adayları bir danışmana, estetik adayları diğerine gidebilir.
Atama kuralları yalnızca içe aktarma, web formu veya API ile gelen kayıtlarda çalışır; elle eklenen kayıtta devreye girmez. Bir kural girişi en fazla 25 kritere sahip olabilir. Onaysız (unconfirmed) kullanıcılar kayıt sahipliği almaz. Atama kuralları Müşteri Adayları, Kişiler, Firmalar, Anlaşmalar, Görevler, Talepler, özel modüller ve ekip modülleri için kurulabilir. Menü: Kurulum > Otomasyon > Atama.
Kapsamı belirleyin
Tüm kayıtlar ya da kritere uyanlar. Bir alanı başka bir alanla da karşılaştırabilirsiniz (örn. "Şehir, Bölge alanına eşitse").
Kime atansın?
Birden çok kullanıcı seçilirse round-robin (sırayla) dağıtım çalışır. Koşullu atamada "ABD kayıtları Jerusha'ya, Hindistan kayıtları Steve'e" gibi kural kurulur.
Müsaitlik kontrolü
Kullanıcının CRM'e giriş yapmış olmasına ve/veya vardiya saatine göre atayabilirsiniz. İkisi birden seçilirse hem çevrimiçi hem vardiyada olan kullanıcılara atanır.
Takip görevi
Atamadan sonra otomatik bir "ara/e-posta gönder" görevi ekleyin; böylece kayıt yalnızca el değiştirmez, üzerinde bir sonraki adım da netleşir.
Bir iş akışı kuralının içindeki "Kayıt sahibi ata" eylemi de bu mantığı kullanır. Burada kritik bir mekanik var: bir kayıt birden çok kural kriterine uysa bile sahip ataması yalnızca eşleşen ilk kuraldan yapılır; sonraki kurallar diğer eylemlerini çalıştırır ama sahibi değiştirmez. Bu, kaydın sürekli el değiştirmesini engeller.
Atama eşiği ve kapasite
Atama kuralları kaydı dağıtır; ama bir temsilciye günde 200 aday düşerse kalite çöker. Atama eşiği (Assignment Threshold), her kullanıcıya kapasitesine göre üst sınır koyar. Ekip ustalaştıkça eşik kademeli yükseltilir. İki bileşenden oluşur:
- Dönem başına azami sayı (zorunlu): Bir kullanıcıya gün/hafta/ay içinde atanabilecek en fazla kayıt. Varsayılan dönem gündür.
- İzin verilen birikim — backlog (opsiyonel): Üzerinde iş bekleyen kayıt sayısının tavanı. Hangi kaydın "birikmiş" sayılacağını siz kriterle tanımlarsınız (örn. 1-60 gündür temas edilmemiş adaylar).
Bir kayıt atanmadan önce iki kontrol yapılır: birikim sayısı izin verilenin altında mı (yalnızca backlog tanımlıysa) ve dönemdeki atama sayısı tavanın altında mı? İkisi de geçerse kayıt kullanıcıya gider; aksi hâlde varsayılan atanan kişiye (genelde satış yöneticisi) düşer. Varsayılan atananda bir kaydın ne kadar kalabileceğine süre koyabilir, süre aşılırsa kaydın eşiği zorlasa bile bir kullanıcıya atanmasını sağlayabilirsiniz. Yetki: Assignment Rules & Threshold. Menü: Kurulum > Otomasyon > Atama > Thresholds.
Eşiklerin iş akışı kurallarıyla etkileşimine dikkat. "Kayıt oluşunca/düzenlenince kayıt oluştur" tarzı bir kural, yeniden tahsiste sahip değiştiği için kuralı yeniden tetikleyebilir; üç-çalıştırma sınırı olsa da nadir kurgularda gereksiz kayıt çoğalmasına yol açar. Bu tür kurguları canlıya almadan önce mutlaka test ortamında deneriz — ki e-posta iş akışları Sandbox'ta çalışmadığından, atama tarafını ayrı bir org'da doğrulamak gerekebilir.
Puanlama: önceliği objektifleştirmek
Puanlama kuralları (Scoring Rules), "hangi kayda zaman ayrılmalı" sorusunu sezgiden çıkarıp ölçülebilir hâle getirir. Temel ilke: puan ne kadar yüksekse dönüşüm olasılığı o kadar yüksektir. İki yaklaşım vardır ve seçim, elinizdeki veri olgunluğuna bağlıdır.
Manuel puanlama
Her kanal ve faktör için kendi puanlarınızı siz tanımlarsınız. İş modelinize tam uyum sağlar; geçmiş veri gerektirmez.
Zia puanlaması
Sistem, geçmiş dönüşüm metriklerine bakarak puanı otomatik atar. Anlamlı sonuç için yeterli ve düzenli geçmiş veri ister.
Puanlama modeli her işletmede, hatta her departmanda farklıdır. Bu yüzden birden çok puanlama kuralı kurulabilir: satış, pazarlama ve destek aynı kişiyi kendi kriteriyle ayrı değerlendirir. Bir B2B satış puanlaması örneği:
- Son 20 günde çağrı yanıtlandıysa +10 puan
- Çağrı süresi 900 saniyeyi (15 dk) geçtiyse +20 puan
- Görüşmede "satın alma" anahtar kelimesi geçtiyse +20 puan
Puanın asıl gücü, bir iş akışı tetikleyicisi olarak kullanılmasında ortaya çıkar. Belli eşiği aşan aday otomatik kıdemli temsilciye atanabilir ya da "sıcak" etiketi alabilir. Böylece puanlama, atama ve iş akışı zinciri tek bir otomatik öncelik motoruna dönüşür.
Cadence: yanıta göre takip
Cadence, müşterinin tepkisine göre kendini ayarlayan çok kanallı takip dizisidir. E-posta, çağrı, görev ve WhatsApp adımlarını birleştirir; en kritik özelliği, hedeflenen yanıt alındığında kişinin diziden otomatik çıkmasıdır. Böylece "zaten cevap vermiş müşteriye dördüncü hatırlatma" gibi ilişkiyi yıpratan durumlar yaşanmaz.
Dinamik yön
Takipler müşterinin eylemine göre yön değiştirir; her kişinin yolculuğuna uygun kalır, sabit bir liste gibi davranmaz.
Çok kanallı
E-posta, çağrı, görev ve WhatsApp tek dizide birlikte kurgulanır; kanal körü bir kampanya değildir.
Otomatik çıkış
İstenen sonuca ulaşılınca kayıt diziden çıkar; ekibin odağı hep yanıt bekleyen aktif hedeflerde kalır.
Saha senaryoları
- Klinik / sağlık: Randevu onayı takvim davetiyle gider; açılmazsa randevu yaklaştıkça hatırlatma tetiklenir, gelmeme (no-show) oranı düşer.
- Eğitim / danışmanlık: Ön kayıt sonrası bilgi e-postası; yanıt verene kişisel görüşme daveti, vermeyene nazik ikinci hatırlatma kurgulanır.
- Emlak: İlgilenilen mülk için detay gönderilir; yanıta göre yerinde gezi planı ya da ek bilgilendirme devreye girer.
Çağrı takipleri Anlaşmalar (Deals) modülünde desteklenmez. WhatsApp adımı için Business Messaging etkin olmalıdır. Bir takip adımı oluşturulduktan sonra (yalnızca son adım hariç) silinemez; bu yüzden diziyi kurmadan önce kâğıt üzerinde planlamak gerekir. Erişim için "Cadences Enrollment" ve "Manage Automation" yetkileri aranır.
Zamanlamalar ve fonksiyon sınırları
Zamanlamalar (Schedules), bir Deluge fonksiyonunu belirli bir anda ya da düzenli aralıkla (günlük/haftalık/aylık/yıllık) otomatik çalıştırır. İş akışı kuralları bir kayıt değiştiğinde tetiklenirken, zamanlamalar takvime bağlıdır. Tipik kullanım: kişileri başka uygulamayla periyodik senkronlamak, CRM verisini yedek için eski sisteme aktarmak ya da boşta kalan aday/anlaşmalar için uyarı üretmek. Menü: Kurulum > Otomasyon > Zamanlamalar; yetki: Manage Workflow.
- Bir kuruluşta aktif/pasif fark etmeksizin en fazla 10 zamanlama olabilir.
- Başlangıç tarihi bugünden itibaren 1 yılı aşamaz; "Şimdi Çalıştır" ile günde en fazla iki kez elle tetiklenir.
- Fonksiyon 15 dakikadan uzun sürmemeli ve 200.000 satır yürütmeyi geçmemeli; mümkünse entegrasyon görevleri (integration tasks) tercih edilmelidir.
- Aynı zamanlama adı tekrar kullanılamaz; her çalıştırma CRM Denetim Günlüğü'ne (Audit Log) yazılır, başarısızlar Failure sekmesinde görünür.
Fonksiyon ve API çağrı limitleri
| Kaynak | Günlük sınır (tipik) |
|---|---|
| Özel fonksiyon (Custom Function) çağrısı | 20.000/gün veya kullanıcı lisansı başına 200 — hangisi düşükse |
| Deluge üzerinden Zoho API çağrısı | 25.000/gün |
| GET / POST çağrısı (her biri) | 25.000/gün |
Professional: 50.000/gün veya kullanıcı başına 100 · Enterprise: 500.000/gün veya kullanıcı başına 500 · Ultimate: 1.000.000/gün veya kullanıcı başına 1.000. Yoğun entegrasyon tasarımında bu tavanlar mimari kararı belirler; kesin ve güncel sayı için lisans/DC kontrolü önerilir.
Limitler, raporlar ve kör noktalar
İyi kurulmuş bir otomasyon görünmez çalışır; ama görünmezliği "çalıştığını varsaymak" ile karıştırmamak gerekir. E-posta limitleri ve kullanım raporları, sistemin gerçekten işe yarayıp yaramadığını gösteren tek dürüst kaynaktır.
Günlük otomasyon e-posta limitleri
| Sürüm | Günlük limit (hangisi düşükse) |
|---|---|
| Free / Starter | (Kullanıcı × 50) veya 5.000 |
| Standard | (Kullanıcı × 100) veya 5.000 |
| Professional | (Kullanıcı × 200) veya 10.000 |
| Enterprise | (Kullanıcı × 500) veya 25.000 |
| Ultimate | (Kullanıcı × 1.000) veya 50.000 |
Free sürümde otomasyon e-postaları yalnızca organizasyon içi kullanıcılara gider; adaylara ya da kişilere değil. Bu, Free'de "müşteriye otomatik karşılama e-postası" kurgusunun neden çalışmadığını açıklar.
Kullanım raporu ve başarısız eylemler
Kullanım raporu, bir kuralın her aşamada kaç kaydı etkilediğini gösterir: tetiklemeye uyanlar, koşulu sağlayanlar, eylemlerin sonucu (gönderilen, sektü, açılan, tıklanan e-postalar). Bir eylem hatalı e-posta adresi, limit aşımı ya da webhook/fonksiyon hatasıyla başarısız olursa, hata listesinden nedeniyle birlikte görüp yeniden deneme (retry) yapabilirsiniz.
- Yeniden deneme yalnızca e-posta bildirimleri, webhook'lar ve özel fonksiyonlar için geçerlidir; eylem başına en fazla 5 deneme.
- Önceki alan değerleriyle (bağlantı/limit sorunu için) ya da güncel değerlerle (veri düzeltildiyse) deneyebilirsiniz; öncesinde koşul kontrolü yaptırmayı seçebilirsiniz.
- Bir kuralı silmek, etkilenen kayıtlara ait tüm planlı eylemleri de siler; aday dönüştürülünce o adaya ait planlı eylemler çalışmaz.
- Etiketleme kayıt başına 10 etiketle sınırlıdır; aşan etiketler başarısız sayılır.
