Abonelikte atlama, duraklatma ve adres değişiklikleri: kurallar ve arayüz

Neden bu abonelik kontrolleri müşteri tutmayı belirler

Tüketim ürünleri aboneliği, insanların aboneliğe devam etmekte güvende hissetmesiyle çalışır. Bu ister protein tozu, vitamin, kahve, jilet yedekleri ister cilt bakım ürünleri gönderiyor olun geçerlidir. İhtiyaçlar aylara göre değişir ve insanlar ayarlamanın ne kadar kolay olduğuna göre sizi değerlendirir.

Atlama, duraklatma ve adres düzenlemeleri riskli hissedildiğinde churn (abonelikten ayrılma) yaratır. Bir müşteri bir değişikliğin bir sonraki tahsilattan önce “kalıcı” olacağından emin değilse, denemek yerine iptal etmeyi tercih eder. Bir siparişin yanlış adrese gideceğinden veya seyahatteyken teslim edileceğinden endişe ediyorsa, stresi önlemek için iptal eder.

Kurallar belirsiz ve arayüz sonuçları gizliyse ortaya çıkan duruma biz "destek kaosu" diyoruz. Bu, genellikle faturalama ve sevkiyat etrafında hızla görünür.

Yaygın belirtiler şunlardır:

• Tahsilat zaten yapıldıktan sonra müşterilerin "lütfen bir sonraki kutumu durdurun" diye e-posta atması
• Müşteri atlama yaptığı halde sistem yine de sipariş oluşturduğu için çift gönderimler
• Adres değişikliği taleplerinin self-servis yerine destek ekiplerine gitmesi
• Sürpriz teslimatlar sonrası geri ödeme talepleri, chargeback'ler ve olumsuz yorumlar
• Temsilcilerin gerçek uç durumları çözmek yerine politika açıklamakla zaman harcaması

Amaç basit: değişiklikleri self-servis ve öngörülebilir kılmak. Öngörülebilir olmak, müşterinin tahmin etmeden üç soruya cevap verebilmesi demektir: ne olacak, ne zaman olacak ve maliyeti ne olacak.

Bu yüzden "abonelik atlama, duraklatma ve adres değişiklikleri" ekstra ayarlar gibi ele alınmamalı. Bunlar tutundurma (retention) kontrolleridir. Net olduklarında müşteri yoğun bir ay için duraklatır, sonsuza dek iptal etmez. Karışık olduklarında ise her hayat olayı (seyahat, taşınma, yeni bir lezzet deneme, bütçe daralması) bir iptal anına dönüşür.

İyi kontroller takımınızı da korur. Daha az bilet, daha az manuel müdahale, daha az tek seferlik geri ödeme ve daha tutarlı cevaplar anlamına gelir. Ürün, müşteri değişikliği yaparken kuralları açıklar.

UI'yi inşa etmeden önce tanımlamanız gereken kurallar

Bir abonelik ekranı, arkasındaki kurallar kadar açık olabilir. Kural çalışmasını atalarsanız müşteriler tahminde bulunur, şaşırır ve desteğe başvurur.

Abonelik şartlarınızı müşterinin tekrar edebileceği sade bir dilde yazın. "Faturalama periyodu" veya "fulfillment batch" gibi iç terimlerden kaçının. İnsanların zaman ve bir sonraki adım hakkında basit bir zihinsel modeli olmalı.

Kilitlemeniz gereken asgari tanımlar:

• Döngü (Cycle): siparişin ne sıklıkla tekrarlandığı (her 4 hafta, her ayın 15'i vb.)
• Kesme zamanı (Cutoff): bir değişikliğin bir sonraki siparişi etkileyeceği son an
• Bir sonraki gönderim tarihi: bir kutunun gönderilmesinin beklendiği tarih (sadece faturalama değil)
• Bir sonraki tahsilat tarihi (farklıysa): ödemenin alındığı tarih
• Uygun değişiklikler: hangi alanların düzenlenebileceği (ürünler, miktar, adres, tarih)

Sonra benzer görünen ama farklı davranan eylemleri ayırın. Müşteriler "skip" (atla), "pause" (duraklat) ve "cancel" (iptal) ifadelerinin farklı olmasını bekler; ürününüz de öyle davranmalı.

• Atla (Skip) = sadece bir sonraki siparişi atla, sonra otomatik devam etsin
• Duraklat (Pause) = müşterinin yeniden başlatana kadar gelecekteki siparişleri durdur
• İptal (Cancel) = aboneliği sonlandır (sadece gelecekteki siparişleri mi durdurur yoksa zaten planlanmış olanı da mı engeller tanımlayın)

Şimdi bir adres değişikliğinin neyi etkilediğini tanımlayın ve ona sadık kalın. Çoğu karışıklık burada başlar. Bir adres değişikliğinin uygulanıp uygulanmayacağını kararlaştırın:

• Sadece bir sonraki sipariş (seyahat için faydalı)
• Tüm gelecekteki siparişler (taşınma için faydalı)

Bir müşteri bir şeyi değiştirirken promosyonlar ve ekstra ürünler hakkında açık olun. Biri "3 ay al, ücretsiz hediye" teklifindeyken atlamaya karar verirse hediye taşınır mı yoksa teklif sona mı erer? Bir paket indirimi iki ürüne bağlıysa, biri çıkarılırsa ne olur? Stok azsa, fiyatı kaybetmeden geciktirebilir mi?

Basit bir test: 2 günlük bir kesme zamanı olan bir şampuan aboneliği düşünün. Biri kesme zamanından bir gün önce duraklatırsa yine de gönderim yapılır mı? Yapılmıyorsa, devam ettiklerinde indirimleri kalır mı? Bu tür soruların cevabını UI tasarlamadan önce verin.

Sürprizleri önleyen kesme pencereleri ve sevkiyat zamanlaması

Çoğu abonelik sorunu müşteriler ve operasyon ekibinizin farklı saatleri kullanmasından başlar. Çözüm basittir: bir sonraki gönderime bağlı tek bir açık kesme zamanı yayınlayın ve değişiklik yapılabilecek her yerde gösterin.

Depo işleyişinize uyan bir kesme zamanı seçin. "Değişiklikler gönderimden 48 saat önce kapanır" yaygındır, ama doğru pencere toplama-paketleme süresi, kargo alımı ve etiketleme sıklığına bağlıdır.

Kesme zamanından sonra bir davranış seçin ve buna sadık kalın:

• Geçerli sipariş için değişiklikleri engelle (temiz ve öngörülebilir), veya
• Uyarı ile değişiklike izin ver ve ne olacağı açıkça belirtin (örneğin: "Bu güncelleme hâlihazırda işlenen siparişe değil, sonraki siparişe uygulanır.")

Abonelik atla/duraklat/adres değişiklikleri ekranı üst kısmında üç şeyi göstermeli: bir sonraki gönderim tarihi, kesme tarih/saat (zaman dilimiyle) ve hangi eylemlerin hâlâ kullanılabilir olduğu.

Çoğu sürprizi ortadan kaldıran kararlar:

• Kesme için tam zaman damgası (tarih + zaman dilimi), sadece "2 gün önce" değil
• Kesme sonrası her eylem için ne olacağı (atla, duraklat, adres düzenle)
• Ödemenin yetkilendirilme ve tahsil edilme zamanları
• Bir değişiklik yapıldığında stok kısa ise ne olacağı

Ödeme zamanlaması ekiplerin beklediğinden daha önemli olabilir. Müşteri kesme zamandan önce atlar veya duraklatırsa, o dönem için tahsilat yapmaktan kaçının ve "bu dönem ücretlendirme olmayacak" diye onay verin. Eğer daha erken ön yetkilendirme yapıyorsanız bunun ne zaman serbest bırakılacağını söyleyin ve açıklayın.

Geç kalan adres değişiklikleri için güvenli bir kural gerekir. Biri gönderimden 12 saat önce adresi günceller ve etiket zaten oluşturulduysa ne yapacağınızı belirleyin (mevcut değişiklikleri engelle, ücretli yeniden gönderim sun, iade edilen ürünleri geri öde) ve bu sonucu "Kaydet"e basmadan önce gösterin.

Abonelik değişikliklerini basit tutan UI desenleri

Her şeyi tek bir yere bağlayın: tek bir Bir Sonraki Teslimat kartı. Bu kart teslimat tarihini, kutudaki öğeleri, toplam fiyatı ve küçük bir adres önizlemesini göstermeli. İnsanlar ne olacağını gördüğünde yanlışlıkla yapılan değişiklikler azalır ve destek talepleri düşer.

Ana kontrolleri insanların sayfayı açma sebeplerine odaklayın:

• Bir sonraki siparişi atla
• Duraklat
• Adresi değiştir

Diğer seçenekler (frekans değişikliği, ürün takası, ödeme düzenleme) ikincil "Yönet" alanının arkasında olabilir. Temel eylemleri gömmeyin.

İyi işleyen basit bir desen: önizleme -> eylem seç -> onayla -> sonucu gör. Onay adımı churn'ü engellediğiniz yerdir. Yeni bir sonraki teslim tarihini büyük metinle gösterin ve fiyat ve adres gibi kilit detayları tekrarlayın ki müşteri hataları fark edebilsin.

Birkaç UI detayı çok işe yarar:

• Tarih, öğeler, fiyat ve adres önizlemesi içeren bir birincil "Bir Sonraki Teslimat" kartı
• Düz ve net etiketli üç birincil düğme (jargondan kaçının)
• "Bir sonraki teslimatınız şimdi…" gibi güncellenmiş tarihi belirten bir onay görünümü
• Neyin ne zaman, kim tarafından değiştirildiğini gösteren bir etkinlik kaydı
• Eylemin yanında zamanlama ve sonuçları belirten kısa mikro metin

Zamanla ilgili mikro metin en çok önem taşıyan kısımdır. Eğer değişikliklerin bir kesme zamanı varsa bunu eylemin yanında söyleyin, politika metninin içinde saklamayın. Örneğin: "Bu teslimata yapılan değişiklikler yarın saat 17:00'de kapanır."

Atla ve duraklatma için adım adım akış (dokunuştan onaya)

İyi bir atla veya duraklatma akışı hemen bir soruyu cevaplar: bir sonraki teslimatıma ne olacak?

Basit bir durum kartıyla başlayın. Aboneliğin Aktif mi yoksa Duraklatıldı mı olduğunu, bir sonraki tahsilat tarihini, bir sonraki gönderim/teslim tarihini ve bir sonraki kutuda ne olduğunu gösterin. Bir kesme zamanı varsa ("Değişiklikler Salı 18:00'e kadar"), aynı yerde gösterin.

Kullanıcı Atla veya Duraklat'a dokunduğunda sonucu tahmin etmesini istemeyin. Onaydan önce güncellenmiş programın önizlemesini gösterin. Atlamak genellikle bir sonraki teslimatı sonraki döngüye taşır ve aynı ritmi korur. Duraklatma ise açık bir soru sormalı: belirli bir tarihe kadar mı duraklatılsın yoksa ben tekrar başlatana kadar mı?

Gerçek hayatta tutan bir akış:

1. Mevcut durumu ve "Bir Sonraki Teslimat" detaylarını, son değişiklik tarihini gösterin.
2. Atla veya Duraklat seçildikten sonra güncellenmiş programı gösterin ("sonraki iki teslimat" bile yeterli olabilir).
3. Özet ekranında onaylatın: ne değişti, yeni tarihler ve ödemenin etkilenip etkilenmediği.
4. Hemen uygulama içinde onay gönderin ve eğer normalde fiş/fiş e-postası gönderiyorsanız e-posta da gönderin.
5. Eğer sevkiyat başlamadıysa kısa bir geri alma penceresi sunun ve ne zaman sona ereceğini açıkça gösterin.

Özet spesifik olsun. Örneğin: "12 Nisan'ı atladınız. Bir sonraki teslimatınız 10 Mayıs olacak. 11 Nisan'da ücretlendirme yapılmayacak." Bu, "Duraklattım ama yine ücretlendirildim" klasik destek talebini önler.

Geri almayı güvenli kılın. Sipariş zaten paketlenmiş veya etiket bastırılmışsa "Geri Al" yerine: "Bu sipariş zaten işleniyor ve değiştirilemiyor" mesajı gösterin ve bir sonraki kullanılabilir eylemi sunun ("Bir sonraki teslimattan sonra duraklat").

Adres değişiklikleri: kurallar, uç durumlar ve güvenli düzenleme akışı

Adres düzenlemeleri bir aboneliği yardımcı hissettirebilir veya düşmanlaştırabilir. İnsanlar bir hata yapma korkusu hissederse, destek yerine değiştirmek yerine iptal ederler. UI'nin bir şeyi açık hale getirmesi gerekir: bir sonraki teslimat için hangi adres kullanılacak ve sonrasında ne olacak.

Önceden belirlenmesi gereken kurallar

Her adres düzenlemesi net bir seçimle başlamalı: sadece bir sonraki sipariş için mi değiştirilsin, yoksa tüm gelecekteki siparişler için mi? Birçok müşteri seyahat eder, geçici taşınır veya bir kutuyu hediye gönderir. Kalıcı bir değişikliğe zorlamak hatalar ve destek talepleri yaratır.

Kesme zamanları önemli. Eğer bir sonraki sipariş zaten işleniyorsa, kaydetmeden önce bunu söyleyin. Düz bir dille: "Bu sipariş zaten hazırlanıyor. Değişikliğiniz gelecek aydan itibaren uygulanacaktır" ve hangi tarihten itibaren uygulanacağını gösterin.

Doğrulamayı sona bırakmayın; kullanıcı yazarken eksik alanları yakalayın ve yaygın formatları kabul edin (Apt, Daire, #, Kat). Adres hataları genellikle küçük görünür ama teslimat hatalarına yol açar.

Sürprizleri önleyen güvenli bir düzenleme akışı

Ekranı öngörülebilir tutun:

• Üstte Bir Sonraki Teslimat Adresi'ni açık bir önizlemeyle gösterin.
• Kullanıcılara Sadece bir sonraki sipariş veya Tüm gelecekteki siparişler seçeneklerini sunun ve her birini bir cümleyle açıklayın.
• Kesme zamanı geçtiyse açık bir uyarı gösterin ve değişikliğin hangi teslimatı etkileyeceğini belirtin.
• Kayıtlı adresleri destekliyorsanız, kullanıcıların yeniden yazmadan seçim yapmasına izin verin.
• Son olarak kısa bir özet: "Bir sonraki teslimat X adresine DATE tarihinde gönderilecek." gösterin.

Çoklu adres senaryoları açık etiketler gerektirir. Hediye veya bölünmüş gönderimleri destekliyorsanız, her gönderim satırını kendi adresiyle gösterin. Desteklemiyorsanız "Sipariş başına bir adres" deyin ve müşteriyi tek seferlik ayrı sipariş oluşturmaya yönlendirin.

Örnek: bir cilt bakım aboneliğinde biri iki hafta seyahat ediyor. "Sadece bir sonraki sipariş"i seçer, otel adresini girer, bir uyarı görür: "Bu ayın siparişi hâlâ işleniyor" ve onay evrakı bu teslimat için ev adresini, sonraki aydan itibaren otel adresini gösterir. Bu netlik, adres değişikliklerini self-servis haline getirir.

Fiyatlama, promosyonlar ve stok durumları takımınızı tökezletir

Çoğu abonelik şikayeti atla veya duraklat düğmesiyle ilgili değildir. Para ve bulunabilirlikle ilgilidir.

Birisi atladığında veya duraklattığında indirimlerin ne olacağını belirleyin ve karar anında görünür kılın. Kullanıcı dostu basit bir kural: kazanılmış indirimler korunur, ama süre sınırlı promosyonlar orijinal bitiş tarihine göre sona erer. Pause sırasında bir promosyonu donduruyorsanız, bunu onaydan önce söyleyin. Kaldırıyorsanız yeni fiyatı ve sebebini gösterin.

Ön ödemeli planlar ve sınırlı stok kutuları ekstra özen gerektirir. Ön ödemeli genellikle sabit sayıda gönderim vaat eder, sabit bir takvim değil. Duraklatma takvimi duraklatmalı ama kalan gönderimleri azaltmamalıdır. Sınırlı stokta atlamak o ayın kutusunu kaybetmek anlamına gelebilir. Bunu onaylamadan önce söyleyin.

Eklentiler ve tek seferlik ürünler sıkça tuzak olur. "Bir sonraki sipariş"in sisteminizde ne anlama geldiği konusunda net bir söz verin, özellikle bir sonraki sipariş atlandığında veya abonelik duraklatıldığında.

Stok dışı durumları kullanıcı tercihine bırakılmış hissettirin, sürpriz gibi değil. Küçük bir seçenek seti sunun: yerine geçecek ürün, bu gönderimi atla veya stok dışı ürünü çıkart. Yerine geçen ürün fiyatı değiştiriyorsa açık onay isteyin.

Bölge kuralları güveni hızlıca bozabilir. Gönderim ülkeleri veya ürün kuralları farklıysa, geçersiz takasları engelleyin ve nedenini sade ifadeyle açıklayın ("Bölgenizde mevcut değil"). Müşteri adresini kısıtlı bir alana değiştirirse, bir sonraki gönderime ne olacağını söyleyin: ürün değişikliği, gecikme veya iptal.

Örnek: müşteri duraklatır, sonra devam ettiğinde "ilk ay %20 indirim"in geri geleceğini bekler. Eğer arayüz "Promosyon 31 Ekim'de sona erdi" derse, chargeback ve sinirli e-postayı önlemiş olursunuz.

Churn ve destek talepleri yaratan yaygın hatalar

Tüketim ürünleri aboneliklerindeki çoğu churn fiyatla ilgili değildir. Sürprizlerle ilgilidir. İnsanlar arayüz esnek görünür ama sistem bir sonraki kutu zaten hareket halindeyken farklı davranıyorsa kendilerini tuzağa düşmüş hissederler.

Yaygın bir tuzak kesme zamanını son adıma kadar saklamaktır. Eğer biri Atla'ya dokunur, onaya yakın bir adımda "Bu sipariş için artık çok geç" görürse, aboneliğe bir daha güvenmez. Bir sonraki tahsilat tarihini ve düzenleme son tarihini ana abonelik kartında gösterin.

Diğer tekrar eden hata, adres değişikliğini kabul etmek ama hangi gönderimi etkileyeceğini söylememektir. Sistem zaten toplama-paketleme aşamasındaysa bunu söyleyin ve bunun yerine ne olacağını gösterin ("Bu değişiklik 12 Şubat siparişinden itibaren uygulanır"). Teslimat notları, geçit kodları ve apartman numaraları için de aynı uygulanır.

Belirsiz kelimeler de karışıklık yaratır. "Hold" veya "snooze" gibi etiketler kişiden kişiye farklı şeyler ifade eder. Tarihleri ve sonuçları kullanın: "10 Mar'a kadar duraklat" veya "Bir sonraki siparişi atla (15 Oca)". Müşteriler asla ücretlendirileceklerini tahmin etmek zorunda kalmamalı.

Abonelik kontrollerini destek kaosuna dönüştüren en yaygın hatalar:

• Kesme kuralları gömülü veya sadece onay denemesi sonrası gösteriliyor.
• Adres düzenlemeleri kabul ediliyor ama yeni adresin hangi gönderimi etkileyeceği gösterilmiyor.
• Eylemler belirsiz isimler kullanıyor; tarih, bir sonraki tahsilat bilgisi veya önizleme yok.
• Bir iz kaydı yok, bu yüzden destek "Bunu kim ve ne zaman değiştirdi?" sorusuna cevap veremiyor.
• Atla/duraklat ekranda güncelleniyor ama arka plan işleri yine de tahsilat yapıyor veya sevkiyat kuyruğuna alıyor.

Son madde en zararlı olanıdır çünkü sözünüz tutulmamış gibi hissettirir. Eğer faturalama ve sevkiyat planlı işler üzerinde çalışıyorsa, atla/duraklat/adres durumunu her seferinde okuyan birinci sınıf durum olarak ele alın, sadece arayüz bayrağı olarak değil.

Abonelik ayarları deneyiminiz için hızlı kontrol listesi

İyi bir abonelik ekranı, müşterinin herhangi bir değişiklik yapmadan önce iki soruyu cevaplamasını sağlar: sırada ne var ve ne zaman?

Yayımlamadan önce bir aboneliği 30 saniyeden kısa sürede yönetebilmeyi hedefleyin. Bir sonraki gönderim detayını onaylayabilmeli, bir değişiklik yapabilmeli ve beklenmeyen bir şey olmayacağından emin olabilmelisiniz.

Kontrol listesi:

• Bir sonraki sipariş açıklığı: bir sonraki teslimat tarihi (varsa tahmini varış), kutuda ne olduğu ve toplam fiyat birlikte görünmeli.
• Değişiklik zamanlaması: kesme tarih ve saati (zaman dilimiyle) son onaydan önce görünmeli ve ne zaman çok geç olduğu belli olmalı.
• Güvenilir onay: atla veya duraklat sonrası güncellenmiş bir sonraki gönderim tarihini ve ücretlendirme durumunu gösterin.
• Hata kurtarma: mümkünse geri al seçeneği veya kısa bir esneme penceresi, bitiş zamanıyla birlikte sunulmalı.
• Adres etkisi: adres düzenlemeleri bir sonraki gönderimi mi yoksa gelecektekileri mi etkilediğini net olarak belirtmeli.

Pratik bir kontrol: önlemek istediğiniz destek talebini yazın ve sonra UI'nin onu cevaplayıp cevaplamadığını test edin. Örnek: "Atladım ama yine ücretlendirildim mi?" Ekran o eylem için ücret zamanlamasını açıklamıyorsa, onay yakınındaki bir cümle ekleyin.

Örnek senaryo: son dakika seyahatinde bir cilt bakım aboneliği

Maya aylık bir cilt bakım aboneliği kullanıyor ve gönderimler her ayın 12'sinde yapılıyor. Bugün 8 Mayıs ve 11-25 Mayıs arası seyahat edeceğini öğreniyor. Kutunun seyahat sırasında gelmesini önlemek için Aboneliği Yöneti açıyor.

Ekran hemen üç bilgiyi gösteriyor: Bir Sonraki Teslimat: 12 Mayıs, Düzenleme kesme zamanı: 9 Mayıs 23:59, ve Tahmini toplam: $38.00 (ücretsiz gönderim). Altında iki net eylem görüyor: Bir sonraki teslimatı atla ve Aboneliği duraklat. O Bir sonraki teslimatı atlayı seçiyor.

Bir onay sayfası çıkıyor:

• 12 Mayıs siparişini atlayacaksınız.
• Bir sonraki teslimatınız 12 Haziran olacak.
• Fiyatınız aynı kalır.
• 9 Mayıs'a kadar bunu geri alabilirsiniz.

Onayladıktan sonra ana sayfa Bir sonraki teslimat: 12 Haziran olarak güncelleniyor ve küçük bir afiş: 12 Mayıs atlandı ekleniyor. Bir Etkinlik paneli şu kaydı alıyor: "8 Mayıs, 15:14 - 12 Mayıs teslimatı atlandı." Maya ekrana bir onay numarası alıyor, böylece destekle e-posta yazmasına gerek kalmıyor.

İki gün sonra (10 Mayıs) Haziran gönderimini yeni apartmanına göndermek istediğini hatırlıyor. Gönderim adresini açıyor ve bir uyarı görüyor: Bir sonraki teslimat için düzenlemeler kilitli. Yine de gelecekteki teslimatlar için adresi ayarlayabilirsiniz. UI ona iki seçenek sunuyor: Haziran 12 için mevcut adresi koru (seçili) ve Yeni adresi Temmuz 12'den itibaren kullan.

Eğer Maya Haziran 12 için adresi zorla değiştirmeye çalışırsa, net bir mesaj alır: Haziran 12 gönderimini değiştirmek için çok geç. Kesme zamanı 9 Mayıs'tı. Ekran güvenli seçenekler önerir: Destekle yeniden yönlendirmeyi talep et (mümkünse) veya Yeni adresi Temmuz'dan itibaren ayarla.

Bu, abonelik yönetiminin nasıl hissettirmesi gerektiğinin özeti: net tarihler, görünen toplamlar, spesifik kesme zamanları ve ne olduğunu kanıtlayan bir etkinlik kaydı.

Sonraki adımlar: kuralları çalışan bir abonelik yönetim ekranına dönüştürün

Ekranlardan önce kurallarla başlayın. Her kuralı bir destek temsilcisinin kelimesi kelimesine tekrarlayabileceği kısa bir ifade olarak yazın. Ekibinizde iki kişi aynı durumu farklı açıklıyorsa UI de kafa karıştırıcı olur.

İyi bir kural seti şu şekilde duyulmalı: "Bir sonraki sipariş için değişiklikler göndermeden 2 gün önce 18:00'e kadar yapılmalıdır" ya da "Duraklatma gelecekteki siparişleri durdurur ama aboneliği iptal etmez." Listeyi küçük tutun ve tasarımdan önce karara bağlayın.

Önce temel öğeleri prototipleyin

Müşterilerin en çok merak ettiği soruyu cevaplayan bir kart oluşturun: "Sırada ne var?" "Bir Sonraki Teslimat" kartınız tarih, adres, ürünler, fiyat ve değişiklik kesme zamanını göstermeli.

Sonra müşterilerin en çok kullandığı üç eylemi prototipleyin: Bir sonraki siparişi atla, belirli bir süre duraklat ve adresi değiştir. Her eylem bir onayla bitmeli ve yeni bir sonraki tarih ve müşteri hiçbir şey yapmazsa ne olacağı tekrar edilmeli.

Ölçeklemeden önce test edin ve görünürlüğü artırın

5-10 gerçek müşteri ile hızlı testler yapın (takım arkadaşlarınız değil). Onlara "bir sonraki siparişi atla" gibi görevler verin ve sessiz kalın. Nerede tereddüt ettiklerini izleyin: kelimeler, kesme açıklaması, indirimi kaybetme korkusu. Bu noktaları tasarım aşamasında düzeltin.

Sayfaya büyük hacim çekmeden önce destek kaosunu önleyecek iki şey ekleyin:

1. Her abonelik değişikliği için kayıt (kim, ne, ne zaman, önceki değer, yeni değer, kesme durumu).

2. Bir admin görünümü: bir sonraki planlanmış siparişi, son birkaç değişikliği ve her değişikliğin bir sonraki sevkiyatı mı yoksa ondan sonrayı mı etkilediğini gösteren basit bir panel.

Eğer bu kuralları hızlıca çalışan bir prototipe dönüştürmek istiyorsanız, Koder.ai (koder.ai) sohbetten akışları oluşturup, onayları ve geri alma dostu anlık görüntüleri içeren bir uygulama üretebilir.