Sepete ürün ekleyen herkes hemen satın almaya hazır değildir. Bazı kişiler toplam maliyeti görmek, bazıları ürünleri karşılaştırmak ister. Bu yüzden her terk edilen sepeti teknik hata diye yorumlamayın. Yine de son adımda ortaya çıkan beklenmedik ücret, kaybolan adres bilgisi veya belirsiz ödeme sonucu düzeltilebilir sorunlardır. İncelemeye müşteri yolculuğunu gerçek bir sipariş senaryosuyla baştan sona deneyerek başlayın.
Toplam maliyeti karar verilmeden önce gösterin
Ürün tutarı, indirim, teslimat ve varsa diğer ücretler anlaşılır biçimde ayrılmalıdır. Teslimat tutarı adrese göre hesaplanıyorsa ne zaman netleşeceğini açıklayın. Kupon alanını bütün ekranın ana odağı yapmak, kuponu olmayan kişinin yanlış bir fırsatı kaçırdığını düşünmesine neden olabilir. İndirim uygulanamadığında nedenini ve hangi koşulun eksik olduğunu açıkça söyleyin; sadece kırmızı hata göstermek yeterli değildir.
Üyelik gereksinimini iş modeline göre değerlendirin
Bazı mağazalar müşteri hesabına ihtiyaç duyabilir; ancak üyelik zorunluluğunun nedenini açıklayın. Uygunsa misafir satın alma seçeneğini değerlendirin. Kullanıcının sipariş verebilmek için ilgisiz profil alanlarını doldurması gerekmemeli. İletişim bilgilerinin sipariş ve teslimat için kullanımı ile pazarlama tercihlerini ayrı ve anlaşılır sunun. Formun kısa olması, gerekli açıklamaların saklanması anlamına gelmez.
Başarısızlık ve belirsizlik durumlarını tasarlayın
Ödeme reddedildi, bağlantı kesildi veya sağlayıcı yanıtı gecikti: bunlar farklı durumlardır. Kullanıcıya ne olduğunu ve hangi güvenli adımı atabileceğini söyleyin. Tutarın çekilip çekilmediği bilinmiyorken koşulsuz tekrar ödeme önerisi vermeyin. Sunucu tarafında sipariş ve ödeme durumları doğrulanmalıdır. Aynı isteğin tekrarlanması iki ayrı tahsilat veya iki sipariş üretmemelidir; bunu kullanılan sağlayıcının yöntemlerine göre uygulayın.
Örnek bir testte ödeme sağlayıcısı başarılı yanıt verirken müşterinin tarayıcısı kapanabilir. Siparişin yalnızca teşekkür sayfası açıldığı için başarılı sayıldığı bir tasarım bu durumu kaçırır. Sunucu bildirimleri ve doğrulama süreciyle gerçek durum izlenmelidir. Bildirimler de tekrar gelebilir; işlem kayıtlarının tekrarlandığında nasıl davranacağı proje kapsamına dahil edilmelidir.
Sipariş operasyonunu da kontrol edin
Ödeme tamamlandıktan sonra stok, sipariş paneli, müşteri bildirimi ve kargo hazırlığı aynı ürün ve adetle ilerliyor mu? Test ortamında başarısız ödeme, iptal, kupon ve farklı teslimat seçeneklerini deneyin. Canlı test gerekiyorsa işletmenin onayladığı küçük ve kontrollü süreç kullanın. Kart bilgilerini uygulama günlüklerine yazmayın. Destek ekibinin işlem durumunu nasıl göreceği de belli olsun.
- Ödenecek toplam son onaydan önce açık mı?
- Hatalı alana dönüşte diğer bilgiler korunuyor mu?
- Aynı gönderim iki sipariş oluşturuyor mu?
- Ödeme sonucu sunucuda doğrulanıyor mu?
- Müşteri destek için sipariş numarasını bulabiliyor mu?
Terk oranını aşamalara bölün
Sepet, adres, teslimat ve ödeme aşamalarını ayrı inceleyin. Ödeme hatası artarken reklamı değiştirmek gerçek sorunu çözmez. Belirli cihaz veya tarayıcıda düşüş varsa arayüz sorunu araştırın. Ücret görüntülendikten sonra çıkış artıyorsa toplam maliyetin daha erken açıklanması gerekebilir. Kişisel verileri toplamadan hata sınıfları ve işlem durumları üzerinden teknik görünürlük sağlamak mümkündür.
Tekrar eden istek yönetimine örnek olarak Stripe idempotent istek belgesi incelenebilir; kendi sağlayıcınızın davranışını ayrıca doğrulayın. Mobil form rehberi ve e-ticaret çalışmalarımız akışın diğer parçalarını tamamlar.