Koşullu dallanma: tek akışta farklı müşteri yolları

Salı sabahı 09:40. Bir eğitim teknolojisi şirketinin satış ekibinde tek bir karşılama akışı çalışıyor: formu dolduran herkese aynı e-posta gidiyor, aynı gün sıradaki temsilciye atanıyor. O sabah forma 34 kayıt düşüyor. Bunların çoğu tek başına çalışan bir öğretmen, bir kısmı küçük bir kurs merkezi, dördü ise yüzlerce öğrencisi olan bir okul zinciri. Üçü de aynı metni alıyor: "Denemek için 14 günlük ücretsiz hesabınız hazır." Okul zincirinin satın alma sorumlusu bu e-postayı açmadan siliyor, çünkü onun sorusu deneme hesabı değil; sözleşme, fatura ve kaç kullanıcıya kadar ölçeklendiği. Cuma günü ekip dönüşüm oranına bakıp akışın çalışmadığını söylüyor. Oysa akış gayet çalışıyor — sadece tek bir yol biliyor.

Koşullu dallanma tam olarak burada devreye girer: aynı tetikleyiciden başlayan akışın, elindeki veriye bakıp farklı kollara ayrılması. Aşağıda önce tek yollu akışın nerede kırıldığını, sonra dallanma kararının hangi veriye dayanması gerektiğini ele alıyoruz. Ardından filtre, if/else dalı ve ayrı akış arasındaki farkı bir tabloda karşılaştırıp koşul sırasının sonucu neden değiştirdiğini gösteriyoruz. Son bölümlerde dal sayısının makul sınırı, dallar içindeki bekleme adımları, sessiz kalan bir dalın teşhisi, yayına almadan test ve dallanan akışta gerçekten okunması gereken sayılar var.

Tek yollu akış nerede kırılır?

Tek yollu akış aslında bir varsayımdır: "bu tetikleyiciden gelen herkes aynı şeyi istiyor." Bu varsayım küçük hacimde fark edilmez, çünkü ekip elle telafi eder. Temsilci yanlış mesajı görür, üstüne kendi cümlesini yazar, akış hatasını kapatır. Hacim arttığında telafi eden kişi kalmaz ve akış olduğu gibi görünür hale gelir.

Kırılma genellikle üç yerde olur. Birincisi kaynak farkı: sitedeki fiyat sayfasından gelen bir talep ile soğuk listeden yanıt veren bir kişi aynı olgunlukta değildir. gelen ve giden lead'leri ayrı yönetmek gerektiğini söyleyen mantık, tek akış içinde iki dal olarak da kurulabilir. İkincisi büyüklük farkı: tek kullanıcılık bir talep ile çok kullanıcılı bir kurum aynı takip ritmini kaldırmaz. Üçüncüsü ise zamanlama: mesai dışında düşen bir talep, mesai içinde düşenle aynı hızda aranamaz.

Bu üç kırılmanın ortak yanı şudur: hiçbiri "daha iyi metin yazarak" çözülmez. Metni ne kadar iyileştirirseniz iyileştirin, tek metin üç farklı ihtiyacın ortalamasında kalır. Ortalama mesaj kimseyi ikna etmez; sadece kimseyi rahatsız etmez. Dallanma, ortalamadan çıkıp her kola kendi cümlesini vermenin yoludur.

Dallanma kararını hangi veri taşımalı?

Bir dalın değeri, dayandığı verinin akış çalıştığı anda gerçekten dolu olmasına bağlıdır. Formda sorulmayan bir alana göre dallanan akış, pratikte tek dal gibi davranır: koşul hep boş döner, herkes "diğer" koluna düşer. Bu yüzden dallanma tasarımı aslında veri toplama tasarımıyla başlar. Önce "hangi soruyu sorarsam bu kararı verebilirim" diye sorun, sonra o alanı forma ya da kayıt ekranına koyun.

İyi dallanma verisi üç özelliğe sahiptir: kaydın kendisinde durur, sınırlı sayıda değer alır ve karar anında değişmez. Şirket büyüklüğü, talep tipi, sektör, kaynak kanalı ve bütçe aralığı bu tanıma uyar. "İlgi düzeyi" gibi yoruma açık alanlar uymaz, çünkü iki temsilci aynı kaydı farklı işaretler. Kaydın hangi evrede olduğunu tutuyorsanız, yaşam döngüsü evrelerini haritalamak dallanma için hazır ve tutarlı bir eksen verir.

Ürün tarafında bu, Çoklu Tetikleyici ile Koşullu Dallanma adımının birlikte çalışmasıdır: akışı form gönderimi, webhook, zamanlama ya da mesaj alımı başlatır; hemen ardından gelen if/else adımı kaydın alanlarına bakıp yolu seçer. Karar bir kişinin kafasında değil, akışın kendisinde kayıtlıdır — altı ay sonra "bu müşteri neden hızlı aranan kola düştü" diye sorduğunuzda cevap adımın koşulunda durur.

Filtre, dal ve ayrı akış: hangisi ne zaman?

Her farklılık dal gerektirmez. Bazı ayrımlar akış başlamadan önce, bazıları akışın ortasında, bazıları ise ayrı bir akış olarak ele alınmalıdır. Yanlış aracı seçmek, akışı gereksiz karmaşık ya da gereksiz kaba yapar. Aşağıdaki tablo karar kriterini özetler.

Yöntem	Ne zaman kullanılır	Gözden kaçan riski
Tetikleyici filtresi	Bir grup akışa hiç girmemeli; ayrım baştan bellidir	Filtrelenen kayıtlar hiçbir yerde görünmez, sessizce kaybolur
If/else dalı	Aynı hedefe farklı yollardan gidilir; adımların çoğu ortaktır	Dal sayısı büyüdükçe canvas okunmaz hale gelir
Ayrı akış	İki yolun tetikleyicisi, sahibi ve ölçüsü farklıdır	Ortak adımlar iki yerde ayrı ayrı bakım ister
Alt akış çağırma	Aynı adım dizisi birden çok akışta tekrar eder	Zincir uzarsa hangi akışın ne yaptığını izlemek zorlaşır

Pratik bir eşik şudur: iki yol adımlarının yarısından fazlasını paylaşıyorsa dal kurun, paylaşmıyorsa ayrı akış yazın. Ortak kısım üçüncü bir akışta tekrar ediyorsa Alt Akış Çağırma adımıyla tek yerde toplayın; döngü ve derinlik koruması zincirin kendi kuyruğunu ısırmasını engeller. koşullu kurallarla süreçleri otomatikleştirmenin genel mantığını kurduysanız, bu üç aracı seçmek artık mimari bir karardır, teknik bir engel değil.

Koşulların sırası sonucu nasıl değiştirir?

If/else zinciri yukarıdan aşağı okunur ve ilk tutan koşul kazanır. Bu basit kural, dallanan akışların en sık görülen hatasının kaynağıdır: geniş bir koşulu dar bir koşulun üstüne koymak. "Sektör = eğitim" koşulunu "kullanıcı sayısı 500'den fazla" koşulunun üstüne yazarsanız, büyük okul zinciri hiçbir zaman kurumsal kola ulaşamaz. Dal doğru kurulmuştur, sıra yanlıştır.

Doğru yöntem, koşulları darlıktan genişliğe dizmektir. En özel durum en üstte, en genel durum en altta. En sonda mutlaka bir "diğer" kolu bulunsun; koşulların hiçbirine uymayan kayıt akışın ortasında asılı kalmasın. Bu kol çoğu zaman yalnızca bir görev oluşturur ve bir insana "bak, bunu sınıflandıramadık" der.

Sıralama tartışması aslında satış tarafındaki eski bir ayrımın teknik yüzüdür. B2B ve B2C satışın iki farklı oyun olması, aynı formdan gelen iki kaydın aynı kolda ilerlememesi gerektiği anlamına gelir: biri tek karar vericiyle dakikalar içinde ilerler, diğeri komite ve bütçe takvimiyle haftalara yayılır. Koşul sırası bu ayrımı akışa yazan yerdir.

Kaç dal fazla, kaç dal az?

Dal sayısının teknik bir üst sınırı yoktur ama pratik bir sınırı vardır: ekibin akışı tek ekranda okuyabilmesi. Deneyimli ekiplerde ilk sürüm genellikle iki ya da üç dalla başlar. Dört ve üzeri dal, ancak her dal için farklı bir mesaj, farklı bir sahip veya farklı bir zamanlama gerçekten tanımlıysa anlamlıdır.

Dalın haklı olup olmadığını sınamanın kolay yolu şu sorudur: bu kol kaldırılırsa müşteri deneyiminde ne değişir? Yanıt "mesajın bir cümlesi" ise dal değil, mesaj içinde bir değişken kullanın. Yanıt "kim arıyor, ne zaman arıyor ve ne teklif ediyor" ise dal gerçekten gerekir. kurumsal ile KOBİ satışını ayıran mantık burada birebir işler: iki kolun takip ritmi ve muhatabı farklıysa, tek metin iki işi birden yapamaz.

Ters yönde bir hata daha vardır: gereğinden az dal. Bir akışta tek bir "büyük müşteri" kolu varsa ve o kola giren kayıtların yarısı aslında sadece çok kullanıcılı ama küçük bütçeli firmalarsa, kol kendi içinde tekrar bölünmeyi bekliyordur. Bunu dönüşüm oranından değil, kolun içindeki yanıt sürelerinin dağılımından anlarsınız.

Dallar içinde bekleme ve zamanlama neyi değiştirir?

Dallanma yalnızca "ne gönderileceğini" değil, "ne zaman gönderileceğini" de ayırır. Hızlı karar veren bir kol için beş dakikalık bekleme uygundur; komiteyle ilerleyen bir kol için beş dakikalık takip rahatsız edicidir. Aynı akışın iki kolunda bekleme süreleri farklı olabilir ve olmalıdır.

Burada Zamanlayıcı adımının yanında iki koruma daha devreye girer. Hız ve Mesai Sınırları, saat, gün veya hafta başına çalıştırma tavanını ve mesai penceresini tanımlar; gece 03:00'te düşen bir kayıt sabah mesai açılışını bekler. Yanıt Gelince Dur ise kişi cevap verdiğinde ya da lead kapandığında bekleyen adımları iptal eder, böylece müşteri yanıt yazmışken üçüncü hatırlatma gitmez.

Bekleme adımının en görünür faydası randevu ve teslimat gibi tarihli süreçlerde ortaya çıkar. no-show oranını düşüren hatırlatma kurgusu aslında zamanlama koşullarıyla kurulmuş bir dallanmadır: randevuya bir gün kalan kayıt bir kol, aynı gün içindeki kayıt başka bir kol izler.

Operasyon tarafında da aynı mantık geçerlidir. Durum değişimine bağlı bilgilendirme akışları, sipariş durumunu otomatik ileten bir kurguya dönüştüğünde, her durum kendi kolunu ve kendi bekleme süresini alır; kargoya verilen sipariş anında haber verilirken, hazırlanmakta olan sipariş için bir sonraki güne kadar beklenir.

Bir dal hiç çalışmıyorsa nereye bakarsınız?

Dallanan akışlarda en sinsi arıza, hata vermeyen arızadır. Akış yeşil görünür, çalıştırma sayısı artar, ama bir kol hiç kimseye ulaşmaz. Sebep neredeyse her zaman üç maddeden biridir: koşul yanlış sırada, koşulun baktığı alan boş, ya da o koldaki kanal bağlanmamış.

Çalıştırma Geçmişi bu üçünü ayırmanın en kısa yoludur: tek tek kayıtların hangi adımdan geçtiğini görürsünüz, koşulun hangi değerle karşılaştığı listede durur. Otomatik Teşhis ise siz aramadan kopuk adım, hiç tetiklenmemiş akış ve bağlanmamış kanal gibi sorunları çıkarır. Huni Analizi de kişilerin tam olarak hangi adımda düştüğünü gösterir; bir kolun huni grafiğinde ilk adımdan sonra düz çizgi görüyorsanız sorun mesajda değil, koşuldadır.

Teşhisin son halkası insandır. Sınıflandırılamayan kayıtlar için kurduğunuz "diğer" kolu boş bir kol olmamalı; oradan bir görev doğmalı. otomatik görev oluşturmayı şablonla standartlaştırmak, bu kolun bir çöp kutusu değil, bir kuyruk olmasını sağlar.

Dallanmayı yayına almadan nasıl denersiniz?

Dallanan bir akışın ilk gerçek koşusunu müşteri üzerinde yapmak pahalıdır: yanlış kola düşen bir kurumsal talep, geri alınamayacak bir ilk izlenim bırakır. Kuru Çalıştırma Testi tam olarak bunu önler — örnek veriyle akışı baştan sona yürütür, hangi adımın çalışacağını adım adım gösterir ve gerçek e-posta, WhatsApp ya da SMS göndermez.

Test ederken her kol için bir örnek kayıt hazırlayın, bir de hiçbir koşula uymayan bir kayıt ekleyin. Dört kollu bir akış için beş test kaydı demektir bu. Kayıtları çalıştırdığınızda beklediğiniz kol ile gerçekleşen kol aynı değilse, düzeltmeniz gereken şey mesaj değil koşuldur.

Yayına aldıktan sonra da geri dönüş yolunuz açık kalır. Sürüm Geçmişi her kaydı bir sürüm olarak saklar; bozulan akışı tek tıkla eski sürüme döndürürsünüz ve geri alma öncesindeki hal de kaybolmaz. Riskli bir kolda — örneğin indirim teklifi gönderen kolda — Onay Bekle adımı koyarsanız akış durur, seçtiğiniz kişiye bildirim gider ve süre dolarsa onaysız ilerlemez.

Dallanan akışta hangi sayılar anlamlı?

Dallandığınız andan itibaren akışın toplam dönüşüm oranı yanıltıcı bir sayıya dönüşür. İki kolun ortalaması, iyi çalışan kolu kötü çalışan kolun altında gizler. Bu yüzden ölçümü de dallandırmak gerekir: her kol için giren kayıt sayısı, ilk yanıt süresi, kol içi tamamlanma oranı ve kolun ürettiği fırsat sayısı ayrı ayrı okunur.

Kol bazlı okumanın ilk faydası, dalın gerçekten gerekli olup olmadığını göstermesidir. İki kolun sayıları birbirine çok yakınsa dal muhtemelen fazladır; aralarında kalıcı bir fark varsa dal işini yapıyordur. İkinci faydası, hangi kolun iyileştirmeye değdiğini söylemesidir — küçük hacimli ama yüksek değerli bir kolda birkaç puanlık iyileşme, büyük hacimli kolda aynı iyileşmeden daha çok kazandırabilir.

Sayısal ölçüme bir de deneyim ölçümü ekleyin. Kolların müşteri tarafında nasıl hissettirdiğini anlamak için NPS, CSAT ve CES ile memnuniyeti ölçmek işe yarar: farklı kollardan çıkan kayıtlara aynı soruyu sorup skorları karşılaştırdığınızda, hangi kolun temposunun ağır geldiğini görürsünüz.

Gelen mesajların tonundaki değişimi izlemek de erken uyarı verir. Mesajlardaki memnuniyetsizliği yakalayan duygu analizi, bir kolun aşırı sık yazdığını dönüşüm oranı düşmeden önce haber verir; tek bir kolda artan sert ton, çoğu zaman o kolun bekleme sürelerinin kısa olduğunu söyler.

Kendi akışınızda ilk dallanmayı kurup kuru çalıştırma testiyle denemek için ücretsiz bir Rocketly hesabı açabilirsiniz.

Sıkça sorulan sorular

Bir akışta kaç dal kurabilirim?

Teknik bir sayı sınırından çok okunabilirlik sınırı vardır. İlk sürümü iki ya da üç dalla kurun; her dal için farklı bir mesaj, sahip veya zamanlama tanımlayamıyorsanız o dalı mesaj içindeki bir değişkene indirin. Dördüncü daldan sonra ortak adımları Alt Akış Çağırma ile tek yerde toplamak canvas'ı okunur tutar.

Koşulun baktığı alan boşsa ne olur?

Kayıt o koşulu sağlamaz ve zincirdeki bir sonraki koşula geçer; hiçbirine uymazsa en sondaki "diğer" koluna düşer. Bu yüzden her dallanan akışta bir "diğer" kolu bulunması ve o kolun bir görev üretmesi gerekir — aksi halde sınıflandırılamayan kayıtlar sessizce akışın sonuna gider.

Dalları sonradan değiştirirsem çalışan kayıtlar ne olur?

Değişiklik siz kaydedene kadar yayına çıkmaz; kaydettiğiniz an yeni çalıştırmalar yeni sürümle başlar. Beklemede olan kayıtların davranışını görmek için Çalıştırma Geçmişi'ne bakın, sonuç beklediğiniz gibi değilse Sürüm Geçmişi üzerinden önceki sürüme dönebilirsiniz.

Dallanmayı AI Copilot ile kurabilir miyim?

Evet. İstediğiniz ayrımı düz cümleyle yazarsınız, Copilot koşullu adımı canvas'a kurar ve sonraki mesajlarınız mevcut akışı düzenler. Copilot hiçbir şeyi kendi başına yayına almaz: yalnız taslağı günceller, kaydetme kararı sizde kalır.