Transactional E-Postayı Kullanıcı İçin Tasarlamak

İşlem e-postaları çoğu ekipte tasarım kapsamının dışında kalıyor, oysa kullanıcı markayla en sık orada karşılaşıyor: sipariş onayı, şifre sıfırlama, kargo bildirimi. Burada iyi tasarım demek, bilginin engellere rağmen yerine ulaşması demek. Engeller de belli: indirilmemiş görseller, eski render motorları, dolu bir gelen kutusu.

Konu satırı e-postanın kendisidir

Kullanıcıların önemli bir kısmı işlem e-postasını açmıyor, gelen kutusu listesinde okuyor. "Siparişiniz onaylandı" bu haliyle yetersiz. "Siparişiniz onaylandı: #12345, 3 ürün, 14 Mart teslim" listeden bakan kişiye aradığı cevabı veriyor ve işini e-postayı hiç açmadan bitiriyor. Bu, açılma oranını düşürür; işlem e-postasında düşmesi gereken oran da zaten odur.

Önizleme metni aynı satırın devamı. Boş bırakıldığında istemci gövdenin ilk cümlesini çekiyor, o da çoğu şablonda "Bu e-postayı görüntüleyemiyorsanız" oluyor. Konu satırının tekrarı değil, tamamlayıcısı olarak yazılmalı.

Görseller kapalıyken geriye ne kalıyor

İstemcilerin çoğu uzak görselleri varsayılan olarak indirmiyor. Sipariş numarasını, tutarı ya da doğrulama kodunu görsele gömen bir şablon, o kullanıcı için bilgiyi tamamen yok ediyor. Kullanıcının ihtiyaç duyduğu her veri metin olarak durur, görsel yalnızca destekler.

Aynı sebeple işlem e-postası modern bir web sayfası gibi kurulmuyor. Bir kısım istemci hâlâ eski render motorlarıyla çalışıyor, harici stil dosyası yok sayılıyor, flex ve grid güvenilmez. Tablo tabanlı yerleşim ve satır içi stil en geniş uyumu veren yol olmaya devam ediyor. Koyu tema ayrı bir kalem: bazı istemciler renkleri kendiliğinden çeviriyor, beyaz zemine gömülü logo koyu arka planda beyaz bir kutu olarak kalıyor.

Test tarafında tek kural var. Gerçekten gönderip bakacaksınız. Tasarım aracının önizlemesi Outlook'un ne yaptığını göstermiyor.

Pazarlamayı buraya karıştırmanın bedeli

İşlem e-postasının açılma oranı yüksek olduğu için pazarlama tarafı sürekli buraya göz koyuyor. Sipariş onayının altına kampanya bloğu iliştirmem, gerekçesi de estetik değil.

Reklam gördüğü e-postayı kullanıcı spam olarak işaretliyor. O işaret, gönderen alan adının ve IP'nin itibarına yazılıyor. Aynı yoldan çıkan şifre sıfırlama e-postası bir sonraki sefer spam klasörüne düşüyor, kullanıcı giriş yapamıyor, destek kaydı açılıyor. Bir kampanya tıklamasının gerçek fiyatı bu.

Ayrım gönderim katmanında kurulur: pazarlama ve işlem trafiği ayrı alt alan adlarından çıkar, itibarları birbirine bulaşmaz. Yasal taraf da farklı yerde duruyor. Pazarlama izni olmayan kullanıcıya kampanya göndermenin adı, sipariş onayının içine konduğu için işlem e-postası olmuyor.

İki kez gelen onay

Kullanıcının "siparişim iki kere mi geçti" diye destek araması genelde tasarım sorunu değil. Gönderim kuyruğu yanıt alamadığında aynı işi yeniden işliyor, gönderim tarafında bir idempotency anahtarı yoksa aynı onay iki kez çıkıyor.

Şablonda sipariş numarasını ve işlem zamanını görünür tutmak durumu en azından teşhis edilebilir yapıyor: kullanıcı iki e-postada aynı numarayı görünce tek sipariş olduğunu anlıyor. Ama çözüm şablonda değil, kuyrukta.

Çıkış ve tercihler

Gerçek işlem e-postasından çıkış diye bir şey yok, şifre sıfırlamayı kullanıcı kendisi tetikliyor. Tartışma, işlem kılığına girmiş bildirimlerde: stok geldi, birisi yorum yaptı, haftalık özet. Bunlar için tercih ekranı gerekli ve tek adımda ulaşılabilir olmalı.

Çıkışı zorlaştırmak kullanıcıyı listede tutmuyor, spam düğmesine yönlendiriyor. Sonuç bir önceki bölümdekiyle aynı yere çıkıyor: teslim edilemeyen şifre sıfırlama e-postası.