Sipariş ekranında aynı kişi varsayımını bırakın

Bir işletme internetten sipariş verirken ürünü seçen çalışan, şirket adına alım yapan kişi, ödemeyi tamamlayan yetkili ve paketi teslim alacak kişi aynı olmayabilir. Küçük bir tüketici alışverişinde hepsi tek kişi gibi görünür; kurumsal siparişlerde ise farklı kişiler, adresler ve kayıtlar devreye girebilir. Form bütün bilgileri tek bir “müşteri” alanına sıkıştırırsa ekip siparişi doğru hazırlasa bile paketi yanlış kişiye yönlendirebilir, belge bilgisini yanlış kayıttan alabilir veya siparişle ilgili soruyu kime soracağını karıştırabilir.

Bu rehber belirli bir Florya işletmesi veya gerçekleşmiş sipariş hakkında iddia içermez. Ödeme öncesinde her alanın hangi rolü tanımladığını ve siparişin neresinde kullanılacağını açık etmeyi anlatır. Özel teklif, bayi fiyatı, ödeme sağlayıcı yanıtı ve sipariş sonrası değişiklik kapsam dışıdır.

Önce siparişteki rolleri adlandırın

Form tasarımından önce işletme, siparişe katılan tarafları ve görevlerini bir sayfada tanımlamalıdır. “Alıcı” sözcüğü tek başına belirsizdir: ürünü satın alan kişi mi, şirket mi, siparişi sisteme giren çalışan mı, teslim alacak kişi mi? Ekip kendi sözlüğünü kurmalı ve aynı terimi ürün sayfasında, ödeme adımında, sipariş özetinde ve iç yönetim ekranında aynı anlamda kullanmalıdır. Böylece aynı bilgi farklı alanlarda tekrar sorulsa bile bunun neden istendiği anlaşılır.

Pratik bir rol tablosu dört satırdan başlayabilir: siparişi oluşturan kişi, adına alım yapılan kurum, teslimat alıcısı ve ödeme ya da fatura kaydında kullanılacak taraf. Küçük siparişlerde bir kişi birden fazla rolü üstlenebilir. Bu nedenle sistem, “her rol mutlaka farklı kişidir” diye varsaymamalı; birleştirme seçeneği vermeli ve yalnız farklı olduğunda ek alan açmalıdır. Ayrı kişi gerektiğinde de rolün adını görünür kılmalıdır. “İletişim bilgisi” gibi genel bir başlık yerine “Sipariş hakkında aranacak kişi” ifadesi daha anlaşılır olabilir.

Rol tablosu hukuki veya muhasebe tavsiyesi değildir. Gerekli şirket ve belge alanlarını işletmenin yetkili sorumluları belirler; tasarım ekibi yalnızca bu onaylı bilgileri anlaşılır toplar. Zorunluluğu açıklanamayan alan eklenmemelidir.

Satın alma yapan kişi ile kurum kaydını ayırın

Siparişi başlatan kullanıcı, şirket adına işlem yapabilir. Bu durumda kişi adı ve iletişim bilgisi, siparişin hangi kurum adına verildiğini gösteren bilgilerden farklı bir amaca hizmet eder. Kullanıcı adına işlem yaptığı kurumu seçebilir veya doğrulanmış kurum bilgisini girebilir; işletmenin süreçleri gerektiriyorsa kurum içindeki sipariş referansını da ekleyebilir. Bu referans, mağazanın ürün kodu ya da kampanya kodu değildir; alıcının kendi takip düzeninde kullandığı bir değer olabilir.

Alan adları rolü açık etmelidir. “Ad soyad” başlığı altında şirket adının istenmesi, “şirket” alanına kişinin yazılması veya sipariş referansının ürün notu içine bırakılması sonraki ekiplerin kayıtları yorumlamasını zorlaştırır. Kurum alanı kullanılacaksa kişi alanını silmek gerekmez; fakat her ikisinin siparişte neyi temsil ettiği açıklanmalıdır. Kişi şirket adına alım yapmıyorsa kurum alanını boş bırakabilmeli; kurum adına alıyorsa bu ilişkinin sipariş özetinde de doğru görünmesi gerekir.

Teslimat alıcısını ayrı ve anlaşılır kaydedin

Ödeme yapan veya siparişi oluşturan kişi, paketi teslim alacak kişi olmayabilir. Kurumsal satın almada ürün depo, mağaza, ofis ya da proje sorumlusuna gönderilebilir. Adres ve alıcı alanları, ödeme bilgisinin altına açıklamasız biçimde eklenmemelidir. “Teslim alacak kişi” ve “teslimat adresi” gibi etiketler, bilginin hangi iş için kullanıldığını söyler. Kullanıcı aynı kişi ve adresi kullanacaksa mevcut bilgiyi kopyalama seçeneği sunulabilir; farklıysa yeni alanlar açılmalıdır.

Kopyalama seçeneği sadece görünür alan değerlerini çoğaltmakla kalmamalı, hangi verinin kopyalandığını da kullanıcıya göstermelidir. Adres daha sonra değiştirildiğinde kurum kaydının da değiştiği izlenimi oluşmamalıdır. Sipariş özeti, ürünleri, miktarları, alıcıyı ve teslimat bilgisini ödeme öncesinde birlikte göstermelidir. Kişi geri dönüp düzeltme yapabilmeli, fakat hangi bölümün güncellendiğini anlayabilmelidir. Bu kontrol, sipariş sonrası adres değişikliği akışından farklıdır: burada hedef ilk kaydın doğru kurulmasıdır.

Ödeme ve fatura alanlarını gerçek gereksinime bağlayın

Ödeme adımında kartı kullanan kişi ile siparişi alan kurum aynı olmayabilir. Arayüz, ödeme yöntemi bilgisini satın alan tarafın kimliğiyle karıştırmamalıdır. Ödeme hizmetinin güvenli sayfasına yönlendirme veya ödeme sonucunu alma biçimi, işletmenin kullandığı altyapıya bağlıdır; bu yazı belirli bir sağlayıcının alanlarını ya da özelliklerini garanti etmez. Mağaza yalnızca onaylanmış sipariş bilgilerini ödeme adımına aktarır ve müşteriye gördüğü toplamı, seçtiği ürünleri ve teslimat bilgisini tekrar kontrol etme olanağı sunar.

Fatura için toplanacak alanlar ve zorunluluklar işletmenin muhasebe süreci ve geçerli yükümlülükleri doğrultusunda belirlenmelidir. Bu rehber vergi veya belge düzeni hakkında hukuki görüş vermez. Tasarım kararı açısından temel nokta, fatura alıcısına ait bilgiyi teslimat etiketi için kullanılan kişi ve adresle otomatik olarak eşitlememektir. Müşteri kurum adına kayıt seçtiğinde kurum bilgisini; kişisel alışverişte ise kişisel alıcı bilgisini girebilmelidir. İstenen her alan için kısa bir açıklama verilmeli; format örneği, gerçek bir kimlik numarası veya hassas veri gerektirmeyen bir örnekle anlatılmalıdır.

Doğrulama hatası hangi alanın nasıl düzeltileceğini söylemeli. Genel “bilgileri kontrol edin” uyarısı yerine kurum, teslim alıcısı veya adres alanı işaretlenmeli; doğru girdiler korunmalıdır. Kişisel ve kurumsal işlem yolları ayrılıyorsa kullanıcıya seçim değiştiğinde ne olacağı açıklanmalıdır.

Gereksiz bilgiyi toplamayın, erişimi sınırlayın

Sipariş için kullanılmayacak bir kişinin telefonunu, kişisel kimlik ayrıntısını veya kurum içi bilgiyi toplamak fayda sağlamaz. Her alan için “Bu bilgi olmadan hangi ekip hangi işi yapamaz?” sorusunu sorun. Cevap yoksa alanı kaldırın ya da isteğe bağlı yapın. Serbest metin kutusu yerine sınırlı ve amaca uygun bir alan seçmek, gereksiz veri girişini de azaltabilir. Ancak kullanıcının kendi notunu eklemesi gerekiyorsa bunun nerede görüleceği ve hangi amaçla kullanılacağı açıklanmalıdır.

Bilgi saklama süresi veya silme yükümlülüğü hakkında genel bir süre uydurmayın. Bu kararlar işletmenin hukuki ve muhasebe sorumlularınca belirlenir. Yazılım ekibi onaylanan saklama ve erişim kurallarını uygulayabilir, ancak kendisi süre veya yasal uygunluk vaadi veremez. Proje kapsamı görüşmesinde hangi alanın hangi işlem için tutulduğu, kimlerin göreceği ve silme talebinin nasıl ele alınacağı netleştirilmelidir. Bu açıklık, tasarım kararını hem kullanıcı hem de işletme ekibi için denetlenebilir kılar.

Ödeme öncesi kontrol turunu gerçek siparişlerle sınayın

Yayına çıkmadan önce yalnızca sorunsuz tamamlanan siparişi denemek yetmez. Biri kendi adına alışveriş yapan bireysel kullanıcıyı, diğeri şirket adına işlem açan kişiyi temsil eden test siparişleri hazırlayın. Ayrıca siparişi açan, ödeme yapan ve ürünü teslim alan kişinin farklı olduğu bir örnek kurun. Her senaryoda form başlıklarının rolü doğru anlatıp anlatmadığını, zorunlu alanların gerekçeli olup olmadığını ve sipariş özetinin seçilen kişileri doğru gösterip göstermediğini gözlemleyin.

Mobil ödeme deneyimi rehberi, küçük ekranda sepetten ödemeye ilerlerken kontrol edilmesi gereken görevleri ele alır: mobil e-ticaret kontrol turunu inceleyin. Ödeme hizmetinden dönen yanıt ve sipariş durumunun nasıl ayrılacağı için ödeme entegrasyonu rehberine bakın. Buradaki tasarım kararı ödeme işlemini yeniden anlatmaz; siparişte hangi kişinin veya kurumun hangi rolü üstlendiğini kontrol eder. Sipariş sonrası alıcıya hangi gelişmelerin iletileceği ayrı bir ihtiyaçtır; sipariş durumu bildirim tercihleri rehberi bu sonraki aşamayı açıklar.

Proje kapsamını görüşmede somutlaştırın

Sonra ajansla kapsamı kayıt altına alın: hangi alanlar gösterilecek, hangi seçimler yeni alan açacak, ödeme öncesi özet neleri içerecek, yanlış veya eksik girişte ne olacak, yönetim ekranında hangi roller görülecek? Bu soruların yanıtı tasarım onayından önce netleşirse, formu yalnızca görsel bir ekran olarak değil, siparişin doğru kişilere bağlandığı bir iş akışı olarak değerlendirebilirsiniz. BiKreatif’in e-ticaret yazılımı hizmetini değerlendirirken bu örnek akışları proje kapsamı görüşmesinde paylaşabilirsiniz. Belirli bir işletmenin Florya’da bulunduğu, bu bölgede hizmet verdiği veya sonuç aldığı ileri sürülmüyor.

Sık sorulan sorular

Satın alma yapan kişi ile teslimat alıcısı aynı değilse bunu ödeme öncesinde belirtmek gerekir mi?

Evet. Kullanıcı aynı kişi seçeneğini kullanabilmeli; farklıysa teslim alıcısının adı ve adresi ayrı kaydedilmelidir. Sipariş özeti, paketin kime ve nereye gideceğini ödeme öncesinde göstermelidir. Bu, sonradan adres değiştirme süreci değildir; doğru ilk kaydı kurar.

Şirket adına alışveriş yapıldığında çalışan bilgisi de istenmeli mi?

Çalışan bilgisi sipariş takibi için gerçekten gerekiyorsa alınabilir ve amacı açıklanmalıdır. Kurum adı ile kişinin adı farklı alanlarda tutulmalı; her siparişte temsilci zorunlu varsayılmamalıdır. İşletme gerekli rolü belirlemeli ve sipariş özetinde göstermelidir.

Ödeme yapan kişi ile faturada yer alacak taraf farklı olabilir mi?

İşlem türüne ve işletmenin doğruladığı muhasebe sürecine bağlıdır. Arayüz ödeme yapanı otomatik olarak fatura alıcısı saymamalı; gerekli alanları yetkili sorumlu belirlemelidir. Hukuk veya vergi kuralı bu rehberden çıkarılmamalı; özel sorular uzmanlara yöneltilmelidir.

Kurum içi sipariş numarası zorunlu alan yapılmalı mı?

Yalnızca siparişi veren kurum bu numarayı düzenli olarak kullanıyorsa zorunlu olması düşünülebilir. Farklı müşteriler aynı alanı kullanmıyorsa zorunluluk, gereksiz hata yaratır. İşletme bu bilgiyi sipariş kaydında arama veya teslimat eşleştirme için kullanıp kullanmadığını belirlemelidir. Alan isteğe bağlıysa örnek açıklama, müşterinin ürün kodu veya kampanya kodu girmesini önleyebilir.

Şirket ve teslimat bilgileri aynıysa ayrı ayrı tekrar girmek gerekir mi?

Hayır; aynı kişi veya adres seçeneği, kullanıcıya tekrar yazma yükünü azaltabilir. Yine de sistem hangi bilgiyi nereye kopyaladığını göstermeli ve kullanıcıya kontrol olanağı sunmalıdır. Bir alandaki değişikliğin diğer kayıtları sessizce değiştirdiği izlenimi oluşmamalıdır. Farklı teslimat seçildiğinde adres ve alıcı alanları görünür olmalı; sipariş özeti seçimin son halini göstermelidir.

Fatura alanlarında hangi bilgiler zorunlu olmalıdır?

Bu rehber yasal veya muhasebe gereklilikleri belirlemez. Alan listesi, işletmenin yetkili muhasebe sorumlusu ve kullandığı süreç doğrultusunda onaylanmalıdır. Tasarım ekibi onaylı listeyi anlaşılır etiketlere dönüştürür ve her alanın amacını belirtir. Gerekliliği net olmayan bir kimlik veya şirket alanını tahminle zorunlu kılmak yerine önce sorumlu kişiden doğrulama alınmalıdır.

Yanlış kişi veya adres bilgisi girilirse kullanıcı ne görmeli?

Hata mesajı hangi alanın sorunlu olduğunu söylemeli, güvenli biçimde nasıl düzeltileceğini göstermeli ve kullanıcıyı formun başına göndermemelidir. Hata metni “bilgi yanlış” gibi belirsiz kalmamalı; adres satırı mı, posta kodu mu, alıcı adı mı kontrol edilecek anlaşılmalıdır. Sistem kullanıcının zaten girdiği doğru alanları korumalı ve değişiklikten sonra sipariş özetini yenilemelidir.

Bu tasarım kararı sipariş sonrası değişiklik akışıyla aynı mıdır?

Hayır. Buradaki amaç, sipariş oluşturulmadan önce alıcı, kurum, teslimat ve ödeme/fatura rollerini doğru alanlara bağlamaktır. Sipariş onaylandıktan sonra adres veya ürün değiştirme, iptal, iade ve bildirim süreçleri başka kurallara sahiptir. Önceki sipariş değişikliği rehberinde olduğu gibi bu işlemler siparişin mevcut durumunu ve sorumlu ekipleri etkiler. İlk formu doğru tasarlamak sonradan gelen bütün değişiklik isteklerini çözmez.