12 Ara 2025·7 dk
Kullanıcıların gerçekten güvendiği bakım mesajı şablonları
Planlı kesinti, kısmi arıza ve düşük performans sırasında kullanıcıları sakinleştiren bakım mesajı şablonları. Panik ve destek taleplerini azaltır.
Planlı kesinti, kısmi arıza ve düşük performans sırasında kullanıcıları sakinleştiren bakım mesajı şablonları. Panik ve destek taleplerini azaltır.
Çoğu bakım bildirimi tek bir nedenle başarısız olur: belirsizlik yaratır. Sadece “Bakım yapıyoruz” diyen bir bant, kullanıcıları neyin bozulduğunu, ne kadar süreceğini ve işlerinin güvende olup olmadığını tahmin etmeye zorlar. Tahmin korkuya dönüşür, korku da destek taleplerine.
Belirsiz mesajlar ayrıca şüphe uyandırır. Kullanıcılar hatalar görürken mesajınız sakin ve genel görünüyorsa, gerçek problemi sakladığınızı düşünürler. Deneyimledikleri şeyle söyledikleriniz arasındaki bu boşluk güveni yıkar.
İnsanlar genellikle hemen üç şeye ihtiyaç duyar: net etki, net zamanlama ve net sonraki adımlar.
Etkiden kasıt hangi özelliğin etkilendiğini adlandırmaktır (giriş, dışa aktarmalar, ödemeler), sadece “hizmet kesintisi” demek değil. Zamanlama, belirli bir pencere ve bir sonraki güncellemenin ne zaman yapılacağı demektir, “kısa süre içinde” değil. Sonraki adımlar ise beklerken ne yapmaları gerektiğini söylemektir: örneğin “20 dakika sonra tekrar deneyin” veya “onun yerine mobil uygulamayı kullanın.”
Aşırı söz vermek işleri kötüleştirmenin en hızlı yoludur. “Etki beklenmiyor” yalnızca gerçekten eminseniz risklidir. Bir kullanıcı bile etkileniyorsa, bu ifade ilginizi göstermediğinizin kanıtı olur. Dürüst güncellemeler daha iyi çalışır: bildiğinizi, henüz bilmediğinizi ve bir sonraki kontrolü ne zaman yapacağınızı söyleyin.
Amaç hikâye çevirmek değil. Amaç belirsizliği azaltmaktır. İnsanlar ne olduğunu, bunun onlar için ne anlama geldiğini ve şimdi ne yapmaları gerektiğini anladığında yenilemeyi bırakır, en kötüsünü varsaymayı bırakır ve kontrolü sağlamak için bilet açmaktan vazgeçer.
Kullanıcılar durumu düz ve anlaşılır kelimelerle duyunca rahatlar. Her şeyi “bakım” veya “sorun” diye adlandırırsanız, insanlar en kötüsünü varsayar ve tekrar denemeye, sayfayı yenilemeye ve destek açmaya başlar.
Doğru etiketle başlayın:
“Düşük performans” asla belirsiz olmamalı. Kullanıcının ne fark edeceğini söyleyin. Örneğin: “Dışa aktarmalar normalden 10–20 dakika daha uzun sürebilir” demek, “Düşük performans yaşanıyor” demekten daha açıktır.
Etkilenenleri kısa bir liste bile olsa açıkça belirtin. İnsanların en çok önem verdiği alanları (giriş, ödemeler ve faturalandırma, senkronizasyon, bildirimler, panolar, dışa aktarmalar, API erişimi, dosya yüklemeleri) anın.
Korkutucu kelimelerden kaçının ama gerçeği saklamayın. “Kritik arıza”nın yerine “bazı kullanıcılar giriş yapamıyor” diyebilir, “sistem kararsızlığı”nın yerine “kaydetme sırasında zaman aşımı görebilirsiniz” diye yazabilirsiniz. Sakin bir ton iyimserlikten değil doğruluktan gelir.
Emin değilseniz, dahili sebepten ziyade kullanıcı etkisine uyan etiketi seçin. “Veritabanı bakımı” çoğu insan için az şey ifade eder. “Faturalandırma sayfası en fazla 15 dakika kullanılamayabilir” ne bekleyeceklerini ve ne yapmaları gerektiğini anlatır.
Kullanıcılar, engellendikleri anda görebildikleri şeye güvenirler. İyi şablonlar kelime oyunlarından çok doğru yüzeyi kullanmakla ilgilidir.
Çoğu planlı iş için uygulama içi bir bant kullanın. İnsanlar yapabildiklerini yapmaya devam ederken görünür kalır ve ekranı kaplamaz.
Kullanıcı güvenli bir şekilde devam edemeyecekse (faturalandırma işlemleri, veri düzenlemeleri, kayıtlar) yalnızca modal kullanın. Modal kullanırsanız insanların kapatmasına izin verin ve sonrasında kalıcı bir bant bırakın.
Toast bildirimleri kısa, düşük riskli güncelleştirmeler için uygundur (örneğin: “Dışa aktarmalar 10 dakika boyunca yavaş olabilir”). Kolayca gözden kaçtıkları için gerçek kesintilerde kullanmayın.
Basit bir kural:
Kullanıcılar giriş yapamayacaksa aynı mesajı giriş ekranına koyun. Panik burada başlar, çünkü kullanıcılar hesaplarının bozulduğunu varsayar. Basit bir not: “Giriş 02:00–02:30 UTC arasında başarısız olabilir” bile talepleri hızla azaltır.
Süregelen güncellemeler ve geçmiş için durum sayfanızı kullanın (ne değişti, ne halen etkileniyor, ne düzeldi). Uygulama içi bildirim ise kullanıcının şimdi ne yapması gerektiğini söylemeli (bekleyin, daha sonra tekrar deneyin, dışa aktarmalardan kaçının vb.). Kritik detayları sadece durum sayfasında saklamayın; birçok kullanıcı onu hiç kontrol etmez.
E-posta ve push bildirimleri etki yüksekse ve kullanıcıların plan yapması gerekiyorsa yardımcı olur. Aksi halde gürültülü hissedilir. Gönderirseniz, içerik uygulama içi metinle tutarlı olsun.
Son olarak, destek ekiplerini aynı dilde hizalayın. Otomatik yanıtınız bant metni ve durum güncellemeleriyle eşleşsin ki kullanıcılar karışık mesaj almasın.
Kullanıcılar bakım bildirimlerine spesifik, dürüst ve faydalı olduklarında güvenirler. Bu uzun olmak zorunda değil. Stresli bir kullanıcının ilk 10 saniyede sorduğu sorulara net zamanlama ve bir planla cevap vermektir.
Güvenilir bir bildirim beş temel içerir:
Zaman, mesajların sıklıkla güvenini kaybettiği yerdir. İnsanların anlayacağı bir pencere kullanın: “16 Oca, 01:00–02:30 UTC” gibi. Büyük küresel bir kitleniz varsa, kullanıcıların ortak kullandığı ikinci bir referans zamanı eklemeyi düşünün (örneğin, “08:00–09:30 Singapur saati”). “02:17’de geri döneceğiz” gibi yanlış bir kesinlikten kaçının. “30–60 dakika” gibi bir aralık daha dürüst hissedilir ve sinirli yenileme döngülerini azaltır.
Henüz bilmiyorsanız, bir sonraki kontrolde neye bakacağınızı söyleyin. Örneğin: “Artan veritabanı yükünü araştırıyoruz ve son dağıtımları ile yavaş sorguları inceliyoruz. Bir sonraki güncelleme 14:30 UTC’de.” Bu tek cümle sessizliği bir plana çevirir.
Her zaman bir sonraki güncelleme zamanını ekleyin; hatta çok yakın olsa bile ve hiçbir şey değişmese bile. “Bir sonraki güncelleme 20 dakika içinde” demek, yerine getirilebilir bir söz verdiğiniz için insanları rahatlatır.
Güven oluşturan detay örneği: “Dosya dışa aktarmaları normalden 10–30 dakika daha uzun sürebilir. Bu sırada raporları uygulama içinde görüntüleyebilirsiniz. Bir sonraki güncelleme 16:10 UTC’de yayınlanacak.”
İyi bakım bildirimleri belirli ve tutarlı oldukları için sakin hissedilir. Onları duyuru değil kontrol listesi gibi ele alın.
İlk taslağı net yer tutucularla yazın. Şu konularla başlayın: ne etkileniyor, ne zaman başlıyor, ne kadar sürebilir ve kim etkileniyor. Kesin bitiş zamanı, etkilenen bölgeler, özellik adı gibi daha sonra doğrulayabileceğiniz detaylar için parantez bırakın. Bu, tahminde bulunmadan erken yayınlamanıza olanak verir.
Gerçeklikle eşleşen bir şiddet etiketi seçin. Bant, durum sayfası ve e-postada tek bir etiket kullanıp ona bağlı kalın. Örneğin: Bakım (planlı), Kısmi arıza (bazı kullanıcılar veya özellikler), Düşük performans (yavaş veya gecikmeli). Renk kullanıyorsanız, bunları tutarlı tutun (yeşil = normal, sarı = düşük performans, kırmızı = arıza) ki kullanıcılar hızlıca tarayabilsin.
Etiketin ne anlama geldiğini düz bir cümleyle açıklayan bir satır ekleyin. “Düşük performans” her zaman “dışa aktarmalar 5–15 dakika sürebilir” gibi somut bir anlama sahip olmalı.
Mümkünse bir geçici çözüm sunun. Küçük bir alternatif bile destek taleplerini azaltır. Örnek: “Rapor gerekiyorsa, zamanlanmış dışa aktarmalar gecikiyorsa gösterge panosundan CSV indirimi kullanın.” Geçici çözüm yoksa, bunu netçe bir kez belirtin.
Yayınlamadan önce güncellemelerinizi planlayın. İki hatırlatma planlayın: biri pencere öncesi, diğeri ise “şimdi başladı” mesajı. Zamanlama değişirse önce bildirimi güncelleyin, sonra hatırlatmayı gönderin.
İşi kapatırken son bir güncelleme yapın. Ne değiştiğini, ne zaman düzeldiğini ve bir şey hâlâ yanlış görünüyorsa kullanıcıların ne yapması gerektiğini söyleyin (yenile, tekrar giriş yap veya destekle iletişime geçerken zaman damgası veya iş kimliği gibi belirli bilgileri ekle).
Bu şablonları başlangıç noktası olarak kullanın, sonra kullanıcılarınızın üründe gerçekte ne yaptıklarını dikkate alarak ayrıntıları ayarlayın. Ton sakin ve düz olsun. Kullanıcıların alacağı tek net eylemi verin.
Konu/Başlık: [Gün] [Tarih] [Başlangıç saati] [TZ] tarihinde planlı bakım\n Mesaj: Belirli bir güncelleme yapıyoruz: [Gün, Tarih] tarihinde [Başlangıç saati] – [Bitiş saati] [TZ] arası planlı bakım var.
Bu pencere sırasında [ne kullanılamayacak]. [ne çalışmaya devam edecek] kullanılabilir durumda kalacaktır.
Hazırlık yapmanız gerekiyorsa: lütfen [tavsiye edilen eylem, ör. dışa aktarmaları bitirin, taslakları kaydedin] işlemini [saat] öncesinde yapın. Bu pencere sırasında buradan güncelleme yayınlayacağız.
Başlık: Bakım şimdi devam ediyor
Mesaj: Bakım başladı ve tahminen [Bitiş saati] [TZ] tarihine kadar sürecek.
Şu anda [ne kullanılamaz]. Eğer [yaygın görev] yapmayı denerseniz, [beklenen hata/behaviour] görebilirsiniz.
Bir sonraki güncelleme [saat] (veya bir şey değişirse daha erken).
Başlık: Bakım planlandığından uzun sürüyor
Mesaj: Bakım beklenenden daha uzun sürüyor. Yeni tahmini bitiş zamanı [Yeni bitiş saati] [TZ].
Bu sizin için ne anlama geliyor: [etki tek cümlede]. Şimdi ne yapabilirsiniz: [güvenli geçici çözüm veya “lütfen X sonra deneyin”].
Verdiğimiz rahatsızlıktan dolayı üzgünüz — bir sonraki güncelleme [saat].
Başlık: Bakım tamamlandı
Mesaj: Bakım [saat] [TZ] itibarıyla tamamlandı.
Artık [doğrulamak için en önemli 2–3 eylem, ör. giriş yapma, dışa aktarma çalıştırma, ödeme gönderme] işlemlerini yapabilirsiniz. Hâlâ bir şey yanlış görünüyorsa, [basit adım, ör. yenile/yeniden giriş yap] deneyin ve sonra destekle iletişime geçerken [hangi bilgileri eklemeleri gerektiği, ör. zaman damgası veya ekran görüntüsü] belirtin.
Başlık: Bakım sonrası izleme
Mesaj: Sistemler çevrimiçi ve bir sonraki [X saat] boyunca yakından izleniyor.
Kuyruklar temizlenirken [küçük semptom, ör. daha yavaş yükleme, gecikmiş e-postalar] fark edebilirsiniz. Hata alırsanız [süre] sonra tekrar deneyin.
Bir sonraki güncelleme [saat] (veya bir sorun görürsek daha erken).
Uygulama tamamen kapalı değilken belirsiz bantlar en çok paniğe yol açar. Hangi özelliğin etkilendiğini (özellik, bölge veya adım), neyin çalıştığını ve kullanıcıların şimdi ne yapması gerektiğini açıkça söyleyin.
Kullanın: ürünün çoğu çalışıyor ama bir alan çalışmıyor.
Şablon
Başlık: Kısmi arıza: [özellik/hizmet] [bölgede/hesap tipinde] kullanılamıyor
Gövde: [özellik] bazı kullanıcılar için çalışmıyor. Uygulamanın diğer bölümleri, özellikle [ne çalışıyor], normal şekilde çalışıyor. Ekibimiz çözüm üzerinde çalışıyor.
Etkisi: [hareket] yapmaya çalıştığınızda [hata mesajı/sembol] görebilirsiniz.
Geçici çözüm: Düzeltme yapılana kadar lütfen [güvenli alternatif eylem] yapın.
Sonraki güncelleme: [saat + zaman dilimi] içinde (veya daha erken).
Kullanın: istekler başarılı ama yavaş olduğu için bozuk gibi hissediliyor.
Şablon
Başlık: Düşük performans: [alan] normalden daha yavaş
Gövde: Bazı işlemler normalden daha uzun sürüyor, özellikle [belirli işlemler]. Zaman aşımı veya tekrar deneme görebilirsiniz, ancak veriler kaybolmamalıdır.
Ne yapmalı: Hata alırsanız [X dakika] bekleyin ve tekrar deneyin. Aynı işlemi defalarca tekrarlamaktan kaçının (kopyalar oluşabilir).
Sonraki güncelleme: [saat + zaman dilimi].
Kullanın: en zorlayıcı kısım belirsizlik olduğunda.
Şablon
Başlık: Aralıklı sorun: [özellik] rastgele başarısız olabilir veya bazen çalışabilir
Gövde: [özellik] bazen çalışırken bazen başarısız oluyor. Başarısız olursa, [X dakika] sonra güvenle tekrar deneyebilirsiniz.
Nasıl yardımcı olabilirsiniz: Destekle iletişime geçerseniz [istek ID / zaman aralığı / etkilenen bölge] ekleyin.
Kullanın: kullanıcılar giriş yapamıyorsa. Ton sakin ve doğrudan olsun.
Şablon
Başlık: Giriş sorunları: bazı kullanıcılar oturum açamayabilir
Gövde: [kim etkilendiği] için artmış giriş hataları görüyoruz. Engellendiyseniz şifreyi tekrar tekrar sıfırlamayın; açık bir şifre hatası görmedikçe bunu yapmayın.
Ne denemeli: Bir kez yenileyin, sonra [X dakika] bekleyin ve tekrar deneyin. SSO kullanıyorsanız sorunun yalnızca SSO mi yoksa tüm giriş yöntemleri mi olduğunu not edin.
Kullanın: kullanıcılar verinin eksik olduğunu düşünüyor.
Şablon
Başlık: Veri gecikmesi: [raporlar/senkronizasyon/analitik] [X dakika/saat] geride olabilir
Gövde: Yeni etkinlik [alan] içinde daha uzun sürede görünebilir. Veriler hâlâ toplanıyor, ancak işleme gecikmiş durumda.
Ne anlama geliyor: Bu zaman diliminde oluşturulan dışa aktarmalar/raporlar eksik olabilir. Mümkünse kritik raporları [saat] sonrasına erteleyin.
Sonraki güncelleme: [saat + zaman dilimi].
Bakım sırasında destek patlamalarının çoğu bakımın kendisinden kaynaklanmaz. İnsanların ne olduğunu, nasıl etkilendiklerini ve ne zaman biteceğini tahmin etmeye zorlayan ifade tarzları biletleri artırır. Kullanıcı tahmin yapmak zorunda kalırsa bilet açar.
Panik yaratan kalıplar:
Küçük bir örnek: dışa aktarma aracınız yavaş fakat uygulamanın geri kalanı çalışıyor. Bantınız “Hizmet kesintisi” diyorsa, dışa aktarma yapmayanlar bile durur ve destek bildirir. Eğer “Dışa aktarmalar 10–20 dakika sürebilir; panolar ve düzenleme normal. Bir sonraki güncelleme 14:30 UTC” yazıyorsa birçok kişi beklemeyi tercih eder.
Mesaj şablonları hazırlıyorsanız, üç soruyu hızlıca yanıtlayan sade bir dil hedefleyin: Ne etkileniyor, şu anda ne yapmalıyım ve bir sonraki güncelleme ne zaman gelecek.
Yayınlamadan önce mesajınızı endişeli bir müşteri gibi okuyun. Amaç basit: belirsizliği azaltmak.
Bant, e-posta, destek makroları ve durum mesajları arasında ifade tutarlılığı sağlayın. Biri “düşük performans” diğeri “kapalı” diyorsa, insanlar bir şey saklandığını varsayar.
Ton sakin ve olgusal olsun. Abartı, şaka veya “endişe yok” tarzı ifadelerden kaçının. Basit, steady bir çizgi: “Dışa aktarmaların yavaş olduğunu araştırıyoruz” fazlasıyla iyimser olmaya çalışmaktan daha etkilidir.
Açıklık testi yapın: yeni bir kullanıcı sorunu tek cümlede sizin söylediklerinizden fazlasını tahmin etmeden tekrar edebiliyor mu? Eğer hayırsa, yeniden yazın.
İş bittikten sonra açıkça kapatın: sorunun çözüldüğünü doğrulayın, çözüm zamanını verin ve kullanıcıların ne yapması gerektiğini söyleyin (ör. “Dışa aktarımı tekrar deneyin” veya “Hâlâ hata görüyorsanız yenileyin”).
Sık görülen “her şey bozuk” anı, bir özellik bozulduğu halde uygulamanın geri kalanı iyi göründüğünde yaşanır. Bir finans aracını düşleyin: fatura sayfası yüklenir, faturalar görünür ve ödemeler devam eder. Ancak CSV dışa aktarımları bazı kullanıcılar için zaman aşımına uğramaya başlar. İnsanlar yeniler, tekrar dener ve veri eksik olduğunu varsayıp destek biletleri açar.
İlk mesaj neyin çalıştığını, neyin çalışmadığını, kimlerin etkilendiğini ve şimdi ne yapacaklarını söylemeli. Örnek:
“Faturaları CSV olarak dışa aktarma bazı hesaplar için şu anda zaman aşımına uğruyor. Faturalandırma sayfaları ve ödemeler normal şekilde çalışıyor. Eğer veriye acil ihtiyacınız varsa, ekrandaki filtreleri kullanıp sonuçları kopyalayın ya da daha küçük bir tarih aralığıyla dışa aktarın. Sorunu araştırıyoruz, buradan 15 dakika içinde güncelleme paylaşacağız.”
Sonraki saat boyunca güncellemeler “sorunu tespit ettik”ten “ne değişti”ye doğru evrilmeli:
Son mesaj döngüyü kapatır. Onarımı, kapsamı ve açık destek yolunu içerir:
“Çözüldü: dışa aktarma işleyici kapasitesini artırdık ve zaman aşımı ayarlarını düzelttik. 10:05–11:05 UTC arasında bazı CSV dışa aktarmaları başarısız oldu, ancak faturalandırma ve ödemeler kullanılabilir kaldı. Hala dışa aktarma yapamıyorsanız son biletinize dışa aktarma zamanı ve fatura aralığını ekleyerek cevap verin.”
Böyle iletişim kuran ekipler genellikle daha az destek bileti görür, çünkü kullanıcılar üç şeyi çabucak öğrenir: verileri güvende, şimdi ne deneyebileceklerini ve bir sonraki güncellemenin ne zaman geleceğini.
Bakım iletişimini tek seferlik bir özür değil, küçük bir ürün özelliği gibi ele alın. Amaç tutarlılıktır: kullanıcılar kalıbı tanımalı, ne yapacaklarını bilmeli ve zamanında güncelleme alacaklarına güvenmeli.
En iyi metinlerinizi değişkenlerle yeniden kullanılabilir bloklara çevirin ve herkesin yeniden yazmadan bir bildirimi yayınlayabileceği tek bir yerde saklayın. Başlangıç zamanını, beklenen bitişi, etkilenen özellikleri, bölgeleri ve kimlerin etkilendiğini (tüm kullanıcılar veya bir alt küme) standartlaştırın.
Sahiplik ve basit bir onay akışı yazın. Bir kişi taslak yazar, bir kişi onaylar ve bir kişi yayınlar; küçük ekiplerde bu rollerin iki veya üçü aynı kişi olabilir. Bir güncelleme sıklığı belirleyin (örneğin, bir olay sırasında her 30 dakikada bir) ki destek ne zaman mesaj geleceğini tahmin edebilsin.
“Anlık görüntü” ve “geri alma” dilinde dikkatli olun. Geri alma mümkün ama garanti değilse bunu açıkça söyleyin ve kullanıcının güvenebileceği şeylere odaklanın.
Bu süreci uygulama içinde tekrarlanabilir kılmak istiyorsanız, bir kere teslim noktalarını kurup tekrar kullanmak işe yarar: uygulama içi bir bant bileşeni, hafif bir durum sayfası ve bakım sonrası “her şey tamam” akışı. Eğer ekibiniz Koder.ai (koder.ai) ile ürünler inşa ediyorsa, bu UI parçalarını ve güncelleme akışlarını chat tabanlı bir oluşturma süreciyle yaratabilir, sonra metni ve değişkenleri uygulamayı yeniden inşa etmeden ayarlayabilirsiniz.
Son olarak düşük riskli bir bakım penceresinde kuru koşu yapın. Gerçek şablonları kullanın, gerçek yüzeylere yayınlayın, güncellemeleri zamanlayın ve sonrasında inceleyin:
Bu döngüyü oturttuğunuzda, şablonlar doküman olmaktan çıkar ve bir alışkanlık haline gelir.
Start with what’s affected, how long it will last, and what the user should do right now. A plain line like “Exports may take 10–20 minutes longer; dashboards work normally; next update at 14:30 UTC” prevents guessing and cuts tickets.
Use Maintenance for planned work with a defined window, Partial outage when a specific feature/region is down, and Degraded performance when things work but are slow or error-prone. Pick the label that matches what users feel, not the internal cause.
Write what the user will notice in one sentence, then quantify it if you can. For example: “Exports may take 10–30 minutes and may time out on large date ranges,” instead of “We’re seeing degraded performance.”
Use an in-app banner for most situations so people can keep working. Use a modal only when continuing could cause errors or lost work (like billing actions or data edits), and keep a persistent banner afterward so the message doesn’t disappear.
Put the same message on the login screen whenever sign-in might fail, because that’s where panic starts. If you only post updates inside the app, locked-out users will assume their account is broken and flood support.
Avoid false certainty like “No impact expected” unless you’re truly sure. Say what you know, what you don’t know yet, and when you’ll update next; that honesty reads as competence, not weakness.
Always include a specific next update time, even if nothing changes. “Next update in 20 minutes” sets a promise users can rely on and reduces the refresh-and-ticket cycle.
Give one safe action that reduces risk and duplicates. For example: “Retry once after 2 minutes,” “Avoid repeating the same export,” or “Use a smaller date range,” and if there’s no workaround, say so clearly once.
State what’s affected, what still works, and what to do if they’re blocked. Tell users not to do high-risk actions repeatedly (like password resets or repeated submissions) unless the message specifically tells them to.
Close with an explicit “resolved” note that includes the time, what was restored, and what to try if something still looks wrong (refresh, re-login, retry once). If users may still see edge cases, say you’re monitoring and when you’ll post the final confirmation.