Modifiche d'Ordine via E-mail: Applicare o Rifiutare
Come un agente IA gestisce modifiche e annullamenti d'ordine ricevuti via e-mail: trovare l'ordine, leggerne lo stato nell'ERP, poi decidere.
La Risposta in Breve
Un'e-mail che modifica un ordine esistente è un lavoro diverso da un'e-mail che ne inserisce uno nuovo. L'agente deve trovare l'unico ordine a cui il cliente si riferisce, leggere nell'ERP che cosa gli è già successo e solo dopo decidere se la modifica può essere applicata, richiede una persona o va rifiutata. A decidere è lo stato dell'ordine, non la formulazione del messaggio.
Per un direttore del servizio clienti, il risultato è che le modifiche di routine su ordini intatti vengono confermate in pochi minuti, mentre tutto ciò che tocca scorte, credito o una spedizione arriva all'ufficio ordini come decisione già preparata, non come conversazione da districare.
Questo articolo descrive uno schema di progettazione, non un risultato misurato. L'agente per gli ordini pubblicato da VoxDonna crea ordini cliente a partire da ordini di acquisto, e i suoi casi di accettazione usano dati sintetici. Non abbiamo pubblicato risultati sulle modifiche d'ordine, e nessun numero qui sotto è un risultato VoxDonna.
Perché le Modifiche Sono Più Difficili dei Nuovi Ordini
Un nuovo ordine non fa riferimento a nulla di esistente. Una modifica fa riferimento a qualcosa che esiste già e che continua a muoversi dopo l'invio dell'e-mail.
Tre elementi rendono il lavoro diverso:
- L'e-mail indica un ordine, spesso in modo vago. «Spostate di una settimana l'ordine dell'Ohio» lascia all'agente il compito di trovare quale, quali righe, e se il cliente ne ha due simili aperti.
- La risposta giusta dipende dallo stato. Lo stesso annullamento è innocuo su un ordine che nessuno ha toccato e costoso dopo la creazione di una consegna.
- Lo stato può cambiare tra la lettura e la scrittura. Un ordine che alle 15:00 sembrava intatto può avere una consegna alle 15:02.
Una modifica sbagliata può alterare in silenzio un impegno su cui produzione o magazzino stanno già lavorando.
Un Precedente: Decide lo Stato, Non la Richiesta
I sistemi di gestione ordini codificano già questo principio. La documentazione di Oracle per il portale fornitori di Oracle Retail Order Broker Cloud Service (versione della documentazione 22.2.401.0) descrive come un fornitore tratta le richieste di un rivenditore di cambiare un indirizzo di consegna o annullare una riga d'ordine. L'esito dipende dallo stato della riga:
| Stato della riga | Che cosa succede a una richiesta di annullamento |
|---|---|
| Nuovo ordine | Applicata automaticamente |
| In lavorazione o In sospeso | Passa al fornitore per accettazione o rifiuto |
| Spedita o Annullata | Rifiutata automaticamente |
La stessa pagina riporta tre dettagli da copiare. Le richieste di annullamento sono per singola riga, quindi annullare un intero ordine richiede una richiesta per ogni riga. Un secondo cambio di indirizzo inviato prima che il primo sia deciso rifiuta automaticamente il primo. E quando una richiesta viene rifiutata automaticamente perché la riga è già spedita o annullata, nello storico non viene creata alcuna registrazione. È questa la lacuna da evitare: un rifiuto che non lascia traccia è il più difficile da spiegare a un cliente una settimana dopo. Fonte: Oracle Retail Order Broker Cloud Service, Purchase Order Change Requests.
Avvertenza sull'ambito: è un flusso di consegna diretta nel commercio al dettaglio, con stati propri, non l'ufficio ordini di un'azienda manifatturiera. È una prova della forma della regola, non del comportamento del vostro ERP.
Che Cosa l'ERP Permette a un Agente di Leggere Prima di Scrivere
Per SAP S/4HANA, il servizio OData degli ordini cliente API_SALES_ORDER_SRV restituisce campi di stato insieme all'ordine. Il riferimento del connettore per quel servizio elenca, nella testata dell'ordine, uno stato di consegna per tutte le righe, uno stato di fatturazione legata all'ordine per tutte le righe, uno stato di rifiuto per tutte le righe, uno stato complessivo dei controlli di credito, un blocco di consegna e un blocco di fatturazione. Su ogni riga elenca uno stato di consegna e un motivo di rifiuto. Espone inoltre operazioni per aggiornare un ordine e una riga d'ordine. Fonte: riferimento del connettore Ballerina per API_SALES_ORDER_SRV, versione 2.1.0.
Due note su questo uso. Si tratta di una pagina di connettore di terze parti generata dalla definizione del servizio SAP: verificate la disponibilità dei campi rispetto alla vostra versione e configurazione. E i controlli propri di SAP restano l'autorità: se SAP rifiuta una modifica, l'agente deve intercettare il rifiuto, mettere la richiesta in attesa con il suo contesto e non riprovare alla cieca.
La regola pratica che ne deriva è semplice. L'agente legge prima lo stato, applica a quello stato le vostre regole scritte e scrive solo quando una regola dice sì. Non deve avere alcun diritto di cancellare un ordine.
La Pipeline, Fase per Fase
Un agente di cui un direttore del servizio clienti può fidarsi segue lo stesso percorso per ogni e-mail.
- Acquisizione. Controlla la casella degli ordini, accetta solo domini di clienti noti e prenota ogni messaggio in un registro durevole prima di iniziare: un riavvio non può quindi produrre due risposte.
- Estrazione. Legge il corpo e gli allegati secondo uno schema fisso: cliente, numero d'ordine del cliente, tipo di modifica (quantità, data di consegna, indirizzo di consegna, annullamento di riga, annullamento d'ordine), righe interessate e nuovi valori. Un'e-mail che non è una richiesta di modifica viene registrata e lasciata stare.
- Individuazione. Abbina la richiesta a un solo ordine aperto usando cliente, numero d'ordine del cliente e riga. Zero corrispondenze o più di una: la richiesta viene messa in attesa. Non sceglie mai l'ordine più probabile.
- Lettura dello stato. Legge gli stati di consegna, fatturazione, blocco e credito di quell'ordine e, quando la modifica riguarda delle righe, di quelle righe.
- Regole. Codice ordinario confronta la modifica richiesta con la vostra politica: che cosa può cambiare, di quanto, sotto quale valore, per quali clienti. Ogni risultato viene registrato. Nessun modello ha voce in capitolo su se una regola si applichi.
- Decisione. L'agente sceglie se applicare, far rivedere o rifiutare, come descritto qui sotto.
- Registrazione. Una modifica applicata viene scritta nell'ERP, una nota viene registrata sull'ordine o nel CRM con la conversazione allegata, e la risposta parte nella conversazione originale. Anche un rifiuto viene registrato.
Tre Esiti: Applicare, Rivedere, Rifiutare
| Esito | Quando si applica | Che cosa riceve il cliente | Che cosa vede l'ufficio ordini |
|---|---|---|---|
| Applicare | Un solo ordine corrisponde esattamente, nulla a valle dell'ordine, nessun blocco, un tipo di modifica consentito dalla vostra politica, un valore sotto un tetto che fissate voi | Conferma della nuova quantità o data nella conversazione originale | Una riga di log con prima e dopo |
| Rivedere | Un aumento di quantità, un cambio di indirizzo di consegna, una data anticipata, una nuova riga, un ordine consegnato in parte, tutto ciò che riapre scorte o credito | Un messaggio che indica che cosa è stato ricevuto e quando attendersi una risposta | Una modifica preparata con il motivo per cui serve una persona |
| Rifiutare | Nessun ordine o più ordini corrispondenti, un ordine già consegnato o fatturato, istruzioni in contrasto, uno stato che non è stato possibile leggere | Un messaggio che indica che cosa non si può fare e che cosa può fare il cliente | Un'escalation con la conversazione completa |
Trattate per impostazione predefinita come revisioni gli aumenti di quantità e le date anticipate: chiedono all'azienda qualcosa di nuovo, come scorte, capacità o credito. Le riduzioni e le date posticipate sono i candidati abituali al trattamento automatico, e solo dove la vostra storia dimostra che sono di routine.
Iniziate con l'applicazione disattivata. Eseguite ogni modifica come bozza preparata per diverse settimane, confrontate ciascuna con ciò che ha fatto il vostro team e abilitate l'applicazione solo per il gruppo di clienti e il tipo di modifica in cui le bozze coincidevano.
Un Esempio Pratico (Illustrativo)
Questo è uno scenario costruito, non dati di clienti. Un produttore statunitense di valvole e raccordi industriali riceve un giovedì alle 18:10 un'e-mail dall'acquirente di un distributore, che cita il numero d'ordine del distributore. L'acquirente chiede quattro modifiche.
| Richiesta | Che cosa trova l'agente | Esito |
|---|---|---|
| Spostare di cinque giorni la data di consegna della riga 10 | Ordine intatto, nessuna consegna creata, nessun blocco | Applicata; conferma con la nuova data |
| Ridurre la riga 20 da 500 a 400 pezzi | Intatta, 400 è sopra il lotto minimo | Applicata; conferma con la nuova quantità |
| Aumentare la riga 30 da 200 a 300 pezzi | Scorte e credito vanno ricontrollati | Revisione; modifica preparata con i dati di scorte e credito allegati |
| Annullare la riga 40 | Martedì è stata creata una consegna | Rifiutata; passata all'ufficio ordini e al magazzino |
L'acquirente riceve la sera stessa una risposta: le righe 10 e 20 sono modificate, la riga 30 è in conferma, e la riga 40 non può essere annullata automaticamente perché è già in consegna, con un referente indicato. Venerdì mattina l'ufficio apre due elementi preparati invece di una conversazione. Richiamare o meno la consegna della riga 40 è una decisione aziendale per le persone, con la posizione del magazzino davanti.
Che Cosa Arriva nell'ERP e nel CRM
Una modifica applicata viene scritta sulle righe d'ordine interessate, con l'e-mail di origine indicata. Una nota sull'account cliente nel CRM registra che cosa è cambiato e chi l'ha confermato.
I permessi sono ristretti. L'agente aggiorna i campi di quantità e data sugli ordini che superano le regole, e registra. Non cancella ordini, non rimuove blocchi, non modifica i prezzi e non tocca i dati anagrafici dei clienti.
Il lato di acquisizione di questa casella è descritto in acquisizione degli ordini di acquisto e sulla pagina dell'agente per gli ordini. Il preventivo è la fase precedente, trattata in automazione delle RFQ.
Come Testare Prima Che Scriva Qualsiasi Cosa
Eseguite questi casi su una copia della casella degli ordini e su un ERP di prova, e leggete il log di esecuzione invece della risposta. Sono criteri di accettazione da eseguire, non risultati che abbiamo misurato.
- Modifica di un ordine intatto, corrispondenza esatta. Atteso: applicata una sola volta, con registrazione di prima e dopo.
- Due ordini aperti dello stesso cliente con righe simili. Atteso: messa in attesa, nulla modificato, entrambi i candidati allegati.
- Annullamento di una riga la cui consegna esiste già. Atteso: rifiutata ed escalata, non applicata.
- La stessa e-mail di modifica consegnata due volte, con un riavvio durante l'esecuzione. Atteso: una sola modifica e una sola risposta.
- Una consegna creata tra la lettura dello stato e la scrittura. Atteso: il rifiuto dell'ERP viene intercettato, la richiesta messa in attesa e al cliente non viene detto che la modifica è stata applicata.
- Un aumento di quantità che porta il cliente oltre il suo limite di credito. Atteso: revisione, non applicazione.
Un agente che applica la modifica semplice è facile da costruire. Ciò che conta è che rifiuti le altre cinque.
Da Dove Iniziare
- Misurare la base di partenza. Dagli ultimi 90 giorni della casella degli ordini, contate le richieste di modifica a settimana, la quota arrivata dopo la creazione di una consegna e il tempo mediano di conferma.
- Ordinarle per tipo. Spostamenti di data, riduzioni, aumenti, annullamenti. La composizione indica quanta parte potrebbe mai essere gestita senza revisione.
- Scrivere la politica. Che cosa può cambiare, di quanto, per chi. Se il vostro ufficio non sa enunciarla, un agente non può seguirla.
- Avviare un pilota in modalità bozza. Misurate con che frequenza la modifica preparata coincide con ciò che avrebbe fatto il vostro team.
Se state confrontando questo approccio con l'automazione tramite script, dipendente IA o RPA spiega dove si adatta ciascuno. L'insieme dei flussi di lavoro per l'industria è sulla nostra pagina agenti IA per le aziende manifatturiere.
FAQ
Un agente IA può annullare un ordine di acquisto?
Per una classe ristretta, sì. Una corrispondenza esatta, nulla a valle, nessun blocco e un valore sotto un tetto che fissate voi possono essere gestiti in automatico. Quando esiste una consegna o una fattura, l'agente deve rifiutare ed escalare, perché la decisione coinvolge magazzino e finanza, non solo l'ordine.
Come evita di modificare l'ordine sbagliato?
Abbina cliente, numero d'ordine del cliente e riga. Se il risultato è zero o più ordini, non modifica nulla e mette la richiesta in attesa con i candidati allegati.
E le modifiche che arrivano via WhatsApp o per telefono?
La pipeline è la stessa: estrarre, individuare, leggere lo stato, applicare le regole. L'agente per gli ordini pubblicato da VoxDonna legge le e-mail e non abbiamo pubblicato un flusso di modifica su altri canali; qualsiasi altro canale verrebbe definito come progetto.
VoxDonna ha pubblicato risultati sulle modifiche d'ordine?
No. Questo articolo è uno schema di progettazione costruito sulla nostra pipeline di acquisizione ordini pubblicata. Qualsiasi risultato misurato verrà da un progetto definito, con base di partenza, periodo e metodo dichiarati.