Pazar yeri operasyonları için uyuşmazlık çözümü takip sistemi

Pazar yeri uyuşmazlıklarını yönetmek neden zorlaşır?

Bir pazar yeri uyuşmazlığı genellikle düzenli bir vaka dosyası olarak başlamaz. Alıcı geciken teslimatla ilgili e-posta gönderir, satıcı sohbette yanıt verir ve destek temsilcisi bir e-tabloya not ekler. Ödeme ayrıntıları başka bir yerde durur. Birinin karar vermesi gerektiğinde aynı vaka dört farklı yerde bulunabilir.

Bu dağınıklık pahalı hatalara yol açar. Temsilci, satıcının daha önce gönderdiği takip kanıtını gözden kaçırabilir, aynı belgeyi iki kez isteyebilir veya finans ekibi satıcının ödemesini serbest bıraktıktan sonra para iadesini onaylayabilir. Son tarihler de baskı yaratır. Alıcılar, satıcılar ve ödeme sağlayıcıları genellikle belirli bir süre içinde yanıt bekler. Bir sonraki adımdan kimin sorumlu olduğu belli değilse vaka yoğun bir destek gününde gözden kaçabilir.

Her uyuşmazlığın ortak bir kayda ve vakayı ilerletecek tek bir sorumluya ihtiyacı vardır. Destek ekibi mesajları toplayabilir, operasyon ekibi politikayı inceleyebilir ve finans ekibi ödemeleri yönetebilir. Ancak belirli bir sorumlunun atanması, herkesin yanıtı başka birinin vereceğini varsaymasını önler.

Kullanışlı bir uyuşmazlık çözümü takip sistemi; sipariş, alıcı, satıcı, uyuşmazlık tutarı ve ödeme durumunu talebin nedeni, ilgili politika, kanıtlar, bir sonraki son tarih, mevcut sorumlu ve nihai kararla birlikte göstermelidir. Ayrıca para iadesini, ödemenin serbest bırakılmasını veya bloke edilmesini de kaydetmelidir.

Teslimatın hiç yapılmadığını söyleyen bir alıcıyı düşünün. Destek ekibi şikayeti ekler, satıcı teslimat kanıtını yükler ve operasyon incelemecisi sipariş zaman çizelgesini kontrol eder. Her şey tek bir vaka kaydında olduğunda incelemeci, gelen kutularını aramadan veya ekip arkadaşlarından bilgi istemeden karar verebilir.

Basit bir uyuşmazlık vakası

Bir alıcı, hasarlı bir kahve makinesi teslim aldıktan sonra vaka açar. Destek temsilcisi vaka kimliği, sipariş numarası, alıcı ve satıcı adları, satın alma tutarı, teslimat tarihi ve kısa bir açıklama içeren bir kayıt oluşturur: "Alıcı, teslimatta su haznesinin çatlak olduğunu bildiriyor."

Alıcı üç fotoğraf yükler ve tam para iadesi ister. Temsilci fotoğrafları vakaya ekler, istenen tutarı kaydeder ve alıcının destek ekibiyle iletişime geçtiği zamanı not eder. Satıcı daha sonra paketleme fotoğraflarını gönderir ve makinenin depodan sağlam çıktığını söyler. Temsilci bu yanıtı ve taşıyıcının teslimat kaydını aynı vakaya ekler.

Kısa bir durum akışı işi anlaşılır tutar:

• Yeni: Ekip talebi aldı.
• Satıcı yanıtı bekleniyor: Satıcının yanıt vermesi için hâlâ süresi var.
• İnceleniyor: Atanan incelemeci kanıtları kontrol ediyor.
• Karar verildi: Ekip sonucu kaydetti.
• Kapatıldı: Finans ödeme işlemini tamamladı ve her iki tarafa da bildirim gönderildi.

Teslimat kaydı teslim sırasında hasar olmadığını, ancak paketleme fotoğraflarının ürünün taşıma sırasında güvende kaldığını kanıtlamadığını gösteriyorsa pazar yeri 40 ABD doları tutarında kısmi para iadesini onaylayıp satıcının kalan ödemesini serbest bırakabilir. Vaka kaydında gerekçe, karar tarihi, onaylanan tutar ve ödeme işlemi yer almalıdır.

Tek başına durum etiketi yeterli değildir. Ekip mesajları, kanıtları, son tarihleri, kararları ve parayı aynı kayda bağlamalıdır.

Her vaka için gerekli bilgileri seçin

Her uyuşmazlıkta aynı formatı kullanın. Temsilciler farklı ayrıntıları farklı yerlere kaydettiğinde incelemeciler talebi değerlendirmeden önce temel soruların yanıtlarını aramakla zaman kaybeder.

Sipariş numarasından ayrı, benzersiz bir vaka kimliğiyle başlayın. Tek bir sipariş birden fazla sorun doğurabilir. DSP-2025-00418 gibi bir kimlik, destek, finans ve operasyon ekiplerine mesajlar ve raporlar için ortak bir referans sağlar.

Her kaydın ayrıca bir sorumlusu, önceliği ve mevcut durumu olmalıdır. Öncelikleri basit tutun: düşük, normal, yüksek ve acil. Acil seçeneğini kısa ödeme son tarihleri, ciddi dolandırıcılık şüpheleri veya aynı gün işlem gerektiren müşteri sorunları için kullanın.

Uyuşmazlığı tanımlayan ayrıntılar

Bir temsilcinin vakayı başka birkaç aracı açmadan anlayabilmesi için gereken bilgileri saklayın. Pazar yeri uyuşmazlık yönetimi için sipariş kimliği, ürün veya hizmet adı, işlem tarihi, ödeme yöntemi, alıcı ve satıcı adları ile hesap kimliklerini ekleyin.

Uyuşmazlık tutarını ve para birimini kaydedin, ardından bu tutarın neyi etkilediğini belirtin: alıcı para iadesi, satıcı ödemesi, platform ücreti veya bunların birkaçı. 75 ABD doları tutarındaki iade talebi ile 75 ABD doları tutarındaki ödeme blokesi aynı siparişle ilgili olabilir, ancak finans ekibi bu işlemleri farklı şekilde yürütür.

Yararlı vaka alanları şunlardır:

• Ürün teslim edilmedi, hasar gördü veya yetkisiz ödeme yapıldı gibi uyuşmazlık nedeni
• Alıcının veya satıcının uyuşmazlığı açtığı tarih
• Ödeme ve satıcı ödeme durumu
• Bağlantılı destek bileti, ödeme referansı veya teslimat referansı
• Vakanın sade bir dille yazılmış özeti

Örneğin bir incelemeci DSP-2025-00418 numaralı, yüksek öncelikli ve Maya'ya atanmış bir vaka görebilir. Vaka ORD-8821 numaralı siparişe bağlıdır. Alıcı kameranın hasarlı geldiğini söylüyor, satıcı talebe itiraz ediyor ve pazar yeri 240 ABD doları tutarındaki satıcı ödemesini bloke etmiş durumda. Bu özet, bir sonraki temsilciye net bir başlangıç noktası verir.

Herkesin aynı şekilde anlayacağı durumlar kullanın

"Aktif" veya "devam ediyor" gibi belirsiz etiketlerden kaçının. Bu ifadeler ekibin işlem yapması mı yoksa başka birini mi beklemesi gerektiğini göstermez.

Genellikle küçük bir durum kümesi yeterlidir: yeni, alıcı yanıtı bekleniyor, satıcı yanıtı bekleniyor, inceleniyor, karar verildi, ödeme bekleniyor ve kapatıldı. Her değişikliğin hangi koşulda yapılacağını tanımlayın. Örneğin vaka, istenen fotoğraflar, mesajlar veya teslimat kanıtı geldikten sonra kanıt bekleniyor durumundan inceleniyor durumuna geçebilir.

Kararı ayrı bir alanda tutun. Ekibin para iadesini onaylayıp onaylamadığını, ödemeyi serbest bırakıp bırakmadığını, tutarı bölüp bölmediğini, talebi reddedip reddetmediğini veya başka bir işlem yapıp yapmadığını kaydedin. Karar tarihini ve kararı veren kişiyi de ekleyin. Böylece finans ekibi, durumun ne anlama geldiğini tahmin etmeden ödeme uyuşmazlığı sürecini kontrol edebilir.

Oluşturmadan önce iş akışını haritalayın

Takip sistemi, ekibinizin karar verme biçimine uymalıdır. Para iadesi talebi, teslimatın kaybolması, ilandaki üründen farklı bir ürün veya yetkisiz ödeme gibi vakayı açan olaylarla başlayın. Her olay; neden, tarih, sipariş referansı ve atanmış sorumluyla birlikte bir vaka oluşturmalıdır.

Ekranları veya alanları oluşturmadan önce iş akışını sade bir dille yazın. Bir teslimat şikayeti şu yolu izleyebilir: alıcı talebi gönderir, ekip sipariş ayrıntılarını ve teslimat kanıtını ister, satıcı yanıt verir, operasyon temsilcisi belgeleri inceler ve incelemeci sonucu kaydeder. Süreci yazıya dökmek eksikleri erkenden ortaya çıkarır.

Herkese net bir görev verin

Belge toplayan kişinin para iadesini onaylama yetkisine her zaman sahip olması gerekmez. Ekibinizin büyüklüğüne ve risk düzeyine uygun roller belirleyin:

• Destek ekibi vakayı açar ve talebin yeterli bilgi içerdiğini kontrol eder.
• Operasyon ekibi kanıtları toplar, alıcı veya satıcıyla iletişime geçer ve bulguları kaydeder.
• Yönetici, yüksek tutarlı iadeleri, ödeme geri alma işlemlerini veya hesap kısıtlamalarını onaylar.
• Finans ekibi paranın hareket ettiğini doğrular ve işlem referansını ekler.

Küçük ekipler bu görevleri birleştirebilir. Yine de takip sistemi her kararı kimin ve ne zaman verdiğini kaydetmelidir. Alıcı, talebinin neden reddedildiğini sorduğunda veya satıcı geciken ödemeyi sorguladığında bu geçmiş önem kazanır.

Karardan sonra işi tamamlayın

Karar verildiğinde vaka kendiliğinden kapanmaz. Ekip alıcıya para iadesini onayladıysa finans bunu gerçekleştirmelidir. Talep reddedildiyse birinin açıklama göndermesi ve itiraz süresi boyunca vakayı açık tutması gerekebilir.

Her sonucu belirli bir işleme bağlayın: alıcıya para iadesi yapın, satıcının ödemesini serbest bırakın, parayı bloke edin, siparişi kısmen iade edin veya hesap işlemi uygulayın. İşlemin tamamlandığı zamanı kaydedin.

AppMaster'da görsel bir iş süreci vaka durumunu güncelleyebilir, bir sonraki ekip arkadaşını atayabilir ve onaydan sonra ödeme görevi oluşturabilir. Böylece kayıt hem kararı hem de gerekli işlemin yapıldığına dair onayı gösterir.

Kanıtları ve mesajları bir arada tutun

Bir incelemeci gelen kutusunda arama yapmak, bir ekip arkadaşından ekran görüntüsü istemek veya hangi belge sürümünün güncel olduğunu tahmin etmek zorunda kalmamalıdır. Yüklenen dosyaları, vaka notlarını ve mesaj geçmişini durum, son tarih ve ödeme ayrıntılarıyla birlikte saklayın.

Bu, sorumluluk değiştiğinde özellikle önemlidir. Bir temsilci pazartesi günü vakayı başlatır ve başka bir temsilci perşembe günü incelerse ikinci kişinin tüm bağlama hemen ulaşması gerekir. Eksiksiz bir kayıt, kararı taraflardan birine açıklamayı da kolaylaştırır.

Her kanıt öğesini etiketleyin

photo_1023.jpg adlı bir dosya incelemeciye çok az bilgi verir. Her öğeye kısa bir açıklama ve temel bağlam ekleyin:

• Alındığı veya oluşturulduğu tarih ve saat
• Alıcı, satıcı, taşıyıcı veya operasyon temsilcisi gibi kaynak
• Öğenin ne gösterdiğine dair açıklama
• Fotoğraf, fatura, teslimat kanıtı veya sohbet ekran görüntüsü gibi kanıt türü
• Alıcının talebini, satıcının yanıtını destekleyip desteklemediği veya hiçbirini desteklemediği

Örneğin: "14 Mayıs'ta taşıyıcıdan alındı. Paketi binanın girişinde gösteriyor, ancak daire numarası görünmüyor." Bu not, bir sonraki incelemecinin varsayım yapmadan görüntüyü değerlendirmesine yardımcı olur.

Bu ayrıntıları ayrı bir e-tabloya koymak yerine dosyayla birlikte saklayın. Böylece ekip daha fazla bilgi istemeden veya ödeme onaylamadan önce vaka kaydını kontrol edebilir.

Özel notları dış mesajlardan ayırın

Dahili notlar ve müşteri mesajları farklı görünürlük düzeylerine sahip olmalıdır. Bir temsilci, satıcının daha önce benzer taleplerde bulunduğunu veya yöneticinin ödemeyi serbest bırakmayı onaylaması gerektiğini not edebilir. Alıcılar ve satıcılar bu yorumları asla görmemelidir.

Her mesaja net bir hedef kitle verin: dahili ekip, alıcı veya satıcı. Dış mesajları gönderen, alıcı ve teslimat durumuyla birlikte tarih sırasına göre gösterin. Dahili notları ayrı bir akışta tutun ve yazarı belirtin.

AppMaster, ilgili kanıt ve mesaj kayıtları bulunan bir vaka modeli oluşturabilir, ardından operasyon çalışanları ve dış kullanıcılar için ayrı görünümler sunabilir. Bu yapı, ekiplerin özel yorumları gizli tutmasına ve eksiksiz bir vaka geçmişi oluşturmasına yardımcı olur.

Son tarihleri manuel takip olmadan yönetin

Çoğu uyuşmazlığın birden fazla son tarihi vardır. Alıcının ekran görüntülerini göndermek için üç, satıcının yanıt vermek için beş günü olabilir. Operasyon ekibinin de son yanıttan sonra 24 saat içinde vakayı incelemesi gerekebilir. Her son tarihi sorumlusu ve mevcut durumuyla birlikte kayda ekleyin.

Genel bir "son tarih" alanına güvenmeyin. Bu alanın kimin, neden işlem yapması gerektiğini gizler. Alıcı yanıtı, satıcı yanıtı, dahili inceleme, nihai karar ve para söz konusu olduğunda ödeme blokesi veya serbest bırakma için ayrı alanlar kullanın.

Hasarlı sipariş talebi pazartesi günü açılabilir. Alıcının fotoğrafları yüklemek için perşembeye, satıcının yanıt vermek için cumaya kadar süresi olabilir. Atanan temsilci de her iki yanıt geldikten sonraki ilk iş gününde karar vermelidir. Her tarihin net bir amacı vardır.

Geciken işleri görünür kılın

İşlem gerektiren vakalar için günlük bir görünüm oluşturun. Bugün sona erecek, yakında sona erecek ve gecikmiş son tarihleri gösterin. Kaçırılan son tarihleri yaşına göre sıralayın, ardından sorumluyu, durumu ve ödeme tutarını veya bloke durumunu gösterin.

Kapalı vakaları ve gelecekteki bir son tarihi bekleyen işleri bu görünümün dışında tutun. Operasyon lideri her sabah bu görünümü kontrol edebilir, sorumlusu olmayan vakaları atayabilir ve ödeme gecikmesi şikayete dönüşmeden önce temsilcilere yardımcı olabilir.

Durum renkleri işe yarayabilir, ancak sade etiketler daha önemlidir. "Son tarih bugün", "2 gün içinde" ve "1 gündür gecikmiş" gibi ifadeler kullanın. Metin, dışa aktarımlarda, mobil görünümlerde ve erişilebilirlik araçlarında da anlaşılır kalır.

İşlem yapabilecek kişiye bildirim gönderin

Hatırlatmaları ortak bir gelen kutusuna değil, sorumlu kişiye gönderin. Normal bir son tarihten 24 saat önce gönderilen tek bir hatırlatma çoğu zaman yeterlidir. Kısa dahili incelemelerde son tarihten iki saat önce hatırlatma gerekebilir.

Son tarih geçtiğinde önce sorumlu kişiye bildirim gönderin. Vaka belirlenmiş ek süre sonunda hâlâ açıksa ekip liderini uyarın. Bu yaklaşım, tekrarlanan mesajları önlerken geciken vakaları görünür tutar.

AppMaster ile görsel bir iş süreci mevcut zamanı vaka son tarihleriyle karşılaştırabilir, vaka etiketini güncelleyebilir ve atanan sorumluya e-posta, SMS veya Telegram bildirimi gönderebilir. Geciken vakaları günlük takip görünümüne de ekleyebilir.

Takip sistemini adım adım oluşturun

Bir vaka tablosuyla başlayın. Her uyuşmazlığa vaka kimliği verin ve vakayı siparişe, alıcıya, satıcıya ve atanmış ekip üyesine bağlayın. Durum, vaka türü, açılış tarihi, yanıt son tarihi, karar, ödeme tutarı ve ödeme durumunu ekleyin.

Kanıtları bir mesaj dizisine gömülü notlar yerine ilgili kayıtlar olarak saklayın. Her kanıt kaydında dosya, açıklama, gönderen ve alınma tarihi bulunabilir. İncelemeciler, her iki tarafın da istenen kanıtı gönderip göndermediğini hızlıca görebilir.

Ekibinizin gerçekten ihtiyaç duyduğu formları oluşturun: ilk şikayet için talep formu, belgeler ve fotoğraflar için kanıt formu, personel için dahili notlar ve sonuç, gerekçe, incelemeci, iade veya satıcı ödeme değişikliğini içeren karar formu.

AppMaster, aynı veri modeline bağlı görsel araçlarla bu web veya mobil ekranları oluşturmanıza olanak tanır. Business Process Editor, rutin güncellemeleri yönetebilir; böylece temsilcilerin her alanı manuel olarak değiştirmesi gerekmez.

Rutin işler için kurallar belirleyin:

• Yeni vakaları uyuşmazlık türüne veya belirli bir sorumluya göre atayın.
• Kanıt geldiğinde veya incelemeci karar kaydettiğinde durumu güncelleyin.
• Alıcı ve satıcı yanıt son tarihlerinden önce hatırlatmalar gönderin.
• Vaka geciktiğinde ekibi uyarın.
• Ödemeyi bloke etmeden, serbest bırakmadan veya değiştirmeden önce nihai karar kaydı isteyin.

İlk iş akışını kısa tutun. Yeni, kanıt bekleniyor, inceleniyor, karar verildi ve kapatıldı durumları birçok vakayı kapsar. İstisnaları yalnızca gerçek iş ihtiyaç duyduğunda ekleyin.

Canlı vakaları içe aktarmadan önce takip sistemini gerçekçi örneklerle test edin. Teslimatın yapılmadığı bir talep oluşturun, teslimat kanıtı isteyin, yanıtı ekleyin, karar kaydedin ve ödeme işleminin bu kararla eşleştiğini doğrulayın. İkinci bir ekip arkadaşından vaka geçmişini ek açıklama olmadan okumasını isteyin. Ayrıca geciken bir son tarihi test ederek hatırlatmanın ve günlük görünümün beklendiği gibi çalıştığını doğrulayın.

Daha sonra karışıklığa yol açan hatalar

Kısa yollar uzun temizlik işlerine dönüşür. Takip sistemi ne olduğunu, her kararı kimin verdiğini ve nedenini korumalıdır. Personel eski kayıtları iz bırakmadan değiştirebiliyorsa incelemeciler satıcının eksik kanıt mı gönderdiğini yoksa birinin vakayı daha sonra mı düzenlediğini anlayamaz.

İlk şikayeti dahili notlardan ayrı tutun. Şikayet metnini, gönderim zamanını, ekleri ve göndereni değiştirilemeyen bir kayıt olarak saklayın. Müşteri teslimat tarihini düzeltir veya fotoğraf eklerse ilk kaydı değiştirmek yerine yeni bir kayıt ekleyin.

Belirsiz durumlar da güvenilmez iş kuyrukları oluşturur. "Beklemede" alıcının, satıcının, ödeme sağlayıcısının veya dahili incelemecinin beklendiği anlamına gelebilir. Hem vakanın durumunu hem de işlem yapması beklenen kişiyi belirten adlar kullanın.

Finans para iadesini, ödemenin serbest bırakılmasını, ücret iadesini veya kısmi ödemeyi onaylamadan önce gerekçe, incelenen kanıt, onaylayan kişi, tutar ve tarihi içeren bir karar kaydı isteyin. Daha yüksek tutarlarda veya politika istisnalarında ikinci bir onay mantıklı olabilir.

Kapatılmış vakaları sipariş numarası, alıcı, satıcı, sorun türü, karar ve tarihe göre aranabilir tutun. Geçmiş vakalar ekibin soruları yanıtlamasına, şikayetleri nasıl ele aldığını incelemesine ve tekrarlanan satıcı sorunlarını fark etmesine yardımcı olur.

İşe yarayan ilk sürümle başlayın

Ekibinizin sık karşılaştığı tek bir uyuşmazlık türünü seçin. Hasarlı siparişler ve teslim edilmeyen ürünler iyi başlangıç noktalarıdır, çünkü kanıtları ve ödeme sonuçları genellikle nettir. Dar kapsamlı ilk sürüm, projeyi uzun bir fikir listesine dönüştürmeden ekibe kullanışlı bir araç sunar.

Teslimatın yapılmadığı bir talep için sipariş numarası, alıcı ve satıcı bilgileri, talep tarihi, mesajlar, teslimat kanıtı, karar, ödeme tutarı ve son tarihle başlayın. Ekibin kullanmak için gerçek bir nedeni olana kadar isteğe bağlı alanları eklemeyin.

Uyuşmazlıkları inceleyen kişilerden formları ve durumları gerçekçi örneklerle test etmelerini isteyin. İsimleri ve hassas ayrıntıları kaldırılmış eski vakaları kullanın. Bu kişiler ayrı notlar tutmadan vaka açabilmeli, kanıt ekleyebilmeli, bilgi isteyebilmeli, karar kaydedebilmeli ve ödeme uyuşmazlığı sürecini tamamlayabilmelidir.

İncelemecilerin farklı düşündüğü noktaları izleyin. Biri "satıcı yanıtı bekleniyor", diğeri "kanıt gerekli" seçeneğini işaretliyorsa durum tanımlarını netleştirin. Her durumun altına kısa bir açıklama eklemek, daha fazla etiket eklemekten çoğu zaman daha iyi sonuç verir.

AppMaster, vaka, kanıt, mesaj, son tarih ve ödeme kayıtlarına sahip kodsuz bir uyuşmazlık çözümü takip sistemi oluşturmanıza yardımcı olabilir. Veri yapısı için Data Designer'ı, inceleme ve onay adımları için Business Process Editor'ı, incelemeciler ve yöneticiler için web veya mobil arayüz oluşturucularını kullanın. AppMaster, iş akışı değiştikçe arka uç, arayüzler ve uygulamanın kaynak kodunu oluşturur.

Birkaç canlı vakadan sonra incelemecilerin doğru kaydı hızlıca bulup bulamadığını, her son tarihin bir sorumlusu olup olmadığını ve yöneticilerin bir ödemenin neden onaylandığını veya reddedildiğini görebilip göremediğini kontrol edin. İadeler, sahte ürün talepleri, ödeme uyuşmazlıkları veya satıcı itirazları gibi yeni alanlar eklemeden önce günlük sorunları düzeltin.