YAZILIM GELİŞTİRME
Yazılımda Bildirim Tasarımı: E-posta, SMS ve Uygulama İçi Ne Zaman?
Her olayı her kanala göndermek kullanıcıyı yorar ve maliyeti artırır. Olayın aciliyetine, kullanıcı tercihine ve maliyete göre e-posta, SMS ve uygulama içi bildirim arasında karar vermenin bir yöntemi.
İçindekiler
Bir yazılımda bildirim tasarlarken ilk refleks genellikle "her önemli olayda kullanıcıya haber verelim" olur. Oysa asıl soru teknik değil, karar sorusudur: bu olay gerçekten bildirime değer mi, değerse hangi kanaldan gitmeli? Aynı olayı e-posta, SMS ve uygulama içi bildirime birden göndermek, kullanıcıyı bilgilendirmek yerine yorar; zamanla kullanıcı tüm bildirimleri kapatır ve gerçekten önemli olanı da kaçırır.
İyi bir bildirim tasarımı, her olay türünü dört ölçüte göre bir kanala bağlar: aciliyet, kullanıcının tercihi, maliyet ve yarattığı gürültü. Aşağıda bu kararı veren bir yöntem, olay-kanal eşlemesi için temsili bir tablo ve bildirim yorgunluğunu azaltmanın yolları var.
Önce olayı sınıflayın, sonra kanalı seçin
Kanal seçimi olayla başlar. Bir olayın kullanıcının hemen harekete geçmesini mi gerektirdiğini, yoksa sadece kayıt amaçlı mı olduğunu belirleyin. Hemen aksiyon isteyen ve kaçırılması maliyetli olaylar (güvenlik, zamana duyarlı onaylar) daha ısrarcı kanallara; bilgilendirici ve beklemeye uygun olaylar daha sessiz kanallara gider. Aşağıdaki eşleme temsilidir; her projenin kullanıcı kitlesine ve olay setine göre yeniden kararlaştırılması gerekir.
| Olay türü | Uygun kanal | Aciliyet |
|---|---|---|
| Giriş doğrulama / güvenlik kodu | SMS veya uygulama içi anlık | Yüksek |
| Onay bekleyen talep (sorumluya) | Uygulama içi + e-posta | Orta-yüksek |
| Sipariş/işlem durumu değişti | E-posta, kritikse SMS | Orta |
| Haftalık özet / bilgilendirme | E-posta (digest) | Düşük |
| Sistem içi küçük güncelleme | Yalnızca uygulama içi | Düşük |
Bildirim yorgunluğunu tasarımla azaltın
En büyük risk, az bildirim değil çok bildirimdir. Kullanıcı gereğinden fazla bildirim alınca hepsini görmezden gelmeye başlar; bu noktadan sonra kritik bir uyarı bile kaybolur. Çözüm, her olayı anında göndermek yerine hangi olayın anlık, hangisinin toplu (digest) gitmesi gerektiğine karar vermek ve kullanıcıya kontrolü bırakmaktır.
- Anlık mı, digest mi? Zamana duyarlı olaylar anında; birikebilen bilgilendirmeler saatlik/günlük özet olarak gitsin.
- Aynı olaya iki kanaldan birden bildirim göndermekten kaçının; kanalları tamamlayıcı kullanın, tekrar için değil.
- Kullanıcıya kanal ve sıklık tercihi (opt-out) sunun; hangi bildirimi hangi kanaldan alacağını seçebilsin.
- Benzer olayları gruplayın: on ayrı "yeni yorum" yerine tek "10 yeni yorum" bildirimi daha az yorar.
Maliyeti ve teslim güvenilirliğini hesaba katın
Kanal seçimi yalnızca deneyim değil, maliyet kararıdır da. SMS mesaj başına ücretlidir ve çoğu ülkede ticari SMS için açık izin (onay) gerekir; bu yüzden SMS'i yüksek aciliyetli, gerçekten gereken olaylara ayırmak hem bütçeyi korur hem de yasal tarafı rahatlatır. E-posta ve uygulama içi bildirim birim maliyeti düşük kanallardır, ancak teslim güvenilirliği kanaldan kanala değişir.
- SMS: mesaj başına ücretli ve onay gerektirir; anlık teslim güçlü ama maliyet nedeniyle yalnızca kritik olaylar için düşünün.
- E-posta: ucuz ve ayrıntıya uygun, ancak spam filtresi veya gecikme olabilir; kritik olaylarda tek kanal olarak güvenmeyin.
- Uygulama içi: maliyeti düşük, ama kullanıcı uygulamayı açmazsa görülmeyebilir; zamana duyarlı olaylarda tek başına yeterli olmayabilir.
UYGULAMA ÖZETİ
Bildirim tasarımı kontrol listesi
Kanal kararı
- Her olay aciliyetine göre sınıflandı.
- Her olaya tek bir birincil kanal atandı.
- Anlık mı digest mi kararı verildi.
Kullanıcı ve maliyet
- Kullanıcıya kanal/sıklık tercihi ve opt-out sunuldu.
- SMS yalnızca kritik, onaylı olaylarla sınırlandı.
- Kritik olaylarda teslim güvenilirliği planlandı.
SSS
Sık sorulan sorular
Aynı olayı hem e-posta hem SMS hem uygulama içi göndermek iyi değil mi?
Genellikle değil. Aynı olayı her kanaldan birden göndermek bilgilendirme değil tekrar üretir ve kullanıcıyı yorar. Kanalları tamamlayıcı kullanın: örneğin kritik bir olayda uygulama içi + e-posta birlikte anlamlı olabilir, ama her olayı üç kanala birden koymak bildirim yorgunluğuna yol açar.
SMS'i ne zaman tercih etmeliyim?
SMS'i yüksek aciliyetli ve kaçırılması maliyetli olaylara ayırın; örneğin giriş doğrulama kodu veya zamana duyarlı kritik uyarılar. SMS mesaj başına ücretlidir ve ticari kullanımda açık izin gerektirir, bu yüzden düşük öncelikli bilgilendirmeler için uygun değildir.
Digest (toplu) bildirim ne zaman mantıklı?
Olay zamana duyarlı değilse ve birikebiliyorsa digest uygundur; örneğin "bugün gelen 8 yeni yorum" tek bir özet olarak gidebilir. Anında aksiyon gerektiren olaylar ise beklemeden gitmelidir. Kararı olayın aciliyetine göre verin, her şeyi aynı sıklıkta göndermeyin.
BİRİNCİL KAYNAKLAR
Kaynaklar ve İleri Okuma
- Google — Faydalı, güvenilir, insan öncelikli içerik (yeni sekmede açılır)
Bildirim kararlarını kullanıcı değeri ve gereksiz gürültüyü azaltma üzerinden vermek.
YAZAR
Next Medya Strateji ve Teknoloji Ekibi
Özel yazılım ve iş süreçleri
Next Medya ekibi; özel yazılım projelerinde bildirim akışlarını kullanıcı deneyimi, maliyet ve teslim güvenilirliğiyle birlikte ele alır. Bu rehberlerdeki senaryolar, karar yöntemini açıklayan temsili örneklerdir.
İLGİLİ HİZMET
İş akışı ve onay sistemiSONRAKİ OKUMA
İlgili diğer analizler
YAZILIM GELİŞTİRME
Web Formundan CRM’e Nitelikli Talep Akışı
Web formu ve CRM arasında alan eşleme, mükerrer kayıt, talep sahibi ve satış aşamalarını planlayın. Kesinti ve tekrar durumları için kontrol listesi kullanın.
Okumaya devam edinYAZILIM GELİŞTİRME
Ürün Konfigüratöründe Seçenek ve Fiyat Kuralları
Ürün konfigüratöründe uyumsuz seçenekleri, üretim kısıtlarını, fiyat sürümünü ve teklif onayını tasarlayın. Temsili örnek ve kabul matrisiyle kapsamı belirleyin.
Okumaya devam edinBildirim akışınızı birlikte tasarlayalım
Hangi olayın hangi kanala gideceğini, tercih ekranını ve teslim güvenilirliğini projenizin ihtiyaçlarına göre birlikte kararlaştıralım.
Projenizi görüşelim