Crea un tracker per la risoluzione delle controversie che organizzi i casi del marketplace, assegni i responsabili, tenga sotto controllo prove e scadenze e registri le decisioni sui pagamenti.
Una controversia su un marketplace raramente inizia come un fascicolo ordinato. Un acquirente scrive un'email per una consegna in ritardo, il venditore risponde in chat e un addetto del supporto aggiunge una nota a un foglio di calcolo. I dettagli del pagamento si trovano altrove. Quando arriva il momento di decidere, lo stesso caso può esistere in quattro posti diversi.
Questa frammentazione porta a errori costosi. Un addetto potrebbe non vedere la prova di tracciamento già inviata dal venditore, chiedere due volte lo stesso documento oppure approvare un rimborso dopo che l'ufficio finanziario ha già sbloccato il pagamento del venditore. Le scadenze aumentano la pressione. Acquirenti, venditori e fornitori di pagamento spesso si aspettano una risposta entro un periodo preciso, e un caso può sfuggire di mano durante una giornata intensa di supporto se nessuno è responsabile della prossima azione.
Ogni controversia ha bisogno di un unico record condiviso e di una persona responsabile di farla avanzare. Il supporto può raccogliere i messaggi, il team operations può verificare la policy e la finanza può gestire i pagamenti, ma assegnare un responsabile preciso evita che tutti pensino che risponderà qualcun altro.
Un tracker utile per la risoluzione delle controversie mostra insieme ordine, acquirente, venditore, importo contestato e stato del pagamento, oltre al motivo della richiesta, alla policy applicabile, alle prove, alla prossima scadenza, al responsabile attuale e alla decisione finale. Deve registrare anche eventuali rimborsi, sblocchi dei pagamenti o somme trattenute.
Immagina un acquirente che dichiara di non aver mai ricevuto un articolo. Il supporto aggiunge il reclamo, il venditore carica la prova di consegna e un addetto alle operations controlla la cronologia dell'ordine. Con tutto in un unico record, il revisore può decidere senza cercare nelle caselle email o chiedere ai colleghi il contesto del caso.
Un acquirente apre un caso dopo aver ricevuto una macchina da caffè danneggiata. L'addetto del supporto crea un record con ID del caso, numero dell'ordine, nomi dell'acquirente e del venditore, importo dell'acquisto, data di consegna e una breve descrizione: «L'acquirente segnala un serbatoio dell'acqua crepato all'arrivo.»
L'acquirente carica tre foto e chiede un rimborso completo. L'addetto allega le foto al caso, registra l'importo richiesto e annota quando l'acquirente ha contattato il supporto. Il venditore invia poi le foto dell'imballaggio e afferma che la macchina ha lasciato il magazzino integra. L'addetto aggiunge la risposta e il registro della consegna del corriere allo stesso caso.
Un breve flusso di stato mantiene il lavoro chiaro:
Se il registro della consegna non mostra danni al momento della consegna, ma le foto dell'imballaggio non dimostrano che l'articolo sia rimasto integro durante il trasporto, il marketplace potrebbe approvare un rimborso parziale di 40 $ e sbloccare il resto del pagamento del venditore. Il caso deve indicare il motivo, la data della decisione, l'importo approvato e l'operazione sul pagamento.
Una semplice etichetta di stato non basta. Il team deve collegare messaggi, prove, scadenze, decisioni e denaro allo stesso record.
Usa lo stesso formato per ogni controversia. Quando gli addetti raccolgono dettagli diversi in luoghi diversi, i revisori perdono tempo a rispondere a domande di base prima di poter valutare la richiesta.
Inizia con un ID univoco del caso, separato dal numero dell'ordine. Un ordine può generare più di un problema. Un ID come DSP-2025-00418 offre a supporto, finanza e operations un riferimento comune per messaggi e report.
Ogni record ha bisogno anche di un responsabile, di una priorità e di uno stato attuale. Mantieni la priorità semplice: bassa, normale, alta e urgente. Riserva «urgente» alle scadenze ravvicinate sui pagamenti, ai seri sospetti di frode o ai problemi dei clienti che richiedono un'azione nello stesso giorno.
Conserva i fatti che servono all'addetto per capire il caso senza aprire diversi strumenti. Per la gestione delle controversie del marketplace, includi ID dell'ordine, nome dell'inserzione o del servizio, data della transazione, metodo di pagamento, nomi dell'acquirente e del venditore e ID degli account.
Registra l'importo contestato e la valuta, poi indica cosa riguarda: un rimborso all'acquirente, un pagamento al venditore, una commissione della piattaforma oppure più di uno di questi elementi. Una richiesta di rimborso di 75 $ e un blocco di 75 $ sul pagamento del venditore possono riguardare lo stesso ordine, ma la finanza li gestisce in modo diverso.
I campi utili del caso includono:
Per esempio, un revisore potrebbe vedere il caso DSP-2025-00418, con priorità alta, assegnato a Maya e collegato all'ordine ORD-8821. L'acquirente afferma che una fotocamera è arrivata danneggiata, il venditore contesta la richiesta e il marketplace ha bloccato un pagamento di 240 $. Questo riepilogo offre al prossimo addetto un punto di partenza chiaro.
Evita etichette vaghe come «attivo» o «in corso». Non indicano se il team deve agire o se deve aspettare qualcun altro.
Di solito funziona bene un piccolo insieme di stati: nuovo, in attesa dell'acquirente, in attesa del venditore, in revisione, deciso, pagamento in sospeso e chiuso. Definisci cosa provoca ogni cambiamento. Per esempio, un caso passa da «in attesa delle prove» a «in revisione» quando arrivano le foto, i messaggi o la prova di consegna richiesti.
Tieni la decisione in un campo separato. Registra se il team ha approvato un rimborso, sbloccato un pagamento, diviso l'importo, respinto la richiesta o compiuto un'altra azione. Includi la data della decisione e la persona che l'ha presa. In questo modo la finanza può controllare il processo relativo alla controversia sul pagamento senza dover interpretare il significato dello stato.
Il tracker deve riflettere il modo in cui il team prende le decisioni. Inizia dagli eventi che aprono un caso: richiesta di rimborso, consegna mancante, articolo diverso da quello dell'inserzione o pagamento non autorizzato. Ogni evento deve creare un caso con motivo, data, riferimento dell'ordine e responsabile assegnato.
Descrivi il flusso in linguaggio semplice prima di creare schermate o campi. Un reclamo per una consegna potrebbe seguire questo percorso: l'acquirente invia la richiesta, il team chiede i dettagli dell'ordine e la prova di consegna, il venditore risponde, un addetto alle operations esamina il materiale e un revisore registra l'esito. Metterlo per iscritto fa emergere presto le lacune.
La persona che raccoglie i documenti non deve necessariamente avere il permesso di approvare un rimborso. Definisci ruoli adatti alle dimensioni e al livello di rischio del team:
I team piccoli possono combinare questi compiti. Il tracker deve comunque registrare chi ha preso ogni decisione e quando. Questa cronologia è importante quando un acquirente chiede perché una richiesta è stata respinta o un venditore contesta un pagamento ritardato.
Una decisione non chiude automaticamente un caso. Se il team approva un rimborso all'acquirente, la finanza deve emetterlo. Se il team respinge una richiesta, qualcuno potrebbe dover inviare una spiegazione e lasciare aperto il caso per il periodo previsto per un ricorso.
Collega ogni esito a un'azione precisa: rimborsare l'acquirente, sbloccare il pagamento del venditore, trattenere i fondi, rimborsare parzialmente un ordine o applicare un provvedimento sull'account. Registra quando l'azione è completata.
In AppMaster, un processo aziendale visivo può aggiornare lo stato del caso, assegnare il prossimo collega e creare un'attività di pagamento dopo l'approvazione. Il record può quindi mostrare sia la decisione sia la conferma che l'azione richiesta è stata eseguita.
Un revisore non dovrebbe cercare in una casella email, chiedere screenshot a un collega o indovinare quale versione di un documento sia quella aggiornata. Conserva caricamenti, note del caso e cronologia dei messaggi insieme a stato, scadenza e dettagli del pagamento.
Questo è particolarmente importante quando cambia il responsabile. Se un addetto inizia un caso lunedì e un altro lo esamina giovedì, il secondo deve avere subito tutto il contesto. Un record completo rende anche più facile spiegare una decisione a una delle due parti.
Un file chiamato photo_1023.jpg dice ben poco a un revisore. Aggiungi a ogni elemento una breve descrizione e il contesto di base:
Per esempio: «Ricevuto dal corriere il 14 maggio. Mostra il pacco all'ingresso dell'edificio, ma non è visibile il numero dell'unità.» La nota aiuta il revisore successivo a valutare l'immagine senza fare supposizioni.
Conserva questi dettagli insieme al file invece di inserirli in un foglio di calcolo separato. Il record del caso diventa così la fonte che il team consulta prima di chiedere altre informazioni o approvare un pagamento.
Le note interne e i messaggi per i clienti devono avere visibilità diversa. Un addetto potrebbe annotare che un venditore ha presentato richieste simili in passato o che un manager deve approvare lo sblocco di un pagamento. Acquirenti e venditori non devono mai vedere questi commenti.
Assegna a ogni messaggio un pubblico chiaro: team interno, acquirente o venditore. Mostra i messaggi esterni in ordine cronologico con mittente, destinatario e stato di consegna. Inserisci le note interne in un feed separato e identifica l'autore.
AppMaster può modellare un caso con record collegati per prove e messaggi, quindi offrire viste separate al personale operations e agli utenti esterni. In questo modo il team mantiene private le informazioni interne e conserva una cronologia completa del caso.
La maggior parte delle controversie ha diverse scadenze. Un acquirente potrebbe avere tre giorni per inviare gli screenshot, un venditore cinque giorni per rispondere e le operations potrebbero dover esaminare il caso entro 24 ore dall'ultima risposta. Inserisci ogni scadenza nel record insieme al responsabile e allo stato attuale.
Non affidarti a un unico campo generico «data di scadenza». Nasconde chi deve agire e perché. Usa campi separati per risposta dell'acquirente, risposta del venditore, revisione interna, decisione finale e blocco o sblocco del pagamento quando sono coinvolti dei fondi.
Un reclamo per un ordine danneggiato potrebbe essere aperto lunedì. L'acquirente ha tempo fino a giovedì per caricare le foto, il venditore fino a venerdì per rispondere e l'addetto assegnato deve decidere entro il giorno lavorativo successivo all'arrivo di entrambe le risposte. Ogni data ha uno scopo preciso.
Crea una vista giornaliera per i casi che richiedono un'azione. Mostra le scadenze di oggi, quelle imminenti e il lavoro in ritardo. Ordina le scadenze mancate in base all'anzianità, poi visualizza responsabile, stato e importo del pagamento o stato del blocco.
Escludi da questa vista i casi chiusi e quelli in attesa di una scadenza futura. Ogni mattina un responsabile operations può controllarla, assegnare i casi senza proprietario e aiutare gli addetti prima che un ritardo nel pagamento diventi un reclamo.
I colori degli stati possono aiutare, ma le etichette testuali sono più importanti. Usa diciture come «Scade oggi», «Scade tra 2 giorni» e «In ritardo di 1 giorno». Il testo resta chiaro nelle esportazioni, nelle viste mobile e negli strumenti di accessibilità.
Invia i promemoria alla persona responsabile, non a una casella condivisa. Per una scadenza normale, spesso basta un promemoria 24 ore prima. Le revisioni interne brevi possono richiedere un promemoria due ore prima della scadenza.
Dopo il superamento della scadenza, avvisa prima il responsabile. Informa il team lead solo se il caso resta aperto oltre un periodo di tolleranza definito. Così eviti messaggi duplicati mantenendo visibili i casi in ritardo.
Con AppMaster, un processo aziendale visivo può confrontare l'ora attuale con le scadenze dei casi, aggiornare l'etichetta del caso e inviare una notifica via email, SMS o Telegram al responsabile assegnato. Può anche aggiungere i casi in ritardo alla vista giornaliera di follow-up.
Inizia con una tabella per i casi. Assegna a ogni controversia un ID e collegala all'ordine, all'acquirente, al venditore e al membro del team assegnato. Includi stato, tipo di caso, data di apertura, scadenza della risposta, decisione, importo del pagamento e stato del pagamento.
Conserva le prove come record collegati invece di nasconderle nelle note di una conversazione. Ogni record di prova può includere un file, una descrizione, chi l'ha inviato e la data di ricezione. I revisori possono vedere rapidamente se entrambe le parti hanno inviato le prove richieste.
Crea solo i moduli di cui il team ha bisogno: un modulo di raccolta per il reclamo iniziale, un modulo per documenti e foto, note interne per il personale e un modulo decisionale per esito, motivo, revisore, rimborso o modifica del pagamento al venditore.
AppMaster permette ai team di creare queste schermate web o mobile tramite builder visuali collegati allo stesso modello di dati. Il suo Business Process Editor può gestire gli aggiornamenti di routine, così gli addetti non devono modificare manualmente ogni campo.
Imposta regole per il lavoro ordinario:
Mantieni breve il primo flusso. Nuovo, in attesa delle prove, in revisione, deciso e chiuso coprono molti casi. Aggiungi eccezioni solo quando il lavoro reale lo richiede.
Prova il tracker con esempi realistici prima di importare i casi reali. Crea un reclamo per una consegna mancante, chiedi la prova di consegna, allega la risposta, registra una decisione e verifica che l'operazione sul pagamento corrisponda alla decisione. Chiedi a un secondo collega di leggere la cronologia del caso senza spiegazioni aggiuntive. Prova anche una scadenza superata e verifica che il promemoria e la vista giornaliera funzionino come previsto.
Le scorciatoie portano a lunghe attività di pulizia. Un tracker deve conservare cosa è successo, chi ha preso ogni decisione e perché. Se il personale può modificare i vecchi record senza lasciare traccia, i revisori non possono capire se un venditore ha inviato prove incomplete o se qualcuno ha modificato il caso in seguito.
Tieni il reclamo originale separato dalle note interne. Salva il testo del reclamo, l'ora di invio, gli allegati e l'autore come voce fissa. Se un cliente corregge una data di consegna o aggiunge una foto, crea una nuova voce invece di sostituire la prima.
Anche gli stati vaghi creano code poco affidabili. «In sospeso» potrebbe significare in attesa dell'acquirente, del venditore, del fornitore di pagamento o di un revisore interno. Usa nomi che indichino sia la condizione del caso sia la prossima persona chiamata ad agire.
Prima che la finanza approvi un rimborso, uno sblocco del pagamento, lo storno di una commissione o un pagamento parziale, richiedi un record della decisione con motivo, prove esaminate, approvatore, importo e data. Per importi elevati o eccezioni alla policy è utile una seconda approvazione.
Mantieni i casi chiusi ricercabili per numero d'ordine, acquirente, venditore, tipo di problema, decisione e data. I casi passati aiutano il team a rispondere alle domande, verificare come ha gestito i reclami e individuare problemi ricorrenti di un venditore.
Scegli un tipo di controversia che il team gestisce spesso. Gli ordini danneggiati e le consegne mancanti sono buoni punti di partenza perché le prove e gli esiti sui pagamenti sono generalmente chiari. Una prima versione mirata offre al team uno strumento utile senza trasformare il progetto in un lungo elenco di idee.
Per una richiesta relativa a una consegna mancante, inizia con numero dell'ordine, dati dell'acquirente e del venditore, data del reclamo, messaggi, prova di consegna, decisione, importo del pagamento e scadenza. Lascia fuori i campi facoltativi finché il team non avrà un motivo concreto per usarli.
Chiedi alle persone che esaminano le controversie di provare moduli e stati con esempi realistici. Usa vecchi casi da cui siano stati rimossi nomi e dati sensibili. Devono poter aprire un caso, aggiungere prove, chiedere informazioni, registrare una decisione e completare il processo relativo alla controversia sul pagamento senza conservare note separate.
Osserva i punti in cui i revisori non sono d'accordo. Se una persona seleziona «in attesa del venditore» e un'altra «servono prove», chiarisci le definizioni degli stati. Una breve spiegazione sotto ogni stato spesso funziona meglio dell'aggiunta di altre etichette.
AppMaster può aiutarti a creare un tracker no-code per la risoluzione delle controversie con record per casi, prove, messaggi, scadenze e pagamenti. Usa Data Designer per la struttura dei dati, Business Process Editor per i passaggi di revisione e approvazione e i builder dell'interfaccia web o mobile per revisori e manager. AppMaster genera backend, interfacce e codice sorgente dell'applicazione mentre il flusso di lavoro cambia.
Dopo alcuni casi reali, verifica se i revisori trovano rapidamente il record giusto, se ogni scadenza ha un responsabile e se i manager possono capire perché un pagamento è stato approvato o respinto. Risolvi questi problemi quotidiani prima di aggiungere resi, richieste per prodotti contraffatti, controversie sui pagamenti o ricorsi dei venditori.
14 lug 2026
9 min
13 lug 202610 min
08 lug 202611 minSperimenta con AppMaster con un piano gratuito.
Quando sarai pronto potrai scegliere l'abbonamento appropriato.
