Çalıştırma geçmişi ve yeniden deneme: başarısız adımı kurtarmak

Perşembe sabahı 08:40. Bir eğitim danışmanı paneli açıyor ve dün akşam formu dolduran otuz sekiz adayın hiçbirine karşılama mesajının gitmediğini görüyor. Akış bozuk görünmüyor: ekranda "aktif" yazıyor, tetikleyici otuz sekiz kez ateşlenmiş, ilk iki adım da tamamlanmış. Kırılan tek yer üçüncü adım — mesajı taşıyan kanalın yetkisi gece 23:10'da düşmüş ve o saatten sonra başlayan her çalıştırma aynı noktada durmuş. Kimse yanlış bir şey kurmadı. Yalnızca kimse bakmadı, kimse yeniden denemedi.

Bu yazı o otuz sekiz çalıştırmayı geri kazanmanın düzenini anlatıyor. Önce bir çalıştırmanın tam olarak nerede kırıldığını ve çalıştırma geçmişinin hangi soruyu yanıtlaması gerektiğini ele alıyoruz. Ardından hangi hatanın yeniden denemeye değdiğini, yeniden denemenin neden ikinci bir mesaj göndermemesi gerektiğini, toplu denemenin ne zaman doğru karar olduğunu, yarıda kalan çalıştırmaların neden biriktiğini, akışı düzeltmekle tek bir çalıştırmayı kurtarmanın farkını, hatayı kimin ne kadar sürede öğrenmesi gerektiğini, kurtarma hamlesinin nerede prova edildiğini ve tüm bunun haftalık bir alışkanlığa nasıl dönüştüğünü sırayla anlatıyoruz.

Bir çalıştırma tam olarak nerede kırılır?

Otomasyon "çalıştı" ya da "çalışmadı" diye ikiye ayrılmaz. Bir çalıştırma adım adım ilerler ve her adımın kendi başarısızlık biçimi vardır. Tetikleyici hiç ateşlenmemiş olabilir: form yayından kalkmıştır, webhook'u gönderen sistem adresi değiştirmiştir. Tetikleyici ateşlenmiş ama koşul beklenmedik bir dala sapmıştır: alan boş geldiği için "if" tarafı yerine "else" tarafı çalışmış, kimseye mesaj gitmemiştir. Ya da akış doğru dala girmiş, mesajı göndereceği anda dış servis reddetmiştir.

Dördüncü bir durum daha var ve en sinsisi odur: adım başarıyla tamamlanmıştır ama sonucu yanlıştır. Mesaj gitmiştir, yalnızca boş bir değişkenle gitmiştir; görev açılmıştır, yalnızca yanlış kişiye atanmıştır. Bu tür çalıştırmalar hata listesine hiç düşmez, çünkü sistem açısından her şey yolundadır. Onları ancak çıktının kendisine bakarak yakalarsınız — gönderilen metnin örneğini okuyarak, açılan görevin sahibini kontrol ederek.

Bu üç durum aynı ekranda "başarısız" görünür, ama üçünün çözümü birbirinden tamamen farklıdır. Birincisi kurulum hatasıdır, ikincisi veri hatasıdır, üçüncüsü geçici bir bağlantı sorunudur. Otomasyon yatırımlarının beklentiyi karşılamamasının sık görülen sebeplerinden biri tam burada saklıdır ve CRM projelerinin neden hedefini tutturamadığı tartışmasının otomasyon tarafındaki karşılığıdır: ekip hatayı görür, ama hatanın hangi türden olduğunu ayırt edecek kaydı elinde tutmaz. Ayrım yapılamayınca da tek bir refleks kalır — akışı kapatmak.

Çalıştırma geçmişi hangi soruyu yanıtlamalı?

İyi bir çalıştırma kaydı "hata oldu" demez; "şu kayıt için, şu saatte, şu adımda, şu sebeple durdu" der. Pratikte dört alanı okuyabilmeniz gerekir: çalıştırmayı başlatan olay ve ilgili kişi, akışın kaçıncı adıma kadar ilerlediği, duran adımın dönüş mesajı ve çalıştırmanın toplam süresi. Bu dördü olmadan her inceleme tahmine dönüşür.

Rocketly tarafında bunu iki ekran birlikte taşır. Analitik ve loglar hangi adımın ne kadar sürdüğünü ve nerede takıldığını gösterir; Çalıştırma Geçmişi ve Yeniden Deneme ise her koşuyu tek tek kayıt altında tutar, böylece hata alan çalıştırmaları tek tek değil toplu olarak yeniden denersiniz. Süre bilgisi göründüğü kadar ikincil değildir: aniden üç kat uzayan bir adım, henüz hataya dönüşmemiş bir sorunun ilk işaretidir. Kişi tarafındaki karşılığını görmek isterseniz kaydı müşterinin tek kartta toplanan geçmişiyle yan yana koymak, "bu kişiye zaten dün konuşuldu mu" sorusunu saniyeler içinde kapatır.

Hangi hata yeniden denemeye değer, hangisi boşuna?

Yeniden deneme bedava değildir. Kalıcı bir hatayı yüz kez denemek yüz kez aynı sonucu verir, ama karşı sistemdeki kotanızı tüketir ve gerçek sorunu log yığınının altına gömer. Bu yüzden denemeden önce hatayı sınıflandırmak gerekir. Sınıflandırmayı kolaylaştıran soru tek cümledir: "hiçbir şey değişmezse bir sonraki deneme farklı bir sonuç verebilir mi?" Yanıt hayırsa, denemek değil düzeltmek gerekir. Aşağıdaki ayrım günlük kullanımda yeterince keskindir.

Hata türü	Tipik örnek	Yeniden deneme	Önce ne yapılır
Geçici bağlantı	Zaman aşımı, servis kısa süre yanıt vermiyor	Evet, aralık artırarak	Bir şey yapmayın, bekleyin
Yetki düşmüş	Kanal bağlantısının süresi dolmuş	Evet, ama bağlantı yenilendikten sonra	Kanalı yeniden bağlayın
Veri eksik	Telefon alanı boş, e-posta biçimi geçersiz	Hayır, kayıt düzelmeden anlamsız	Kaydı düzeltin ya da koşula filtre ekleyin
Kural reddi	Alıcı listeden çıkmış, sessiz saat penceresi	Hayır, doğru davranış budur	Denemeyin; akışın kararını kabul edin
Kurulum hatası	Kopuk adım, silinmiş şablon	Düzeltmeden hayır	Akışı düzeltip yeni sürümü yayınlayın

Bu tablo özellikle işlem tarafında hayat kurtarır. Sipariş yönetimi akışlarında "kargo servisi yanıt vermedi" ile "adres alanı boş" aynı kırmızı rozetle görünür; ilkini beş dakika sonra denemek çözer, ikincisini elli kez denemek yalnızca gürültü üretir.

Yeniden deneme ikinci bir mesaj gönderir mi?

Ekiplerin toplu yeniden denemeden çekinmesinin gerçek sebebi budur: aynı kişiye ikinci kez mesaj gitmesi korkusu. Korku haklıdır, ama çözümü denememek değildir. Çözüm, çalıştırmanın nerede kaldığını bilmesidir — yeniden deneme kaldığı adımdan devam etmeli, akışı baştan başlatmamalıdır. Tamamlanmış adımlar tamamlanmış sayılır; yalnızca duran adım tekrar denenir.

Metin taşıyan adımlarda ikinci bir güvence daha vardır. Dizi Adım Editörü'nde bir adım için A/B varyantı tanımladığınızda, varyant seçimi çalışma anında sabitlenir; yeniden deneme aynı kişiye ikinci bir mesaj göndermez ve varyantı da değiştirmez. Bu, ölçümü de korur — aksi halde her yeniden deneme A/B sonucunu sessizce bozardı. Aynı disiplin soğuyan lead'leri yeniden ısıtan kampanyalarda daha da kritiktir: aylardır sessiz kalmış bir kişiye üst üste iki mesaj göndermek, kampanyanın kendisini geri tepen bir hamleye çevirir.

Toplu yeniden deneme ne zaman doğru karar?

Tek bir çalıştırmayı elle denemek her zaman mümkündür, ama gece boyunca biriken altmış üç kayıt için bu iş saatlerce sürer. Toplu deneme, hepsinin aynı sebeple durduğunu doğruladığınızda doğru karardır. Doğrulama basit: geçmişte hata mesajlarını gruplayın, tek bir sebep listenin ezici çoğunluğunu kaplıyorsa ortak bir kök var demektir. Grup dağınıksa, yani beş farklı sebep beşe bölünmüşse, toplu deneme yanlış araçtır; orada tek tek bakmak daha hızlı sonuç verir.

Sıra da önemlidir. Önce kökü giderin — kanalı yeniden bağlayın, eksik yetkiyi verin — sonra toplu deneyin. Ters sırada çalışmak yalnızca hata sayısını ikiye katlar. Zamanlamaya da bakın: yüzlerce çalıştırmayı aynı anda serbest bırakmak, karşı sistemdeki kotayı bir dakikada tüketebilir. Hız ve mesai sınırları burada devreye girer; saat veya gün başına çalıştırma tavanı, kişi bazlı sınır ve mesai penceresi tanımlıysa kurtarma dalgası kendiliğinden yayılır. Randevu iptali ve yeniden planlama akışlarında bu özellikle görünürdür: sabahın körüne denk gelen bir kurtarma dalgası, hatırlatmayı gece yarısı bildirimine dönüştürür.

Yarıda kalan çalıştırmalar neden birikir?

Her başarısızlık gürültülü değildir. Bazı çalıştırmalar hata da vermez, tamamlanmaz da: bekleme adımında asılı kalır, yanıt bekler, sonra unutulur. Bunlar listede "çalışıyor" göründükleri için kimsenin dikkatini çekmez ve haftalar içinde birikirler. Sonuç, kaç akışın gerçekten canlı olduğunu kimsenin bilmediği bir panodur.

Rocketly'de Takılan Akışları Temizleme tam bunun için vardır: yarıda kalmış çalıştırmalar sistemde birikmez, tespit edilip süpürülür. Otomatik Teşhis ise bir adım öteye gider ve kopuk adım, hiç tetiklenmemiş akış ya da bağlanmamış kanal gibi sorunları siz aramadan raporlar. Aynı temizlik alışkanlığı reklam tarafında da geçerlidir; yeniden pazarlama kurgularında aylar önce kurulmuş ve artık kimseye ulaşmayan bir akışın sessizce durması, hata vermesinden daha pahalıdır.

Akışı mı düzeltmeli, çalıştırmayı mı kurtarmalı?

Bu iki iş sık sık karıştırılır. Çalıştırmayı kurtarmak geçmişe dokunur: dün akşam yarıda kalan otuz sekiz kişiye bugün ulaşmayı hedefler. Akışı düzeltmek geleceğe dokunur: yarın akşam aynı şeyin tekrarlanmamasını hedefler. Bir olay sonrası ikisi de gerekir, ama sırayla ve ayrı ayrı yapılır.

Karışıklık genellikle şöyle çıkar: ekip paniğe kapılıp akışı düzenlemeye başlar, editörde birkaç adım değiştirir, sonra eski çalıştırmaları yeniden dener — ve kurtarma artık başka bir akışla çalışır. Sürüm Geçmişi bu riski küçültür: her kayıt sürüm olarak saklandığı için bozulan akışı tek tıkla eski sürüme döndürebilirsiniz ve geri alma öncesindeki mevcut hal de saklanır. Yani hem düzeltmeyi hem düzeltmeden önceki hali kaybetmezsiniz. Mantığı, yanlışlıkla silinmiş bir kaydı çöp kutusundan geri yüklemeye benzer: geri dönülebilir olmak, dikkatli olmaktan daha güvenilir bir koruma sağlar.

Hatayı kim, ne kadar sürede öğrenmeli?

Açılış sahnesindeki asıl kayıp otomasyonun kırılması değil, kırılmanın dokuz buçuk saat fark edilmemesiydi. Bu yüzden kurtarma düzeninin yarısı uyarı tasarımıdır. İşe yarayan yaklaşım eşik koymaktır: tek bir başarısız çalıştırma kimseyi uyandırmaz, ama aynı adımda arka arkaya beş hata ya da bir saatte yüzde onu aşan hata oranı sahibine gider. Buradaki sayılar örnektir; sizin eşiğiniz akışın hacmine göre değişir. Günde üç kez çalışan bir akışta "arka arkaya beş" ölçütü iki gün boyunca hiç uyarı üretmez, o yüzden düşük hacimli akışlarda tek bir hata bile uyarılmayı hak edebilir.

Sahibi kelimesi burada teknik değil örgütseldir: her akışın adı yazılı bir sorumlusu olmalı, uyarı ekibe değil o kişiye düşmelidir. Herkese giden uyarı kimseye gitmemiş sayılır. Eşikleri gevşek tutmak da aynı kapıya çıkar; bildirim yorgunluğu CRM uyarılarını kısa sürede göz ardı edilen arka plan gürültüsüne çevirir ve gerçekten önemli olan mesaj da o gürültünün içinde kaybolur.

Kurtarmayı yayına almadan nerede prova edersiniz?

Bir kurtarma hamlesi de bir değişikliktir ve kendi riskini taşır. Yüzlerce kişiye dokunacak bir toplu denemeden önce, düzeltilmiş akışın gerçekten doğru davrandığını görmek istersiniz. Kuru Çalıştırma Testi bunu yayına almadan yapar: örnek veriyle akışı yürütür, hangi adımın çalışacağını adım adım gösterir ve gerçek mesaj göndermez.

Riskli adımların önüne Onay Bekle koymak da aynı işi farklı bir yerden yapar; akış durur, seçtiğiniz kişiye bildirim gider ve süre dolarsa akış onaysız ilerlemez. İkisini birlikte kullanmak, kurtarmanın kendisini ikinci bir olaya dönüştürme ihtimalini ciddi biçimde düşürür. Deneme sürümünü ücretliye çeviren dizilerde bu prova alışkanlığı doğrudan gelire dokunur: onboarding dizisinin üçüncü gününde duran bir adım, kullanıcının ürünü hiç kurmadan denemesini bitirmesi demektir.

Bu düzen haftalık bir alışkanlığa nasıl dönüşür?

Kurtarma yeteneği, kullanılmadığı sürece yalnızca bir ekran olarak kalır. İşe yarayan hale gelmesi için haftada on beş dakikalık sabit bir bakış yeter. Sırası şudur: geçmişte son yedi günün başarısız çalıştırmalarını hata mesajına göre grupla, en kalabalık üç grubun kökünü yaz, kökü giderilebilir olanları gider, sonra o grupları toplu yeniden dene. Ardından hiç tetiklenmemiş akışlara bak — bunlar hata vermez ama çoğu zaman en pahalı sessizliktir.

Bu on beş dakikanın takvimde yeri olması, kimin yapacağının yazılı olmasından daha önemlidir. Yeri olmayan bakış, yoğun bir haftada ilk düşen iştir ve iki ay sonra kimse çalıştırma geçmişini açmıyordur. Gözden geçirmenin çıktısını kısa tutun: üç kök sebep, bir düzeltme kararı ve iki sayı. Uzun bir rapora dönüştüğü an alışkanlık ölür.

Dördüncü adım ölçmektir: geçen haftaya göre hata oranı düştü mü, ortalama adım süresi uzadı mı. Bu iki sayı, otomasyonun sağlığını tek bakışta veren en ucuz göstergedir. Yazılım şirketlerinde bu bakış çoğu zaman deneme ve genişleme akışlarına bağlanır; SaaS şirketleri için CRM kurgusunda haftalık çalıştırma incelemesi, churn sinyallerini fark etmenin en erken noktalarından biridir. Kendi akışlarınızın geçmişini bu düzende okumaya başlamak isterseniz ücretsiz bir Rocketly hesabı açıp ilk akışınızı kurabilirsiniz.

Sıkça sorulan sorular

Yeniden deneme akışı baştan mı başlatır?

Hayır, doğru kurulmuş bir yeniden deneme çalıştırmayı kaldığı adımdan sürdürür. Tamamlanmış adımlar tekrar çalışmaz; yalnızca duran adım ve sonrası yürütülür. Bu yüzden ilk iki adımı geçmiş bir çalıştırmayı denemek ikinci bir karşılama mesajı üretmez.

Kaç kez denemek makul?

Geçici hatalar için üç ila beş deneme, aralarını açarak, çoğu senaryoda yeterlidir. Bu sayıda düzelmiyorsa sorun geçici değildir ve denemeye devam etmek yalnızca kotayı tüketir. Kalıcı hatalarda ise doğru sayı sıfırdır: önce kök giderilir.

Hangi çalıştırmalar hiç denenmemeli?

Kural gereği reddedilenler. Alıcı listeden çıkmışsa, sessiz saat penceresi kapalıysa ya da günlük mesaj tavanı dolmuşsa akış hata yapmamıştır; tam da tasarlandığı gibi davranmıştır. Bunları zorlamak izin yönetimini bozar.

Eski bir çalıştırmayı günler sonra denemek mantıklı mı?

Bağlama bağlıdır. Bir görev oluşturma ya da etiket atama adımı günler sonra da anlamlıdır. Zamana bağlı bir hatırlatma ise değildir — randevu geçtikten sonra gönderilen hatırlatma yardımcı olmaz, rahatsız eder. Denemeden önce mesajın hala doğru olup olmadığını sorun.