Ticari Sağlık Metodolojisi
Sürüm 1.1·Yürürlük 1 Temmuz 2026
BM-THM-v1.1
English version governs. The legally binding version of this document is the English version 1.1 (content fingerprint
bb88bfe44dccad3a8c354a9ddc2468989ba9b0b87e59e53c2649bbf76814f4ea). This translation is provided for convenience only.The binding English version is available at this permalink.
Bu sayfa, Berry Marketplace’in her şirket profilinde, ilan kartında ve platform genelindeki teklif yüzeylerinde gösterilen Ticari Sağlık Skorunu (Ticari Sağlık Skoru) nasıl hesapladığını açıklar. Platform Şartları’nın 7. bölümü (İtibar Sistemi) yürürlüğe girdiğinden beri Berry’nin bu hükümleri nasıl yorumladığını belgeler ve şeffaflık için burada yayımlanmıştır. Bağımsız bir sözleşme değildir ve kabul gerektirmez.
Ticari Sağlık Skoru nedir?
Ticari Sağlık Skoru, Berry tarafından bir şirketin platformdaki doğrulanmış ticaret geçmişinden hesaplanan 0 ile 100 arasında bir sayıdır. Kullanıcılar tarafından yazılan değerlendirmelerle birlikte (ve asla bunlarla karıştırılmadan) gösterilir; böylece karşı taraflar tek bakışta iki ayrı sinyal okuyabilir:
- Yıldızlar — diğer şirketlerin bir şirket hakkında kendi ifadeleriyle söyledikleri.
- Ticari sağlık — bir şirketin kendi ticaret kaydının onun hakkında söyledikleri, Berry tarafından nesnel olaylardan hesaplanan.
Bir şirketin skoru, skoru besleyen bir ticari olay gerçekleştiğinde otomatik olarak güncellenir (sözleşme tamamlanır, anlaşmazlık sonuçlanır, fatura ödenir, teslimat kaydedilir). Canlı tetikleyicilerin kaçırmış olabileceği olayları yakalamak için günlük bir yedek yeniden hesaplama 06:30 UTC’de çalışır.
Skor, ait olduğu bant ve bileşen bazında döküm her şirket profilinde görünür. Şirketler, kendi skorlarını besleyen tek tek olayları Şirketim → Ticari sağlık etkinliği sekmesinde görebilir.
Bantlar
| Skor | Bant |
|---|---|
| 90–100 | Mükemmel |
| 75–89 | İyi |
| 60–74 | Orta |
| 60’ın altı | Dikkat gerektiriyor |
| Tamamlanmış sözleşme sayısı 3’ten az | Yetersiz ticaret geçmişi (yayımlanmış skor yok) |
Platformda üçten az tamamlanmış sözleşmesi olan bir şirket skor yerine “Oluşturuluyor (3 üzerinden X)” gösterir. Bu, yeni şirketleri seyrek veri yüzünden cezalandırmayı önler. Eşik aşıldığında skor görünür.
Bileşenler ve ağırlıklar
Skor dört bileşenin ağırlıklı ortalamasıdır. Ağırlıklar toplamı 1,00’dır.
| Bileşen | Ağırlık | Ne ölçer |
|---|---|---|
| Anlaşmazlık oranı | %35 | Sorunsuz tamamlanan sözleşmelerin, kalite sorunu veya anlaşmazlık içerenlere oranı; sonuç ağırlığına göre ağırlıklandırılır. |
| Zamanında teslimat | %25 | Bir şirketin teslimatlarının programa ne kadar yakın geldiği (satıcı tarafı sinyali). |
| Komisyon ödeme zamanında gerçekleşmesi | %20 | Bir şirketin Berry’nin işlem başına komisyon faturalarını vadesinde veya vadesinden önce ödeyip ödemediği (alıcı tarafı sinyali). |
| Anlaşmazlığa yanıt oranı | %20 | Bir şirketin kendisine açılan anlaşmazlıklarda anlaşmazlığın yanıt penceresi içinde angaje olup olmadığı. |
Her bileşen bağımsız olarak 0,0 ile 1,0 arasında bir değer olarak hesaplanır, ardından ağırlığıyla çarpılır. Bileşen değerleri toplanır ve şirket için en az bir olayı olan bileşenlerin toplam ağırlığına bölünür. Sonuç, gösterilen skoru üretmek için 100 ile çarpılır.
Bir şirket belirli bir bileşen için olay içermiyorsa (örneğin yalnızca satmış bir şirketin komisyon ödeme geçmişi yoktur), o bileşen hem payda hem paydadan çıkarılır — skoru ne iyileştirir ne kötüleştirir.
Zaman skoru nasıl etkiler?
Ticari sağlık bir sulandırma modeli kullanır, eksiltme (decay) modeli değil. Bu önemli bir ayrımdır.
Eksiltme modeli der ki: “Eski olaylar zamanla daha az sayılır.” Berry bunu yapmaz. Eski olaylar tam ağırlıkla, süresiz sayılır.
Sulandırma modeli der ki: “Her yeni tamamlanan sözleşme kaydınıza eklenir ve iyi davranış biriktikçe genel oranınız otomatik iyileşir.” Berry bunu yapar.
Pratik sonuç: Tek eski bir sorunu ve ardından gelen çok sayıda temiz işlemi olan bir şirket skorunun doğal olarak yükseldiğini görür — sorun silinmez, ancak şirketin toplam ticaret geçmişindeki aritmetik payı, eklenen her temiz sözleşmeyle küçülür. Sorundan çıkış yolu ticaretle mümkündür — her temiz sözleşme önceki bir sorunun etkisini sulandırır; sorunun hiç olmamış gibi davranılmaz.
Eski olayları “unutmuyoruz”. Üç yıllık bir anlaşmazlık, bir aylık anlaşmazlıkla aynı aritmetik ağırlıkta sayılır. Değişen, o olayın şirketin toplam kaydındaki payıdır.
Bu metodolojinin gelecek bir sürümü, veriler pasif şirketler için sinyali iyileştiriyorsa simetrik bir güncellik katmanı (eski olaylara hafifçe daha az ağırlık) getirebilir. Getirilirse yalnızca simetrik katman olur — yakın zamanlı olayları orantısız şekilde büyüten bir eğri olmaz. Böyle bir değişiklik, Berry’nin metodoloji evrimi üzerindeki takdir hakkını saklı tutan Platform Şartları 7.3’e uygun olarak bu sayfanın yeni bir sürümü (v1.1, v2.0 vb.) olarak yayımlanır.
Gelecek bir sürüm ayrıca Bayesci büzülme (Bayesian shrinkage) getirebilir — bu istatistiksel teknik, 3 sözleşme eşiğine yakın şirketler için skor oynaklığını, oranlarını platform geneli ortalamaya nazikçe çekerek azaltır. v1.0 basit bir kesim kullanır (3 sözleşmenin altında yayımlanmış skor yok); v2.0 bunu eşiğin üzerinde büzülme ile yumuşatma olasılığı yüksektir. v1.0’da bulunmamasını açıklıyoruz ki ileride eklenmesi sürpriz olmasın.
Bileşen ayrıntıları
Anlaşmazlık oranı (ağırlık %35)
Kaynak: COMPLETED durumuna ulaşan her sözleşme. Her tamamlanan sözleşme
etkilenen her taraf için (alıcı ve satıcı) bir satır üretir; satırın
değeri o sözleşmedeki en kötü kalite sonucuna göre belirlenir. Temiz işlemler
tam sayılır; kalite sorunu veya anlaşmazlığı olan işlemler sorunun nasıl
çözüldüğüne ve kusurun kime yüklendiğine bağlı olarak oransal olarak daha az
sayılır.
| Sözleşmedeki sonuç | Kusurlu taraf için değer | Karşı taraf için değer |
|---|---|---|
| Temiz işlem — kalite sorunu yok, anlaşmazlık yok | 1,00 | 1,00 |
| Kalite sorunu iki taraflı çözüldü (resmi anlaşmazlık yok) | 0,85 | 0,85 |
| Anlaşmazlık → talep geri çekildi (genelde platform dışı çözüldü) | 1,00 (yanıtlayan) | 0,95 (başlatan) |
| Anlaşmazlık → mutabık kalınmış eylem yok (talepler karşılıklı düştü) | 0,95 (yanıtlayan) | 0,92 (başlatan) |
| Anlaşmazlık → kusur kabulü, tam iade (para iadesi veya değişim) | 0,50 | 1,00 |
| Anlaşmazlık → kusur atfı ile kısmi iade anlaşması | 0,50 | 0,95 |
| Anlaşmazlık → taraf kusuru olmadan çözüldü (uzlaşma) | 0,70 | 0,70 |
| Anlaşmazlık → harici tahkime sevk | 0,60 | 0,60 |
| Anlaşmazlık → talep süresi doldu (angaje yok, zaman aşımı) | 0,10 (yanıtlayan) | 0,50 (başlatan) |
Bu tabloyu okurken birkaç not:
- Adil çözülmüş bir anlaşmazlık yine de bir miktar sayılır. Haklı bir şikayetten sonra değişim gönderen bir satıcı o satırda 1,0 değil 0,50 alır. Değişim doğru yanıttı, ancak gerçek bir sorun yaşandı ve skor bunu yansıtır. Değişim, tam para iadesi ve mağaza kredisi eşdeğer işlenir — iadenin biçiminden bağımsız olarak kusur atfı aynıdır.
- Geri çekilen talepler iyimser yorumlanır. Talebin geri çekilmesinin en yaygın nedeni platform dışı dostane çözümdür. Yanıtlayan taraf temiz 1,00 alır; başlatan 0,95.
- Şikayeti görmezden gelmek rutinde en kötü sonuçtur. Angaje olmadan talebin süresinin dolmasına izin veren yanıtlayan taraf 0,10 alır. Çekilen başlatan taraf da 0,50 alır.
- Harici tahkim her iki taraf için de 0,60’ta tutulur ta ki tahkim sonucu platforma işlenene kadar; o zaman skor o sonuca göre yeniden hesaplanır.
Zamanında teslimat (ağırlık %25)
Kaynak: kaydedilen her teslimat (teslim edilmiş contract_deliveries
satırı). Gecikme günü, gerçek teslimat tarihi − planlanan tarih olarak
hesaplanır, sıfır altına indirgenir (erken teslimatlar zamanında ile aynı
puanı alır).
| Gecikme (gün) | Değer |
|---|---|
| 0 (programda veya öncesinde) | 1,00 |
| 1–3 gün | 0,70 |
| 4–7 gün | 0,40 |
| 8–14 gün | 0,20 |
| 15+ gün | 0,10 |
Bu sinyal satıcıya yazılır: yalnızca satıcının skoru etkilenir.
Komisyon ödeme zamanında gerçekleşmesi (ağırlık %20)
Kaynak: durumu PAID olan her komisyon faturası (alıcıya yansıtılan işlem
başına Berry ücreti). Gecikme günü, ödeme tarihi − vade tarihi olarak
hesaplanır, sıfır altına indirgenir.
| Gecikme (gün) | Değer |
|---|---|
| 0 (vade veya öncesinde ödendi) | 1,00 |
| 1–3 gün | 0,80 |
| 4–7 gün | 0,40 |
| 8–14 gün | 0,20 |
| 15+ gün | 0,10 |
Yalnızca 1–3 gün bandında zamanında teslimattan biraz daha hoşgörülü — SEPA banka mutabakatı meşru olarak 1–2 gün sürebilir. Eğriler 4. günden itibaren birleşir; banka gecikmesi açıklamaları artık geçerli değildir.
Bu sinyal alıcıya yazılır: yalnızca alıcının skoru etkilenir.
Abonelik faturaları Ticari Sağlığın parçası değildir. Berry’nin aylık veya yıllık platform aboneliği, her şirket ile Berry arasında ticari bir ilişkidir; şirketin karşı taraflara nasıl sunulduğundan ayrıdır. Abonelik tahsilatını karşı tarafın gördüğü itibar ölçüsüne katmak iki ilgisiz ilişkiyi birbirine karıştırır; bu yüzden yapmıyoruz.
Alıcıdan satıcıya sözleşme ödemeleri de Ticari Sağlığın parçası değildir. Bu ödemeler platform dışında (genelde doğrudan havale ile) yapılır ve Berry’nin ne zaman tahsil edildiğine dair yetkili kayıtları yoktur. Berry’nin sözleşme ödemelerinde arabuluculuk rolü gelecekte genişlerse bu bileşen eklenebilir.
Anlaşmazlığa yanıt oranı (ağırlık %20)
Kaynak: şirkete karşı açılan her anlaşmazlık (bu şirket yanıtlayan olduğunda).
| Yanıt davranışı | Değer |
|---|---|
| Anlaşmazlığın yanıt penceresi içinde yanıtlandı | 1,00 |
| Pencereden sonra ama sonuçlanmadan önce yanıtlandı | 0,50 |
| Hiç yanıt verilmedi | 0,00 |
Yanıt penceresi, anlaşmazlığın respondentDeadline alanından anlaşmazlık
başına okunur — kodla sabit 7 gün değildir. B2B tarım anlaşmazlıkları numune
testi, laboratuvar analizi, tatil dönemleri ve mücbir sebep durumları için
değişken yanıt pencerelerini haklı olarak gerektirir; sistem buna yer verir.
İlgili soru “7 gün içinde yanıt verdiniz mi?” değildir; “bu belirli
anlaşmazlık için geçerli olan pencere içinde yanıt verdiniz mi?”dir.
Düzeltmeler — Berry İşletimi tarafından girdi düzeltmesi
Platform Şartları 7.3. bölümü, şirketlerin itibar skorlarını etkileyen olgusal hataların gözden geçirilmesini talep edebileceğini belirtir. Berry bu takdiri tek bir mekanizmayla kullanır: tek tek olayların skor girdi kümesinden çıkarılması.
Bir şirketin skoruna asla farklı bir sayı yazılmaz. Skor her zaman bir olay çokluğuna uygulanan deterministik bir formülün sonucudur. Berry İşletimi’nin yapabildiği — ve yalnızca denetlenmiş bir iş akışıyla Berry İşletimi’nin yapabildiği — belirli bir olayı, adlandırılmış bir neden ve kalıcı denetim kaydıyla sayılmıyor olarak işaretlemektir.
Berry İşletimi’nin bir olayı bir şirketin skorundan hariç tutabileceği nedenlerin kapalı kümesi:
| Neden | Ne zaman uygulanır |
|---|---|
| Platform hatası veya kayıt hatası | Soruna Berry’nin kendi sistemleri neden oldu ya da sistem olayı yanlış kaydetti (teslimat zamanındaydı ama geç olarak işlendi; bir entegrasyon bir ödemeyi yanlış saydı). Hem veri tarafındaki hem de platform tarafındaki kusurlar bu tek neden altında toplanır — denetim satırındaki serbest metin notu durumu netleştirir. |
| Karşı taraf dolandırıcılığı doğrulandı | Karşı taraf kötü niyetle hareket etti ve olay bu şirketin davranışını değil bunu yansıttı. |
| Mücbir sebep | Liman grevi, gümrük kilidi, hava olayı veya benzeri bir durum ticareti tarafların kusuru olmadan etkiledi. |
| Platform dışı yan anlaşma | Taraflar işlemi Platform dışında çözdü (genellikle doğrudan iletişimle) ve platform üzerindeki kayıt artık gerçekte ne olduğunu yansıtmıyor. Platform üzerindeki olay yanıltıcıdır ve skoru beslememelidir. |
| Diğer (belgelendirilmiş) | Başka her şey; operatör hariç tutmayı denetim kaydında yazılı olarak gerekçelendirmelidir. Serbest metin notu zorunludur. |
Yalnızca dahili kategoriler. Veritabanında ayrı, kamuya açık olmayan
bir neden — test veya demo verisi — bulunur; bu, üretime sızan staging
fixture’larını temizlemek içindir. Hiçbir zaman gerçek şirket davranışını
yansıtmaz, normal işleyişte gerçek işlemlere uygulanmaz ve burada
bütünlük adına belgelenmiştir — bir şirketin kendi denetim satırında
karşılaşabileceği bir neden olarak değil. Gerçek bir işlemde
TEST_OR_DEMO hariç tutması görürseniz destek ile iletişime geçin —
neredeyse kesinlikle haberdar olmak istediğimiz bir İşletim hatasıdır.
Her hariç tutma, Berry İşletimi tarafından bile düzenlenemeyen veya silinemeyen yalnızca ekleme yapılabilen bir denetim tablosuna kaydedilir. Skoru etkilenen şirket, operatör gizliliği için operatör adları “Berry İşletim ekibi” olarak maskelenmiş şekilde kendi hariç tutma listesini Şirketim → Ticari sağlık etkinliği sekmesinde görebilir. Şirket, bağlı CRM kaydı üzerinden bir hariç tutmanın gözden geçirilmesini talep edebilir (veya bir hariç tutma için iddia sunabilir).
Hariç tutulan olaylar genel profil döküm panelinde sessizce yoktur (bir hariç tutulmuş anlaşmazlığı ve 19 temiz sözleşmesi olan şirket %5 anlaşmazlık oranı gösterir, “bir hariç tutmayla %5” değil). Denetim izi denetimin ait olduğu yerde kalır — CRM’de ve etkilenen şirketin kendi Ticari sağlık etkinliği sekmesinde. Genel profiller temizlenmiş, savunulabilir skoru gösterir.
Bütünlük ihlalleri — doğrulanmış dolandırıcılık, ardından yeniden etkinleştirilen hesabın askıya alınması, tekrarlayan kalıp ihlalleri — rutin sinyallerden farklı işlenir. Süresiz tam ağırlıkta sayılır ve yukarıda açıklanan sulandırma mekaniğine tabi değildir. v1.0’da henüz bütünlük olayları uygulanmamıştır; ancak çerçeve burada açıklanmıştır ki gelecekte karşılaşan bir şirket bunu geriye dönük bir değişiklik olarak görmesin.
Olgusal inceleme hakkı
Belirli bir olayın yanlış kaydedildiğine ve Ticari Sağlık Skoruna sayılmaması gerektiğine inanan bir şirket, Şirketim → Ticari sağlık etkinliği sekmesinden bağlanan destek kanalı üzerinden inceleme talep edebilir. Berry İşletimi talebi yukarıdaki beş nedene göre inceler, hariç tutmayı uygular veya talebi reddeder ve kararını denetim günlüğüne kaydeder. Berry, doğrulanmış işlemsel sonuçlardan veya belgelenmiş anlaşmazlıklardan kaynaklanan skorları değiştirmekle yükümlü değildir (Platform Şartları 7.3, ikinci cümle).
Kapsam ve sorumluluk reddi
İtibar skorları yalnızca bilgilendirici göstergelerdir ve hukuki hüküm teşkil etmez. Platform Şartları 7.2(a) uyarınca diğer platform kullanıcılarına görünürler. Berry, Platform Şartları 7.3 kapsamında zaman içinde gelişebilen hesaplama metodolojisi üzerinde takdir hakkını saklı tutar.
Ticari sağlık yalnızca Berry platformundaki olaylardan hesaplanır. Şirketin platform dışındaki ticaret geçmişi, referansları, sertifikaları veya itibarı dahil edilmez.
Ticari Sağlık Skoru şu anda arama sıralamasını veya eşleştirme sonuçlarını etkilemez. Platformun gelecek bir sürümünde bu değişirse bu sayfa güncellenir ve değişiklik duyurulur.
Önceki sürümler
Sürüm 1.1 (1 Temmuz 2026), bu sayfayı yöntemde herhangi bir değişiklik olmaksızın platformun HTML işlemesine taşımıştır. Sürüm 1.0 (20 Kasım 2025), bu sayfanın yayımlanan ilk sürümüydü.