Approfondimento sulle Integrazioni: Collegare l’help desk all’API di Amazon per modificare gli ordini e ottenere rimborsi istantanei

TL;DR

Il più grande costo nascosto nell’assistenza Amazon non è il ticket in sé. È il cambio di contesto che l’agente deve fare per risolvere effettivamente qualcosa. Ogni volta che qualcuno lascia l’help desk per accedere a Seller Central, trovare l’ordine ed elaborare manualmente un rimborso o una cancellazione, il tuo AHT sale, il tuo timer SLA si riduce e il tuo cliente aspetta. Un’integrazione API diretta elimina completamente questo passaggio. I rimborsi, le cancellazioni e le modifiche agli ordini avvengono all’interno del ticket, in pochi secondi, e la conferma arriva all’agente prima che abbia finito di scrivere la risposta.

Il collo di bottiglia: azione manuale vs. risoluzione istantanea

Il momento più costoso nell’assistenza clienti di Amazon è l’intervallo tra la richiesta del cliente e l’azione dell’agente.

Immagina il flusso di lavoro che la maggior parte dei team sta ancora eseguendo. Un cliente invia un messaggio chiedendo un rimborso. L’agente apre il ticket, lo legge e poi… deve andarsene. Nuova scheda. Accesso a Seller Central (che potrebbe essere scaduto). Vai all’ordine. Trova la voce giusta. Clicca su tre schermate di conferma. Elaborare il rimborso. Poi torna all’help desk. Trova di nuovo il ticket. Scrivi la conferma. Invia.

L’intera sequenza richiede pochi minuti. A volte più a lungo se Seller Central è lento quella mattina. E mentre accade, tre cose si stanno silenziosamente rompendo:

• L’AHT sale. Il tempo medio di gestione aumenta per l’intera durata del cambio di contesto, non solo per l’azione stessa. Moltiplica questo dato per il volume giornaliero di ticket e ti ritroverai con ore di capacità perse.
• Il timer dello SLA continua a scorrere. Amazon ti dà 24 ore per rispondere e la pazienza dell’acquirente di solito è molto più breve. Se l’agente deve gestire altri cinque biglietti prima di rispondere a questo, il divario aumenta.
• Il cliente diventa impaziente. Inviano un follow-up. “Hai già elaborato il rimborso?” Tecnicamente si tratta di un contatto separato, ma in realtà è solo una seconda occasione per lasciare un feedback negativo. I reclami dalla A alla Z vengono presentati esattamente in questa finestra.

La soluzione non consiste nel rendere i tuoi agenti più veloci nel cambiare scheda. La soluzione consiste nel rimuovere il cambio di scheda.

Cosa sblocca l’integrazione diretta con le API

Quando il tuo help desk si collega direttamente a API di Amazon per i partner venditori (il moderno sostituto del precedente MWS), l’agente smette di essere un operatore e diventa un controllore. Le azioni avvengono dall’interno del ticket. Le conferme arrivano automaticamente. Nulla esce dallo schermo.

Come si presenta nella pratica:

• Risoluzione a schermo singolo. Messaggio del cliente a sinistra. Pulsante di rimborso o cancellazione a destra. Entrambi visibili. L’azione si effettua con un clic e la conferma appare nella stessa vista.
• Tasso di errore più basso. Niente più copia-incolla degli ID degli ordini. Non dovrai più digitare l’importo del rimborso sbagliato perché lo schermo è stato coperto da una notifica. I dati fluiscono dalla fonte.
• FCR più elevato. La risoluzione del primo contatto è la metrica che conta di più in questo caso. Secondo La ricerca di benchmark FCR di MetropolisAnche un miglioramento dell’1% nella FCR può generare centinaia di migliaia di risparmi annuali per un’operazione di assistenza di medie dimensioni, soprattutto grazie all’eliminazione dei contatti ripetuti e del tempo di gestione sprecato. Le azioni integrate portano l’FCR per i ticket di rimborso e cancellazione verso la soglia dell’80%, perché la risoluzione avviene nel primo contatto, per definizione.
• Traccia di controllo intatta. Ogni azione viene registrata da Amazon esattamente come se fosse stata eseguita manualmente in Seller Central. Il tuo help desk registra il lato dell’agente. Insieme, costituiscono una traccia completa.

La SP-API di Amazon è ampiamente adottata. La documentazione per gli sviluppatori riporta che oltre un milione di venditori in tutto il mondo utilizzano applicazioni basate sull’API per automatizzare parti della loro attività. Quindi non si tratta di una sperimentazione. È il modo in cui operano i venditori seri.

Caso d’uso 1: Rimborsi istantanei, completi e parziali

I rimborsi sono l’azione a più alto volume e rischio dell’assistenza Amazon. Sono anche l’azione in cui il ritardo manuale causa i danni maggiori.

Ecco lo scenario che la maggior parte dei team conosce bene. Un acquirente invia un messaggio dicendo che il suo articolo è arrivato danneggiato. Vuole un rimborso. L’agente è d’accordo, ma l’elaborazione del rimborso vero e proprio deve aspettare di arrivare alla Seller Central più tardi nel turno. Il cliente non lo sa. Non vede alcun movimento. Pensano che non stia accadendo nulla. Presenta una richiesta di rimborso da A a Z. Ora l’agente deve elaborare il rimborso e difendere la richiesta di risarcimento, spesso contemporaneamente.

Con un flusso di lavoro integrato, questo scenario scompare. L’agente legge il messaggio, conferma che la politica è adatta, fa clic sul pulsante di rimborso del biglietto stesso e seleziona un rimborso totale o parziale. L’istruzione viene inviata ad Amazon tramite l’API. La conferma torna indietro. La risposta al cliente può includere il numero di conferma effettivo, non un vago “abbiamo iniziato a elaborare il suo rimborso”. Tre frasi. Forse 90 secondi in totale.

I rimborsi parziali sono ancora più utili. Un acquirente vuole uno sconto del 20% perché uno dei tre articoli del suo ordine aveva un piccolo problema estetico. L’agente inserisce l’importo parziale, seleziona il codice del motivo e il rimborso viene eseguito con tutti i dati necessari trasmessi accuratamente ad Amazon. Non c’è il rischio di sbagliare l’importo. Non c’è il rischio di selezionare il codice di motivazione sbagliato (che può innescare un’interrogazione di controllo in un secondo momento). Il sistema applica la conformità alla policy per conto dell’agente.

Il risultato per i clienti: un rimborso elaborato in pochi secondi, con un numero di conferma reale, prima che abbiano avuto il tempo di scrivere un messaggio di follow-up. Il risultato interno: L’AHT diminuisce, il FCR aumenta e la richiesta di rimborso da A a Z non viene mai archiviata.

Caso d’uso 2: Cancellazioni di ordini prima che il magazzino si muova

Le richieste di cancellazione sono sensibili al tempo, mentre i rimborsi non lo sono. I rimborsi possono essere elaborati in qualsiasi momento dopo la spedizione dell’ordine. Le cancellazioni devono avvenire prima che il magazzino prenda in consegna l’articolo, altrimenti si verifica una situazione di rimborso forzato (che incide sulla tariffa di ritardo della spedizione) invece di una cancellazione pulita.

Il flusso di lavoro integrato per le cancellazioni è essenzialmente una gara contro il tuo processo di adempimento. Ecco la sequenza:

1. Il cliente chiede di cancellare entro la finestra ammissibile. Il ticket arriva all’help desk.
2. L’agente vede lo stato dell’ordine. Sei ancora in “In attesa”? La cancellazione è semplice. Già in fase di adempimento? Il flusso cambia. Già spedito? Si tratta di un reso, non di una cancellazione.
3. Per gli ordini FBML’agente fa clic su Annulla all’interno del biglietto. La chiamata API viene inviata ad Amazon, l’ordine viene congelato e il sistema di magazzino viene avvisato prima che avvenga il ritiro. Per FBA, il sistema trasmette la richiesta di cancellazione ai centri di evasione di Amazon, che la accettano se l’ordine non è ancora in fase di elaborazione.
4. Il codice del motivo viene acquisito automaticamentee questo è importante per l’audit trail e per mantenere pulite le metriche dei tuoi venditori.
5. Un messaggio di cancellazione conforme alla politica al cliente con il numero di conferma, il motivo e gli eventuali passi successivi.

Quando funziona, l’intera sequenza dura meno di un minuto. L’alternativa (in cui l’agente lascia l’help desk, naviga verso Seller Central, trova l’ordine, elabora l’annullamento, torna indietro e scrive il messaggio) è in genere di quattro-sei minuti, durante i quali il magazzino potrebbe aver già spostato l’articolo.

La differenza tra queste due tempistiche non è solo l’AHT. È se l’ordine viene cancellato o meno.

Come eDesk esegue le azioni tramite la SP-API di Amazon

L’integrazione di eDesk Integrazioni con Amazon è bidirezionale. Legge dall’API per popolare il ticket con il contesto dell’ordine e scrive all’API per eseguire le azioni.

Come si presenta all’interno della Casella di Posta Intelligente:

• Widget utilizzabili appaiono direttamente su ogni biglietto Amazon. Rimborso, cancellazione, rimborso parziale, modifica dell’ordine. Pulsanti, non link ad altri siti.
• Sincronizzazione bidirezionale Ciò significa che quando l’agente fa clic su uno di questi pulsanti, eDesk invia l’istruzione all’SP-API. L’API risponde con una conferma. Il ticket si aggiorna. L’agente vede il risultato. Non è necessario aggiornare.
• Coerenza cross-canale. Per i venditori che utilizzano Amazon Multi-Channel Fulfillment (MCF) per spedire gli ordini su Shopify o sul webstore, l’integrazione consente di mantenere i dettagli dell’ordine accurati, indipendentemente dal luogo di provenienza. Un’unica fonte di verità per tutti i canali.

La garanzia tecnica di tutto questo: ogni azione passa attraverso l’SP-API ufficiale e autorizzata di Amazon, con le corrette autorizzazioni di ruolo (il ruolo Payment Initiation Service Provider per i rimborsi, il ruolo Direct-to-Consumer Shipping per le modifiche all’adempimento e così via). Niente screen-scraping. Niente automazioni non autorizzate che potrebbero far scattare i flag dell’account.

Punti di forza

• Il cambio di contesto è il vero costo. L’elaborazione manuale non è solo più lenta, ma è il momento in cui si concentra il rischio di ODR.
• Integrazioni bidirezionali, non solo unidirezionali. Leggere i dati dell’ordine nel ticket è metà del valore. L’esecuzione di azioni dal ticket è l’altra metà.
• Dai priorità alle azioni più volatili. Rimborsi (totali e parziali) e cancellazioni. Questi sono i biglietti a più alto volume e a più alto rischio e sono quelli in cui i guadagni di FCR sono maggiori.
• Tratta l’FCR come la metrica principale. Un FCR elevato sui ticket per i rimborsi e le cancellazioni significa che la risoluzione è avvenuta prima che il cliente abbia avuto l’opportunità di rivolgersi a un’escalation.
• Le tracce di controllo non sono facoltative. Assicurati che qualsiasi cosa implementerai mantenga un record pulito da entrambe le parti (Seller Central e il tuo help desk). Sia i revisori che l’assistenza di Amazon richiedono questi dati.

Domande frequenti

Collegare un help desk all’API di Amazon è effettivamente conforme alle politiche di Amazon?

Sì, a condizione che l’integrazione utilizzi l’API Selling Partner autorizzata da Amazon (SP-API) con le corrette autorizzazioni di ruolo. L’utilizzo di un provider autorizzato e affidabile con un flusso OAuth e una gestione delle PII adeguati è lo standard. Lo screen-scraping o le automazioni non autorizzate mettono nei guai gli account. L’accesso all’SP-API tramite un’applicazione approvata è esattamente il modo in cui Amazon si aspetta che avvenga.

Se elaboro un rimborso attraverso l’help desk, dove appare il registro delle transazioni?

Viene visualizzata in Seller Central esattamente come se l’avessi elaborata manualmente. La transazione vera e propria viene eseguita dall’API di Amazon, quindi la ricevuta, il record finanziario, la conferma dell’acquirente, tutto questo si trova nel sistema di Amazon. L’help desk conserva la traccia di controllo dell’azione dell’agente (chi ha cliccato il pulsante, quando, su quale ticket). Insieme si ottiene una documentazione completa.

Funziona sia per gli ordini FBA che per quelli FBM?

Entrambi, ma le meccaniche pratiche differiscono. Le cancellazioni sono più sensibili al tempo per FBM, perché l’integrazione deve fermare il magazzino prima del prelievo. Nel caso di FBA, la richiesta di cancellazione viene inviata ai centri di evasione di Amazon, che la accetteranno se l’ordine è ancora in stato di “In attesa”, mentre potrebbero non essere in grado di farlo se è già in fase di elaborazione. I rimborsi funzionano in modo pulito per entrambi.

In che modo questa integrazione aiuta la difesa dei sinistri dalla A alla Z?

In due modi. In primo luogo, per la velocità: spesso la risoluzione arriva prima che il cliente pensi di presentare un reclamo, il che elimina completamente la motivazione. In secondo luogo, grazie alle prove: se il reclamo viene presentato, la traccia di controllo dell’help desk mostra che l’agente ha elaborato (o tentato) la risoluzione entro pochi minuti dalla richiesta. Si tratta di una potente prova di buona fede per l’indagine di Amazon. La maggior parte dei reclami che vanno a tuo favore hanno alle spalle una tempistica documentata come questa.

Cosa succede se la chiamata API fallisce o se il sistema di Amazon non funziona?

Un’integrazione ben fatta riprova automaticamente le chiamate fallite e invia all’agente un messaggio di errore chiaro se l’azione non può essere completata. L’agente può quindi tornare all’elaborazione manuale mantenendo il ticket aperto. Lo scopo dell’integrazione è quello di gestire in modo pulito il 99% dei casi, non di far finta che i casi limite non esistano.

L’integrazione richiede che il mio team impari qualcosa di nuovo?

Non proprio. Il punto è che le azioni appaiono all’interno dell’interfaccia dell’help desk che il team già utilizza. Un nuovo pulsante sul ticket. Tutto qui. Non sono necessari altri accessi, né dashboard separati, né conoscenze API da parte dell’agente. La configurazione è gestita a livello di amministratore.

Per vedere i rimborsi istantanei, le cancellazioni e le modifiche degli ordini all’interno dell’interfaccia dei biglietti, Prenota una demo gratuita.