Case-to-Resolution: collegare SAP Service Cloud V2 con S/4HANA Public Cloud

Una consegna arriva ammaccata dal cliente. La chiamata finisce al service, l’e-mail con le foto segue un’ora dopo, e da lì in molte aziende inizia un pellegrinaggio: il reclamo vive nella casella condivisa, l’ordine sostitutivo in una lista Excel, la nota di credito da qualche parte in contabilità. Il cliente chiama tre volte per sapere a che punto è la sua pratica, e riceve tre risposte diverse. È esattamente questo flusso che abbiamo ricostruito presso un produttore B2B: ticket in SAP Service Cloud V2, evasione in S/4HANA Public Cloud, stato di ritorno nel ticket. Questo articolo mostra come appare il collegamento quando è fatto in modo pulito, e quali regole del gioco si sono dimostrate valide nel progetto.

Dove vive il ticket, dove vive l’evasione

L’architettura inizia con una divisione dei compiti deliberata. Il ticket vive in Service Cloud V2. Lì convergono tutti i canali: e-mail, telefono, portale clienti, tutto diventa lo stesso oggetto, il case. Lì stanno anche le categorie di ticket, gli accordi sui livelli di servizio con scadenze ed escalation, e tutta la comunicazione con il cliente. L’agente vede a colpo d’occhio chi chiede, cosa è già successo e quanto tempo resta prima della violazione dello SLA.

L’evasione vive in S/4HANA. Ordine di service, reso, logistica dei ricambi, conferma, fattura o nota di credito: tutti documenti con gestione delle scorte, contabilità dei costi e contabilità finanziaria dietro. Un CRM queste cose non le sa fare, e non deve nemmeno provarci. Chi ricostruisce giacenze o fatturazione nel CRM sta costruendo un secondo ERP, solo peggiore.

Due sistemi, due ruoli. L’integrazione li collega, non li mescola.

Prima i dati anagrafici, poi il processo

L’errore più frequente in questi progetti è la sequenza. Tutti vogliono costruire subito il flusso di processo, creare l’ordine di service dal ticket, vedere lo stato che torna indietro. Solo che: senza dati anagrafici sincronizzati, niente di tutto questo funziona. Prima che un documento fluisca, due cose devono essere a posto.

Primo, i clienti. Gli account in Service Cloud V2 e i business partner in S/4HANA devono essere gli stessi, con un mapping pulito degli ID tramite la replica standard. Secondo, i prodotti registrati, l’equipment in linguaggio ERP. L’agente deve vedere nel ticket quale macchina, quale apparecchio, quale impianto si trova dal cliente, con numero di serie e data di installazione.

Solo allora il ticket diventa intelligente: la verifica di garanzia e diritti gira contro i dati S/4. L’apparecchio è ancora in garanzia? Esiste un contratto di service? Senza questo collegamento l’agente tira a indovinare o va a cercare nell’ERP, ed entrambe le cose costano minuti su ogni singola pratica. L’integrazione dei dati anagrafici non è spettacolare, ma è il fondamento. De facto decide se l’integrazione di processo che segue richiede settimane o mesi.

Il flusso pulito: dal ticket alla risoluzione

Ecco come appare il case-to-resolution quando entrambi i sistemi giocano il loro ruolo:

1. Il ticket nasce in Service Cloud V2, qualunque sia il canale. Chiamata, e-mail, inserimento da portale: tutto finisce nello stesso case, collegato al cliente e al prodotto registrato.
2. L’agente categorizza e verifica. Impostare la categoria, controllare garanzia e diritti contro i dati S/4, il cronometro SLA parte adesso.
3. Il documento successivo nasce in S/4HANA. Dal ticket viene avviata la transazione giusta: ordine di service, reso o richiesta di nota di credito, a seconda dello scenario.
4. S/4HANA evade. Prelevare il ricambio, confermare l’intervento del tecnico, fatturare o accreditare. L’ERP guida, come sempre.
5. Lo stato torna nel ticket. L’agente vede nel case che la consegna sostitutiva è partita o che la nota di credito è registrata, e informa il cliente da lì.

L’ultimo punto è il più importante: la comunicazione con il cliente resta interamente nel CRM. Il cliente ha un punto di contatto, un filo, una storia. Quello che succede nell’ERP non lo vede mai direttamente, lo apprende attraverso il ticket.

Il nostro scenario di esempio, la consegna ammaccata, si svolge allora così: arriva la chiamata, il ticket viene creato con la categoria danno da trasporto, le foto si agganciano allo stesso case via e-mail. L’agente verifica la consegna nel documento S/4 collegato, avvia il reso e la consegna sostitutiva, più la richiesta di nota di credito in un colpo solo. Appena S/4 conferma la sostituzione, l’informazione parte verso il cliente dal ticket. Una pratica, un numero, niente ricerche.

Cosa si è dimostrato valido nel progetto

Tenere piccola la tassonomia dei ticket. La tentazione è reale: costruire per il go-live un albero di categorie con quaranta rami, uno per ogni caso immaginabile. Il risultato: gli agenti scelgono a caso, e il reporting perde ogni valore. La nostra regola: da cinque a otto categorie alla partenza, poi affinare dopo tre mesi sulla base delle pratiche reali. Sono i dati stessi a mostrare dove servono rami più fini.

Collegare la telefonia. Nel service B2B il telefono resta il canale più forte. Un’integrazione CTI che identifica il chiamante e mostra all’agente il contesto del cliente mentre il telefono sta ancora squillando risparmia il primo minuto di ogni chiamata, più la fastidiosa domanda sul numero cliente. Abbiamo costruito adattatori CTI di questo tipo per Service Cloud V2 più volte; lo sforzo è contenuto, l’effetto quotidiano è grande.

E cosa è meglio lasciar perdere: primo, ricostruire la logica di stati dell’ERP nel CRM. Il ticket non ha bisogno di un gemello di ogni stato documento S/4, ha bisogno della risposta alla domanda del cliente: in lavorazione, in viaggio, concluso. Chi rispecchia ogni flusso documentale da quel momento mantiene due modelli di stato. Secondo, mantenere le gerarchie prodotto in doppio. La gerarchia ha una sola casa, l’ERP, e da lì viene replicata. Due gerarchie mantenute a mano divergeranno, è garantito, l’unica domanda è quando.

Cosa si ottiene alla fine

Una pratica tracciabile dalla prima chiamata fino alla nota di credito. Un agente che vede garanzia e stato di consegna senza cambiare sistema. Un cliente che chiama una volta invece di tre. E due sistemi che restano nello standard, perché nessuno imita il lavoro dell’altro.

Domande frequenti

Service Cloud V2 sostituisce uno strumento di ticketing separato?

Per il service rivolto al cliente: sì. Ricezione omnicanale, categorie di ticket, SLA, knowledge base e storia del cliente sono a bordo, e il collegamento all’ERP è il vero vantaggio rispetto a uno strumento di ticketing generico. Per il ticketing IT interno uno strumento dedicato resta spesso la scelta migliore; è un altro caso d’uso.

I tecnici sul campo possono lavorarci?

Sì, per interventi semplici direttamente con il ticket e l’ordine di service S/4. Quando la pianificazione diventa impegnativa, con turni, competenze e ottimizzazione dei percorsi, SAP Field Service Management è il complemento giusto: il ticket resta in Service Cloud V2, la pianificazione gira in FSM. Il ponte tra i due è standard.

Quale sforzo è realistico?

Se l’integrazione dei dati anagrafici è in piedi, cioè account ed equipment si replicano già, per il flusso case-to-resolution parliamo di settimane, non di mesi. L’integrazione standard via SAP Integration Suite copre i flussi documentali. Diventa costoso solo se mancano i dati anagrafici o se qualcuno costruisce eccezioni fatte in casa nella logica di stati.

I vostri reclami vivono in una casella condivisa e il vostro service va a cercare gli stati di consegna nell’ERP? Vi mostriamo volentieri il flusso dal vivo, con i vostri processi di service. Parlate con noi.