Hizmet kesintisi duyurusu ve durum (status) sayfası kurmak

Pazartesi 09.12'de bayi sipariş portalı açılmıyor. Dokuz dakika içinde destek kutusuna on dört mesaj düşüyor ve hepsi aynı soruyu soruyor. Ekipten üç farklı cevap çıkıyor: biri on beş dakikaya döner diyor, biri bizde bir sorun görünmüyor diyor, biri kontrol ediyoruz yazıp mesajı okunmuş bırakıyor. Teknik taraf sorunu kırk dakikada çözüyor. Ama o kırk dakika boyunca destek ekibi tek bir sorunu çözmeden tükeniyor, iki müşteri konuyu herkese açık biçimde soruyor ve akşam iki bayi kendi müşterilerine ne söyleyeceğini bilmediği için sipariş vermiyor. Kesinti kırk dakika, hasar iki gün.

Aşağıda kesinti iletişimini baştan sona kuruyoruz: durum sayfasının neyi çözüp neyi çözmediği, ilk duyurunun hangi anda çıkması gerektiği, duyuruda neyin yazılıp neyin yazılmayacağı, güncelleme ritmi, şiddet seviyelerinin tanımı, sayfanın fiziksel olarak nerede duracağı, metni kimin yazıp kimin onaylayacağı, duyurunun kime gideceği, şeffaflığın sınırı ve kesinti bittikten sonra ne yapılacağı.

1Tespit2İlk duyuru3Güncelleme4Çözüm5Olay raporu

Durum sayfası neyi çözer, neyi çözmez?

Durum sayfasının işi kesintiyi kısaltmak değil, kesinti sırasında aynı sorunun yüz kez sorulmasını engellemektir. Herkesin bakabileceği tek bir adres olduğunda destek ekibi cevaplamak yerine yönlendirir, satış ekibi müşteriye ne diyeceğini bilir, yönetici gelişmeyi öğrenmek için kimseyi rahatsız etmez. Sayfanın ikinci ve az konuşulan izleyicisi de budur: kendi ekibiniz.

Çözmediği şey de nettir. Sözleşmesinde taahhüt bulunan müşteriye, kritik bir entegrasyonu duran iş ortağına ve o gün canlıya geçen projeye durum sayfası yetmez; onların bir insandan haber alması gerekir. Sayfa toplu iletişimi ölçekler, bireysel iletişimin yerine geçmez. Kesinti anında gelen mesaj yığınının tek ekranda nasıl toplanacağını ortak gelen kutusu yazısında ele aldık.

Sayfanın getirisini hesaplamak da zor değil. Bir kesintide açılan destek taleplerinin büyük kısmı çözüm isteyen talepler değildir; "bende mi bir sorun var" sorusudur. Bu soru, ekibinizin en sıkışık olduğu dakikalarda gelir ve her biri birkaç dakika yer. Talebi açılmadan önce cevaplayan bir sayfa, size kesinti sırasında en çok ihtiyaç duyduğunuz şeyi kazandırır: dikkat.

İlk duyuruyu hangi anda yayınlamalısınız?

Ekiplerin çoğu ilk duyuruyu sebebi bulana kadar bekletir. Bu, iletişimin teknik ekibin hızına bağlanması demektir ve müşteri o sırada zaten sorunu yaşamaktadır. Doğru eşik şudur: kesintiyi sizden başkası da görebiliyorsa duyuru çıkar. İlk duyuru sebep içermez, içermemelidir; yalnızca neyin çalışmadığını, kimin etkilendiğini ve ne zaman tekrar yazacağınızı söyler.

Bunu ölçen bir sayı var ve teknik ekibin çözüm süresinden bağımsız: ilk duyuruya kadar geçen süre. Çözüm süresi mühendisliğin işidir, ilk duyuru süresi iletişimin işidir ve ikisini aynı raporda takip eden ekipler kesinti sırasında çok daha az kaosla çalışır. Hedefi dakikayla tanımlayın, cümleyle değil.

Erken duyurunun bir yan faydası, kesintiyi henüz fark etmemiş müşterilere sorun yaratmayacağı korkusudur ve bu korku genellikle yersizdir. Bir şeyin bozuk olduğunu ilk fark eden kişi, ekranın karşısındaki kullanıcıdır; siz duyurmadığınızda o kişi sorunun kendisinde olduğunu düşünür, tarayıcı değiştirir, şifresini sıfırlar ve sonunda destek talebi açar. Sorunu müşteriye önce sizin söylemenizin mantığını proaktif müşteri desteği yazısında genişçe anlatıyoruz.

Bir kesinti duyurusunda ne yazar, ne yazmaz?

Duyuru bir özür metni değil, bir durum bildirimidir. Uzunluğu kısa, dili düz olmalı; müşteri o metni okumaya değil, taramaya gelir. Aşağıdaki yedi bileşen hem ilk duyuru hem sonraki güncellemeler için aynı iskeleti verir.

• Etki cümlesi: Neyin çalışmadığı, kullanıcının gördüğü dille: giriş yapılamıyor, sipariş kaydedilmiyor, rapor açılmıyor.
• Kapsam: Kimin etkilendiği; tüm kullanıcılar mı, bir bölge mi, tek bir modül mü. Kapsamı yazmamak en pahalı ihmaldir.
• Çalışmaya devam edenler: Etkilenmeyen bileşenler. Bu satır, etkilenmeyen müşterilerin destek talebi açmasını tek başına engeller.
• Geçici çözüm: Varsa alternatif yol; mobil uygulamadan devam edilebiliyorsa, dosyayı sonra yükleme seçeneği varsa burada yazar.
• Şu anki durum: Araştırılıyor, sebep tespit edildi, düzeltme uygulanıyor, izleniyor. Dört kelimelik bu skala herkese aynı şeyi anlatır.
• Müşterinin yapmaması gereken: Siparişi tekrar göndermeyin, ödemeyi yinelemeyin. Bu satır olmadığında kesinti bittiğinde mükerrer kayıt temizlemekle uğraşırsınız.
• Sonraki güncelleme: Saatiyle. Yeni bilgi olmasa bile o saatte yazacaksınız.

Yazılmaması gereken tek şey ise sebep tahminidir. Kesinti sırasında ilk akla gelen sebep çoğu zaman yanlış çıkar ve halka açık bir sayfada verilen yanlış sebebi geri almak, hiç sebep vermemekten çok daha pahalıdır. Aynı mantığı bireysel müşteri iletişiminde de kuruyoruz; ayrıntısı müşteriye kötü haber verme yazısında.

Güncelleme ritmi nasıl kurulur?

Kesinti sırasında en pahalı seçenek sessizliktir. 10.20'de yayınlanan duyuru ile 11.45'te gelen ikinci duyuru arasındaki bir saat yirmi beş dakika, bütün destek talebi yığınının üretildiği yerdir. Ritim, gelişmeye göre değil, taahhüde göre kurulur: her duyuruda bir sonraki güncelleme saatini yazarsınız ve o saate uyarsınız.

Pratik aralık şiddete göre değişir. Tam kesintide yarım saatte bir, kısmi kesintide saatte bir, performans düşüşünde birkaç saatte bir yazmak çoğu ekip için sürdürülebilir. Aralığı kısa tutmaktan çok, verdiğiniz aralığa sadık kalmak önemlidir; kaçırılan bir güncelleme saati, müşteriye kesintinin kontrolden çıktığını söyler.

Yeni bilgi yokken ne yazılır?

Boş güncelleme diye bir şey yoktur, kötü yazılmış güncelleme vardır. Elinizde ilerleme olmasa bile söyleyebileceğiniz üç şey vardır: neyi elediğinizi, şu anda hangi ekibin ne üzerinde çalıştığını ve bir sonraki güncellemenin ne zaman geleceğini. "Çalışmalar sürüyor" cümlesi bunların hiçbirini söylemez; "veritabanı tarafını elediğimizi, şimdi ödeme sağlayıcısıyla görüştüğümüzü" söyleyen bir cümle ise ilerleme olmadan da bilgi taşır.

Şiddet seviyelerini nasıl tanımlarsınız?

Seviye tanımları sıfat üzerine kurulduğunda işe yaramaz; "kritik" ve "yüksek" herkes için farklı şey demektir. Çalışan tanım, seviyeyi iki somut sonuca bağlar: kim uyanır ve hangi kanal kullanılır.

Seviye	Ne demek	Duyuru ve devreye girenler
Tam kesinti	Ana hizmet hiçbir kullanıcı için çalışmıyor	Durum sayfası, e-posta, kritik hesaplara telefon; nöbetçi ekip ve yönetici
Kısmi kesinti	Bir modül veya bir bölge çalışmıyor	Durum sayfası ve etkilenen hesaplara e-posta; nöbetçi ekip
Performans düşüşü	Çalışıyor ama yavaş, hatalar aralıklı	Durum sayfasında bileşen notu; ekip içi kanal
Planlı bakım	Önceden ilan edilmiş pencere	Önceden e-posta ve sayfada takvim; bakım sorumlusu
Tekil sorun	Yalnızca bir hesabı etkileyen durum	Durum sayfasına konmaz; doğrudan destek talebi

Tablonun son satırı en çok tartışılanıdır ve orada kalması gerekir. Tek bir hesabı ilgilendiren sorun durum sayfasına yazıldığında sayfa gürültüye döner, gürültülü sayfa da okunmaz. Seviye eşiği aşıldığında doğru kişiye otomatik olarak haber gitmesinin kurgusunu yükseltme otomasyonu yazısında bulabilirsiniz.

Seviyeler arasında en yanlış değerlendirilen, performans düşüşüdür. Sistem tamamen durduğunda kullanıcı durumu anlar ve bekler; sistem yavaşladığında anlamaz, dener, tekrar dener, tarayıcı değiştirir ve sonunda yazar. Yavaşlık çoğu ekipte kullanıcı başına tam kesintiden daha fazla destek talebi üretir. Bu yüzden performans düşüşünü sayfaya yazmayan ekipler, aslında en çok talep üreten olay tipini gizlemiş olur.

Durum sayfası nerede durmalı?

Bu, en sık yapılan ve en sessiz cezalandırılan hatadır: durum sayfasını, durumunu bildirdiği sistemin üstüne kurmak. Ana uygulamanız çöktüğünde aynı sunucudaki sayfa da çöker; alan adınızın DNS'i etkilendiğinde alt alan adında duran sayfa da açılmaz. Sayfanın bağımsızlığı teknik bir ayrıntı değil, sayfanın var olma sebebidir.

Pratik kural, durum sayfasını ayrı bir barındırma ortamında ve mümkünse ayrı bir alan adında tutmak, sayfanın adresini de fatura altına, sözleşmeye ve destek imzalarına önceden yazmaktır; kesinti anında kimse adres aramamalıdır. Aynı bağımsızlık mantığının veri tarafındaki karşılığını yedekleme ve felaket kurtarma yazısında ele alıyoruz.

Duyuruyu kim yazar, kim onaylar?

Kesinti sırasında iki rol birbirinden ayrılmalıdır: sorunu çözen ile durumu anlatan. Aynı kişi ikisini birden yaptığında ya duyuru gecikir ya çözüm yavaşlar. Küçük ekiplerde bu iki ayrı departman demek değildir; o gün nöbette olan iki kişi demektir.

Onay konusu ise çoğu ekibin ilk duyuruyu geciktirme sebebidir. Her cümleyi yönetime veya hukuka okutmak barış zamanında makul, kesinti sırasında felakettir. Çözüm, metni değil şablonu onaylatmaktır: sakin bir günde üç şablon yazılır, onaylanır ve kesinti anında yalnızca boşlukları doldurulur. Marka düzeyine büyüyen olaylarda izlenecek geniş çerçeveyi kriz iletişimi yazısında anlattık.

Dilin kendisi de bir onay meselesidir. Duyuruda sistemin iç adını değil müşterinin bildiği adı kullanın; kuyruk servisi çöktü demek yerine sipariş onayları gecikiyor deyin. Edilgen cümlelerden kaçının, çünkü "bir kesinti yaşanmıştır" cümlesi kimsenin sahiplenmediği bir olay izlenimi bırakır. Kısa, öznesi belli, kullanıcının ekranda gördüğü şeyi tarif eden cümleler hem daha hızlı yazılır hem daha az soru üretir.

Herkese mi duyurulur, yalnızca etkilenenlere mi?

Durum sayfası çeken bir kanaldır: merak eden gelir, bakar. Bildirim ise iten bir kanaldır ve her itme bir maliyet üretir. Etkilenmeyen bir müşteriye gönderilen kesinti e-postası, ona kesintinizi hatırlatır ve bir dahaki gerçek uyarınızın okunma ihtimalini düşürür. Uyarıların nasıl körelttiğini bildirim yorgunluğu yazısında ayrıntılı ele aldık.

İşleyen kurgu katmanlıdır. Uygulama içi şerit yalnızca o sırada sistemi kullanmaya çalışan kişiye görünür ve en isabetli kanaldır. E-posta bildirimi abone olanlara gider. Sözleşmesinde taahhüt bulunan hesaplara ise doğrudan, isimle yazılır; bu grubun listesi kesinti başlamadan hazır durmalıdır. Taahhüdün nasıl yazıldığı ve neyi kapsadığı müşteri sözleşmesinde hizmet seviyesi yazısının konusudur.

Kesinti sırasında ödediğiniz asıl bedel dakikalar değil, o dakikalar boyunca müşterinin kendi müşterisine ne söyleyeceğini bilememesidir.

Şeffaflığın sınırı nerede?

Yaygın tavsiye her şeyi duyurmayı söyler; bu tavsiyenin sınırı var. Üç dakikalık her dalgalanmayı sayfaya yazan ekipler, sayfayı okunmaz hâle getirir ve abone listesi zamanla ölür. Eşiği önceden tanımlayın: kaç kullanıcıyı, kaç dakika etkileyen olay sayfaya çıkar. Eşiğin altında kalanı ekip içinde kaydedin, dışarı taşımayın.

Ters yönde yapılan hata daha tehlikelidir. Geçmişi yeşil tutmak için gerçek kesintileri sayfaya yazmayan şirket, kesintiyi yaşayan müşteriye "tüm sistemler çalışıyor" yazan bir sayfa gösterir ve o an sayfanın bütün değeri sıfırlanır. Basit ölçüt şudur: müşteriler fark ettiyse sayfaya çıkar. Durum sayfası bir karne değildir. Güvenlik olayları ise ayrı bir başlıktır; orada yalnızca doğrulanmış bilgiyi paylaşın ve kişisel veri söz konusuysa bildirim yükümlülükleri için kendi durumunuza göre hukuk danışmanınıza danışın.

Kesinti bittikten sonra ne olur?

Kapanış duyurusu tek başına yeterli değildir; ardından bir olay raporu gelir. Raporun içeriği kısadır: ne oldu, kimi ne kadar süre etkiledi, neden oldu, ne değiştiriyoruz ve neyi bilerek değiştirmiyoruz. Son madde alışılmadıktır ama en güven vereni odur, çünkü her kesintiden sonra her şeyi değiştirdiğini söyleyen bir şirkete kimse inanmaz.

Raporu kimin okuduğunu bilmek üslubu belirler. Bu metin sizin mühendisiniz için değil, karşı taraftaki bilgi işlem sorumlusu ve satın almacı için yazılır; tedarikçi değerlendirme dosyasına konur ve bir sonraki yenileme görüşmesinde açılır. Bu yüzden teknik ayrıntıdan çok, alınan önlemin tarihi ve sorumlusu önemlidir. Bir daha olmayacak cümlesini yazmayın; neyi değiştirdiğinizi yazın. Kesinti sırasında müşterinin kendi başına ilerleyebilmesi için bilgi bankanızın ne kadar hazır olduğunu ise self servis destek ve bilgi bankası yazısında ölçüyoruz.

Ölçmeye değer dört sayı var. İlk duyuruya kadar geçen süre iletişim tarafının tek gerçek performans göstergesidir. Duyuru başına açılan destek talebi sayısı, sayfanın işini yapıp yapmadığını söyler; iyi bir duyurudan sonra bu sayı düşer. Abone sayısındaki değişim, sayfanın gürültüye dönüşüp dönüşmediğinin erken uyarısıdır. Olay raporunun kesintiden kaç gün sonra yayınlandığı ise sözünüzü tutup tutmadığınızın ölçüsüdür.

Nereden başlamalı?

Bir öğleden sonrada kurulabilecek asgari sistem şudur: ayrı bir yerde duran basit bir durum sayfası, üç onaylı şablon, beş satırlık bir şiddet tablosu, taahhütlü hesapların hazır listesi ve nöbet sırasındaki iki isim. Ardından bunu gerçek bir kesinti beklemeden bir tatbikatla deneyin; ilk duyurunun kaç dakikada çıktığını ölçün ve o sayıyı hedefe bağlayın. Kesinti, veri kaybı ve kilit kişi riskini birlikte planlamanın çerçevesini iş sürekliliği planı yazısında bulabilirsiniz.

Kesinti iletişiminin zor tarafı metin yazmak değil, kimin etkilendiğini kesinti anında bilmektir. Rocketly'de müşteri kayıtları, iletişim geçmişi, görev ve hatırlatmalar ile ekip notları aynı yerde durduğu için etkilenen hesap listesini dakikalar içinde çıkarabilir, ücretsiz hesap açarak kendi duyuru akışınızı kurabilirsiniz.