Onay ve İşlem E-postalarında Kullanıcı Deneyimi
Sipariş onayı, şifre sıfırlama, kargo bildirimi. Bu e-postalar bültenlerden çok daha yüksek oranda açılır, çünkü kullanıcı onları bekleyerek gelen kutusuna bakar. Buna rağmen metinleri çoğu kurumda geliştirme sırasında hızlıca yazılmış taslak olarak kalır, bir daha kimse dönüp bakmaz.
Gönderen adı ve konu satırı
Kullanıcının çoğu zaman gördüğü tek şey bu ikisidir. Mobil istemcilerin liste görünümü konu satırının ilk kırk karakter kadarını gösterir, gerisi kesilir. Dolayısıyla ayırt edici bilgiyi sona koymak onu saklamakla aynı şeydir.
Siparişiniz alındı (#48213) satırı, Siparişiniz başarıyla alınmıştır, teşekkür ederiz satırından her ölçüde daha iyidir: aynı yerde hem işlemi hem kaydın numarasını söyler, nezaket cümlesi ise gövdede zaten yerini bulur. Gönderen adı da marka adını taşımalı. no-reply@ adresinin kendisi sorun değil, ama görünen ad olarak "noreply" yazan bir kutudan gelen mesaj, kullanıcının aradığı anda hatırlayamayacağı bir mesajdır.
İlk ekranda ne olmalı
Kullanıcı e-postayı açtığında tek bir soruyla gelir: işlem oldu mu, olmadı mı. Cevap ilk cümlede verilmeli. Takip numarası, tutar ve destek bağlantısı hemen ardından gelir. Pazarlama metni, öneri listesi, sosyal medya ikonları varsa en altta durur, çünkü bunlar kullanıcının değil gönderenin önceliğidir.
Bir noktayı özellikle ayırmak gerekiyor: işlem detayı e-postanın gövdesinde yazılı olmalı, yalnızca bir bağlantının arkasında değil. "Detaylar için tıklayın" diyen bir onay e-postası, iki yıl sonra o URL 404 döndüğünde hiçbir şey ifade etmez. Kullanıcının elinde kalan tek kayıt o mesajdır.
Kaç e-posta göndermeli
"Mesaj sayısını azaltın" tavsiyesi tek başına işe yaramıyor, çünkü azaltma kararının ölçütünü vermiyor. Ölçüt şu: her e-posta, kullanıcının başka türlü göremeyeceği bir durum değişikliğine karşılık gelmeli.
Sipariş alındı bilgisi bu testi geçer, kullanıcı ödemenin geçtiğini başka yerden bilemez. Kargoya verildi bilgisi geçer. "Siparişiniz hazırlanıyor", "Siparişiniz hâlâ hazırlanıyor" türü ara bildirimler geçmez; bunlar durum değil, gönderenin kendini hatırlatma isteğidir. Üç gün boyunca her sabah aynı kargo durumunu tekrarlayan bir sistem, dördüncü gün gerçekten önemli olan mesajı da okunmadan silinen yığının içine koyar.
Teslimat süresi bir tasarım meselesidir
Metin ne kadar iyi olursa olsun, e-posta geç gelirse işe yaramaz. Burada iki pratik mesele var ve ikisi de arayüz tarafında değil, kodun içinde çözülür.
Birincisi gönderimin nereden tetiklendiği. Onay e-postasını sipariş kaydının yazıldığı veritabanı işleminin içinden göndermeyi değil, kuyruğa bırakıp işlemi kapatmayı tercih ederim; SMTP sunucusu yavaşladığında kullanıcı ödeme ekranında beklemek zorunda kalmasın, daha kötüsü zaman aşımı yüzünden tamamlanmış bir sipariş geri alınmasın.
İkincisi süreli bağlantılar. Şifre sıfırlama bağlantısına on beş dakika ömür vermek yaygın bir alışkanlık, ama bu süre teslimat gecikmesini hesaba katmıyor. Alıcı sunucu greylisting uyguluyorsa ilk deneme reddedilir ve ikinci deneme beş ila on beş dakika sonra yapılır. Kullanıcıya kalan gerçek süre, on beş dakikadan gecikmenin düşülmüş hali olur ve sonuç çoğu zaman tıklandığı anda süresi dolmuş bir bağlantıdır. Doğru yaklaşım, süreyi yuvarlak bir sayıdan değil kendi gönderim kayıtlarınızdaki tetikleme-teslimat farkının üst dilimlerinden türetmek. Ölçmediğiniz bir süreyi kısaltmak güvenlik sağlamaz, sadece destek talebi üretir.
Gelen kutusu kullanıcının arşividir
İnsanlar bir siteye geri dönmek istediğinde arama motoruna değil, kendi gelen kutusuna yazıyor. Eski siparişi, rezervasyonu, fatura numarasını orada arıyor. Bu, işlem e-postalarının en çok hafife alınan işlevi.
Pratik karşılığı şu: gönderen adı zaman içinde sabit kalmalı, konu satırı kullanıcının arayacağı kelimeyi içermeli (ürün adı, rezervasyon kodu, şehir), gövdedeki özet de o mesajı tek başına anlaşılır kılmalı. Altı ay sonra "bilgilendirme" konulu yüz e-posta arasından doğru olanı bulmak imkânsızdır. Marka adıyla sipariş numarasını taşıyan tek bir satır bu işi bitirir.