Süreç Yönetimi (Blueprint, Onay, İnceleme)

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.

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, 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 ve 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.

Bir Blueprint kurmak özünde üç adımdır: temel bilgileri girmek, akışı çizmek, geçiş ayarlarını yapmak. Menü yolu hepsinde aynıdır.

1. 01Temel Bilgiler

   Sürecin hangi kayıtlar üzerinde, hangi alana göre çalışacağını belirler.

   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.

2. 02Akışı Çizin

   Sürecin görsel haritasını oluşturur; herkes aynı resmi görür.

   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.

3. 03Geçiş Ayarları

   Sürecin kuralları burada hayata geçer.

   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.

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

Bir geçişin tüm zekâsı bu üç katmanda saklıdır. Bu örnekteki kliniğin Konsültasyon aşamasından Fiyat Teklifi aşamasına geçişini ele 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").

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.

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.

1. 1

   Kural Kriteri

   Hangi kayıt onaya girer? (Kriter zorunludur.)

2. 2

   Kim Onaylar

   Kullanıcı / Rol / Grup / Seviye / Yönetici / Kayıt Sahibi.

3. 3

   Onay Aksiyonu

   Onaylanınca ne olacak?

4. 4

   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.

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

1. 01Süreç bilgisi ve kriter

   Hangi kayıtların inceleneceğini netleştirir.

   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.

2. 02İncelenecek alanlar

   Denetimi gerçekten önemli alanlarla sınırlar.

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

3. 03Kurallar ve incelemeciler

   Doğru kaydı doğru kişiye yönlendirir.

   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.

4. 04Aksiyon ve ret nedenleri

   Süreci şeffaf ve hesap verebilir kılar.

   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.

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

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.

Süreç tasarlarken sürüm limitlerini bilmek, sonradan duvara toslamayı önler. Blueprint'in başlıca limitleri sürüme göre şöyledir:

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

İç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.