Bir müşteri siparişi tamamladıktan kısa süre sonra yanlış beden seçtiğini fark eder ya da teslimat adresindeki bir hatayı düzeltmek ister. Paket henüz hazırlanmamış olabilir; fakat mağaza ekibinin ekranında ürün ayrılmış, ödeme alınmış veya kargo etiketi oluşturulmuş görünebilir. İstek makul olsa da sipariş üzerinde gelişigüzel değişiklik yapmak stok, tutar, fatura, depo ve müşteriye verilen bilgi arasında yeni bir tutarsızlık yaratabilir. E-ticaret sitesi tasarımında bu küçük görünen istek için ayrı bir karar yolu tanımlamak önemlidir. Buradaki konu, sipariş verildikten sonra ve fiziksel hazırlık başlamadan önce gelen değişiklik talebidir. Gerçek bir Yeşilyurt işletmesi, siparişi veya müşteri deneyimi anlatılmıyor.

Sipariş değişikliğini iptal ve iadeden ayırın

Sipariş değişikliği, müşterinin mevcut satın alma kaydında sınırlı bir alanı düzeltme isteğidir. İptal, satın alma ilişkisinin devam edip etmeyeceğine dair ayrı bir karardır. İade ise çoğunlukla ürün müşteriye ulaştıktan sonra veya iade süreci başlatıldığında gündeme gelir. Bu kavramları aynı düğmede toplamak, hem müşteriye hem operasyon ekibine yanlış bilgi verebilir. Ürün henüz paketlenmemişken adresin düzeltilmesiyle teslim edilmiş ürünün iadesi aynı akıştan yürütülmemelidir.

Talep türlerini ürün ya da varyant, miktar, adres, not, iptal ve teslimat sonrası iade diye ayırın. Mağaza hepsini sunmak zorunda değildir; alınan talep ile onaylanmış değişikliği arayüzde farklı gösterin.

Hangi işlem aşamasında değişiklik yapılabildiğini belirleyin

Değişiklik için ortak ve bütün mağazalara uyan tek bir son dakika yoktur. Mağazada ödeme bekleyen, ödemesi doğrulanmış, ürünü ayrılmış, toplama listesine alınmış, paketlenmiş veya taşıyıcıya teslim edilmiş siparişler bulunabilir. İşletmenin depo düzeni ve kullandığı sistem bu aşamaları farklı adlandırabilir. Tasarım ekibi evrensel bir saat sınırı uydurmak yerine mağaza sorumlusundan gerçek iş akışını öğrenmelidir: Hangi olaydan sonra ürün üzerinde değişiklik zorlaşır? Etiket ne zaman basılır? Paket ayrıldıktan sonra kim durdurabilir?

Talebin doğru siparişe ve yetkili kişiye bağlanmasını sağlayın

Bir telefon, e-posta veya mesajda “siparişimde değişiklik yapın” denmesi, hangi siparişin kastedildiğini her zaman açıklamaz. Kayıt düzeni, isteği uygun sipariş numarasına ve değişmesi istenen alana bağlamalıdır. İletişim yolunda hangi bilginin gerekli olduğunu işletme belirler; gereksiz kişisel veri istemek yerine, talebi mevcut siparişle eşleştirmeye yetecek doğrulamayı seçin. Sipariş kaydını gören her kullanıcının adres, fiyat veya ürün satırı değiştirebildiği varsayılmamalıdır.

Yetki sınırı yönetim ekranında da açık olmalıdır. Müşteri talebi iletir; sorumlu kişi stok, ödeme ve sevkiyatı kontrol eder; depo ekibi gerekirse paketi durdurur. Küçük ekipte görevler birleşebilir, ancak karar sahibi kayıt üzerinde belli kalmalıdır.

Her değişiklikte ürün, miktar ve tutarı yeniden değerlendirin

Bir varyantı değiştirmek yalnızca ekrandaki adın yenilenmesi değildir. Yeni seçenek stokta olmayabilir; birim fiyatı, indirim koşulu, kargo ağırlığı veya teslimat bedeli farklı olabilir. Miktar artırıldığında mevcut stok ve ayrılmış ürün yeniden kontrol edilmelidir. Miktar azaltıldığında farkın tutara nasıl yansıyacağı, ödeme veya iade adımının ayrıca gerekip gerekmediği mağazanın kullandığı altyapıya bağlıdır. Yazılım, bu ayrıntılar doğrulanmadan eski toplamı yeni ürünle birlikte göstermemelidir.

Shopify’ın sipariş düzenleme belgesi ürün, miktar ve bazı ücret değişikliklerinin sipariş düzenleme akışında ele alınabildiğini; toplam artışı ya da azalışının ek tahsilat veya iade gerektirebileceğini açıklar. Shopify’ın ürün düzenleme kılavuzu, indirim ve gönderim tutarlarının bazı düzenlemelerde otomatik yeniden hesaplanmayabileceğini ve güncel toplamın gözden geçirilmesi gerektiğini ayrıca belirtir. WooCommerce’in resmî yönetici kılavuzunda ise düzenlenebilir alanlar sipariş durumuna bağlıdır; bazı ürün ve ücret değişiklikleri yalnız belirli durumlarda yapılabilir. Bunlar farklı platform örnekleridir, Yeşilyurt’taki veya başka bir mağazanın kullandığı sistemin aynı davranacağı anlamına gelmez. Güncel ürün sürümü, eklenti ve ayarlar doğrudan resmî belgelerinden ve mağaza ortamından sınanmalıdır.

Değişiklik ekranında önceki ve yeni toplamı, varsa ek ödeme veya geri ödeme adımını anlaşılır biçimde gösterin. Para hareketi henüz tamamlanmadıysa bunu “işlem bekliyor” gibi doğru bir durumla ayırın. Ekranda güncellenmiş bir toplam görmek, bankadaki tahsilatın ya da iadeyi başlatan işlemin tamamlandığını tek başına kanıtlamaz. Ödeme sonucu ile sipariş kaydını ilişkilendirme için ödeme entegrasyonunda başarılı yanıt ve sipariş durumu rehberini inceleyebilirsiniz.

Adres değişikliğinde paket ve taşıyıcı adımını da kontrol edin

Teslimat adresi değişikliği, müşterinin profilindeki adresi güncellemekle aynı şey değildir. İstek yalnız mevcut siparişi mi, yoksa gelecekteki siparişlerde kullanılacak adresi de mi etkiliyor? Bu iki tercih birbirine karıştırılmamalıdır. Paket listesi hazırlanmışsa depo ekibinin eski adresi görmeye devam edip etmediği, etiket oluşturulmuşsa yenisinin gerekip gerekmediği ve taşıyıcıya veri gidip gitmediği kontrol edilmelidir. Sistem bu kontrolleri otomatik yapmıyorsa tasarım, yapılmış gibi onay göstermemelidir.

Adres, posta kodu veya teslim seçeneği değiştiğinde gönderim tutarının ve hizmet verilebilirliğinin yeniden değerlendirilmesi gerekebilir. Bu kararları mağaza ve ilgili teslimat sağlayıcısı doğrular. Bir kargo etiketi iptal edilmiş veya yeniden oluşturulmuşsa her adımın hangi siparişe bağlı olduğu tutulmalıdır. Sipariş kaydıyla paket ve taşıma olaylarının ilişkisini anlamak için kargo entegrasyonu ve teslimat durumu rehberi yardımcı olabilir.

Değişiklik anını ve sonraki sorumluluğu kaydedin

İyi bir değişiklik kaydı, yalnızca son hâli saklamaz. Talebin ne zaman geldiği, hangi alanın değişmesinin istendiği, kimin kontrol ettiği, hangi gerekçeyle kabul veya ret verdiği ve hangi yan sistemlerin güncellendiği izlenebilir olmalıdır. Eski adresi veya miktarı tamamen silmek, daha sonra paket neden farklı hazırlandı sorusuna cevap vermeyi zorlaştırabilir. Müşteri kaydında gerekli olmayan kişisel ayrıntılar tutmak yerine değişiklik türünü ve ilgili işlem numarasını saklayın; erişim ve saklama kararlarını mağazanızın sorumluları belirlesin.

Müşteriye bekleyen ve tamamlanmış işlemi ayrı anlatın

Müşteri, isteğinin alındığını ve ne zaman kesinleşeceğini bilmek ister. Talep alındı mesajı, “değişiklik yapıldı” sözünden ayrılmalıdır. Talep kabul edilirse hangi ürün, miktar veya adresin güncellendiği kısa bir özetle gösterilebilir. Yeni tutar oluştuysa, ödeme veya iade tamamlanmadıysa sonraki adım açık olmalıdır. Talep yerine getirilemiyorsa nedenini doğrulanmış iş kuralıyla açıklayın ve mümkünse mağazanın sunduğu başka yolu belirtin. Henüz karar yokken kesin teslim tarihi veya ücret sözü vermeyin.

Yayından önce gerçekçi sipariş senaryolarıyla deneyin

Yalnız kolay bir adres düzeltmesiyle yetinmeyin. Stokta bulunan başka varyanta geçiş, tükenen ürüne değişiklik talebi, miktar azaltma, miktar artırma, adres güncellemesi, paket listesi hazırlanmış sipariş ve değişikliğin reddedilmesi ayrı senaryolar olabilir. Her testte başlangıç durumunu, beklenen yeni sipariş kaydını, stok etkisini, ödeme veya iade adımını, müşteriye gidecek açıklamayı ve kontrol edecek rolü yazın. Kişisel gerçek müşteri verileri yerine test kaydı kullanın.

Değişiklik tamamlandıktan sonra sipariş toplamı, stok, depo ekranı, kargo etiketi ve müşteri bildirimi birbirini tutuyor mu? Bir adım başarısız olursa eski kayıt korunuyor mu, yoksa yeni durum kısmen mi uygulanmış? Aynı talep tekrar gönderildiğinde sistem ikinci kez ücret, stok ayırma veya bildirim üretir mi? Bu soruların her birinin yanıtı altyapıya göre değişebilir; kabul testinde mağazanın onayladığı kurallara göre değerlendirilmelidir. Yayın öncesi kapsam için e-ticaret ilk sipariş test senaryoları rehberine bakabilirsiniz.

Hizmet kapsamını teknik iş ve mağaza kararı diye ayırın

E-ticaret yazılımı çalışmasında ekip; sipariş ekranını tasarlayabilir, talep formu veya durum alanı geliştirebilir ve onaylanmış kuralları sınayabilir. Hangi değişikliğe izin verileceği, stok yoksa ne yapılacağı, ek tutarın nasıl tahsil veya iade edileceği ve hangi teslimat sağlayıcısının kullanılacağı işletme kararlarıdır. Ajans, mağazanın ticari politikasını kendiliğinden belirlememeli veya yasal yükümlülükler hakkında uzman görüşü gibi konuşmamalıdır. Vergi, fatura, tüketici işlemleri ve saklama kuralları gerektiğinde işletmenin yetkili uzmanlarıyla ayrıca doğrulanır.

BiKreatif’in E-Ticaret Yazılımı ve Entegrasyon hizmeti, mağaza arayüzüyle sipariş operasyonunu birlikte ele alır. İlk kapsam görüşmesine mevcut sipariş durumlarını, değişiklik taleplerinin bugün nasıl geldiğini ve hangi rolün onay verdiğini taşıyın. Böylece tasarım, gerçek iş akışını yansıtan sorularla değerlendirilebilir. Burada herhangi bir Yeşilyurt işletmesiyle yapılmış çalışma, yerel ofis veya elde edilmiş sonuç iddia edilmiyor.

Sık sorulan sorular

Ödemesi alınmış sipariş değiştirilebilir mi?

Bu, kullanılan platforma, siparişin hangi aşamada olduğuna ve istenen değişikliğin ödeme toplamına etkisine bağlıdır. Önce talebin doğru siparişe ait olduğunu ve paketin hazırlanmaya başlayıp başlamadığını kontrol edin. Ürün veya miktar değişiyorsa stok ve yeni toplamı tekrar değerlendirin. Ek ödeme ya da geri ödeme gerekiyorsa bu işlemin tamamlandığını ayrıca doğrulamadan siparişi kesinleşmiş gibi göstermeyin.

Adres değişikliği profilime de uygulanır mı?

Mevcut siparişin adresiyle müşteri hesabında saklanan varsayılan adres ayrı alanlardır. Müşteri hangisini değiştirmek istediğini açıkça seçebilmeli; mağaza talep etmediği bir hesap bilgisini sessizce değiştirmemelidir. Sipariş için adres kabul edilse bile paketin ve taşıyıcı etiketinin güncellenmesi gerekebilir. Müşteriye yeni adresin hangi kayıt için geçerli olduğu gösterilmelidir.

Sipariş ekranında talep formu sunmak zorunlu mudur?

Her mağaza aynı arayüzü kullanmak zorunda değildir. E-posta veya destek kanalı yeterli olabilir; önemli olan isteğin hangi siparişle ilişkilendirileceğinin, kimin inceleyeceğinin ve müşteri yanıtının nerede verileceğinin belirli olmasıdır. Form kullanılacaksa sadece kararı değerlendirmek için gereken alanlar sorulmalı, isteğin gönderilmesiyle değişikliğin yapılmadığı açıkça belirtilmelidir.

Ürün veya miktar değişince yeni sipariş mi açılmalı?

Bu tercih, mevcut platformun olanakları ve mağazanın satış, stok, fatura ve ödeme süreçleriyle birlikte belirlenir. Bir sistem mevcut kaydı düzenlemeye izin verirken başka bir sistemde yeni sipariş veya ayrı tahsilat daha uygun olabilir. Müşteriye iki ayrı sipariş numarası verilmesi gerekiyorsa bunların ilişkisi açıklanmalıdır. Uygulama kararı gerçek altyapıda test edilmeden evrensel kural gibi sunulmamalıdır.

Ek ücret veya geri ödeme ne zaman tamamlanmış sayılır?

Sipariş toplamının değişmesi, bankadaki hareketin tamamlandığını kendiliğinden göstermez. Platformda yeni tutarı görmek, ek tahsilatın sonucu veya iadenin müşteriye ulaştığı anlamına gelmeyebilir. Sipariş ve ödeme kaydındaki durumu sağlayıcının işlem sonucuyla karşılaştırın. Müşteriye hangi adımın tamamlandığını, hangisinin beklediğini ayrı ve anlaşılır biçimde bildirin.

Paket hazırlanırken gelen değişiklik talebinde ne yapılmalı?

Önce siparişin gerçek hazırlık aşamasını ve paketin taşıyıcıya verilip verilmediğini doğrulayın. Depo veya kargo etiketi eski bilgiyle işlem görmüşse ilgili sorumluya ulaşmadan ekranda değişiklik tamamlandı mesajı vermeyin. Yeni ürün, adres ve ücret bilgisi gerekiyorsa bunlar onaylandıktan sonra ilgili kayıtlar birlikte güncellenmelidir. Talep artık uygulanamıyorsa müşteriye mevcut seçenekleri mağazanın gerçek politikasıyla sınırlı kalarak anlatın.

Bir değişiklik geçmişi saklamak müşteriye ne sağlar?

Geçmiş, talebin alındığı zamanı, hangi alanın değiştiğini ve müşteriye hangi yanıtın verildiğini anlamayı kolaylaştırır. Bu kayıt, bir anlaşmazlıkta veya depo sorusunda kararın hangi bilgiye göre alındığını gösterebilir. Gereksiz kişisel bilgileri saklamak yerine değişiklik türü, işlem zamanı ve sorumlu rol gibi gerekli kayıt alanlarını belirleyin. Erişim ve saklama süresini işletmenin yetkilileri kararlaştırmalıdır.

Bu akış e-ticaret sitesi kurulurken mi planlanmalı?

Siparişin nasıl üretildiği, stok ve ödeme kayıtlarının hangi ekrana aktarıldığı yazılım tasarımını etkileyebilir. Bu nedenle ihtiyaç, proje başlangıcında en azından soru olarak gündeme alınmalıdır. İlk sürümde bütün otomasyonun yapılması şart değildir; manuel kontrol gerekiyorsa sorumlusu ve müşteriye verilecek durum bilgisi netleştirilmelidir. Daha sonra eklenen özellikler de test ortamında aynı sipariş senaryolarıyla denenmelidir.