Workflow'da onay bekle adımı: otomasyona insan kararı eklemek

Perşembe 16:40. Bir mobilya toptancısının satış ekibinde teklif akışı üçüncü kez aynı işi yapıyor: teklif hazırlandı, PDF üretildi, müşteriye e-posta gitti. Bu seferki teklifte yüzde 34 indirim var; temsilci fiyat listesini bir satır kaydırarak okumuş. Akış itiraz etmedi, çünkü ona itiraz etmesi söylenmemişti. Satış müdürü indirimi ertesi sabah, müşteri "kabul ediyoruz" yazdıktan sonra gördü. Otomasyon hatasız çalıştı; sorun, hiçbir yerinde durmamasıydı.

Bu yazı akışın tam olarak nerede duracağını ve o duraklamanın nasıl kurgulanacağını anlatıyor. Önce hangi adımların bir insanın gözünü hak ettiğini konuşuyoruz; sonra onay bekle adımının akışı fiilen nerede kestiğini, onayı kişiye mi role mi bağlamak gerektiğini, karar verecek kişinin ekranda neyi görmesi gerektiğini, eşiği hangi ölçütlerle koyacağınızı, süre dolduğunda akışın ne yapması gerektiğini, bu duraklamanın müşteriye nasıl yansıdığını, adımı yayına almadan nasıl deneyeceğinizi, onaylar birikmeye başladığında hangi sayıya bakacağınızı ve onay kapısını nereye koymamanız gerektiğini sırayla ele alıyoruz.

Hangi adım gerçekten bir insanın gözünü hak eder?

Onay kapısı ücretsiz değildir. Koyduğunuz her kapı, akışa bir bekleme, bir bildirim ve birinin dikkatinden bir dilim ekler. Bu yüzden soru "nereye onay koyalım" değil, "hangi adım durmamayı kaldıramaz" olmalıdır. İşe yarayan tek ölçüt geri alınabilirliktir: adım yanlış çalıştığında telafisi bir tıklama mı, yoksa bir özür telefonu mu?

Geri alınabilirliği dört soruyla test edebilirsiniz. Adım kuruluşun dışına bir şey gönderiyor mu? Para, indirim ya da alacak taahhüdü içeriyor mu? Bir kaydı kalıcı olarak siliyor veya kapatıyor mu? Yanlış çalıştığında bunu müşteri mi fark eder, siz mi? Bu sorulardan ikisine "evet" diyen bir adımın önünde bir insan durmalıdır.

• Dışarı çıkan içerik: müşteriye giden teklif, sözleşme, fatura ya da toplu duyuru.
• Parasal taahhüt: indirim, iade, ek hizmet, ödeme planı değişikliği.
• Geri dönülemez durum değişikliği: hesabı kapatma, aboneliği iptal etme, kaydı arşivleme.
• İtibar riski: hatalı gönderimin ekranlarda dolaşabileceği her kanal.

Bu listeye girmeyen adımlar için onay istemek, otomasyonun kazandırdığı zamanı geri götürür. Sınırın nereden geçtiğini genel çerçevede otomasyonu nerede durdurup insanı bırakmalı yazısında tartışmıştık; buradaki fark, kararı akışın içine gömülü bir adım olarak kurmanız.

Onay bekle adımı akışı tam olarak nerede durdurur?

Onay Bekle Adımı, akışın üzerinde bir düğüm olarak durur ve kendisinden sonraki her şeyi askıya alır. Akış o düğüme geldiğinde ilerlemeyi bırakır, seçtiğiniz kişiye bildirim gider ve süre dolarsa akış onaysız ilerlemez. Bu son cümle teknik bir ayrıntı gibi görünüyor ama davranışın tamamını belirler: varsayılan "geç" değil, "geçme"dir.

Askıya alınan şey akışın tamamı değil, o çalıştırmadır. Aynı akış başka bir teklif için aynı anda çalışmaya devam eder; her çalıştırma kendi onayını bekler. Bu yüzden onay kapısı bir darboğaz gibi düşünülmemeli: kuyruk oluşan yer akış değil, karar verecek kişinin dikkatidir.

Adımı yerleştirirken en sık yapılan hata, onayı akışın sonuna koymaktır. Onay, riskli aksiyondan hemen önce durmalıdır — teklifi hazırlayan adımdan sonra, gönderen adımdan önce. Böylece onaylayan kişi soyut bir niyeti değil, gerçekten gidecek olan çıktıyı görür. Kuralların akış üzerinde nasıl kurgulandığını daha geniş çerçevede koşullu kurallarla süreçleri otomatikleştirmek başlığı altında ele almıştık.

Onayı kişi mi, rol mü vermeli?

Akışa tek bir isim yazmak kolaydır ve ilk üç hafta sorunsuz çalışır. Dördüncü hafta o kişi izne çıkar. Onay kapısının en yaygın arıza biçimi teknik değil örgütseldir: karar verecek tek kişi vardır ve o kişi masada değildir.

Pratik çözüm, onayı bir role bağlamak ve rolün altında en az iki kişi bulundurmaktır. Kim onaylarsa akış ilerler, kararı veren isim kaydedilir. Tek kişilik onaylar yalnızca gerçekten devredilemeyen kararlar için anlamlıdır; bunlar da düşündüğünüzden azdır. İndirim özelinde yetkinin nasıl paylaştırılacağını indirimli teklifi kim onaylar yazısında ayrıntılandırmıştık.

İkinci karar, onaylayanın talebi başlatan kişiden farklı olmasını zorunlu kılıp kılmayacağınızdır. Küçük ekiplerde bu kural sürtünme yaratır; sayılabilir bir tutar söz konusu olduğunda ise vazgeçilmezdir. Ortada bir denetim beklentisi varsa kuralı baştan koyun, sonradan eklemek her zaman daha zordur.

Karar verecek kişi ekranda neyi görmeli?

Onay isteği, karar için gereken her şeyi tek ekranda taşımalıdır. "Teklif #4812 onayınızı bekliyor" cümlesi bir bildirim değil, bir ödevdir: alan kişi CRM'i açar, kaydı arar, geçmişe bakar ve ancak ondan sonra karar verir. Bu üç dakikalık ek işin toplamı, onay kapısının gerçek maliyetidir.

İyi kurgulanmış bir onay isteği şunları taşır: kararın konusu, sapmanın büyüklüğü, kıyaslanacak referans ve talebi başlatan kişi. Yani "yüzde 34 indirim" değil, "yüzde 34 indirim — bu müşteride ortalama yüzde 12, kategori tavanı yüzde 20, talep eden Deniz". Onaylayanın bakması gereken tek şey sapmanın gerekçesidir.

Aynı mantık belge ve evrak akışlarında da geçerlidir: eksik evrakla ilerleyen bir süreçte onay isteği, hangi belgenin eksik olduğunu da söylemelidir. Bu tarafın nasıl kurulduğunu müşteriden belge toplama otomasyonu yazısında adım adım anlatmıştık.

Eşiği hangi ölçütlerle koyarsınız?

Eşik, "her şeyi onaylat" ile "hiçbir şeyi onaylatma" arasındaki tek ayardır ve yanlış kurulduğunda ikisinden birine dönüşür. Çok düşük bir eşik, onay kutusunu rutin taleplerle doldurur; onaylayan kişi okumadan onaylamaya başlar ve kapı sembolik hale gelir. Çok yüksek bir eşik ise kapıyı hiç açmaz.

Doğru başlangıç noktası, geçmiş verinizin kendisidir: son üç ayın taleplerini büyüklüğe göre sıralayın ve üstteki yüzde onu kesen değeri eşik olarak alın. Böylece kapı, gerçekten sıra dışı olanları yakalar. Aşağıdaki tablo tipik bir dağılımın nasıl karar kriterine çevrildiğini gösteriyor; sayılar örnektir, kendi verinizle değiştirin.

Adım türü	Örnek eşik	Onay biçimi	Süre dolunca
Standart teklif	Liste fiyatının altında değil	Onay yok	—
İndirimli teklif	Kategori tavanına kadar	Takım lideri	4 saat sonra yükselt
Tavan üstü indirim	Tavanı aşan her oran	Satış müdürü	Beklemede kalır
Ücret iadesi	Tutardan bağımsız	Finans + yönetici	Beklemede kalır
Toplu duyuru	Belirli alıcı sayısının üstü	Pazarlama sorumlusu	24 saat sonra iptal

Eşik bir kere kurulup unutulacak bir ayar değildir. Üç ay sonra onay kutusuna düşen taleplerin oranına bakın: yüzdesi yükseliyorsa ya iş değişmiştir ya eşik eskimiştir. Onay süreçlerinin genel kurgusunu onay akışı otomasyonu yazısında bütün olarak ele almıştık.

Süre dolduğunda akış ne yapmalı?

Her onay kapısının bir zaman aşımı davranışı vardır; siz tanımlamazsanız varsayılan devreye girer ve akış onaysız ilerlemez. Bu güvenli taraftır ama tek seçenek değildir. Üç makul davranış vardır: beklemede kalmak, bir üst mercie yükselmek ya da çalıştırmayı sessizce sonlandırmak.

Seçim, adımın niteliğine bağlıdır. Parasal taahhütlerde beklemek doğrudur — kimse cevap vermediyse indirim de verilmemelidir. Zamana duyarlı ama düşük riskli adımlarda, örneğin bir hatırlatma mesajının gönderilmesinde, süre dolunca yükseltmek daha mantıklıdır: karar birinden diğerine geçer, akış durmaz. Yükseltmenin nasıl zincirleneceğini SLA aşılmadan doğru kişiye iletmek yazısında anlatmıştık.

Üçüncü davranış, yani sessizce sonlandırma, yalnızca tekrar edilebilir adımlar için uygundur. Bir kampanya mesajı gönderilmediyse bir sonraki turda gönderilir. Ama bir iade talebi sessizce kapanırsa, müşteri sizi arayana kadar kimse fark etmez. Kural basittir: sessiz sonlandırma yalnızca müşteri tarafında bir beklenti yaratmamış adımlarda kullanılır.

Bekleyen bir akış müşteriye nasıl yansır?

Onay kapısının en pahalı yan etkisi, müşterinin sessizliğe düşmesidir. Teklifi bekleyen kişi, sizin iç onay sürecinizi bilmez; bildiği tek şey iki saat önce bir şey isteyip cevap alamadığıdır. Bu yüzden onay adımının yanına neredeyse her zaman bir ara bilgilendirme koymak gerekir.

Ara bilgilendirme kısa ve dürüst olmalıdır: talebin alındığı, hazırlandığı ve ne zaman döneceğiniz. Süre vermek risklidir ama vermemek daha risklidir; makul bir üst sınır söyleyip erken dönmek en iyi seçenektir. Bu mesajın kanalı da önemlidir; anlık kanallarda beklenti dakikalarla ölçülür ve otomatik yanıtın ne söylediği WhatsApp otomatik yanıt kurulumunda ayrıntılı olarak ele aldığımız gibi doğrudan bekleme toleransını belirler.

Bilgilendirme adımını onay adımından önce koyun. Sonrasına koyarsanız, tam da onay geciktiği için bilgilendirme de gecikir; yani en çok ihtiyaç duyulduğu anda çalışmaz.

Onay adımını yayına almadan nasıl denersiniz?

Onay kapıları, yanlış kurulduğunda sessizce arızalanan bileşenlerdir. Yanlış rol seçilmiştir, bildirim kimseye gitmez, akış bekler ve kimse beklediğini bilmez. Bunu üretimde keşfetmek pahalıdır.

Kuru Çalıştırma Testi tam bu boşluğu kapatır: akışı örnek veriyle baştan sona yürütür, hangi adımın çalışacağını adım adım gösterir ve gerçek mesaj göndermez. Onay adımının hangi koşulda tetiklendiğini, hangi kola gidildiğini ve bildirimin kime düşeceğini yayına çıkmadan görürsünüz. Testte iki senaryoyu ayrı ayrı deneyin: eşiğin altında kalan bir talep kapıya hiç uğramamalı, üstündeki bir talep kapıda durmalı.

İkinci güvenlik ağı Sürüm Geçmişi'dir. Her kayıt sürüm olarak saklandığı için, eşiği değiştirdiğiniz gün beklenmedik bir davranış görürseniz akışı tek tıkla önceki sürüme döndürürsünüz; geri alma öncesindeki hal de saklanır, yani deneme yapmaktan çekinmezsiniz. Bu disiplini akıştaki diğer otomatik adımlara da yayabilirsiniz; tekrarlayan satış işlerini kodsuz tetikleyicilerle kaldırmak yazısındaki kurulum mantığı burada da geçerlidir.

Onaylar birikmeye başladığında hangi sayıya bakılır?

Onay kapısının sağlığı üç sayıyla ölçülür: bekleyen talep sayısı, ortalama karar süresi ve reddedilme oranı. Üçü birlikte okunduğunda kapının işe yarayıp yaramadığını söyler.

Reddedilme oranı sıfıra yaklaşıyorsa kapı iş görmüyor demektir; onaylayan kişi otomatik onaylayıcıya dönüşmüştür ve eşik çok düşüktür. Ortalama karar süresi uzuyorsa sorun eşikte değil kapasitededir: ya onaylayan rolü genişletmek ya da düşük riskli dalları kapının dışına almak gerekir. Bekleyen talep sayısı gün içinde dalgalanıyorsa, çoğu zaman mesai penceresiyle ilgilidir.

Analitik & Loglar hangi adımın ne kadar sürdüğünü ve akışın nerede takıldığını gösterir; onay adımı listede genellikle en uzun süreli satırdır ve bu normaldir. Anormal olan, sürenin haftadan haftaya büyümesidir. Otomatik Teşhis ise kopuk adım, hiç tetiklenmemiş akış ya da bağlanmamış kanal gibi sessiz arızaları bulur — onay bildirimi kimseye ulaşmıyorsa arıza çoğunlukla buradadır. Otomasyona ne kadar alan bırakılacağı tartışmasını reklam tarafında otomasyona ne zaman güvenmeli sorusuyla birlikte ele almıştık.

Onay kapısını nereye koymamalı?

Onay kapısının en kötü kullanımı, güven eksikliğini süreçle kapatmaya çalışmaktır. Bir ekip üyesinin her işini onaylatmak bir kontrol mekanizması değil, bir gecikme üretecidir; hem işi yavaşlatır hem de onaylayanın dikkatini asıl önemli kararlardan uzaklaştırır.

İkinci hatalı kullanım, düzenli ve öngörülebilir gönderimleri kapıya sokmaktır. Zamana yayılan bir dizide her adımı onaylatmak diziyi kullanılamaz hale getirir; onay dizinin içeriğine değil, dizinin yayına alınmasına konulmalıdır. Bir kere onaylanan içerik, binlerce kez güvenle gönderilebilir — bu ayrımı tetiklenen akışlarla ölçekli kişiselleştirme yazısında tetikleyici tasarımı üzerinden anlatmıştık.

Üçüncüsü, onayı bir imza toplama ritüeline çevirmektir. Aynı talebi üç kişiye sırayla onaylatmak, riski üçe bölmez; sorumluluğu dağıtır ve kimse gerçekten bakmaz. Tek bir yetkili onaylayan, yanında iyi hazırlanmış bir gerekçe ile her zaman daha iyi çalışır.

Kendi akışınızda riskli adımın önüne bir onay kapısı koymayı denemek isterseniz Rocketly hesabınızı açıp ilk kapınızı birkaç dakikada tanımlayabilirsiniz.

Sıkça sorulan sorular

Onay bekleyen bir akış ne kadar süre bekleyebilir?

Süreyi siz belirlersiniz ve bu süre adımın niteliğine göre değişmelidir. Parasal taahhütlerde birkaç saatlik bir pencere yeterlidir; belge ya da evrak bekleyen akışlarda günlerle ölçülen süreler makuldür. Süre dolduğunda akış onaysız ilerlemez, yani beklemek varsayılan olarak güvenli taraftır.

Onaylayan kişi izinliyse akış ne olur?

Onayı tek bir kişiye değil bir role bağlarsanız bu sorun ortaya çıkmaz: rolün altındaki herkes kararı verebilir, veren kişinin adı kayda geçer. Tek kişilik onaylarda ise zaman aşımı davranışını yükseltme olarak ayarlamak, akışın süresiz beklemesini engeller.

Onay adımı akışın diğer dallarını da durdurur mu?

Hayır. Duran şey akışın tanımı değil, o tek çalıştırmadır. Aynı akış başka kayıtlar için çalışmaya devam eder ve her çalıştırma kendi onayını ayrı bekler. Koşullu Dallanma ile eşiğin altında kalan talepleri kapının dışından geçirirseniz, çoğu çalıştırma onay adımına hiç uğramaz.

Onay kararları sonradan denetlenebilir mi?

Evet. Her çalıştırmanın kaydı tutulduğu için hangi talebin kim tarafından, ne zaman onaylandığı ya da beklemede kaldığı geriye dönük olarak izlenebilir. Akışın kendisinde yaptığınız değişiklikler de sürüm olarak saklanır; yani "bu karar hangi kurallar geçerliyken verildi" sorusunun yanıtı da elinizin altındadır.