Üç adresin görevini ayırın

Gönderen, sitenin bildirimi hangi kimlikle oluşturduğunu; alıcı, bildirimi işletmede kimin işleyeceğini; yanıt adresi ise cevap için önerilen hedefi belirler. RFC 5322, Reply-To varsa yanıt hedefinin bu alandan alınabileceğini, yoksa varsayılan hedefin From olduğunu açıklar. Teknik tanımı inceleyin. Bu ayrım teslim garantisi değildir; posta uygulamasında gerçek davranış ayrıca kontrol edilir.

Örnek: ihracat talebini yanıtlamak

Temsili bir üreticide bildirim, işletmenin yetkilendirdiği web sitesi posta adresinden satış kutusuna gelir. Ziyaretçinin formda yazdığı e-posta, yanıt adresidir. Konu satırı “Web talebi · vana serisi · EN” gibi kısa bir bağlam taşır; gövdede dil, ilgili ürün ve müşterinin mesajı ayrı görünür. Ekip yanıt penceresini açtığında alıcıyı kontrol eder. Ziyaretçi adresi hatalıysa sistem bunun çalışan bir posta kutusu olduğunu varsaymaz.

İç bildirim ile müşteriye teyidi karıştırmayın

İşletmeye giden bildirim ve müşteriye giden alındı mesajı iki farklı yazışmadır. Müşteri teyidine yanıt verilebilmesi isteniyorsa oradaki hedef, takip edilen işletme kutusu olmalıdır. İç yönlendirme notlarını veya başka kişilerin iletişim bilgilerini teyit mesajına taşımayın. Türkçe ve İngilizce teyit metinlerinde yalnız gerçekten verilen hizmeti ve ekibin uygulayabildiği dönüş süresini yazın; otomatik bir mesajı kişisel değerlendirme gibi sunmayın.

Ajansa verilecek kabul testi

  • Kontrolünüzdeki iki ayrı test adresinden birer talep oluşturun.
  • Bildirimin beklenen işletme kutusuna geldiğini kontrol edin.
  • “Yanıtla” penceresini açıp hedef adresi gönderimden önce okuyun.
  • Deneme cevabının ilk test kutusuna ulaştığını doğrulayın.
  • Müşteri teyidi varsa ona verilen cevabın işletmeye dönmesini de sınayın.
  • Yanlış yazılmış adresi ve eksik e-posta alanını ayrı hata senaryoları olarak kaydedin.

Ekran görüntüsünde test adreslerini gerektiği kadar maskeleyin; gerçek müşteri verisini test malzemesi yapmayın.

Sahipliği belirleyin

Bir ortak posta kutusunun olması, her talebin bir sorumlusu olduğu anlamına gelmez. Kimin yanıtlayacağı, izin günlerinde kimin devralacağı ve kapanan taleplerin nasıl işaretleneceği yazılı olsun. İlk yayın kontrolüne bu iki yönlü denemeyi ekleyin; form sağlayıcısı veya posta ayarı değiştiğinde tekrarlayın. Tekrar gönderme durumunu ayrıca form teyidi rehberimizde ele alıyoruz. Web tasarım kapsamına bu iletişim kontrolünü somut teslim maddesi olarak ekleyebilirsiniz.

Teslim notunda iki ayrı satır açın: “İç bildirim yanıtı müşteriye” ve “Müşteri teyidi yanıtı işletmeye”. Her satıra beklenen kutuyu, deneme tarihini ve kontrol eden kişiyi yazın. Böylece ekip değiştiğinde ayarın neden böyle kurulduğu anlaşılır. Deneme e-postasının alınması ile gerçek müşterinin yanıtı okumasını aynı başarı ölçüsü olarak kaydetmeyin; ikincisi bu kontrolün kanıtlamadığı ayrı bir durumdur.

Sık sorulan sorular

Reply-To ayarı mesajın teslim edildiğini kanıtlar mı?

Hayır. Yanıt hedefini tanımlar; teslim ve ekip tarafından işlenme ayrıca doğrulanır.

Her talebi otomatik olarak yanıtlamak gerekir mi?

Hayır. Alındı teyidi ile kişisel yanıtı ayırın ve yalnız işletmenin gerçekten takip edebildiği akışı kurun.

Kaynaklar ve ileri okuma

RFC 5322 — Originator fields (3.6.2) ↗
Web tasarım & geliştirmeBu hizmeti konuşalım ↗