Metodologia del Trade Health
Versione 1.1·In vigore dal 1 luglio 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.
La presente pagina descrive il modo in cui Berry Marketplace calcola il punteggio Trade Health visualizzato su ciascun profilo Società, su ogni scheda di inserzione e su ogni superficie di offerta sulla piattaforma. Documenta il modo in cui Berry ha interpretato la Sezione 7 (Sistema di reputazione) delle Condizioni della piattaforma dall’entrata in vigore di tali Condizioni ed è pubblicata qui per trasparenza. Non costituisce di per sé un contratto e non richiede accettazione.
Cos’è il punteggio Trade Health
Il punteggio Trade Health è un numero compreso tra 0 e 100, calcolato da Berry sulla base della storia di negoziazione verificata di una Società sulla Piattaforma. È mostrato accanto a (e non è mai mescolato con) le recensioni redatte dagli utenti, affinché le controparti possano leggere due segnali distinti a colpo d’occhio:
- Stelle — ciò che altre Società hanno detto di una Società, con le proprie parole.
- Trade Health — ciò che la storia negoziale di una Società dice di essa, calcolato da Berry a partire da eventi oggettivi.
Il punteggio di una Società si aggiorna automaticamente ogniqualvolta si verifica un evento di negoziazione che alimenta il punteggio (un contratto si completa, una controversia si risolve, una fattura viene pagata, una consegna viene registrata). Un ricalcolo giornaliero di sicurezza viene eseguito alle 06:30 UTC per rilevare eventuali eventi che i trigger in tempo reale avrebbero potuto non cogliere.
Il punteggio, la fascia in cui ricade e una ripartizione per componente sono visibili su ogni profilo Società. Le Società possono visualizzare i singoli eventi che alimentano il proprio punteggio nella scheda La mia Società → Attività Trade Health.
Fasce
| Punteggio | Fascia |
|---|---|
| 90–100 | Eccellente |
| 75–89 | Buono |
| 60–74 | Sufficiente |
| Inferiore a 60 | Richiede attenzione |
| Meno di 3 contratti completati | Storico di negoziazione insufficiente (nessun punteggio pubblicato) |
Una Società con meno di 3 contratti completati sulla Piattaforma mostra «In costruzione (X di 3)» anziché un punteggio. Ciò evita di penalizzare le Società nuove per dati scarsi. Una volta raggiunta la soglia, il punteggio viene mostrato.
Componenti e ponderazioni
Il punteggio è la media ponderata di quattro componenti. Le ponderazioni sommano a 1,00.
| Componente | Ponderazione | Cosa misura |
|---|---|---|
| Tasso di controversie | 35% | La quota di contratti completati conclusi senza intoppi rispetto a quelli che hanno comportato un problema di qualità o una controversia, ponderata in base alla gravità dell’esito. |
| Consegna nei tempi | 25% | Con quanta puntualità rispetto al calendario arrivano le consegne di una Società (segnale lato venditore). |
| Tempestività del pagamento delle commissioni | 20% | Se una Società paga le fatture di commissione per operazione di Berry entro o alla data di scadenza (segnale lato acquirente). |
| Tasso di risposta alle controversie | 20% | Se una Società interviene nelle controversie proposte nei suoi confronti entro la finestra di risposta della controversia. |
Ciascuna componente è calcolata in modo indipendente come valore tra 0,0 e 1,0, quindi moltiplicata per la propria ponderazione. I valori delle componenti sono sommati e divisi per la ponderazione totale delle componenti che hanno almeno un evento per la Società. Il risultato è moltiplicato per 100 per produrre il punteggio visualizzato.
Se una Società non ha eventi per una data componente (per esempio, una Società che ha venduto soltanto non ha uno storico di pagamento delle commissioni), tale componente è esclusa sia dal numeratore sia dal denominatore — essa non aiuta né danneggia il punteggio.
Come il tempo incide sul punteggio
Il Trade Health utilizza un modello di diluizione, non un modello di decadimento. Questa è una distinzione importante.
Un modello di decadimento direbbe: «Gli eventi vecchi contano meno nel tempo.» Berry non opera così. Gli eventi vecchi contano pienamente, senza limite temporale.
Un modello di diluizione dice: «Ogni nuovo contratto completato si aggiunge al proprio dossier e il rapporto complessivo migliora automaticamente man mano che si accumula una condotta positiva.» Questo è ciò che fa Berry.
L’effetto pratico è che una Società con un problema risalente nel tempo e molte negoziazioni successive pulite vede il proprio punteggio salire in modo naturale — il problema non è cancellato, ma il suo peso aritmetico come quota della storia negoziale complessiva della Società si riduce a ogni contratto pulito aggiunto. È possibile recuperare con la negoziazione — ogni contratto pulito diluisce l’impatto di qualsiasi problema anteriore, senza mai fingere che il problema non sia avvenuto.
Non «dimentichiamo» gli eventi vecchi. Una controversia di tre anni fa ha lo stesso peso aritmetico di una controversia di un mese fa. Ciò che cambia è la quota che tale evento rappresenta sul dossier complessivo della Società.
Una versione futura di questa metodologia potrebbe introdurre una sovrapposizione simmetrica di recenza (eventi più vecchi leggermente ponderati meno rispetto agli eventi recenti) qualora i dati mostrino in seguito che ciò migliora il segnale per Società inattive. Se introdotta, sarà unicamente una sovrapposizione simmetrica — mai una curva che amplifichi in modo sproporzionato gli eventi recenti. Qualsiasi tale modifica sarà pubblicata come nuova versione di questa pagina (v1.1, v2.0, ecc.) ai sensi della Sezione 7.3 delle Condizioni della piattaforma, che riserva a Berry la discrezionalità sull’evoluzione della metodologia.
Una versione futura potrebbe inoltre introdurre lo shrinkage bayesiano — una tecnica statistica che riduce la volatilità del punteggio per le Società vicine alla soglia minima di tre contratti attenuando dolcemente i loro rapporti verso la media dell’intera piattaforma. La v1.0 utilizza una soglia semplice (nessun punteggio pubblicato al di sotto di tre contratti); la v2.0 probabilmente attenuerà tale approccio con shrinkage al di sopra della soglia. Se ne riveliamo l’assenza nella v1.0 affinché la sua eventuale introduzione non risulti una sorpresa.
Dettaglio delle componenti
Tasso di controversie (ponderazione 35%)
Fonte: ogni contratto che raggiunge lo stato COMPLETED. Ogni contratto
completato genera una riga per parte interessata (l’acquirente e il
venditore), e il valore della riga è determinato dal peggiore esito di
qualità su quel contratto. Le negoziazioni pulite contano pienamente; le
negoziazioni con problemi di qualità o controversie contano in misura
proporzionalmente inferiore, a seconda di come il problema è stato risolto
e quale parte era responsabile.
| Esito sul contratto | Valore per la parte responsabile | Valore per la controparte |
|---|---|---|
| Negoziazione pulita — nessun problema di qualità, nessuna controversia | 1,00 | 1,00 |
| Problema di qualità risolto bilateralmente (nessuna controversia formale proposta) | 0,85 | 0,85 |
| Controversia → richiesta ritirata (di norma risolta fuori piattaforma) | 1,00 (respondent) | 0,95 (initiator) |
| Controversia → nessuna azione concordata (richiesta dichiarata respinta di comune accordo) | 0,95 (respondent) | 0,92 (initiator) |
| Controversia → responsabilità riconosciuta, restituzione integrale (rimborso o sostituzione) | 0,50 | 1,00 |
| Controversia → rimborso parziale concordato con attribuzione della responsabilità | 0,50 | 0,95 |
| Controversia → risolta senza parte responsabile (compromesso) | 0,70 | 0,70 |
| Controversia → rinviata ad arbitrato esterno | 0,60 | 0,60 |
| Controversia → richiesta scaduta (nessun coinvolgimento, uscita per decorrenza) | 0,10 (respondent) | 0,50 (initiator) |
Alcune note su come leggere questa tabella:
- Una controversia risolta in modo equo conta comunque qualcosa. Un venditore che ha consegnato una sostituzione dopo un reclamo legittimo ottiene 0,50 su quella riga, non 1,0. La sostituzione è stata la risposta corretta, ma si è verificato un problema reale, e il punteggio lo riflette. Sostituzione, rimborso integrale e nota di accredito sono trattati in modo equivalente — l’attribuzione della responsabilità è la stessa indipendentemente dalla forma della restituzione.
- I reclami ritirati sono letti in modo indulgente. Quando un reclamo è ritirato, il motivo più comune è una risoluzione amichevole fuori piattaforma. Il respondent ottiene un punteggio pulito 1,00; l’initiator ottiene 0,95.
- Ignorare un reclamo è il peggiore esito di routine. Un respondent che lascia scadere un reclamo senza intervenire ottiene 0,10. Anche l’initiator che ha abbandonato il reclamo ottiene 0,50.
- L’arbitrato esterno è fissato a 0,60 per entrambe le parti finché l’esito arbitrale non è registrato sulla Piattaforma, momento in cui il punteggio è ricalcolato a partire da tale esito.
Consegna nei tempi (ponderazione 25%)
Fonte: ogni consegna registrata (riga contract_deliveries con consegna
effettuata). I giorni di ritardo si calcolano come data effettiva di consegna − data programmata, con limite inferiore zero (le consegne
anticipate hanno lo stesso punteggio della puntualità).
| Giorni di ritardo | Valore |
|---|---|
| 0 (nei tempi o in anticipo rispetto al calendario) | 1,00 |
| 1–3 giorni | 0,70 |
| 4–7 giorni | 0,40 |
| 8–14 giorni | 0,20 |
| 15 o più giorni | 0,10 |
Questo segnale è imputabile al venditore: è influenzato soltanto il punteggio del venditore.
Tempestività del pagamento delle commissioni (ponderazione 20%)
Fonte: ogni fattura di commissione (commissione per operazione di Berry
addebitata all’acquirente) con stato PAID. I giorni di ritardo si
calcolano come data di pagamento − data di scadenza, con limite
inferiore zero.
| Giorni di ritardo | Valore |
|---|---|
| 0 (pagata entro o alla data di scadenza) | 1,00 |
| 1–3 giorni | 0,80 |
| 4–7 giorni | 0,40 |
| 8–14 giorni | 0,20 |
| 15 o più giorni | 0,10 |
Lievemente più indulgente rispetto alla consegna nei tempi solo per la fascia 1–3 giorni — il regolamento mediante bonifico nell’area SEPA richiede legittimamente 1–2 giorni. Le curve convergono dal quarto giorno in avanti, ove le spiegazioni legate a ritardi bancari non sono più pertinenti.
Questo segnale è imputabile all’acquirente: è influenzato soltanto il punteggio dell’acquirente.
Le fatture di abbonamento non rientrano nel Trade Health. L’abbonamento mensile o annuale alla piattaforma di Berry è un rapporto commerciale tra ciascuna Società e Berry, distinto dal modo in cui tale Società è presentata alle controparti. Introdurre nella metrica di reputazione rivolta alle controparti la gestione dei solleciti di pagamento dell’abbonamento confonderebbe due rapporti tra loro non collegati, pertanto non lo facciamo.
I pagamenti contrattuali dall’acquirente al venditore non rientrano altresì nel Trade Health. Tali pagamenti avvengono fuori piattaforma (di norma tramite bonifico bancario diretto) e Berry non dispone di registrazioni autorevoli sulla data di incasso. Qualora il ruolo di Berry nella mediazione dei pagamenti contrattuali dovesse ampliarsi in future linee di prodotto, questa componente potrà essere aggiunta.
Tasso di risposta alle controversie (ponderazione 20%)
Fonte: ogni controversia proposta nei confronti della Società (ove tale Società è il respondent).
| Comportamento di risposta | Valore |
|---|---|
| Risposta entro la finestra di risposta della controversia | 1,00 |
| Risposta dopo la finestra ma prima della definizione | 0,50 |
| Nessuna risposta | 0,00 |
La finestra di risposta si legge per ciascuna controversia dal campo
respondentDeadline della controversia — non è un termine fisso codificato
di sette giorni. Le controversie agricole tra imprese richiedono
legittimamente finestre di risposta variabili per prove di campione,
analisi di laboratorio, periodi festivi e situazioni di forza maggiore,
e il sistema le consente. La domanda pertinente non è «avete risposto
entro sette giorni?» bensì «avete risposto entro la finestra applicabile
a questa specifica controversia?»
Correzioni — rettifica degli input da parte di Berry Operations
La Sezione 7.3 delle Condizioni della piattaforma stabilisce che le Società possono richiedere una revisione delle inesattezze di fatto che incidono sul loro punteggio di reputazione. Berry esercita tale discrezionalità mediante un unico meccanismo: escludere singoli eventi dall’insieme di input del punteggio.
Non inseriamo mai un numero diverso nel punteggio di una Società. Il punteggio è sempre il risultato deterministico di una formula applicata a un insieme di eventi. Ciò che Berry Operations può fare — e soltanto Berry Operations, tramite un flusso di lavoro sottoposto a revisione — è contrassegnare un evento specifico come non conteggiato, con motivazione denominata e registrazione di audit permanente.
L’insieme chiuso di motivazioni in forza delle quali Berry Operations può escludere un evento dal punteggio di una Società:
| Motivazione | Quando si applica |
|---|---|
| Difetto di piattaforma o errore di registrazione | I sistemi di Berry hanno causato il problema, oppure il sistema ha registrato in modo errato un evento (la consegna era nei tempi ma è stata annotata in ritardo; un’integrazione ha conteggiato erroneamente un pagamento). Tanto le anomalie sul lato dei dati quanto quelle sul lato della piattaforma rientrano sotto questa unica motivazione — la nota libera nella riga di audit precisa il caso. |
| Frode della controparte accertata | La controparte agiva di mala fede e l’evento rispecchiava ciò, non il comportamento di questa Società. |
| Forza maggiore | Uno sciopero portuale, un blocco doganale, un evento meteorologico o circostanza comparabile ha inciso sul commercio senza colpa di alcuna delle parti. |
| Accordo collaterale fuori piattaforma | Le parti hanno definito la negoziazione al di fuori della Piattaforma (di norma tramite contatto diretto) e la registrazione sulla Piattaforma non rispecchia più ciò che è effettivamente accaduto. L’evento sulla Piattaforma è fuorviante e non deve concorrere al punteggio. |
| Altro (documentato) | Qualsiasi altra ipotesi; l’operatore deve giustificare l’esclusione per iscritto nella registrazione di audit. La nota libera è obbligatoria. |
Categorie a uso esclusivamente interno. Nel database è prevista una
motivazione separata e non pubblica — dati di test o demo — destinata
a rimuovere fixture di staging eventualmente confluite in produzione.
Non rispecchia in alcun caso una condotta reale di una Società, non viene
applicata alle negoziazioni reali in esercizio ordinario ed è documentata
qui per completezza, non come motivazione che una Società possa mai
incontrare nella propria riga di audit. Qualora si riscontri
un’esclusione con TEST_OR_DEMO su una negoziazione reale, contattare
il supporto: si tratta quasi certamente di un errore di Operations di
cui desideriamo essere informati.
Ciascuna esclusione è registrata in una tabella di audit solo appendibile che non può essere modificata o cancellata, neppure da Berry Operations. La Società il cui punteggio è interessato può visualizzare il proprio elenco di esclusioni nella scheda La mia Società → Attività Trade Health, con i nomi degli operatori oscurati come «Team Operazioni Berry» per la tutela della riservatezza degli operatori. La Società può richiedere la revisione di un’esclusione (o proporre un’esclusione) tramite il ticket del Customer Relationship Management collegato.
Gli eventi esclusi sono silenziosamente assenti dal pannello di ripartizione sul profilo pubblico (una Società con una controversia esclusa e 19 contratti puliti mostra un tasso di controversie del 5%, non «5% con un’esclusione»). La pista di audit risiede ove gli audit devono risiedere — nel Customer Relationship Management e nella scheda Attività Trade Health della Società interessata. I profili pubblici mostrano il punteggio ripulito, difendibile.
Le violazioni di integrità — frode accertata, sospensione dell’account seguita da riattivazione, violazioni a schema ripetuto — sono gestite in modo diverso dai segnali ordinari. Contano a pieno peso senza limite di tempo e non sono soggette alla meccanica di diluizione descritta sopra. La v1.0 non ha ancora eventi di integrità implementati, ma la cornice è rivelata qui affinché una Società che vi incorri in futuro non la percepisca come modifica retroattiva.
Diritto di revisione sui fatti
Una Società che ritenga che un evento specifico sia registrato in modo inesatto e non debba concorrere al proprio punteggio Trade Health può richiedere la revisione tramite il canale di supporto collegato dalla propria scheda La mia Società → Attività Trade Health. Berry Operations esamina la richiesta rispetto alle cinque motivazioni di cui sopra, applica l’esclusione o respinge la richiesta e registra la decisione nel registro di audit. Berry non è tenuta a modificare punteggi derivanti da esiti transazionali verificati o controversie documentate (ai sensi della seconda frase della Sezione 7.3 delle Condizioni della piattaforma).
Ambito ed esonero
I punteggi di reputazione sono soltanto indicatori informativi e non costituiscono giudizi di legge. Sono visibili agli altri Utenti della Piattaforma ai sensi della Sezione 7.2, lettera a), delle Condizioni della piattaforma. Berry si riserva discrezionalità sul metodo di calcolo, che può evolvere nel tempo, ai sensi della Sezione 7.3 delle Condizioni della piattaforma.
Il Trade Health è calcolato esclusivamente a partire da eventi sulla Piattaforma Berry. Storia di negoziazione, referenze, certificazioni o reputazione che una Società può vantare fuori dalla Piattaforma non sono incluse.
Il punteggio Trade Health non incide attualmente sul posizionamento nelle ricerche né sui risultati di abbinamento. Qualora ciò dovesse mutare in una versione futura della Piattaforma, la presente pagina sarà aggiornata e la modifica sarà resa nota.
Versioni precedenti
La versione 1.1 (1 luglio 2026) ha migrato questa pagina al rendering HTML della piattaforma, senza modifiche alla metodologia. La versione 1.0 (20 novembre 2025) è stata la prima versione pubblicata di questa pagina.