Takılan workflow'ları temizleme: yarıda kalan akışlar

Perşembe öğleden sonra, saat 15.20. Operasyon sorumlusu haftalık bakım listesini açıp çalıştırma geçmişine bakıyor ve gözüne bir şey takılıyor: "Teklif sonrası takip" akışında 63 çalıştırma hala "devam ediyor" görünüyor ve bunların en eskisi on bir gün önce başlamış. On bir gündür ikinci adıma geçmemiş. Bu örnek sahnede kimse şikayet etmedi, hiçbir müşteri "bana dönüş olmadı" demedi. Çünkü kimse beklemediği bir mesajın gelmediğini fark etmez. Takılan akışların en sinsi tarafı da bu: gürültü çıkarmazlar, sessizce birikirler ve bir gün raporların içinde ortaya çıkarlar.

Bu yazı yarıda kalan çalıştırmaları üç aşamada ele alıyor. Önce bir akışın teknik olarak nerede ve neden takıldığını ayırt ediyoruz; sonra bir çalıştırmayı ne zaman "ölü" sayacağınıza dair eşikleri tabloya döküp süpürme kuralını nasıl yazacağınızı anlatıyoruz; en sonda da temizliği bir kerelik bakım işi olmaktan çıkarıp haftalık rutine çevirmenin ve sonucunu ölçmenin yolunu gösteriyoruz. Ortada, temizlik sırasında kesinlikle dokunulmaması gereken çalıştırma tipleri için ayrı bir bölüm var.

Bir akış "takıldı" derken tam olarak ne oluyor?

Her otomasyonun iki ayrı katmanı vardır: tasarım ve çalıştırma. Tasarım, canvas'ta durduğu haliyle akıştır; adımlar, koşullar, beklemeler. Çalıştırma ise o tasarımın tek bir kişi için başlatılmış bir kopyasıdır. Ayşe için başlayan çalıştırma, Mehmet içinkinden bağımsız ilerler, kendi adım sırasını ve kendi bekleme sayacını taşır. "Akış takıldı" dendiğinde neredeyse her zaman kastedilen şey tasarımın değil, tek tek çalıştırmaların ilerlemeyi bırakmasıdır.

Bir çalıştırmanın normal yaşam döngüsü kısadır: başladı, adımlar sırayla işlendi, bitti. Arada bekleme varsa durum "bekliyor" olur ve sayaç dolunca kaldığı yerden devam eder. Takılma, bu geçişlerden birinin hiç gerçekleşmemesidir. Üç tipik biçimi vardır: sayacı dolan ama uyandırılmayan bekleme adımı, yanıtı gelmeyen bir dış çağrıda kilitlenen adım ve kimsenin dokunmadığı bir onay adımı. Üçünün de ortak özelliği, hata mesajı üretmemeleridir. Hata alan çalıştırma "başarısız" olarak işaretlenir ve listede kırmızı görünür; takılan çalıştırma ise gayet sağlıklı bir şekilde "devam ediyor" der. Koşullu kurallarla süreç kurmanın mantığını iş akışı otomasyonunun temellerinde ayrıntılı anlatmıştık; buradaki konu o mantığın üretim ortamında nasıl yarı yolda kaldığı.

Bu ayrımı baştan yapmak önemli, çünkü çözüm de ikiye ayrılıyor. Tasarım hatasını düzeltmek yeni bir sürüm yayınlamak demektir. Takılmış çalıştırmaları düzeltmek ise geçmişe müdahale etmek, yani var olan kayıtları tek tek ele almak demektir. Tasarımı düzeltseniz bile eski çalıştırmalar kendiliğinden canlanmaz; onların ayrıca ele alınması gerekir.

Yarıda kalan çalıştırma neden zararsız değil?

"Nasılsa kimseye mesaj gitmiyor, dursun" demek cazip gelir. Ama duran çalıştırma boş durmaz. En somut zararı kişiyi kilitlemesidir: çoğu otomasyon motoru aynı kişiyi aynı akışa ikinci kez kaydetmeyi engeller. Yani aynı müşteri iki hafta sonra gerçekten yeni bir teklif aldığında, akış "bu kişi zaten bu akışta" deyip yeni çalıştırmayı hiç başlatmaz. Müşteri sessiz kalır ve kimse sebebini aramaz.

İkinci zarar raporlarda görülür. Adım bazlı huni, kişilerin dizinin tam olarak hangi adımında düştüğünü gösterir; ama takılmış çalıştırmalar o huninin ortasında kalıcı bir tümsek oluşturur. "İkinci adımda yüzde kırk düşüş var" diye okuduğunuz şey aslında bir düşüş değil, temizlenmemiş bir yığın olabilir. Karar verirken güvendiğiniz sayıların altını oyar.

Üçüncüsü zamanlamayla ilgili. Takılmış bir çalıştırma bazen kendiliğinden uyanır; örneğin altyapı tarafında bir yeniden başlatma sayacı tetikler. O zaman on bir gün gecikmeli bir "Teklifimizi değerlendirdiniz mi?" mesajı gider. Bu, hiç gitmemesinden daha kötüdür. Sipariş durumu bilgilendirme akışlarında bu özellikle acıdır: "kargoya verildi" bildirimi ürün teslim edildikten sonra ulaşırsa müşteride güven değil, kafa karışıklığı bırakır.

Takılma nerede başlar? En sık görülen altı sebep

Yüzlerce yarıda kalmış çalıştırmaya bakıldığında sebepler şaşırtıcı şekilde az sayıda başlıkta toplanır. Bunları bilmek, temizlik kuralını yazarken hangi durumu nasıl ele alacağınızı da belirler.

• Bağlanmamış kanal. Akışta WhatsApp adımı var ama kanal bağlantısı kopmuş ya da hiç kurulmamış. Adım gönderemez, bazen hata bile üretmez, sırada bekler.
• Sonu gelmeyen bekleme koşulu. "Müşteri yanıt verene kadar bekle" gibi bir koşula üst sınır konmamıştır. Yanıt hiç gelmezse çalıştırma sonsuza kadar bekler.
• Yanıt vermeyen dış sistem. Webhook çağrılır, karşı taraf düşüktür ya da çok yavaştır. Zaman aşımı tanımlanmamışsa adım asılı kalır.
• Sahipsiz onay adımı. Onay bekle adımı kuruldu ama onaylayacak kişi izinde, ekipten ayrıldı ya da bildirimi görmedi.
• Hiç sağlanmayan dallanma koşulu. If/else kurgusunda "aksi halde" dalı yazılmamıştır. Koşul sağlanmayınca akışın gideceği yer yoktur.
• Eksik veri. Adım telefon numarası bekler, kayıtta numara yoktur. Bazı motorlar bunu hata sayar, bazıları bekletir.

Bu listenin en sık rastlanan yedinci maddesi aslında insan tarafındadır: akış bir şeyin gelmesini bekler ve o şey gelmez. Müşteriden belge ve evrak toplama otomasyonunda bu klasiktir; kimlik fotokopisi yüklenmeden akış ilerlemez ve çalıştırma aylarca "bekliyor" durumunda kalır. Sorun akışın kötü kurulmuş olması değil, beklemeye bir son tarih konmamış olmasıdır.

Bir çalıştırmayı ne zaman "ölü" sayarsınız?

Temizliğin en zor kısmı silmek değil, karar vermektir. Çok erken müdahale ederseniz gerçekten çalışan uzun akışları kesersiniz; çok geç müdahale ederseniz temizlik anlamını yitirir. Bunun için her adım tipine ayrı bir eşik yazmak gerekir. Aşağıdaki tablo bir başlangıç şablonudur; sayılar örnek olarak verilmiştir, kendi sürecinizin ritmine göre ayarlanması beklenir.

Çalıştırma durumu	Normal süresi	Ölü sayma eşiği	Önerilen aksiyon
Planlı bekleme adımı	Adımda yazan süre	Yazan süre + 24 saat	Uyandır, olmazsa işaretle
Onay bekleyen adım	1-2 iş günü	3 iş günü	Yükselt, sonra kapat
Dış çağrı yanıtı	Saniyeler	15 dakika	Yeniden dene, sonra hata yaz
Kanal hatası alan adım	-	3 başarısız deneme	Kanalı bildir, çalıştırmayı kapat
Toplam çalıştırma ömrü	Akış tasarımına bağlı	Beklenen ömrün 2 katı	İncele ve arşivle

Tablonun mantığı şudur: her satırda önce "normal" tanımlanır, sonra eşik normalin üzerine bir pay eklenerek belirlenir. Eşiği mutlak bir sayı olarak değil, beklenen sürenin katsayısı olarak yazmak akış değiştiğinde kuralın da beraberinde değişmesini sağlar. Süre aşımı mantığı yükseltme otomasyonundaki kurguya çok benzer: orada da bir eşik aşılınca iş bir üst basamağa taşınır. Aradaki tek fark, burada eşiği aşan şeyin bir talep değil, bir çalıştırma kaydı olması.

Süpürme kuralını nasıl yazarsınız?

Temizlik kuralı dört adımda yazılır. Birincisi kapsam: hangi akışların çalıştırmaları bu kuralın konusudur? Başlangıçta tek bir akışla başlamak en sağlıklı yöntemdir. İkincisi eşik: yukarıdaki tablodan gelen süre. Üçüncüsü eylem: işaretle, yeniden dene, kapat ya da arşivle. Dördüncüsü ise kayıt: hangi çalıştırmaya ne yapıldığı bir yerde yazılı kalmalı.

Bu dörtlünün uygulamadaki karşılığı Rocketly'de iki özellikte görünür. Takılan Akışları Temizleme, yarıda kalmış çalıştırmaları tespit edip süpürür; böylece eşiği geçmiş kayıtlar listede birikip devam ediyor gibi görünmez. Çalıştırma Geçmişi ve Yeniden Deneme ise kararın geçmişini taşır: her çalıştırmanın kaydı durur, hata alan akışları tek tek değil toplu olarak yeniden denersiniz. Yani "ne oldu" sorusunun cevabı silinmez, sadece çalıştırmanın açık durumu kapanır.

Kural yazarken en çok yapılan hata, ilk günden doğrudan silmeye geçmektir. Önce yalnızca raporlayan bir tur kurun: eşiği geçen çalıştırmaları listeleyip bir hafta boyunca yalnızca bakın. Bu bir hafta size iki şey öğretir; eşiğin çok dar mı geniş mi olduğunu ve listenin içinde tekrar eden bir akış adı olup olmadığını. Eşik kültürünü sayılarla yönetmeye alışık ekipler için bu tanıdık bir refleks olacaktır; çağrı merkezi KPI'larında hizmet seviyesi eşiğinin önce ölçülüp sonra bağlayıcı hale getirilmesi de aynı mantığı taşır.

Süpürme sıklık olarak günde bir kez yeterlidir. Saatte bir çalıştırmak, uzun bekleme adımlarına sahip akışlarda gereksiz risk üretir. Haftada bir ise çok seyrektir: takılan bir akışın kişiyi kilitlediği süre uzar.

Temizlik yaparken hangi çalıştırmalara dokunulmaz?

Her uzun süren çalıştırma takılmış değildir. Bazı akışlar doğası gereği haftalarca hatta aylarca açık kalır ve bunları süpürmek gerçek bir zarar verir. Bu yüzden süpürme kuralının ilk cümlesi bir istisna listesi olmalıdır.

İlk istisna zamana yayılan diziler. Damla dizisi tetikleyici tabanlı akıştan farklıdır: adımlar günler ve haftalar boyunca sırayla ilerler ve aradaki bekleme tasarımın kendisidir. Bir karşılama dizisinin on ikinci gününde bekleyen çalıştırma sağlıklı bir çalıştırmadır. İkinci istisna takvime bağlı akışlar. Doğum günü ve yıldönümü otomasyonları tanımı gereği bir yıl sonrasını bekler; bu kayıtları "on iki aydır ilerlemiyor" diye kapatmak akışı baştan bozar.

Üçüncü istisna sözleşme ve periyot takibi. Periyodik bakım sözleşmesi yönetiminde bir sonraki bakım tarihi altı ay sonra olabilir; arada bekleyen çalıştırma tam olarak işini yapıyordur. Bu üç grubu ayırt etmenin pratik yolu, akış tasarımına bir "beklenen azami ömür" etiketi koymaktır. Süpürme kuralı önce bu etikete bakar, etiket yoksa varsayılan eşiği uygular. Böylece uzun akışları korumak için her seferinde elle istisna girmek gerekmez.

Silmek mi, yeniden denemek mi, kapatmak mı?

Takılmış bir çalıştırma bulunduğunda üç seçenek vardır ve hangisinin doğru olduğu adımın ne yaptığına bağlıdır. Adım henüz dışarıya hiçbir şey göndermediyse yeniden denemek en iyisidir; kaldığı yerden devam eder. Adım mesaj gönderdiyse ama sonrası takıldıysa, yeniden deneme aynı mesajın ikinci kez gitmesine yol açabilir. Bu yüzden tekrar güvenliği önemli: Rocketly'nin dizi adım editöründe metin taşıyan adımlarda A/B varyantı tanımlanabilir ve varyant seçimi çalışma anında sabitlenir, böylece yeniden deneme ikinci bir mesaj göndermez. Bu, "tekrar edilebilir adım" tasarımının somut bir örneğidir.

Üçüncü seçenek, çalıştırmayı hiçbir şey yapmadan kapatmaktır. Bu, süresi geçmiş kayıtlar için doğrudur: dört ay önceki bir teklif takibini bugün uyandırmanın kimseye faydası yok. Kapatırken çalıştırmaya bir kapanış sebebi yazmak sonraki analizi kolaylaştırır.

Yeniden denemede en sık karşılaşılan yan etki tekrarlı kayıt üretmektir; özellikle akış bir kayıt oluşturuyorsa. Aynı kişi için ikinci bir kayıt açılması mükerrer kayıtların temizlenmesi işini büyütür. Bu yüzden yeniden deneme kuralını yazarken "bu adım daha önce başarıyla çalıştıysa atla" kontrolü neredeyse zorunludur.

Takılmayı baştan önleyen tasarım alışkanlıkları

Temizlik bir semptom çözümüdür. Asıl kazanç, akışı takılmayacak şekilde kurmakta. Bunun için beş alışkanlık yeterli.

Birincisi her beklemeye üst sınır koymak. "Yanıt gelene kadar bekle" yerine "yanıt gelene kadar, en fazla üç gün bekle" yazılır; üçüncü gün sonunda akışın gideceği bir yer olur. İkincisi her dallanmaya "aksi halde" dalı eklemek. Üçüncüsü onay adımlarını kişiye değil role bağlamak; böylece bir kişinin izinde olması akışı durdurmaz. Onay Bekle adımında süre dolarsa akış onaysız ilerlemez, ama en azından bekleyen kayıt görünür ve yükseltilebilir.

Dördüncüsü yayına almadan denemek. Kuru Çalıştırma Testi örnek veriyle akışı baştan sona yürütür ve hangi adımın çalışacağını adım adım gösterir; gerçek mesaj gönderilmez. Takılmaların büyük kısmı ilk gerçek koşuda ortaya çıkar, dolayısıyla ilk gerçek koşuyu üretimde yaşamamak doğrudan kazançtır. Beşincisi değişiklikleri geri alabilir tutmak: her kayıt sürüm olarak saklandığı için bozulan bir akışı eski sürümüne döndürmek tek tıklık iştir. Formu yarıda bırakanları geri kazanma akışlarında bu özellikle önemli, çünkü o akışlarda pencere dardır ve bir günlük bir bozulma bile geri dönüşü olmayan kayıp üretir.

Temizliğin işe yaradığını nasıl ölçersiniz?

Bir bakım işini rutine çevirmenin şartı, sonucunu görebilmektir. Dört sayı yeterli. Birincisi açık çalıştırma sayısı: gün sonunda "devam ediyor" durumundaki toplam kayıt. Bu sayı haftalar içinde düz bir çizgi olmalı; sürekli tırmanıyorsa temizlik eşiği geniş demektir. İkincisi açık çalıştırmaların medyan yaşı. Ortalama değil medyan, çünkü birkaç çok eski kayıt ortalamayı yanıltır. Üçüncüsü süpürülen çalıştırmaların toplam içindeki oranı; bu oran düşüyorsa tasarım alışkanlıkları tutuyor demektir. Dördüncüsü tekrar takılma oranı: süpürülüp yeniden başlatılan çalıştırmaların ne kadarı aynı adımda tekrar takılıyor?

Bu sayıları elle toplamak gerekmez. Analitik ve Loglar bölümü hangi adımın ne kadar sürdüğünü ve nerede takıldığını gösterir; Otomatik Teşhis ise kopuk adım, hiç tetiklenmemiş akış ya da bağlanmamış kanal gibi sorunları siz aramadan bulup raporlar. Huni Analizi ve Tanılama ekranı da aynı soruyu kişi tarafından sorar: dizinin hangi adımında düşüş başlıyor? Üçü birlikte, temizlik sonrası tablonun gerçekten düzelip düzelmediğini gösterir.

Ölçümün son halkası, temizliğin kimin işi olduğudur. Haftalık yarım saatlik bir kontrol, üç aylık bir birikimi önlemeye yeter. Bu kontrolü bir kişiye değil bir role bağlamak, tatil ve devir dönemlerinde işlemesini sağlar. Zamanla bu kontrolün bir kısmı da otomatikleşir; otonom AI agent'larının ekip adına yaptığı işler arasında bekleyen kayıtları tarayıp özetlemek de yer alabilir.

Kendi akışlarınızda bu düzeni denemek isterseniz Rocketly hesabınızı ücretsiz açıp önce tek bir akışta süpürme kuralını kurabilirsiniz.

Sıkça sorulan sorular

Takılan çalıştırmayı silmek verileri de siler mi?

Hayır. Çalıştırma kaydı, akışın o kişi için ilerleyişini tutan ayrı bir kayıttır; müşteri, lead ya da görev kayıtlarını içermez. Çalıştırmayı kapatmak yalnızca o ilerleyişi sonlandırır. Üstelik çalıştırma geçmişi saklandığı için "ne oldu" sorusu daha sonra da yanıtlanabilir.

Kaç gün sonra bir çalıştırmayı ölü saymalıyım?

Tek bir doğru sayı yok; adım tipine göre değişir. Pratik yol, akışın beklenen ömrünü yazıp eşiği onun iki katı olarak tanımlamaktır. Bir günlük bir takip akışı için iki gün, altı aylık bir bakım döngüsü için bir yıl mantıklıdır. Önemli olan eşiğin akışla birlikte tanımlanmış olması.

Süpürme sırasında gerçekten çalışan bir akışı yanlışlıkla kesersem ne olur?

Bu yüzden ilk hafta yalnızca raporlayan bir tur önerilir. Yanlışlıkla kapatılan bir çalıştırma için kişiyi yeniden diziye elle kaydetmek mümkündür; bir tetikleyicinin ateşlenmesini beklemek gerekmez. Yine de ilk günlerde silmek yerine kapatmayı tercih edin.

Takılmaları önlemek için tek bir şeyi değiştirecek olsam ne olurdu?

Her bekleme adımına bir üst sınır koymak. Sınırsız bekleyen adım, uzun vadede birikmenin tek büyük kaynağıdır. Üst sınır koyduğunuz anda akış en kötü ihtimalle "süre doldu" dalına gider ve orada görünür olur; görünür olan sorun çözülebilir bir sorundur.