Pazaryeri Müşteri Hizmetleri ve Yönetim Operasyonu Nasıl Kurulur?

Pazaryeri Operasyonu İki Taraflı Hizmet Yönetimidir

Klasik mağazada müşteri ile işletme arasındaki sorunlar yönetilir. Pazaryerinde ise müşteri, satıcı, platform, ödeme ve lojistik tarafları aynı olayın farklı parçalarını oluşturabilir.

Bu nedenle destek ekibinin yalnız mesaj yanıtlaması yeterli değildir. Sipariş bağlamı, sorumluluk, SLA, kanıt, finansal etki ve karar geçmişi tek sistemde izlenmelidir.

1. Operasyon Alanlarını Ayırın

• Müşteri desteği.
• Satıcı desteği.
• Sipariş/kargo operasyonu.
• İade ve uyuşmazlık.
• Trust & Safety.
• Finans/hakediş.
• Katalog moderasyonu.
• Teknik entegrasyon.

Küçük ekipte aynı kişiler görev alabilir; fakat kuyruk ve sorumluluk tipleri ayrı olmalıdır.

2. Destek Talebi Veri Modeli

• ticket_id.
• Talep sahibi ve rolü.
• Konu/kategori.
• İlgili order/seller_order/item/shipment/return/payment ID.
• Öncelik.
• Durum.
• Sorumlu ekip/kullanıcı.
• SLA.
• Mesaj/kanıt geçmişi.
• Çözüm kodu.

3. Talep Kategorileri

Müşteri

• Sipariş durumu.
• Kargo.
• İptal.
• İade/refund.
• Ürün/satıcı şikâyeti.
• Ödeme.
• Hesap.

Satıcı

• Ürün/moderasyon.
• Sipariş/kargo.
• İade/uyuşmazlık.
• Hakediş.
• Entegrasyon.
• Hesap/yetki.

Kategori doğru yönlendirme, SLA ve kök neden raporlamasını mümkün kılar.

4. Önceliklendirme

• P1 kritik: ödeme/finans/güvenlik veya yaygın işlem kesintisi.
• P2 yüksek: aktif sipariş veya teslimatı ciddi etkileyen.
• P3 normal: standart operasyon talebi.
• P4 düşük: bilgi/iyileştirme talebi.

Öncelik yalnız müşterinin seçtiği etikete bırakılmamalı; olay tipi ve etkisine göre sistem kuralı kullanılmalıdır.

5. SLA Tasarımı

İlk yanıt ve çözüm hedefini ayırın.

• İlk yanıt süresi.
• İlk anlamlı aksiyon.
• Çözüm hedefi.
• Bekleyen taraf nedeniyle duraklatma kuralı.
• SLA ihlal alarmı.

SLA kategori ve önceliğe göre farklı olabilir.

6. Sipariş Bağlamlı Destek

Destek temsilcisi müşteri tekrar anlatmadan siparişin kritik olaylarını görebilmelidir.

• Sipariş kalemleri.
• Satıcı.
• Ödeme.
• Kargo.
• İade.
• Önceki destek talepleri.
• Finansal hareket özeti.
• Olay günlüğü.

7. Satıcıyla İletişim

Müşteri sorununu çözmek için satıcıdan bilgi gerekiyorsa talep içinde satıcı görevi oluşturulabilir.

• İstenen aksiyon.
• Son yanıt zamanı.
• Satıcı cevabı.
• Kanıt.
• SLA.

Müşterinin kişisel verisini gereksiz biçimde satıcıya aktarmayın.

8. Uyuşmazlık Akışı

1. Uyuşmazlık açılır.
2. Taraf ve sipariş doğrulanır.
3. Olay türü sınıflandırılır.
4. Gerekli kanıtlar istenir.
5. Sipariş/kargo/ödeme kayıtları incelenir.
6. Politika uygulanır.
7. Karar kaydedilir.
8. Finansal/operasyonel sonuç tetiklenir.
9. Taraflara bildirilir.

9. Kanıt Türleri

• Sipariş kayıtları.
• Kargo takip/teslim bilgisi.
• Ürün ilanının işlem anındaki snapshot'ı.
• Mesaj kayıtları.
• Fotoğraf/dosya uygun olduğunda.
• Ödeme/refund kayıtları.
• Satıcı işlem geçmişi.

Kanıtların saklanması ve erişimi veri koruma ve hukuki gereksinimlere uygun olmalıdır.

10. Politika Motoru

Benzer olaylarda benzer karar üretebilmek için uyuşmazlık kuralları yazılı hale getirilmelidir.

11. Manuel Karar Gerektiren Durumlar

• Çelişkili kanıt.
• Yüksek tutarlı işlem.
• Tekrarlayan kötüye kullanım sinyali.
• Hukuki talep.
• Standart politikanın kapsamadığı olay.
• Finansal risk.

Manuel karar veren kullanıcı gerekçe ve dayanak kaydetmelidir.

12. Trust & Safety Kuyruğu

• Sahte ürün şüphesi.
• Yanıltıcı ilan.
• Hesap ele geçirme şüphesi.
• Yorum manipülasyonu.
• Ödeme/dolandırıcılık risk sinyali.
• Yasaklı/kısıtlı ürün.
• Satıcı davranış ihlali.

Riskli içerik ve hesaplarda otomatik sinyal + insan incelemesi birlikte kullanılabilir.

13. Satıcı Yaptırım Seviyeleri

• Bilgilendirme.
• Uyarı.
• İyileştirme planı.
• Ürün/kategori kısıtı.
• Geçici operasyon kısıtı.
• Hesap askıya alma.
• Sözleşmesel koşullara göre sonlandırma.

Yaptırım ölçülü, gerekçeli ve politika ile uyumlu olmalıdır. Satıcının itiraz yolu varsa süreç açıkça gösterilmelidir.

14. Satıcı Performans İncelemesi

Tek olay yerine trendi izleyin.

• Satıcı kaynaklı iptal.
• Geç kargolama.
• İade.
• Uyuşmazlık.
• Stok doğruluğu.
• Müşteri değerlendirmesi.
• Politika ihlali.

Kategori yapısı farklıysa performans eşikleri bağlama göre değerlendirilebilir.

15. Müşteri Kötüye Kullanım Sinyalleri

Müşteri koruması güçlü olmalı; aynı zamanda sistematik kötüye kullanım sinyalleri izlenmelidir.

• Olağandışı iade paterni.
• Tekrarlayan teslim edilmedi iddiası.
• Kupon/referral kötüye kullanımı.
• Çoklu hesap sinyalleri uygun olduğunda.

16. Admin Operasyon Dashboard'u

• Yeni/kritik destek talepleri.
• Geciken satıcı siparişleri.
• Kargo istisnaları.
• İade/refund kuyruğu.
• Finansal mutabakat farkları.
• Risk incelemeleri.
• Katalog moderasyonu.
• Entegrasyon hataları.

Dashboard 'kaç kayıt var?' değil, 'hangi kayıt şimdi aksiyon istiyor?' sorusunu cevaplamalıdır.

17. Görev Sahipliği

Her kuyruk için birincil ekip ve eskalasyon sahibi tanımlayın.

18. Eskalasyon Matrisi

• Hangi olay?
• Kaç saat/gün sonra?
• Kime?
• Hangi veriyle?
• Müşteriye/satıcıya ne söylenecek?
• Hangi karar yetkisi var?

19. Hazır Yanıtlar ve Makrolar

Tekrarlayan yanıtlar standartlaştırılabilir; ancak müşteri olayına ait gerçek durum otomatik olarak metne çekilmelidir.

Yanlış veya eski durum bilgisi içeren otomatik yanıt güven kaybı yaratır.

20. İç Not ve Dış Mesajı Ayırın

Operasyon ekibinin iç değerlendirmeleri müşteri/satıcıya gönderilen mesajlardan ayrı tutulmalıdır.

• İç not.
• Müşteri mesajı.
• Satıcı mesajı.
• Sistem olayı.

21. Kök Neden Kodları

• Satıcı stok hatası.
• Satıcı geç kargo.
• Taşıyıcı gecikmesi.
• Ödeme hatası.
• Platform teknik hata.
• Yanlış katalog.
• Müşteri adresi.
• Politika/işlem belirsizliği.

Talep kapatılırken çözüm kodu kadar kök neden de seçilirse ürün ve operasyon iyileştirmesi yapılabilir.

22. Operasyon Raporları

• Talep hacmi.
• İlk yanıt/çözüm süresi.
• SLA ihlali.
• Tekrar açılan talep.
• Sipariş başına destek temas oranı.
• Kategori bazlı sorun.
• Satıcı bazlı sorun.
• Kök neden dağılımı.

23. Kalite Kontrol

Destek ve uyuşmazlık kararlarının örneklemini düzenli inceleyin.

• Politikaya uyum.
• Doğru veri kullanımı.
• Doğru finansal aksiyon.
• İletişim kalitesi.
• Gereksiz veri paylaşımı.
• Doğru çözüm kodu.

24. Operasyon Runbook'ları

Kritik olaylar için adım adım çalışma talimatı hazırlayın.

• Ödeme sağlayıcı kesintisi.
• Kargo entegrasyonu kesintisi.
• Toplu yanlış fiyat.
• Satıcı hesap ele geçirme şüphesi.
• Refund kuyruğu büyümesi.
• Sipariş oluşturma hatası.

Runbook; tespit, ilk aksiyon, sorumlu, iletişim, geri dönüş ve olay sonrası inceleme adımlarını içermelidir.

25. Olay Sonrası İnceleme

1. Ne oldu?
2. Ne zaman başladı/bitti?
3. Kim etkilendi?
4. Nasıl tespit edildi?
5. Kök neden neydi?
6. Geçici çözüm neydi?
7. Kalıcı düzeltme ne?
8. Tekrarı nasıl önlenecek?

Amaç suçlu bulmak değil, sistemin aynı hataya karşı daha dayanıklı hale gelmesidir.

26. Günlük Operasyon Ritmi

1. Kritik kuyrukları kontrol et.
2. Geciken sipariş/kargo.
3. İade/refund.
4. Finans istisnaları.
5. Risk olayları.
6. Entegrasyon hataları.
7. SLA ihlalleri.
8. Günün sahiplerini ve aksiyonlarını ata.

27. Haftalık Operasyon Review'u

• En büyük kök nedenler.
• En sorunlu kategori/süreç.
• Satıcı performans trendi.
• Kargo sağlayıcı performansı.
• Refund/finans sorunları.
• Teknik hata trendi.
• Runbook gerektiren tekrarlar.
• Ürün geliştirme backlog'u.

28. Kabul Testleri

1. Müşteri talebi siparişe bağlanıyor.
2. Satıcı görevi ayrı SLA alıyor.
3. P1 olay doğru ekibe yönleniyor.
4. Uyuşmazlıkta kanıtlar kaydediliyor.
5. Karar finansal aksiyonu tetikliyor.
6. Yetkisiz kullanıcı yaptırım uygulayamıyor.
7. Kritik olay eskale oluyor.
8. Talep kapatılırken kök neden seçiliyor.
9. İç not müşteriye görünmüyor.
10. Audit log karar sahibini gösteriyor.

Uygulama: Pazaryeri Operasyon Merkezi

1. Operasyon kuyruklarınızı tanımlayın.
2. Destek kategorilerini oluşturun.
3. P1–P4 öncelik kuralını yazın.
4. SLA tablosu hazırlayın.
5. Sipariş bağlamında gösterilecek verileri seçin.
6. Uyuşmazlık akışını yazın.
7. Trust & Safety kuyruğunu tanımlayın.
8. Yaptırım seviyelerini belirleyin.
9. Eskalasyon matrisi oluşturun.
10. Kök neden kodlarını yazın.
11. Üç kritik runbook hazırlayın.
12. Günlük ve haftalık review ritmini oluşturun.

KMK Pazaryeri Platformunu İnceleyinSatıcı, sipariş ve yönetim operasyonlarının çok satıcılı altyapıda nasıl merkezileştirilebileceğini inceleyin.

Kargo, iade ve günlük operasyon sistemi tamamlandı. Son bölümde tüm pazaryerini uçtan uca test ederek pilot yayına hazırlayacak, canlıya geçiş ve ilk 90 günlük yönetim planını oluşturacağız.