Sayıların ardındaki mantık
Bu sayfanın birinci işi bilgi vermektir: sipariş alındı mı, numarası ne, ne zaman gelecek, bir sorun olursa nereye yazılacak. Aynı alanın pazarlama amaçlı kullanımı ayrıdır ve teşekkür sayfası başlığına girer.
Bilgi işlevinin önce gelmesinin sebebi basit: kullanıcı ödeme yaptı ve o an tek bir şey istiyor — işlemin gerçekten gerçekleştiğine dair net bir onay.
Bu onay yeterince net verilmediğinde ortaya çıkan ilk davranış, müşteri hizmetlerine yazmaktır; sayfanın kalitesi doğrudan destek yükünü belirliyor.
Hangi bilgiler bulunmalı?
| Bilgi | Gerekçe |
|---|---|
| Sipariş numarası | Her iletişimde gerekiyor |
| Ne alındığı ve tutar | Doğrulama ihtiyacı |
| Teslimat tarihi | En çok sorulan soru |
| Teslimat adresi | Hata varsa erken yakalanır |
| Sonraki adımlar | Belirsizliği kaldırır |
| İletişim yolu | Sorun anında aranıyor |
Dördüncü satır küçük ama değerli. Adres bu sayfada gösterildiğinde kullanıcı hatayı kargo çıkmadan fark edebiliyor; bu, hem iade hem yeniden gönderim maliyetini önlüyor.
Nasıl kurulur?
- Onayı net verin. İşlemin tamamlandığı belirgin olsun.
- Numarayı öne çıkarın. Kopyalanabilir biçimde.
- Adresi gösterin. Erken düzeltme şansı.
- Sonraki adımı yazın. Ne zaman ne olacak?
- Erişimi kalıcı kılın. Sayfa sonradan da açılabilsin.
Uygulamada ne oluyor?
En sık hata, sayfanın belirsiz bırakılması. Kısa bir teşekkür yazısı dışında hiçbir bilgi yoksa kullanıcı siparişin gerçekten geçip geçmediğinden emin olamıyor ve destek kanallarına yöneliyor.
İkinci gözlem, teslimat tarihinin yazılmaması. Ödemeden sonraki ilk soru bu; cevap sayfada yoksa başka bir yerde aranıyor.
Üçüncüsü, adresin gösterilmemesi. Yanlış adres burada fark edilebilirken kargo çıktıktan sonra öğreniliyor ve iki kat maliyet üretiyor.
Dördüncüsü, sipariş numarasının zor bulunur olması. Kullanıcı her iletişimde bu numaraya ihtiyaç duyuyor; kopyalanabilir ve belirgin olması gerekiyor.
Beşincisi, sayfanın bir daha erişilemez olması. Tarayıcı kapanınca bilgi kayboluyor; sipariş takip bağlantısı e-postayla da gönderilmeli.
Altıncısı, sonraki adımların anlatılmaması. Ne zaman kargoya verileceği ve nasıl haber verileceği yazıldığında müşteri hizmetlerine gelen soruların önemli bir kısmı ortadan kalkıyor.
Yedincisi, ödeme yöntemine göre farklı bilgi gerektiğinin atlanması. Havale seçildiyse hesap bilgileri ve süre, kapıda ödeme seçildiyse hazırlanması gereken tutar burada olmalı.
Sekizincisi, iptal ve değişiklik yolunun gösterilmemesi. Kullanıcı hemen bir hata fark ettiğinde ne yapacağını bilmiyor ve panikle birden fazla kanaldan yazıyor.
Dokuzuncusu, sayfanın arama motoruna açık bırakılması. Sipariş bilgisi taşıyan bu adresler dizine kapatılmalı; aksi halde hem gereksiz sayfalar taranıyor hem kişisel veri içeren içerik dışarı sızabiliyor.
Onuncusu, dönüşüm ölçümünün yalnızca bu sayfaya bağlanması. Kullanıcı sayfayı görmeden ayrılırsa sipariş sayılmıyor; ölçüm sunucu tarafında da doğrulanmalı.
On birincisi, sayfanın yazdırılabilir olmaması. Bazı kullanıcılar bu bilgiyi saklamak ya da çıktı almak istiyor; basit bir baskı düzeni, destek talebini azaltan küçük bir ayrıntı.
Neyi çözmez?
İyi bir onay sayfası, sipariş sürecindeki gecikmeyi gidermez. Bilgi verir; operasyon yavaşsa müşteri yine bekler.
Sıkça sorulan sorular
En kritik bilgi hangisi?
Teslimat tarihi ve sipariş numarası. Biri en çok sorulan soru, diğeri her iletişimde gerekiyor.
Adresi göstermeli miyim?
Gösterin. Hata burada yakalanırsa kargo çıkmadan düzeltilir.
Teşekkür sayfasından farkı ne?
Bu sayfa bilgi verir; aynı alanın pazarlama amaçlı kullanımı ayrı bir konudur. Bu konuyla birlikte ele alınan Order Confirmation UX, sipariş tamamlandıktan sonraki onay ve bilgilendirme deneyiminin, güven verecek ve beklentileri netleştirecek biçimde tasarlanmasıdır.
Bu kavramın bütün resim içindeki yerini Ürün Sayfası Optimizasyonu Rehberi içinde ayrıntılı anlattım.
E-ticaret için ürün görseli, açıklama, güven alanı, beden/kargo/iade, yorumlar ve sepete ekleme oranı optimizasyonu.
