Kanal sağlık paneli: WhatsApp bağlantısı koptuğunu ne zaman fark edersiniz?

Salı sabahı 09:40. Bir e-ticaret firmasının destek masasında iki temsilci var ve sabah mesaisi normalde hareketli geçer: dokuzla on arası WhatsApp'tan otuz civarı mesaj düşer, kargo sorusu, iade talebi, beden değişimi. O sabah saat on bire kadar yalnızca dört mesaj geldi. Kimse bunu sorun saymadı, "sakin bir gün" denip geçildi. Öğleden sonra bir müşteri Instagram'dan yazıp "dünden beri WhatsApp'tan yazıyorum, kimse dönmüyor" dediğinde gerçek ortaya çıktı: WhatsApp bağlantısı bir önceki akşam 18:20'de kopmuştu ve o saatten sonra gelen hiçbir mesaj gelen kutusuna düşmemişti. Ekranda tek bir hata satırı yoktu. Yalnızca bir boşluk vardı ve boşluk kimseyi uyandırmaz.

Bu yazıda kanal kesintisini görünür kılmanın yolunu sırayla kuruyoruz: bir kanalın "kopması" derken tam olarak neyin bozulduğu, kesintinin neden saatlerce fark edilmediği, hangi belirtilerin bağlantı sorununa işaret ettiği, sağlık kontrolünün ne yoklayıp ne yoklamadığı, webhook loglarının hangi soruyu yanıtladığı, hız limitinin sessizce neyi daralttığı, otomatik yeniden bağlanmanın sınırı, kanal başına alarm eşiklerinin nasıl seçileceği, kesinti anında ekibin izleyeceği sıra ve kesinti bittikten sonra biriken yığının nasıl kapatılacağı.

Bir kanalın "kopması" tam olarak neyi bozar?

"WhatsApp çalışmıyor" cümlesi en az dört farklı arızayı aynı torbaya koyar ve bu yüzden çözümü geciktirir. Birincisi yetkilendirmenin düşmesidir: erişim anahtarı süresi dolmuş ya da iptal edilmiştir, sistem platforma bağlanamaz. İkincisi webhook kopmasıdır; platform mesajı size göndermeye devam eder ama sizin adresiniz yanıt vermediği için mesaj yolda kalır. Üçüncüsü hız limitidir: bağlantı ayaktadır, gönderim reddedilir. Dördüncüsü hesap seviyesinde kısıttır; kalite puanı düşmüş, şablonlar reddedilmiş ya da hat geçici olarak sınırlanmıştır.

Bu dördü aynı görünür ama farklı yerden onarılır. Yetki düşmesi yeniden bağlanmayla, webhook kopması sizin sunucu tarafınızda, hız limiti gönderim planlamasıyla, hesap kısıtı ise platformla yazışarak çözülür. Kurumsal hatta bağlıysanız arıza sınıflarının hangisinin sizi ilgilendirdiğini bilmek için önce hattın nasıl kurulduğunu bilmek gerekir; WhatsApp Business API'nin nasıl alındığını ve neyi taahhüt ettiğini anlamadan arıza tablosunu okumak zordur.

Beşinci bir sınıf da var ve en çok görmezden gelineni budur: QR ile bağlanan kişisel hat. O hat bir telefona bağlıdır. Telefon şarjsız kaldığında, uçak moduna alındığında ya da cihazda WhatsApp'tan çıkış yapıldığında oturum düşer. Teknik olarak hiçbir şey bozulmamıştır; sadece kimse bakmamıştır.

Kesinti neden saatlerce fark edilmez?

Çünkü kesintinin belirtisi bir hata değil, bir yokluktur. Yazılımda gördüğümüz arızaların çoğu kendini gösterir: kırmızı bir uyarı, başarısız bir istek, bir yerde biriken kuyruk. Kanal kesintisi bunun tersidir, ekranı sessizleştirir. Sessizlik ise ekipte hiçbir refleks tetiklemez. Aksine rahatlatır.

İkinci sebep, gelen mesaj hacminin doğal olarak dalgalanmasıdır. Perşembe sabahı otuz mesaj gelen bir kutuya cuma öğleden sonra sekiz mesaj gelebilir ve bu tamamen normaldir. Ekip bu dalgalanmaya alışkın olduğu için düşüşü içgüdüsel olarak mevsimselliğe yorar. Bir kanalın normal ritmini yazılı olarak bilmiyorsanız, o ritmin bozulduğunu da fark edemezsiniz. Hangi kanalın hangi pazarda ne kadar ağırlık taşıdığını önceden belirlemiş ekipler bu karşılaştırmayı daha hızlı yapar, çünkü beklenen dağılımı bilirler.

Üçüncü sebep vardiya devridir. Akşam kapanan kanal, sabah gelen kişinin gözünde zaten sessizdir; onun karşılaştırma noktası dünkü akşam değil, bugünkü sabahtır. Kopmanın en olası saati mesai dışıdır ve fark edilmesi en zor olan da odur.

Hangi belirtiler bağlantı sorununa işaret eder?

Beş belirti vardır ve hiçbiri tek başına kanıt değildir; birlikte okundukları için değerlidir. Birincisi hacim düşüşüdür: kanalın kendi geçmiş ortalamasına göre gelen mesaj sayısındaki sert düşüş. İkincisi tek yönlü akıştır; giden mesajlar gidiyor ama gelen yok. Bu, webhook kopmasının klasik imzasıdır, çünkü gönderme ve alma yolları farklıdır ve biri diğeri olmadan çalışabilir.

Üçüncüsü teslim durumunun takılmasıdır: mesajlar "gönderildi" işaretinde kalıyor, "iletildi"ye geçmiyorsa sorun karşı taraftadır. Dördüncüsü ve en güçlüsü kanal göçüdür. Müşteri yanıt alamadığında kaybolmaz, başka bir kapı çalar. Instagram'dan, e-postadan ya da telefondan gelen "WhatsApp'tan yazdım, dönen olmadı" cümlesi aslında bir arıza bildirimidir. Özellikle CIS pazarında çalışıyorsanız bu göç Telegram üzerinden gelen bir mesaja dönüşür ve orada da tesadüfen görülür.

Beşincisi otomatik davranışların susmasıdır. Mesai dışı otomatik yanıt tanımlıysa, kapalı saatte gelen her mesaj bir yanıt üretir. Gece boyunca hiç otomatik yanıt üretilmemişse gece boyunca hiç mesaj gelmemiş demektir; bu, hacim düşüşünden daha keskin bir sinyaldir çünkü sıfır ile az arasındaki farkı gösterir.

Sağlık kontrolü ne yoklar, ne yoklamaz?

Birleşik Inbox'taki kanal sağlık paneli üç şeyi düzenli aralıklarla yoklar: bağlantının canlı olup olmadığını, webhook uç noktasının yanıt verip vermediğini ve kanalda son hareketin üstünden ne kadar zaman geçtiğini. Bunlara ek olarak hız limiti takibi ve webhook logları aynı ekranda durur, yani arıza sınıfını ayırmak için üç ayrı yere bakmanız gerekmez. Panelin işlevi kesintiyi önlemek değil, kesintiyi görünür kılmaktır; bu ayrım önemlidir çünkü hiçbir panel platform tarafındaki bir arızayı engelleyemez.

Panelin yoklamadığı şeyler de net olmalı. Bağlantının canlı olması mesajın müşteriye ulaştığı anlamına gelmez; ulaşma bilgisi teslim durumundan okunur. Kanalın açık olması gönderdiğiniz içeriğin kabul edildiği anlamına da gelmez; şablon reddi ayrı bir konudur. Bir başka deyişle sağlık paneli borunun tıkalı olup olmadığını söyler, içinden geçen suyun kalitesini söylemez.

Panelin en çok işe yaradığı an, kimsenin bakmadığı andır. Bu yüzden panel bir ekran olarak değil, bir bildirim kaynağı olarak kurulmalıdır. Ekibin gün içinde açıp bakması gereken bir sekme, tanımı gereği gece 02:00'de kopan bağlantıyı yakalamaz.

Webhook logları hangi soruyu yanıtlar?

Tek bir soruyu yanıtlar ve o soru bütün tartışmayı bitirir: platform mesajı gönderdi mi, biz aldık mı? Bu sorunun üç olası cevabı vardır ve üçü üç ayrı ekibi ilgilendirir. Platform hiç göndermediyse sorun hesap tarafındadır; yetki, kısıt ya da yanlış numara eşlemesi. Platform gönderdiyse ama sizin adresiniz başarılı yanıt döndürmediyse sorun sizin altyapınızdadır. Aldıysanız ama konuşma açılmadıysa sorun işleme katmanındadır.

Log olmadan bu üçünü ayırt etmenin yolu yoktur ve ayırt edemeyen ekipler saatlerini yanlış yerde arayarak geçirir. Log varken konuşma "bende mi sende mi" tartışmasından çıkar, zaman damgalı bir kayda dayanır. Kesintinin başlangıç saatini de yalnızca log verir; o saat, kaç müşterinin etkilendiğini hesaplamak için gereken tek girdidir.

Hız limiti sessizce neyi daraltır?

Hız limiti kesintiden farklıdır çünkü kanal ayaktadır. Bağlantı canlı görünür, panel yeşildir, yine de mesajların bir kısmı çıkmaz. En sık görülen sebep, toplu gönderim ile bire bir yanıtların aynı kotayı paylaşmasıdır. Sabah on birde başlayan bir kampanya kotanın büyük bölümünü yerse, öğleden sonra müşteriye yazdığınız tekil yanıtlar kuyruğa girer. Ekip bunu "sistem yavaş" diye tarif eder; oysa sistem yavaş değildir, sıraya girmiştir. Toplu mesaj gönderiminin yasal ve banlanmayan yöntemlerini planlarken kota paylaşımını hesaba katmak, kampanya gününde destek kanalını kilitlememenin en basit yoludur.

İkinci daralma kaynağı şablon tarafındadır. Reddedilen ya da askıya alınan bir şablon, ona bağlı tüm otomatik gönderimleri sessizce durdurur. Sipariş bildirimi giden bir akışta bu, günlerce fark edilmeden sürebilir çünkü müşteri "bana bildirim gelmedi" demez, sadece arar. Reddedilmeyen bir şablonun nasıl yazıldığını bilmek burada arıza sayısını doğrudan düşürür.

Otomatik yeniden bağlanma nereye kadar çözer?

Otomatik yeniden bağlanma, geçici arızaların büyük bölümünü insan görmeden kapatır: ağdaki kısa kesintiler, platform tarafındaki birkaç dakikalık dalgalanmalar, oturum yenileme gecikmeleri. Bu sınıf arızaların sayısı toplamın içinde yüksektir ve otomatik toparlanma olmadan ekip günde birkaç kez gereksiz yere uyarılır. Uyarı enflasyonu, alarmların ciddiye alınmamasının bir numaralı sebebidir.

Çözemediği sınıf ise nettir ve insan gerektirir: iptal edilmiş yetki, hesap seviyesinde kısıt, QR oturumunun düşmesi, webhook adresinin değişmesi. Bu arızalarda yeniden deneme sonsuza kadar sürebilir ve hiçbir şey düzelmez. Bu yüzden kurulacak kural basittir: otomatik deneme sayısına ve süresine bir sınır koyun, sınır aşıldığında sistem kendi kendine denemeyi bırakıp bir insana haber versin. "Hala deniyorum" durumu, çözülmüş bir durum değildir.

Kanal başına hangi eşikte alarm kurulur?

Alarm eşiğini mesaj hacmine değil, sessizliğin süresine bağlamak gerekir. Hacim eşiği kampanya günlerinde ve tatillerde yanlış alarm üretir; sessizlik süresi ise kanalın kendi ritmine göre ayarlanabilir. Birleşik Inbox'ta kaydedilmiş görünüm alarmları bunu doğrudan yapar: sık kullandığınız süzgeç kombinasyonunu bir görünüm olarak kaydeder, üzerine bir eşik koyarsınız ve eşik aşıldığında bildirim gelir. Alarm görünümün kendi koşullarına göre çalıştığı için "yanıtsız WhatsApp konuşması beşi geçerse haber ver" gibi bir kural, kanal bazında ayrı ayrı kurulabilir.

Kanal	Normal ritim (örnek)	Sessizlik eşiği	İlk bakılacak yer
WhatsApp Business API	Mesai içinde saatte on ile otuz mesaj	Doksan dakika hiç gelen yok	Webhook logu ve teslim durumu
WhatsApp kişisel hat (QR)	Gün boyu düzensiz ama kesintisiz	Üç saat hiç gelen yok	Oturumun ve bağlı telefonun durumu
Instagram ve Messenger	Kampanya dışında düşük ve düzensiz	Bir tam iş günü hiç gelen yok	Sayfa yetkilendirmesi
E-posta	Sabah yoğun, gün boyu sürekli	Dört saat hiç gelen yok	Posta kutusu bağlantısı ve istenmeyen klasörü
SMS	Yalnız yanıt geldiğinde hareket	Gönderim hata oranı normalin iki katına çıkınca	Operatör raporu ve gönderim kuyruğu

Tablodaki değerler örnektir; kendi ritminizi iki haftalık geçmişten çıkarıp eşikleri ona göre daraltın. Eşiği fazla dar tutmak, fazla geniş tutmaktan daha zararlıdır, çünkü sık yanlış alarm alan ekip bir süre sonra gerçek alarma da bakmaz.

SMS satırı ayrı bir mantık ister, çünkü SMS'te gelen mesaj beklemezsiniz; ölçtüğünüz şey gönderim başarısıdır. Aynı ayrım e-posta için de geçerli ve iki kanalın arıza davranışı birbirine benzemez; eşiği koymadan önce SMS ile e-posta arasındaki farkı netleştirmek yanlış alarm sayısını doğrudan düşürür.

Kopma anında ekip hangi sırayla ne yapar?

Alarm geldiğinde kaybedilen zamanın çoğu "kim ne yapacak" tartışmasında geçer. Bu yüzden sıra önceden yazılı olmalı ve sıradaki her adım tek bir soruya bağlanmalıdır. Aşağıdaki beş adım çoğu ekip için yeterlidir ve ilk üçü teknik, son ikisi müşteri tarafıdır.

Sıra	Sorulan soru	Cevap hayır ise
1	Bağlantı canlı mı?	Yeniden bağlanmayı elle tetikleyin, yetkiyi yenileyin
2	Platform mesaj gönderiyor mu?	Hesap durumunu ve kısıtları platform tarafında kontrol edin
3	Biz aldığımızı onaylıyor muyuz?	Webhook adresini ve sunucu yanıtını kontrol edin
4	Müşteriye alternatif kapı açık mı?	Yedek kanalı duyurun ve mesai dışı yanıtı güncelleyin
5	Etkilenen konuşmalar listelendi mi?	Kesinti aralığını etiketleyip sahiplendirin

Dördüncü adım en çok atlanandır. Kanal geri gelene kadar müşteriye açık bir kapı bırakmak, kesintinin maliyetini doğrudan düşürür. Bu kapı web sitesindeki sohbet balonu olabilir, kısa bir bilgilendirme SMS'i olabilir ya da CIS pazarında güçlü olan Viber hattı olabilir; önemli olan alternatifin önceden kurulmuş ve test edilmiş olmasıdır. Kesinti anında yeni kanal açmaya çalışmak, arızayı ikiye katlar.

Mobil uygulamanız varsa duyuru için fazladan bir yolunuz daha var: uygulama içi mesaj ya da anlık bildirim, kesinti bilgisini mesajlaşma kanalına hiç dokunmadan iletir. Mobili başlı başına bir kanal olarak kurmanın karşılığı en çok böyle anlarda alınır, çünkü o kanal başka bir sağlayıcıya bağlıdır ve aynı anda düşmesi ihtimali düşüktür.

Beşinci adım kesintinin sınırını çizer. Kesinti aralığındaki konuşmaları ayrı bir etiketle işaretlemek, hem geri dönüş listesini oluşturur hem de yanıt süresi ölçümünüzü bozmaktan kurtarır. Aksi halde ay sonunda ortalama yanıt süresi tek bir gece yüzünden anlamsız görünür.

Kesinti bittikten sonra biriken yığını nasıl kapatırsınız?

Bağlantı geri geldiğinde mesajlar toplu halde düşer ve bu ikinci bir sorun yaratır: yüzlerce konuşma aynı anda açılır, hepsi eşit derecede geciktiği için hiçbiri öncelikli görünmez. Burada işleyen tek yaklaşım sıralamayı gecikmeye değil, konunun türüne bağlamaktır. Sipariş ve ödeme sorusu önce, bilgi talebi sonra. Atama kuralları ve SLA tanımlıysa, kesinti etiketi taşıyan konuşmalar için ayrı bir hedef süre koyup ekibi buna göre dağıtabilirsiniz.

İkinci adım, gecikmiş yanıtın nasıl yazılacağıdır. "Yoğunluk nedeniyle geç dönüş" cümlesi müşteriye bir şey söylemez; teknik bir kesinti olduğunu ve mesajın kaybolmadığını söylemek daha iyi karşılanır. Konuşmanın yanında müşterinin geçmişi durduğu için, gecikmiş yanıtın bağlamla açılması da mümkündür ve bu, özür cümlesinden daha etkilidir. Kesintiden en çok etkilenen hesapları sonradan izlemek isterseniz, müşteri sağlık skorunun risk altındaki hesabı nasıl işaretlediğine bakmak işe yarar; kesinti sonrası birkaç hafta o skorda görülür.

Üçüncü adım satış tarafındadır ve genellikle unutulur. Kesinti sırasında yazan kişilerin bir kısmı destek değil, satın alma niyetiyle yazmıştır. O konuşmaların ayrıca gözden geçirilmesi gerekir, çünkü bir destek sorusu ertelenebilir ama sıcak bir talep ertelenemez. Hangi anlaşmanın tıkandığını gösteren sağlık skoru mantığı burada da geçerlidir: sessizleşen fırsat, kapanmış fırsat değildir.

Kanal kesintisini aksiliğe değil ekip disiplinine dönüştürmek isterseniz, Rocketly hesabınızı ücretsiz açıp kanallarınızı tek kutuda toplayarak başlayabilirsiniz.

Sıkça sorulan sorular

Kanal kesintisini kaç dakikada fark etmek makul?

Mesai içinde otuz ile doksan dakika arası çoğu ekip için ulaşılabilir bir hedeftir; mesai dışında hedef, kanal açıldığı anda ilk bakan kişinin durumu bilmesidir. Önemli olan rakamın kendisi değil, o rakamın kanal bazında yazılı olması ve alarmın buna bağlanmasıdır.

Yeniden bağlanma otomatikse alarm kurmaya gerek var mı?

Var. Otomatik toparlanma geçici arızaları kapatır, kalıcı olanları kapatmaz. Alarmı doğrudan kesintiye değil, "deneme sınırı aşıldı" durumuna bağlarsanız gereksiz bildirim almadan gerçek arızayı yakalarsınız.

QR ile bağlı kişisel hat neden daha sık kopar?

Çünkü o hat bir cihaza bağlıdır ve cihazın durumu sizin kontrolünüzde değildir. Telefonun kapanması, uygulamadan çıkış yapılması ya da uzun süre ağa bağlanmaması oturumu düşürür. Kritik akışları kişisel hatta yaslamak yerine kurumsal hatta taşımak bu riski azaltır.

Kesinti sırasında gelen mesajlar sonradan kutuya düşer mi?

Kanala göre değişir. Bazı platformlar belirli bir süre boyunca yeniden gönderme dener ve bağlantı geri geldiğinde mesajlar toplu halde düşer; bazılarında ise o pencere kapandıktan sonra mesaj kaybolur. Bu yüzden kesinti süresini kısaltmak, kurtarmaya güvenmekten daha sağlam bir yaklaşımdır.