Otomasyonda hız ve mesai sınırı: müşteriyi gece 3'te aramamak

Perşembe gecesi 03:07. Kargo entegrasyonu gün sonu toplu bildirimini gönderiyor, CRM'deki takip akışı tetikleniyor ve 214 müşterinin telefonu aynı anda titriyor. Sabah 08:40'ta destek ekibi kutuyu açtığında 31 şikayet mesajı, dokuz abonelikten çıkma ve bir tane de "bir daha yazmayın" notu buluyor. Akış tam tasarlandığı gibi çalıştı: tetikleyici ateşlendi, mesaj gitti, kayıtlar yeşil. Bozulan şey akışın mantığı değildi, çalıştığı saatti.

Bu yazı otomasyonun birbirini çeken iki ayarını ele alıyor: hız ve sınır. Önce gece giden bir mesajın neye mal olduğunu, sonra hangi mesajın gerçekten beklemediğini ayırt etmeyi konuşuyoruz. Ardından mesai penceresinin kimin saatine göre kurulduğunu, pencere kapalıyken bekleyen adımın ne olması gerektiğini, hız tavanının hangi seviyede tanımlandığını, aynı kişiye günde kaç mesajın fazla geldiğini, müşteri yanıt verdiğinde bekleyen adımların akıbetini, sınırların yayına çıkmadan nasıl denendiğini ve çalışıp çalışmadığının nereden okunduğunu sırayla ele alıyoruz.

Gece gönderilen mesajın gerçek maliyeti nedir?

Gece gelen bir bildirim yalnızca bir kişiyi uyandırmaz; markanın hangi tür bir gönderici olduğunu ilan eder. Uyandırılan kişi mesajı okumaz, susturur. Susturma tek bir kampanyayı değil, o kanaldan gelecek her mesajı kapsar. Yani gece 03:00'te giden bir kargo bildiriminin faturasını, üç hafta sonra gerçekten önemli olan ödeme uyarısı öder.

İkinci maliyet ekibin içinde birikir. Gece giden mesajların yanıtları sabah aynı anda gelir; destek kuyruğu bir saat içinde ikiye katlanır ve bu yığılma, o gün planlanmış hiçbir işi yapamamak anlamına gelir. Otomasyonun kazandırdığı süreyi geri veren şey çoğu zaman akışın kendisi değil, akışın yarattığı temizlik işidir. Bu kalıp otomasyon kurarken tekrarlanan hataların neredeyse tamamında aynı biçimde görünür: adım doğrudur, zamanlama yoktur.

Üçüncüsü daha sessizdir. Bir müşteri gece mesajı aldığında hesabını kapatmaz, sadece bir sonraki mesajı açmaz. Bu kayıp raporlarda "düşük açılma oranı" olarak görünür ve içerik sorunu sanılır. Oysa sorun metinde değil, saattedir.

Hangi mesaj beklemez, hangisi sabaha kalır?

Her mesaja aynı sınırı koymak, sınırı koymamak kadar zarar verir. Ödeme başarısız olduğu için hizmeti kesilecek bir müşteriye "sabah 09:00'u bekledik" demek savunulabilir bir cümle değildir. Ayrım şu soruyla yapılır: mesaj geciktiğinde müşteri para, zaman ya da fırsat kaybeder mi? Cevap evetse pencere dışına çıkma hakkı vardır; hayırsa sabaha kalır.

İkinci soru şudur: mesaj müşteriye mi, ekibe mi gidiyor? Ekibe giden bildirimler kişisel bir rahatsızlık üretmez; bunlar sabah bakılacak bir kuyruğa düşer. Stok eşiği aşıldığında düşen uyarılar tam olarak bu türdendir: gece üretilirler, kimse uyanmaz, sabah listede beklerler.

Mesaj türü	Gecikmeye dayanır mı?	Uygulanacak sınır
Ödeme alınamadı, hizmet duracak	Hayır	Pencere dışı; günlük tavandan muaf
Sipariş kargoya verildi	Evet, sabaha kalabilir	08:00-21:00 penceresi
Yarınki randevu hatırlatması	Saati sabit	Pencereye taşarsa öne çekilir
Takip dizisinin ikinci adımı	Evet	Pencere + kişi başına günlük tavan
Kampanya duyurusu	Evet	Pencere + saatlik çalıştırma tavanı
Ekibe iç bildirim	Hayır, gerek yok	Sınır uygulanmaz

Bu tabloyu kendi akış listenizle bir kez doldurmak, sonraki her tartışmayı bitirir. Sınıflandırma yapılmadığında ekipteki herkes kendi sezgisine göre sınır koyar ve aynı müşteri bir akıştan sabah 07:00'de, diğerinden gece 23:40'ta mesaj alır.

Mesai penceresi kimin saatine göre kurulur?

Pencerenin en sık atlanan tarafı budur. Akışı kuran kişi kendi masasının saatini düşünür; mesajı alan kişi başka bir saat diliminde olabilir. İzmir'den yönetilen bir akış, Almanya'daki bir müşteriye yerel saatle 07:00'de ulaşır. Kural nettir: pencere alıcının saatine göre tanımlanır, gönderenin saatine göre değil.

Rocketly tarafında bu ayar Workflow Builder'ın Hız ve Mesai Sınırları bölümünde durur: saat, gün ya da hafta başına çalıştırma tavanı, kişi bazlı sınır, bekleme süresi ve mesai penceresi aynı akışın üstünde tanımlanır. Yani sınır akışın dışında bir politika belgesi değil, akışın kendi kaydının bir parçasıdır; akışı kim açarsa hangi saatlerde çalıştığını da görür.

Pencere ile takvim ayrı şeylerdir. Hafta sonu, resmi tatil ve yarım gün, penceresi doğru kurulmuş bir akışta bile ayrı bir kararı gerektirir. Tarihe bağlı akışlarda bu ayrım daha da belirgindir: doğum günü ve yıldönümü mesajları günü kaçırmamalıdır ama günün hangi saatinde gideceği tamamen sizin seçiminizdir ve o seçim mesajın samimi mi rahatsız edici mi göründüğünü belirler.

Pencere kapalıyken bekleyen adım ne olmalı?

Sınır koymak kolaydır; sınıra takılan adımın ne olacağına karar vermek asıl iştir. Üç seçenek vardır: adımı kuyruğa alıp pencere açılınca göndermek, adımı tamamen düşürmek, ya da akışı durdurup insan kararı beklemek. Yanlış seçim, sınırı hiç koymamaktan daha kötü sonuç verir.

Kuyruğa alma çoğu takip mesajı için doğrudur. Ancak kuyruk biriktiğinde pencere açılır açılmaz aynı anda yüzlerce mesaj gitmesi riski doğar; bu yüzden pencere ile saatlik tavan birlikte kurulmalıdır. Aksi halde gece engellenen yığın sabah 09:00'da tek seferde boşalır ve sorun saat değiştirmiş olur, kaybolmamış olur.

Düşürme ise zamanı geçmiş mesajlar için doğrudur. Randevudan iki saat önce gidecek hatırlatma, randevu saatinden sonra gönderildiğinde bir şey iletmez, yalnızca sistemin dikkatsiz olduğunu gösterir. Randevu linkiyle gelen kayıtlarda bu kural en görünür haliyle karşınıza çıkar: hatırlatmanın değeri saate bağlıdır, mesaja değil.

Hız tavanı hangi seviyede tanımlanır?

Tek bir tavan yetmez, çünkü üç ayrı taşma biçimi vardır. Birincisi akış seviyesindedir: bir akış, dış sistemden gelen hatalı bir tetikleme yüzünden dakikada yüzlerce kez çalışabilir. İkincisi kişi seviyesindedir: aynı kişi birden çok akışın kapsamına girer ve her akış kendi başına makul davransa da toplam rahatsız edicidir. Üçüncüsü kanal seviyesindedir: gönderim kotanız bir günde tükenir ve gerçekten önemli mesajlar sıraya girer.

Bu yüzden hız tavanı hem akış başına hem kişi başına tanımlanır. Akış başına tavan sistemi kazadan korur; kişi başına tavan müşteriyi korur. İkisi farklı sorunlara bakar ve biri diğerinin yerini tutmaz.

Ani yığılmanın en sık kaynağı, tek bir olayın çok sayıda kaydı aynı anda hareket ettirmesidir. Toplu içe aktarma, dış sistemden gelen gün sonu dökümü ya da bir reklam kampanyasının aynı dakikada getirdiği form akını bu etkiyi yaratır. Formdan fırsata giden akışı kurarken hız tavanını baştan koymak, kampanya günü akışı elle kapatmak zorunda kalmaktan çok daha ucuzdur.

Aynı kişiye günde kaç mesaj fazladır?

Bunun evrensel bir sayısı yoktur ama pratik bir eşiği vardır: müşteri o gün sizinle bir iş yapmıyorsa, bir kanaldan günde birden fazla mesaj genellikle fazladır. Aktif bir işlem varsa (sipariş yolda, dosya inceleniyor, randevu yarın) tolerans yükselir, çünkü mesajlar bir sürecin parçasıdır.

Kişi başına tavanın en çok işe yaradığı yer, birden fazla akışın aynı kişiye denk gelmesidir. Eksik belge hatırlatması ile bir bakım bildirimi aynı güne düştüğünde, kişi bazlı sınır ikisinden birini ertesi güne taşır. Hangisinin taşınacağını da siz belirlersiniz: aciliyeti düşük olan bekler.

Bir başka pratik kural, aynı konunun tekrar sayısını sınırlamaktır. Üç hatırlatmadan sonra dördüncüsü ikna etmez, yalnızca yıpratır. Bakım sözleşmesi yenilemelerinde bu eşik iyi bilinir: üçüncü hatırlatmadan sonra iş otomasyonun değil, telefonun konusudur. Akışın doğru davranışı bu noktada durup bir görev açmak ve konuyu insana devretmektir.

Müşteri yanıt verdiğinde bekleyen adımlar ne olur?

Bir dizinin en kötü anı, müşteri "tamam, ilgileniyorum" yazdıktan iki gün sonra "hala yanıt alamadık" mesajının gitmesidir. Bu, müşteriye kimsenin okumadığını söyler ve o ana kadar kurulmuş güveni tek hamlede harcar.

Workflow Builder'daki Yanıt Gelince Dur davranışı bu durumu akışın içinde çözer: kişi yanıtladığında ya da lead kapandığında bekleyen adımlar iptal olur, sessiz saatler ve günlük mesaj tavanı da aynı anda uygulanmaya devam eder. Yani "durdurma" ayrı bir akış değil, dizinin kendi kuralıdır; kimsenin sabah listeye bakıp elle iptal etmesi gerekmez.

Aynı mantık ters yönde de geçerlidir. Müşteri "şu an ilgilenmiyorum" dediğinde diziyi durdurmak yeterli değildir; o kişinin ne zaman yeniden değerlendirileceğini de kaydetmek gerekir. Soğumuş müşteriyi geri kazanma çalışmasının işe yaramasının tek koşulu budur: geri dönüş, ilk reddedişin üstünden yeterli zaman geçtikten sonra ve farklı bir gerekçeyle yapılır.

Sınırları yayına almadan nasıl denersiniz?

Sınırların çoğu, ilk kez gerçek trafikte sınandığında yanlış çıkar: pencere bir saat kaymıştır, tavan beklenenden düşüktür, kuyruğa alınan adım aslında düşürülmektedir. Bunu üretimde öğrenmek pahalıdır çünkü öğrenme yöntemi müşteriye gerçek mesaj göndermektir.

Kuru çalıştırma testi bu maliyeti ortadan kaldırır: akış örnek veriyle baştan sona yürütülür, hangi adımın çalışacağı adım adım görünür ve gerçek e-posta, WhatsApp ya da SMS gönderilmez. Sınır ayarını değiştirdikten sonra testi tekrarlamak, değişikliğin gerçekten beklediğiniz adımı durdurup durdurmadığını gösterir.

İkinci güvenlik ağı sürüm geçmişidir. Her kayıt bir sürüm olarak saklandığı için, dün gece fazla mesaj gönderen ayarı bulmak "kim ne değiştirdi" tartışmasına dönüşmez; bozulan akış eski sürüme döndürülür ve geri alma öncesindeki hal de saklandığı için kararı geri almak da mümkündür. Riskli bir adımın önüne konan onay bekle adımı ise üçüncü frendir: akış durur, seçtiğiniz kişiye bildirim gider, süre dolarsa akış onaysız ilerlemez.

Sınırın çalıştığını nereden anlarsınız?

Sınır koymanın sessiz tehlikesi şudur: çalıştığında hiçbir şey olmaz. Gönderilmeyen mesaj görünmez, engellenen yığın rapora düşmez ve bir süre sonra kimse sınırın hala orada olduğundan emin olamaz. Bu yüzden sınır da ölçülmelidir.

Analitik ve loglar tarafında bakılacak üç şey vardır: hangi adımın ne kadar sürdüğü, nerede takıldığı ve hata alan çalıştırmaların hangi saatlerde yoğunlaştığı. Çalıştırma geçmişi bu kayıtları tuttuğu için hata alan akışlar tek tek değil toplu olarak yeniden denenebilir; pencere yüzünden ertelenmiş bir yığını sabah bilinçli olarak boşaltmak da böylece bir karar haline gelir.

Otomatik teşhis ise sormadığınız soruyu sorar. Kopuk bir adım, hiç tetiklenmemiş bir akış ya da bağlanmamış bir kanal, sınır ayarını anlamsız kılar: mesaj zaten gitmiyordur ve siz sınırın işe yaradığını sanıyorsunuzdur. Aynı ayrım sipariş durumu bilgilendirmelerinde çok net görülür, çünkü orada müşteri bir mesaj bekler ve gelmediğinde bunu size kendi söyler.

Mesai dışında hiç iletişim kurmamak mı gerekir?

Hayır, ve bu yaygın bir aşırı düzeltmedir. Mesai dışı saatlerde sessiz kalmak, müşteriye gece yazan kişiyi görmezden gelmek anlamına gelir. Gelen mesaja verilen otomatik yanıt ile giden kampanya mesajı bambaşka iki şeydir: biri karşılık verir, diğeri araya girer.

Doğru kurulum ikisini ayırır: gelen kanallar 7/24 açıktır ve karşılayan bir yanıt verir, giden akışlar ise pencereye tabidir. Mesai dışı otomatik yanıtın beklentiyi doğru kurması tam da bu yüzden önemlidir: mesaj ne zaman okunacağını söylerse müşteri beklemeyi kabul eder, söylemezse aynı soruyu üç kanaldan tekrar sorar.

Bu ayrımın pratik testi basittir: mesajı biz mi başlattık, müşteri mi? Müşteri başlattıysa saat kısıtı yoktur, yanıt verilir. Biz başlatıyorsak pencere geçerlidir.

Sonuç

Hız ve sınır birbirinin rakibi değildir; aynı sistemin iki ayarıdır. Hız, müşteriye onu beklettiğinizi hissettirmemek içindir. Sınır, aynı sistemin müşteriyi rahatsız eden bir şeye dönüşmemesi içindir. Biri olmadan diğeri işe yaramaz: sınırsız hız gürültü üretir, hızsız sınır ise geciken bir kurumdan başka bir şey değildir.

Pratik başlangıç şudur: mevcut akışlarınızı yukarıdaki tabloya göre üç gruba ayırın, yalnızca müşteriye giden ve gecikmeye dayanan gruba pencere ile kişi bazlı tavan koyun, sonra bir hafta boyunca çalıştırma kayıtlarına bakın. Değişikliği yayına almadan görmek isterseniz akışları kuru çalıştırma testiyle deneyip Rocketly hesabınızı ücretsiz açarak aynı ayarları kendi akışlarınız üstünde kurabilirsiniz.

Sıkça sorulan sorular

Mesai penceresi acil mesajları da engeller mi?

Engellememeli. Pencere akış bazında tanımlandığı için, hizmet kesintisi ya da ödeme sorunu bildiren akışları pencere dışında bırakabilirsiniz. Ayrım mesajın türünde kurulur, tek bir genel kuralda değil.

Pencere kapalıyken tetiklenen akış kaybolur mu?

Kurulumunuza bağlıdır. Bekleme adımıyla kuyruğa alınan mesaj pencere açılınca gider; zamanı geçmiş bir hatırlatmanın ise düşürülmesi doğrudur. Bu kararı adım bazında vermek, akışın tamamına tek bir davranış dayatmaktan daha iyi sonuç verir.

Kişi bazlı tavan farklı akışları birlikte sayar mı?

Amaç budur: müşteri sizin akış listenizi bilmez, yalnızca kaç mesaj aldığını bilir. Bu yüzden tavanı kişi üzerinden düşünmek, her akışa ayrı ayrı sınır koymaktan daha koruyucudur.

Sınırları koyduktan sonra dönüşüm düşer mi?

Gönderim sayısı düşer, dönüşümün düşmesi beklenmez. Genellikle tersi görülür: aynı kişiye daha az ama daha uygun zamanda ulaşıldığında açılma ve yanıt oranları toparlanır. Bunu varsaymak yerine, sınırdan önceki ve sonraki dört haftayı çalıştırma kayıtları üzerinden karşılaştırın.