# Satış sonrası, talep kayıtları ve ürün iadeleri

> Satış sonrası neredeyse her zaman bir e-posta kutusunda başlar ve sonunda orada kaybolur. Bu yazışmaları ilgili siparişe bağlı olarak mağazaya geri getirmek sık görülen bir ihtiyaçtır — ve yolun bir bölümü platform tarafından zaten alınmıştır.

- Source canonique : [https://allaux.fr/tr/modules/sav-tickets-et-retours](https://allaux.fr/tr/modules/sav-tickets-et-retours)
- Langue : TR
- Dernière mise à jour : 2026-09-30

## Platformun zaten yapabildikleri

PrestaShop'ta yerleşik bir müşteri hizmetleri alanı vardır: bir siparişe bağlı iletiler burada toplanır; konu başlıkları, durumlar ve bir çalışana atama içerir. Müşteri tarafında bir form, yönetim tarafında bir izlemeyle mal iadelerini de yönetir. Bu işlevler sınırlıdır ama gerçektir ve başka bir şey önermeden önce yalnızca kullanılmıyor olup olmadıklarını her zaman denetlerim.

WordPress ve WooCommerce tarafında yerleşik bir eşdeğeri yoktur: talepler sitenin formlarından gelir ve siparişler iç notlarını tutar, ancak yapılandırılmış bir izleme sunulmaz. Bu konuda iki platform arasındaki başlıca fark budur.

## Bu tür ihtiyaçlarda nasıl çalışıyorum

Üç ihtiyaç birbirinden net biçimde ayrılır ve bunları karıştırmak fazlasını geliştirmeye götürür. Birincisi talep izleme: her talebe bir durum vermek, kimin ilgilendiğini bilmek ve siparişe bağlı geçmişi bulabilmek. İkincisi mal iadesi: iade açmak, iade fişi üretmek, malı teslim almak, geri ödeme, alacak dekontu ya da değişim arasında karar vermek ve malı stoğa geri koymak — ya da koymamak. Üçüncüsü garanti: bir süreyi, bir seri numarasını, bir onarımı izlemek.

Eksik bölümü, ayrı bir araç kurmak yerine var olana bağlayarak geliştiririm. Bir iade; bir siparişe, belirli satırlara ve bir duruma bağlıdır ve düzeneğe değerini veren de bu bağdır, çünkü bilgiye araç değiştirmeden sipariş sayfasından ulaşmayı sağlar.

Bir sınırı dürüstçe belirtirim: talep hacmi büyüdüğünde ve birkaç kişi bu işle uğraştığında, özel bir destek aracı işi mağaza içindeki bir geliştirmeden daha iyi yapar. O zaman doğru geliştirme, aracı yeniden yazmak değil ikisini birbirine bağlamaktır.

## İlgili sayfalar

- **Özel sipariş durumları** — Bir iadenin ya da onarımın izlenmesine temel olan mekanizma. ([/prestashop/problemes/statuts-commande-personnalises](/prestashop/problemes/statuts-commande-personnalises))
- **E-posta ve SMS bildirimleri** — Talebinin her aşamasında müşteriyi bilgilendirmek için. ([/modules/notifications-email-et-sms](/modules/notifications-email-et-sms))
- **Yönetim paneline iş ekranı eklemek** — İzleme kendi listesini, süzgeçlerini ve dışa aktarımını hak ettiğinde. ([/modules/ecran-metier-dans-le-back-office](/modules/ecran-metier-dans-le-back-office))
- **İhtiyaca özel geliştirme** — Yerleşik işlevler yetmediğinde işin çerçevesi. ([/services/developpement-sur-mesure](/services/developpement-sur-mesure))

## FAQ

### PrestaShop'un yerleşik müşteri hizmetleri yeterli mi?

Orta düzeyde bir hacim ve tek bir kişinin ilgilenmesi durumunda çoğu zaman evet. Birkaç kişi arasında atama, otomatik hatırlatmalar ve izleme göstergeleri konusunda sınırlarını gösterir; bunlar orada yoktur.

### Bir iade ürünü otomatik olarak stoğa geri koymalı mı?

Bu verilmiş bir şey değil, bir karardır: iade edilen ürün her zaman yeniden satılabilir değildir. Stoğa geri koyma, denetimden sonra alınan açık bir eylem olarak kalmalıdır; yoksa görünen stok yanlışlanır.

### Mağaza mevcut bir destek aracına bağlanabilir mi?

Evet ve araç zaten kuruluysa çoğu zaman en iyi seçenek budur. İş, sipariş bağlamını araca göndermek ve talebin durumunu veriyi çoğaltmadan mağazada göstermektir.

### Geri ödeme yerine değişim nasıl yönetilir?

Değişim genellikle bir iade ve ardından sıfır ya da düzeltilmiş tutarlı yeni bir sipariş olarak temsil edilir. Muhasebede en okunaklı kalan temsil budur ve geliştirmeden önce netleşmesi gereken nokta da budur.