E-ticaret sitesinde iade ve değişim portalı; müşterinin siparişini doğrulayıp uygun ürünü seçtiği, talep nedenini bildirdiği, iade kargo adımını gördüğü ve süreci durum bazında takip ettiği self-servis bir ekran olarak kurulmalıdır. Arka tarafta ise talep → kargo → depoya ulaşma → ürün kontrolü → kabul/ret → bedel iadesi veya değişim sevkiyatı zinciri bulunmalıdır. Portal, yasal cayma hakkını daraltan ek bir engel değil; bildirimi ve operasyonu kayıt altına alan kolaylaştırıcı kanal olmalıdır.
İade portalının temel iş akışı nasıl olmalı?
| Aşama | Müşteri ekranı | Operasyon |
|---|---|---|
| Talep | Sipariş ve ürün seçimi | Sipariş/ürün doğrulama |
| Neden | İade/değişim nedeni | Neden kodu ve not |
| Kargo | Yöntem ve gerekli yönlendirme | Kargo kaydı/takip |
| Teslim alma | Kargoda / ulaştı durumu | Depo kabul |
| Kontrol | İnceleniyor | Ürün ve paket kontrolü |
| Karar | Kabul/ret açıklaması | Yetkili kararı |
| Sonuç | İade tamamlandı / yeni ürün gönderildi | Ödeme iadesi veya yeni sevkiyat |
Müşteri hangi sipariş ve ürünleri görebilmeli?
Oturum açmış müşteride yalnız kendi siparişleri gösterilmelidir. Misafir siparişte sipariş numarası tek başına yeterli doğrulama değildir; siparişe ait e-posta/telefon gibi ek doğrulama veya süreli bağlantı kullanılabilir. Çok ürünlü siparişte tüm siparişi değil, iade edilecek satır ve adedi seçtirmek stok, kargo ve ödeme hesaplarını daha güvenilir yapar.
İade ve değişim nedenleri nasıl tasarlanmalı?
Neden listesini raporlanabilir ama müşteriyi yönlendirmeyecek kadar tarafsız tutun: yanlış ürün, hasarlı ürün, beklenti/uyum, beden/ölçü, eksik parça veya diğer gibi. 'Diğer' için kısa açıklama alınabilir. Yasal hakların varlığı veya kapsamı yalnız seçilen neden koduna bağlanmamalıdır; operasyon kuralı ile tüketici hakkı birbirinden ayrılmalıdır.
Türkiye'de mesafeli satışlarda cayma süreci portala nasıl yansıtılmalı?
Ticaret Bakanlığının 17 Ağustos 2026 tarihli güncel bilgilendirmesine göre tüketici, mesafeli sözleşmelerde genel olarak 14 gün içinde gerekçe göstermeksizin ve cezai şart üstlenmeksizin cayma hakkına sahiptir; süre mal satışında teslimden itibaren işler ve teslimden önce de cayma bildirimi yapılabilir. Bildirimin yazılı veya kalıcı veri saklayıcısıyla yöneltilmesi yeterlidir. Bu nedenle portal 'neden zorunlu değil' seçeneğini destekleyebilmeli ve bildirimin zaman damgasını saklamalıdır.
Aynı Bakanlık bilgilendirmesi, tüketicinin cayma bildiriminden itibaren 14 gün içinde malı geri göndermesi gerektiğini; satıcının geri ödeme süresinin ilgili koşullara göre tüketicinin malı kargoya teslim ettiği tarihten başlayabildiğini ve geri ödemenin satın alırken kullanılan ödeme aracına uygun, masraf yüklemeden yapılması gerektiğini açıklar. Cayma hakkının istisnaları da vardır; portal ürün kategorisine göre otomatik karar verse bile sınır durumlarını insan incelemesine bırakmalıdır.
İade kargo adımı nasıl yönetilmeli?
Talep açıldığında kargo yöntemi, gerekiyorsa kod/etiket ve son gönderim tarihi müşteriye tek ekranda gösterilebilir. Kargo sağlayıcısından olay verisi alınabiliyorsa 'kargoya verildi' ve 'depoya ulaştı' durumlarını otomatik güncelleyin. Ancak yalnız kargo takibini 'iade kabul edildi' saymayın; fiziksel ürünün depo kontrolü ayrı aşamadır.
Depoda ürün kontrolü nasıl kayıt altına alınmalı?
| Kontrol | Kaydedilecek veri | Neden önemli? |
|---|---|---|
| Ürün eşleşmesi | SKU/varyant/adet | Yanlış sipariş satırını önler |
| Fiziksel durum | Standart durum kodu + not | Kararın gerekçesini izlenebilir yapar |
| Paket/içerik | Aksesuar/parça kontrolü | Eksik içerik takibi |
| Kanıt | Gerekliyse yetkili fotoğraf/not | Uyuşmazlık incelemesi |
| Karar | Kabul, kısmi kabul, inceleme | Finans ve stok akışını tetikler |
Depo personelinin serbest metinle farklı ifadeler yazması yerine standart durum kodları kullanın; gerekli durumda açıklama ekleyin. Ürünün tekrar satılabilir stoğa dönmesi, karantina/inceleme stoğuna alınması veya hurda sürecine ayrılması da ayrı stok hareketleri olmalıdır.
Bedel iadesi ödeme sistemiyle nasıl bağlanmalı?
Portal kararından sonra finans ekibinin manuel olarak sipariş aramasını azaltmak için kabul edilen tutarı ödeme işlemine bağlayın. Sistem iade talebi ID'si, sipariş ID'si, ödeme işlem referansı, iade edilen tutar ve sağlayıcı sonucunu saklamalıdır. Aynı talebin iki kez işlenmesini önlemek için idempotent işlem mantığı kullanın; ödeme sağlayıcısından belirsiz yanıt gelirse körlemesine ikinci iade göndermeyin.
Değişim talebi stok ve yeni sevkiyata nasıl dönüşmeli?
Değişim, teknik olarak yalnız 'iade nedeni' değildir. Yeni beden/varyant seçimi, stok rezervasyonu ve yeni sevkiyat gerektirir. İstenen varyant stokta yoksa müşteriye bekleme, alternatif veya iade seçenekleri gösterilebilir. Yeni ürün gönderildiğinde eski talep ile yeni sevkiyat arasında ilişki korunmalıdır.
Müşteriye hangi durumlar gösterilmeli?
| Durum | Müşteriye anlamı |
|---|---|
| Talep alındı | Başvuru kaydedildi |
| Kargo bekleniyor | Ürünün gönderilmesi bekleniyor |
| Kargoda | İade gönderisi yolda |
| Ürün ulaştı | Depo teslim aldı |
| İnceleniyor | Ürün kontrol ediliyor |
| İade onaylandı | Finans işlemi başlatılacak/başladı |
| Değişim hazırlanıyor | Yeni ürün sevkiyata hazırlanıyor |
| Tamamlandı | İade veya değişim süreci sonuçlandı |
| Ek inceleme | İnsan değerlendirmesi gerekiyor |
Kurgusal örnek: giyim mağazasında beden değişimi
Bu senaryo kurgusaldır ve gerçek Akhisar Dijital müşteri sonucu değildir. Türkiye genelinde satış yapan bir giyim mağazasında müşteri iki üründen yalnız birinin bedenini değiştirmek ister. Portal sipariş satırını ve yeni bedeni seçtirir, talep ID oluşturur ve iade kargo yönlendirmesini gösterir. Ürün depoya ulaştığında personel SKU ve fiziksel durumu doğrular; yeni beden için stok rezervasyonu yapılır ve değişim sevkiyatı aynı talep altında takip edilir. Böylece müşteri destek ekibi e-posta zincirlerinden durum aramak zorunda kalmaz.
Canlıya almadan önce kontrol listesi
| Kontrol | Beklenen durum |
|---|---|
| Yetkilendirme | Müşteri yalnız kendi siparişini görür |
| Kısmi iade | Sipariş satırı ve adet seçilebilir |
| Cayma bildirimi | Zaman damgası ve kayıt korunur |
| Kargo | Yöntem ve durum görünür |
| Depo | Ürün kontrolü ayrı aşamadır |
| Stok | İade/değişim stok hareketleri tanımlıdır |
| Ödeme | İade işlemi sipariş ve talep ID ile bağlıdır |
| Çift işlem | Tekrar gönderimde ikinci para iadesi oluşmaz |
| Bildirim | Durum değişiklikleri müşteriye iletilir |
| İnsan incelemesi | İstisna ve belirsiz durumların kuyruğu vardır |
Sık sorulan sorular
İade portalında müşteriden neden seçmesi zorunlu tutulmalı mı?
Genel cayma hakkının kullanılabildiği durumda gerekçe şartı koymayın. Operasyon analizi için isteğe bağlı neden sorulabilir; ürün veya işlem türüne göre mevzuattaki istisnalar ayrıca değerlendirilmelidir.
İade kargosu depoya ulaştığında otomatik para iadesi yapılmalı mı?
Her iş modelinde değil. Kargo teslim olayı ile ürün kontrolünü ayrı durumlar olarak yönetin; ödeme iadesini mevzuata ve işletmenin doğrulanmış karar akışına göre tetikleyin.
Değişim ve iade aynı kayıt modeliyle yönetilebilir mi?
Ortak talep modeli kullanılabilir; ancak değişimde yeni varyant, stok rezervasyonu ve yeni sevkiyat gibi ek adımlar bulunur.
Müşteri iade durumunu nereden görmeli?
Hesabındaki portal veya güvenli talep bağlantısı üzerinden talep alındı, kargo, depo kontrolü, karar ve tamamlanma durumlarını görebilmelidir.
Cayma hakkı her üründe aynı mı?
Hayır. Mesafeli Sözleşmeler Yönetmeliğinde istisnalar bulunur. Ürün kategorisi ve somut işlem için güncel mevzuatı ve işletmenizin hukuk danışmanlığını esas alın.