Bu rehberi okuduğunuzda, satış ve operasyon süreçlerinizi CRM içinde kurallaştırırken hangi aracı seçeceğinizi ve nerede durmanız gerektiğini bileceksiniz. Çoğu işletmede süreç "var"dır ama sadece bir kişinin kafasında ya da bir Excel'de yaşar; ekip büyüyünce indirimler yöneticiye sorulmadan verilir, eksik belgeyle teklif kapanır, web formundan gelen hatalı veri olduğu gibi sisteme akar. Zoho CRM bu boşluğu üç araçla kapatır: Blueprint (sürecin dijital kopyası), Onay Süreci (yetki kapısı) ve İnceleme Süreci (veri kalite kapısı). Biz bu rehberde her birinin gerçek mekaniğini, sürüm limitlerini ve — en önemlisi — hangisini ne zaman kullanmayacağınızı somut bir klinik senaryosuyla anlatıyoruz.
Süreci Önce Tasarlayın, Sonra Sisteme Verin
İş süreci, ortak bir hedefe ulaşmak için birden çok kişinin sırayla yürüttüğü adımlardır: hasta kabulü, teklif hazırlama, sevkiyat, sözleşme onayı. Bu adımlar tek bir departmanda kaldığında sorun çıkmaz; departmanlar arasına dağıldığında bir görev atlanır, bir bilgi eksik kalır, aynı iş iki kez yapılır. Zoho CRM süreç yönetimi tam bu noktada devreye girer: kâğıttaki akışı yazılıma alır, her kayıt için tekrarlanabilir kılar ve "bu aşamada ne yapılmalı, kim yapmalı" sorusunun cevabını kişiye değil sisteme bağlar.
En sık yapılan hata, süreci sistemin izin verdiği şekilde tasarlamaktır. Doğru sıra terstir: önce süreç tasarlanır, sonra sistem sürece uyarlanır. Bunun için de süreci yazılıma dökmeden önce şu sıraya sadık kalırız.
Süreç
Gerçekte ne oluyor? Aşamalar ve sıraları neler?
Karar
Hangi noktada kim karar veriyor? Yetki nerede?
Veri
Her adımda hangi bilgi oluşuyor, hangisi zorunlu?
Otomasyon
Hangi işler insan yerine sisteme bırakılabilir?
Bu sıra, hangi aracı seçeceğinizi de belirler: süreç ve aşama → Blueprint; karar ve yetki → Onay Süreci; gelen verinin doğruluğu → İnceleme Süreci. Yetki tarafında küçük bir not: Blueprint ve Onay Süreci'ne "Otomasyon Yönetimi" (Manage Automation) iznine sahip kullanıcılar erişir; takım modülü yöneticileri kendi modülleri için yapılandırabilir.
Sahada gördüğümüz tablo nettir: süreçler aslında vardır, ama yazılım onları zorlamadığı için kimse aynı şekilde uygulamaz. "Aday hangi noktada 'Görüşüldü' sayılır — bir aramadan sonra mı, beşten sonra mı?" sorusunun yazılı bir cevabı yoksa, ekibin yarısı bir cevabı diğer yarısı başka cevabı uygular. Süreç yönetimi araçları bu boşluğu kapatır.
Blueprint Her Zaman Doğru Cevap Değildir
Blueprint teknik olarak yetenekli bir araçtır: bir kaydın her adımında "şu yapılmadan ileri gidilemez" kuralını sisteme dayatır. Bu, çağrı merkezi gibi tek tip akışlarda işi disipline eder. Ancak randevu, tedavi, danışmanlık gibi istisnası bol operasyonlarda aynı katılık kullanıcıyı kilitler: hasta sırayı bozar, bir aşama atlanması gerekir, ama sistem geçmez. Bu rehberin en kritik kararı budur — Blueprint'i ne zaman kullanmayacağınızı bilmek.
| Soru | Blueprint uygun | Durum alanı + İş akışı uygun |
|---|---|---|
| Akış ne kadar değişken? | Sabit, tek tip, herkes aynı sırayı izler | İstisna bol, sık atlama/geri dönüş var |
| Adım atlanırsa ne olmalı? | Kesinlikle engellenmeli (uyum şart) | Uyarı yeter, kullanıcı tıkanmamalı |
| Kullanıcı yükü | Her geçişte form doldurmaya değer | Manuel form yükü süreci yavaşlatır |
| Tipik örnek | İndirim onayı, sözleşme imza akışı | Hasta takibi, esnek randevu, destek |
Manifesto duruşumuz şudur: kullanıcıyı zorlamak yerine, mümkün olduğunca durum alanı + iş akışı kuralı + planlı fonksiyon + bildirim ile süreci yönlendiririz. Süreç ilerler ama kullanıcı tıkanmaz. Blueprint'i ise yalnızca atlamanın gerçekten yasak olduğu, denetlenebilirliğin zorunlu olduğu noktalara koyarız.
Bir not da yetkiler için: Blueprint, bir geçiş yürütülürken kullanıcının alan erişim haklarını geçersiz kılar ve süreci kurduğunuz birincil alanı (ör. Aşama) kilitler. Yani "neden bu alan elle düzenlenemiyor?" şikâyeti aslında doğru çalışan bir Blueprint'in işaretidir. Bunu baştan tasarlamak sonradan kafa karışıklığını önler.
Blueprint Nasıl Çalışır: State ve Transition
Blueprint, iş sürecinizin çevrimiçi bir replikasıdır. Teknik temeli, Sonlu Durum Makinesi (Finite State Machine) modelidir: bir kayıt aynı anda yalnızca tek bir durumda olabilir; bir tetik geldiğinde önceden tanımlı kurala göre başka duruma geçer. Metrodaki turnike de bu modeldir — "kilitli" ve "açık" iki durum; jeton, geçişi tetikler. Blueprint'in iki yapı taşı tam olarak budur.
Aşama (State)
Kaydın belirli bir andaki durumu. Aşamalar kendi başına yazılmaz; seçtiğiniz bir seçim listesi (picklist) alanının değerlerinden türer — ör. Anlaşma Aşaması alanı. Başlangıç (Start) aşaması, o alanın "None / boş" değerine karşılık gelir.
Geçiş (Transition)
İki aşama arasındaki bağ. Bir kaydın ilerlemesi için gereken koşulları ve yapılacak işleri tanımlar. Her geçiş, kayıt detay sayfasında tıklanabilir bir buton olarak çıkar; tamamlanmadan kayıt ilerlemez.
Önemli bir ayrım: aynı yapı taşlarını (State, Transition, Action) Journey Builder de kullanır, çünkü o da FSM modelindendir. Ama amaçları farklıdır. Blueprint'te geçişi tetikleyen şey bir veri zorunluluğudur (alan girişi, ek belge, checklist); Journey Builder'da ise bir sinyaldir (e-posta açıldı, ankete cevap geldi). Bu yüzden "Journey Builder, modüller arası bir Blueprint'tir" demek yanlıştır — biri uyumu, diğeri müşteri yolculuğunu çözer.
Somut senaryo: İstanbul'da estetik klinik
Bir butik estetik klinik, rinoplasti tekliflerini şu akışla yönetmek istiyor: Niteleme → Konsültasyon → Fiyat Teklifi → Sözleşme. Her aşamada farklı kişi sorumlu (danışman, doktor, ön muhasebe), her geçişte farklı belge gerekiyor (KVKK aydınlatma onayı, hasta foto-arşivi, fiyat onayı). Blueprint bu akışı görselleştirir; danışman "sırada ne var" diye düşünmez, doğru butonu görür, gerekeni doldurur, kayıt ilerler. Tedavi sürecinin kendisi (ameliyat sonrası kontrol randevuları) ise istisnası bol olduğu için — Bölüm 2'deki ilkeyle — Blueprint yerine durum alanı + hatırlatma iş akışıyla kurulur.
Blueprint Professional sürümden itibaren gelir (Professional'da 1 varsayılan Blueprint hazır tanımlıdır). Free ve Standard sürümlerde Blueprint yoktur. Kiosk eklemek ve kullanıcı tanımlı SLA aksiyonları Enterprise ve üzeri gerektirir.
Blueprint Kurma: Üç Adım ve Taslak
Bir Blueprint kurmak özünde üç adımdır: temel bilgileri girmek, akışı çizmek, geçiş ayarlarını yapmak. Menü yolu hepsinde aynıdır.
Temel Bilgiler
Ayarlar > Süreç Yönetimi > Blueprint > + Blueprint Oluştur yolunu izleyin. Modülü, düzeni (layout) ve aşamaların türeyeceği seçim listesi alanını seçin. İsteğe bağlı kriter koyun (ör. Tutar ≥ 50.000); kriter koymazsanız o düzendeki tüm kayıtlar sürece girer. Birincil alan yalnızca şu kanallardan güncellenebilir: Transition API, Workflow API, iş akışı içindeki Özel Fonksiyon, iş akışı Alan Güncelleme ve Command Center Alan Güncelleme — başka kanal yoktur.
Akışı Çizin
Blueprint Editörü'nde aşamaları sürükle-bırak ile yerleştirin, düğümleri birleştirerek akışı kurun. İki aşama arasındaki + butonuyla geçiş oluşturun (silmek için geçiş çizgisine sağ tıklayıp Geçişi Sil). Bir aşamadan en fazla 20 sonuç (çıkış) tanımlanabilir.
Geçiş Ayarları
Her geçiş için Önce (Before), Sırasında (During), Sonra (After) ayarlarını yapılandırın. Bu üçlüyü bir sonraki bölümde ayrıntılı açıyoruz.
Bir Blueprint yayımlandığı an kriteri karşılayan kayıtlar sürece girmeye başlar. Hazır olmadan yayımlamayın: Taslak (Draft) olarak kaydedip rahatça deneyin. Aynı anda bir yayımlı + bir taslak sürüm tutabilirsiniz. Dikkat: taslak bir tuvaldir, test ortamı değil — gerçek davranışı denemek için canlı veriyi etkilemeyen Sandbox kullanın. (Portal kullanıcısını geçiş sahibi yapmak Sandbox'ta desteklenmez.)
Klonlama ve toplu dahil/hariç
Benzer bir süreç için sıfırdan başlamak yerine mevcut Blueprint'i klonlayın; klonlarken yeni aşama ekleyebilir veya eski aşamaları yenilerine eşleyebilirsiniz. Not: yalnızca yayımlanmış Blueprint'ler klonlanabilir. Mevcut kayıtları yeni bir Blueprint'e toplu almak, bir gruptan diğerine taşımak ya da çıkarmak için Filtreler sekmesini kullanın (modül/düzen/Blueprint ve kriter seçilir, eşleşenler toplu Dahil/Hariç edilir).
Gelişmiş Ayarlar altında Sürekli (Continuous) Blueprint oluşturabilirsiniz — duraksamadan tek seferde yürüyen süreçler için, ör. satış arama senaryosu. Tek farkı: tüm sürecin tek sahibi olabilir (normal Blueprint'te her aşamanın farklı sahibi olabilir) ve "Taslak Kaydet" desteklenmez.
Geçişin Zekâsı: Önce / Sırasında / Sonra
Bir geçişin tüm zekâsı bu üç katmanda saklıdır. Kliniğimizin "Konsültasyon → Fiyat Teklifi" geçişini örnek alalım: teklifi yalnızca doktor onayından sonra danışman açabilmeli, indirim oranı ve geçerlilik tarihi girilmeli, indirim %20'yi geçmemeli, kayıt sahibine otomatik bildirim gitmeli. Hepsi şu üç katmanla kurulur.
Önce (Before)
Bu geçişi kim yürütebilir (CRM veya portal kullanıcıları) ve hangi kayıtlarda görünür (kriter). Örn. yalnızca "Doktor Onayı = Tamamlandı" olan kayıtlarda buton çıksın. Kriter koymazsanız buton tüm kayıtlarda görünür.
Sırasında (During)
Geçişi tamamlamak için ne girilecek: alanlar (doğrulamalı), kontrol listeleri, not/dosya/görev/toplantı/arama, etiketler, mesaj, widget ve Kiosk. Bunlar varsayılan olarak zorunludur; isteğe bağlı yapabilirsiniz.
Sonra (After)
Geçiş bitince ne otomatikleşecek: e-posta bildirimi, görev/toplantı/arama oluşturma, alan güncelleme, kayıt oluşturma, webhook ve özel fonksiyon tetikleme, etiket ekleme, kayıt dönüştürme (yalnızca Aday ve Teklif modüllerinde).
"Sırasında" katmanının gücü ve sınırı
Doğru veriyi doğru anda toplamanın en etkili yeri burasıdır. Bir alanın nihai zorunluluğu üç koşula bağlıdır — modül alanının kendisi, düzen kuralı ve Blueprint geçiş ayarı; bunlardan en az biri zorunluysa alan zorunlu olur. Checklist ile atlama yapmayı engellersiniz (ör. "KVKK aydınlatma onayını ekle", "Hasta foto-arşivini bağla").
Çoklu seçim lookup (MxN) ve çoklu kullanıcı (MxU) alanları geçişe eklenebilir ama doğrulanamaz. Bir geçişe widget eklediğinizde o sekmedeki diğer tüm öğeler kaldırılır — widget tek başına çalışır. Ayrıca "Taslak Kaydet", düzen kuralı tetiklendiğinde, yalnızca mesaj alanı olduğunda, widget bulunduğunda ve Sürekli Blueprint'te desteklenmez.
Tıkanmayı Çözen Geçişler ve SLA
Temel akışın ötesinde, gerçek hayattaki dağınıklığı düzene sokan geçiş tipleri vardır. Bunlar Blueprint'i katı bir kafesten esnek bir yönlendiriciye dönüştürür.
- Ortak Geçiş (Common Transition): Her aşamadan erişilebilir. Bir anlaşma her aşamada kaybedilebileceği için "Anlaşma Kaybedildi"yi ortak geçiş yapın — tüm aşamalarda buton görünür.
- Paralel Geçiş: Aynı iki aşama arasında eşzamanlı yürüyen birden çok alt-geçiş. Bir etkinlik kurgusunda "Lojistik"i tek adım yerine mekân, ikram, bilet, baskı diye dört paralel alt-geçişe bölün; hepsi tamamlanmadan ana geçiş bitmez. Alt-geçişlerin yürütme sırası serbesttir; veriler tüm alt-geçişler bitene dek kısmi kaydedilir. Paralel geçişlerde widget desteklenmez.
- Otomatik Geçiş: Kayıt bir aşamada belirlenen "Bekleme" süresinden uzun kalırsa otomatik başka aşamaya taşınır. Ör. "Nitelendi" aşamasında 5 gün hareketsiz kalan kayıt bir sonraki aşamaya geçsin — bekleyen işi ve tıkanmayı önler.
- Aynı aşamada döngü: Müşteriye ulaşana kadar tekrar deneme gibi durumlarda "Tekrar Ara" geçişi aynı aşamaya geri döner; ulaşılınca ileri ilerlenir. Aynı durumda kalmak işin yapılmadığı anlamına gelmez.
Renk ve sıra: benimseme meselesi
Bir aşamadan çok sayıda geçiş çıkıyorsa (Onayla, Reddet, Beklet, Yeniden Ata) hepsi mavi ve sırasız olunca temsilci şaşırır, geçişler yapılmaz, kayıtlar tıkanır. Geçişlere renk verin (Onayla yeşil, Reddet kırmızı, Beklet turuncu) ve sıralayın. Reorder ikonu yalnızca birden çok geçişi olan aşamalarda görünür.
SLA: süreyi denetleyin
SLA, bir kaydın bir aşamada en fazla ne kadar kalabileceğini tanımlar; süre aşılınca CRM ilgili kişileri uyarır. Ör. "Pazarlık" aşaması en fazla 5 gün; aşılınca kayıt sahibine eskalasyon. Standart uyarının yanına süre dolmadan 2 saat önce hatırlatma da koyabilirsiniz. Kullanıcı tanımlı SLA aksiyonları (özel e-posta, görev, alan güncelleme, webhook, özel aksiyon) Enterprise sürümden itibaren gelir — ör. 5 günü aşan kayıtlarda "Aciliyet" alanını "Hafif"ten "Yüksek"e çekip filtreyle önceliklendirme.
Onay Süreci: Altı Adım, Kim Onaylar
Bazı kararlar bir veya birden çok üst yetkilinin onayını gerektirir: belirli oranın üstündeki indirimler, satın alma siparişleri, bütçeler, kampanya harcamaları, izinler. Onay Süreci (Approval Process), kriteri karşılayan kayıtları otomatik olarak doğru kişilere onaya gönderir; "kayıtları elle tarayıp birine yollama" zahmetini ortadan kaldırır. Bir onay süreci tam olarak altı adımdan oluşur.
Kural Kriteri
Hangi kayıt onaya girer? (Kriter zorunludur.)
Kim Onaylar
Kullanıcı / Rol / Grup / Seviye / Yönetici / Kayıt Sahibi.
Onay Aksiyonu
Onaylanınca ne olacak?
Ret Aksiyonu
Reddedilince ne olacak?
Kalan iki adım: (5) kayıt beklerken hangi alanlar düzenlenebilir, (6) kim devralabilir (süreç yöneticileri). Menü yolu: Ayarlar > Süreç Yönetimi > Onay Süreçleri > Onay Süreci Ekle. Tetikleme "Kayıt Oluşturma" ve/veya "Kayıt Düzenleme" olarak seçilir.
Onaylayıcıyı seçmenin esnekliği
Birden çok onaylayıcı eklediğinizde davranışı siz belirlersiniz:
- Herhangi biri (Anyone): İçlerinden biri onaylarsa kayıt ilerler.
- Herkes – Sıralı (Sequential): Listedeki sıraya göre; ilk kişi onaylamadan ikincisi göremez.
- Herkes – Paralel: Hepsi onaylamalı ama eşzamanlı, sırasız.
- Seviyeler (Levels): Onay, kayıt sahibinin hiyerarşideki konumuna göre üst rollere/raporlama yöneticilerine gider. Reporting hiyerarşisinde yönetici yoksa, tercihinize göre bir üst rol / CEO / yönetici onaylar. Boş bir rol seçilirse o seviye otomatik onaylanmış sayılır.
Onay ve ret aksiyonlarının ince ayrımı
Çok aşamalı onayda her onay sonrası görev atama ve alan güncelleme yapılabilir; ancak e-posta uyarısı, webhook ve özel fonksiyon yalnızca nihai onaydan sonra bir kez çalışır. Reddedilince görev atanmaz (çünkü görevin amacı bir sonraki onaylayıcıyı uyarmaktır); önceki onaylayıcılar bilgilendirilir, alan güncelleme/e-posta/webhook/fonksiyon yine tetiklenebilir. Ret e-postası sistem tarafından notifications@zohocrm.com adresinden gönderilir.
Onay beklerken kayıt kilitlenir — dönüştürülemez, silinemez. İzin verirseniz beklerken yalnızca seçili alanlar (en fazla 25 alan) düzenlenebilir. Kayıtlar My Jobs > Onay Süreci sekmesinde toplanır; onaylayıcı buradan Onayla / Reddet / Devret (Delegate) yapar. Kayıt sahibi bekleyen kaydı Geri Çağırma (Recall) ile düzenlenebilir hale getirip yeniden gönderebilir (bu özellik erken erişimdedir, Org ID ile destekten açtırılır). Reddedilen kayıtlar 180 gün içinde yeniden gönderilebilir; onay için tanımlı bir süre sınırı yoktur.
İnceleme Süreci: Alan Bazlı Kapı
İnceleme Süreci (Review Process), veri CRM'e girmeden önce belirli alanların doğruluğunu denetleyen bir kontrol noktasıdır. Özellikle web formundan, API'den, portaldan veya üçüncü taraf entegrasyonundan gelen kayıtlarda değerlidir: hatalı veriyi sisteme hiç sokmadan eler. İncelemedeki kayıtlar kilitlenir, modül liste görünümlerinde gizlenir ve o aşamada iş akışı/onay gibi otomasyonların çalışması durur.
Onay sürecinden en kritik farkı: İnceleme, kaydın tek tek alanlarını denetler. İncelemeci her alanı ayrı onaylar veya reddeder; bir alan reddedilirse tüm kayıt reddedilmiş sayılır. Kayıt giriş kriterine girmeyenler de bir kullanıcıya incelemeye atanabilir.
Süreç bilgisi ve kriter
Ad, açıklama, modül ve düzen girilir (İnceleme düzene özeldir); tüm kayıtlar mı yoksa kriterdekiler mi (ör. web formundan gelenler) inceleneceği seçilir. Her modül için birden çok inceleme süreci kurulabilir. Kayıtlar önce doğrulama kurallarından ve web form onayından geçer, sonra incelemeye girer.
İncelenecek alanlar
İncelemecinin çapraz kontrol edeceği alanlar seçilir. Metin, e-posta, telefon, tarih/saat, sayı/para/yüzde, URL, seçim listesi, çoklu seçim, onay kutusu ve dosya yükleme gibi pek çok tür — alt formdaki bu türler dahil — incelenebilir.
Kurallar ve incelemeciler
En fazla 5 kural eklenir; her kuralda ek filtre + atanan incelemeci olur (ör. "ülke Kanada ise Mike", "kişisel sağlık sigortasıysa David", kalanlar Rachel'a). İncelemeciler Kullanıcı / Rol / Grup / Kayıt Sahibi'nden seçilir; en fazla 5 incelemeci.
Aksiyon ve ret nedenleri
Gönderim, tamamlanma, ret ve SLA eskalasyon bildirimleri seçilir. Varsayılan ret nedenleri (Geçersiz Giriş, Veri Yetersiz, Veri Uyuşmuyor) yanına en fazla 10 olacak şekilde özel neden eklenebilir.
İncelemeciler bekleyen kayıtları My Jobs > İnceleme Süreci altında görür; alan yanındaki onay simgesinden alanı onaylar ya da reddeder. Bir incelemeci tüm alanları sonuçlandırınca kayıt süreçten çıkar ve diğer incelemecilere artık görünmez. Toplu silmeyi yalnızca CRM yöneticileri yapabilir.
İncelemede 3 aydan uzun bekleyen kayıtlar otomatik silinir. Entegrasyonlar için v2.1 API gerekir; v1 API inceleme sürecinin çalışmasını engeller. İnceleme süreci Kampanyalar, Etkinlikler (Activities) ve Zoho Finance modülleri için kurulamaz.
Onay mı, İnceleme mi? Net Tablo
İki araç da "veriyi sisteme almadan denetleme" işi yapar ama farklı kası çalıştırır. Kabaca: Onay, kaydın bütününe yetki verir/vermez (karar gerektiren işler — indirim, bütçe, sipariş); İnceleme, alanların doğruluğunu denetler (form verisinin temizliği). Aşağıdaki tablo seçimi netleştirir.
| Karşılaştırma | Onay Süreci | İnceleme Süreci |
|---|---|---|
| Denetlenen birim | Kaydın tamamı | Kaydın seçili alanları |
| Tetiklenme | Kayıt oluşturma ve düzenleme | Sisteme giren tüm kayıtlar |
| Alan bazlı onay/ret | Yok | Var |
| Düzene özel | Hayır | Evet |
| Maks. onaylayıcı / incelemeci | 10 | 5 |
| Herkesin onayı şart mı? | Yapılandırmaya bağlı (herhangi/sıralı/paralel) | Hayır; herhangi bir incelemeci yeter |
| Onaylayıcı/incelemeci kaynağı | Kullanıcı, Rol, Grup, Seviye, Yönetici, Kayıt Sahibi | Kullanıcı, Rol, Grup, Kayıt Sahibi |
| Devretme (delegate) | Var | Yok |
| Tamamlama süresi / SLA | Süre yok | Süre + SLA eskalasyon |
| Onaylayıcıya/incelemeciye görev | Atanabilir | Atanamaz |
| Hazır raporlar | Yok | Var (4 rapor) |
Pratik kural: kararın kim onaylayacak ve devredilebilmeli kısmı önemliyse Onay; gelen verinin alan alan doğruluğu ve süre takibi önemliyse İnceleme. İkisi birbirini dışlamaz: bir kayıt önce inceleme noktasından geçip temizlenir, sonra bir Blueprint'e ve gerekirse onay sürecine girer. Üçü de — Blueprint, onay, inceleme, hatta Journey Builder ve Cadence — birbirini kesmeden aynı anda çalışır; tek dikkat edilecek nokta, aynı e-postayı/aksiyonu birden fazla aracın tetiklememesidir.
Limitler, Çalışma Sırası, Raporlar
Süreç tasarlarken sürüm limitlerini bilmek, sonradan duvara toslamayı önler. Blueprint'in başlıca limitleri sürüme göre şöyledir:
| Blueprint Limiti | Professional | Enterprise | Ultimate |
|---|---|---|---|
| Sürüm başına Blueprint sayısı | 3 | 20 | 100 |
| Blueprint başına geçiş | 10 | 100 | 300 |
| Ortak geçiş sayısı | 2 | 5 | 25 |
| "Sırasında" bölümünde istenebilen alan | 4 | 10 | 50 |
Onay ve inceleme tarafındaki kritik limitler: modül başına en fazla 10 aktif onay süreci, her onay sürecinde en fazla 5 kural, "Kim onaylamalı" altında en fazla 10 giriş, en fazla 15 süreç yöneticisi, beklerken en fazla 25 düzenlenebilir alan. İncelemede en fazla 5 kural, 5 incelemeci, 10 özel ret nedeni. (Free/Standard'da Blueprint yoktur; kesin sürüm taahhüdü öncesi lisans/DC kontrolü öneririz.)
Bir kayıt kaydedildiğinde otomasyonlar şu sırayla çalışır: Atama Kuralları → İş Akışı Kuralları → Onay Süreci → Blueprint → Vaka Eskalasyon Kuralları. Üst üste binmeleri önlemek için tasarımı bu sırayı bilerek yapın. Ayrıca: yalnızca İş Akışı, Blueprint aksiyonunu geçersiz kılabilir; Onay, Atama vb. Blueprint'i ezemez. Blueprint'ler de sayfadaki listeleme sırasına göre çalışır; benzer şekilde bir kayıt birden çok onay/inceleme kuralına uyuyorsa ilk eşleşen kurala göre işlenir — bu yüzden kural sırası önemlidir.
İçgörü için raporlar
Süreci kurmak yetmez; ölçmek gerekir. Blueprint hazır raporları Ayarlar > Süreç Yönetimi > Blueprint > Kullanım (Usage) altındadır:
- Aşama başına ortalama süre — kayıtlar nerede tıkanıyor?
- Blueprint başına ortalama süre — sürecin uçtan uca hızı.
- Aktif / tamamlanan kayıt sayısı — anlık iş yükü ve verim.
- Geçiş tekrar sayısı + aşamada geçen toplam süre — hangi adımlar en çok yapılıyor, nerede zaman kaybı var.
Bu hazır raporlara ek olarak Raporlar modülünde, bir modül raporu kurarken İlgili Modüller arasından ilgili Blueprint'i seçerek özel rapor da üretebilirsiniz (ör. "Anlaşma Blueprint Durum Raporu"). İnceleme sürecinin de dört hazır raporu vardır: ortalama bekleme süresi, durum bazlı kayıt sayısı, alan bazlı durum ve ret nedeni dağılımı (Ayarlar > Süreç Yönetimi > İnceleme Süreçleri > İnceleme Analitiği). Onay sürecinin hazır raporu yoktur, ama tüm geçmiş My Jobs > Onay Süreci > Onay Geçmişi'nde modül/kullanıcı/aksiyon/zaman filtreleriyle incelenebilir.
Eksenium olarak yaklaşımımız nettir: önce sizin gerçek akışınızı dinleriz, sonra onu en az kural ve en az tıklamayla CRM'e gömeriz. Aşırı karmaşık Blueprint'ler benimsenmez; sade, renk kodlu, doğru ölçülen ve yalnızca atlamanın gerçekten yasak olduğu yerde zorlayan süreçler kalıcı olur.
