Guida all'implementazione di SAP Service Cloud V2: passo dopo passo per i team B2B

La maggior parte dei progetti SAP Service Cloud V2 che incontrano difficoltà le incontra per l’approccio all’implementazione, non per il software. Il team sceglie il prodotto giusto, firma il contratto e passa subito alla configurazione, senza prima mappare il proprio modello di assistenza. Tre mesi dopo arrivano le rilavorazioni, lo sforamento del budget e gli agenti frustrati.

Questa guida copre l’intero ciclo di implementazione, dalla prima call di definizione del perimetro alla fine dell’hypercare. Segue la metodologia SAP Activate che usiamo in ogni progetto, adattata a Service Cloud V2 in contesti B2B.

Se state migrando da C4C (Service Cloud V1), partite invece dalla nostra guida alla migrazione. Questo articolo è pensato per i team che introducono Service Cloud V2 come nuovo sistema, in sostituzione di uno strumento legacy, di fogli di calcolo o di caselle di posta condivise. Per i budget, la guida a prezzi e costi di Service Cloud V2.

In sintesi: Un’implementazione di Service Cloud V2 per un team B2B di medie dimensioni (da 50 a 150 agenti) richiede da 10 a 16 settimane fino al go-live seguendo SAP Activate, più circa quattro settimane di hypercare. Le fasi sono cinque: discovery e preparazione, configurazione, integrazione ERP, test e migrazione, go-live e hypercare. I rischi maggiori sono dati sporchi, configurazione eccessiva, scarsa attenzione all’esperienza degli agenti e formazione tagliata. I progetti semplici vanno in produzione in circa 8 settimane; quelli enterprise con più integrazioni richiedono da 4 a 6 mesi.

Preferite un partner a una guida fai da te? Spadoom è un SAP Gold Partner svizzero per Cloud ERP e Customer Experience: implementiamo SAP Service Cloud V2 e il lato S/4HANA dell’integrazione con un unico team, in Svizzera, Germania, Austria e Italia. Richiedete una call di definizione del perimetro oppure leggete come intelligentfood è andata in produzione con Sales e Service Cloud V2 in tre mesi.

Perché l’approccio all’implementazione conta più del software

SAP Service Cloud V2 offre un case designer configurabile, l’instradamento per team, tipo di caso o categoria, SLA standard, suggerimenti basati su AI per la categoria del caso e per i casi simili, e un agent desktop per telefono, e-mail e chat. SAP elenca il perimetro vincolante nella sua descrizione dell’ambito funzionale.

Tutto questo serve a poco se la configurazione non corrisponde al modo in cui lavora il vostro team di assistenza.

Abbiamo visto organizzazioni configurare 47 stati del ciclo di vita del caso perché “potrebbero servire”, impostazioni SLA con oltre 200 regole che nessuno riesce a mantenere e knowledge base riempite con 3’000 articoli provenienti da un sistema legacy, per lo più superati. Potete immaginare come siano andati quei progetti.

Lo schema si ripete: i team che capiscono il proprio modello di assistenza prima di toccare la configurazione finiscono prima, spendono meno e ottengono un’adozione più alta da parte degli agenti. I team che partono dallo strumento finiscono in un ciclo di rilavorazioni. Per questo la guida comincia prima del progetto.

Prima del progetto: perimetro e valutazione della prontezza

Prima di firmare un contratto di servizi, rispondete a quattro domande. Ogni domanda saltata torna fuori più avanti, di solito durante i test di accettazione.

1. Qual è il vostro modello di assistenza?

Mappate come funziona oggi l’assistenza: il processo reale, non lo schema appeso al muro. Sedetevi accanto agli agenti e osservate come gestiscono i casi. Documentate:

• Tipi di caso: quali categorie di richieste arrivano? Problemi tecnici, domande sulla fatturazione, resi, reclami in garanzia, richieste generiche? Ordinatele per volume.
• Percorsi di risoluzione: quali casi arrivano dritti alla soluzione? Quali rimbalzano tra i team? Dove avvengono i passaggi di consegne?
• Criteri di escalation: che cosa rende urgente un caso? Violazione dello SLA, fascia del cliente, tipo di prodotto, contatti ripetuti?
• Struttura dei team: come sono raggruppati gli agenti? Per competenza, area geografica, linea di prodotto o segmento di clientela?

È l’esercizio più prezioso dell’intera implementazione. Ogni decisione di configurazione (regole di instradamento, definizioni SLA, stati del ciclo di vita) discende da questo modello.

2. Quali canali usano i vostri clienti?

Censite ogni canale in entrata:

• E-mail: quante caselle condivise? Quale volume al giorno?
• Telefono: quale piattaforma di contact center usate (Cisco, Genesys, Microsoft Teams)? Vi serve la CTI?
• Chat: live chat sul sito? Chat in-app? WhatsApp Business?
• Moduli web: un portale clienti con un modulo per aprire ticket?
• Social media: i clienti segnalano problemi di assistenza su LinkedIn, X o Facebook?

Per ogni canale annotate il volume attuale e quello previsto dopo il go-live. Da qui derivano la configurazione dei canali e la pianificazione della capacità. Tenete presente che telefono, chat e SMS arrivano all’agent desktop di V2 tramite fornitori di comunicazione terzi e un widget dell’interfaccia; l’e-mail è gestita in modo nativo.

3. Quali sono i vostri SLA?

Documentate ogni accordo sul livello di servizio, interno ed esterno:

• Tempi di risposta per priorità (per esempio P1: 1 ora, P2: 4 ore, P3: 8 ore, P4: 24 ore)
• Tempi di risoluzione per tipo di caso e priorità
• Regole di escalation: che cosa succede quando uno SLA sta per essere violato?
• Fasce di clientela: i clienti premium ricevono risposte più rapide?
• Orari di servizio: calendari diversi per regioni diverse?

Service Cloud V2 prevede SLA standard per prima risposta, tempo di completamento e tempo di chiusura, e consente di definire parametri propri. Funziona bene, a condizione che gli input siano puliti. SLA vaghi producono automazioni vaghe.

4. Quali sistemi vanno collegati?

Disegnate il quadro delle integrazioni:

• ERP: S/4HANA o ECC? Di quali dati hanno bisogno gli agenti: storico ordini, stato della garanzia, base installata, fatturazione?
• Assistenza sul campo: i casi passano a tecnici in loco? Allora pianificate l’integrazione con SAP Field Service Management.
• Telefonia: CTI per screen pop e registrazione delle chiamate?
• Knowledge base: in quale sistema di conoscenza cercheranno gli agenti? V2 integra una knowledge base esterna invece di fornirne una propria.
• Identity provider: SSO tramite Microsoft Entra ID, SAP Cloud Identity Services o un altro IdP?
• Data warehouse e BI: esigenze di reporting oltre a SAP Analytics Cloud integrato?

Ogni integrazione amplia il perimetro, e le integrazioni richiedono regolarmente più tempo del previsto. Pianificate subito il margine, invece di sperare che non serva.

Fase 1: discovery e preparazione (settimane da 1 a 3)

Questa fase corrisponde alle fasi Discover e Prepare di SAP Activate. L’obiettivo è trasformare la valutazione iniziale in un piano di progetto concreto, senza ambiguità aperte.

Workshop

Organizzate workshop strutturati con tre gruppi.

Direzione dell’assistenza (1 giorno): obiettivi strategici, KPI, target SLA, esigenze di reporting. Che cosa significa successo sei mesi dopo il go-live? Non “un’assistenza migliore”, ma numeri precisi come “tempo di risposta P1 sotto i 30 minuti, risoluzione al primo contatto sopra il 65%”.

Team leader e agenti senior (2 giorni): analisi dettagliate per tipo di caso, scenari di eccezione e le soluzioni di ripiego che le persone hanno costruito attorno al sistema attuale. Queste soluzioni di ripiego rivelano requisiti che i documenti di processo formali non riportano, e sono sempre più numerose di quanto ci si aspetti.

IT e team di integrazione (1 giorno): panorama dei sistemi, disponibilità delle API, accesso ai dati, requisiti di sicurezza e conformità, configurazione di tenant e landscape (tenant di test e di produzione, trasporto della configurazione).

Mappatura dei requisiti

Redigete un documento dei requisiti che associ ogni esigenza di business a una funzionalità di Service Cloud V2:

Requisito	Funzionalità V2	Configurazione necessaria	Sviluppo personalizzato
Instradare i casi di fatturazione al team finanza	Instradamento per categoria e team	Categorie, team, regole di instradamento	No
Mostrare lo storico ordini del cliente nel caso	Integrazione S/4HANA	Contenuto di integrazione standard, mashup o dati replicati	Solo per dati fuori standard
Suggerire una categoria per i casi in arrivo via e-mail	Suggerimenti AI per la categoria del caso	Categorie storiche pulite, attivazione	No
Inoltrare i casi P1 a un responsabile dopo 30 minuti	SLA più autoflow	Definizione SLA, regola autoflow con notifica	No
Screen pop CTI per le chiamate in entrata	Agent desktop con widget di terze parti	Widget del fornitore, ricerca cliente	Dipende dal fornitore

Questa tabella è il vostro backlog di implementazione. Ogni riga viene stimata, prioritizzata e assegnata a uno sprint.

Verifica dei dati

Esaminate i dati che intendete portare in V2:

• Dati di account e contatti: quanto sono puliti? Duplicati? Campi mancanti? Contatti orfani?
• Casi storici: vi servono in V2? Quanti, in quale formato?
• Articoli di conoscenza: quanti sono? Quando sono stati rivisti l’ultima volta? Quanti sono ancora corretti?
• Dati di agenti e team: ruoli, competenze, disponibilità

I dati sporchi sono la causa di ritardo più frequente che osserviamo. Se i vostri dati account contengono il 30% di duplicati, sistemateli prima di configurare V2, non durante i test di accettazione, quando non resta più tempo per farlo come si deve.

Risultato

Un documento di perimetro che comprende la mappa del modello di assistenza, il catalogo dei tipi di caso, l’inventario dei canali con i target SLA, il quadro delle integrazioni con la classificazione per il go-live, la strategia di migrazione dei dati e il piano delle risorse. Questo documento diventa l’accordo di lavoro tra gli stakeholder di business e il team di implementazione.

Fase 2: configurazione e sviluppo (settimane da 4 a 9)

È qui che il sistema prende forma. Lavorate in sprint di due settimane e presentate i risultati agli stakeholder alla fine di ogni sprint, così le correzioni di rotta arrivano presto.

Configurazione della gestione dei casi

Partite dal ciclo di vita del caso e mantenetelo semplice.

1. Definite i tipi di caso: associateli alle categorie del vostro modello di assistenza. Resistete alla tentazione di creare un tipo per ogni caso limite: partite con 5-8 tipi di caso e aggiungetene altri dopo il go-live.
2. Progettate il ciclo di vita: un flusso B2B tipico è Nuovo, Assegnato, In lavorazione, In attesa del cliente, In attesa interna, Risolto, Chiuso. Sette stati, non 47.
3. Modellate fasi e passi: il case designer consente di definire fasi e passi (attività, moduli, approvazioni, workflow, mashup). Decidete chi può far avanzare un caso e quali azioni automatiche scattano, per esempio una notifica su “In attesa del cliente”.
4. Configurate i moduli del caso: quali campi compaiono per quale tipo di caso? Tenete i moduli snelli. Ogni campo inutile è un campo che gli agenti lasciano vuoto o riempiono a caso.

Configurazione dei canali

Configurate ogni canale individuato durante la definizione del perimetro:

• E-mail: collegate le caselle condivise. V2 crea, categorizza, prioritizza e instrada i casi a partire dalle e-mail in arrivo. Impostate modelli di conferma di ricezione per lingua e tipo di caso.
• Telefono: se la CTI rientra nel perimetro, trattatela come un filone di lavoro parallelo. Il vostro fornitore di telefonia si collega all’agent desktop tramite un widget e la ricerca cliente identifica chi chiama. Prevedete da 2 a 4 settimane solo per la CTI. Il nostro articolo sullo screen pop nativo nell’agent desktop di V2 descrive le insidie.
• Chat: configurate il fornitore di chat e la capacità degli agenti (quante chat contemporanee per agente), più le regole di overflow per quando tutti gli agenti di chat sono occupati.
• Modulo web: realizzate o collegate il modulo di invio del vostro portale all’API di creazione dei casi.

SLA

Configurate gli SLA a partire dai target documentati:

• Regole SLA: associate condizioni (tipo di caso, priorità, fascia del cliente) ai target di risposta e risoluzione. Partite con al massimo 10-15 regole. Ogni regola in più è una regola che qualcuno deve capire e mantenere.
• Calendari lavorativi: definite gli orari di lavoro per regione, festività incluse. Se sbagliate qui, i timer SLA contano notti e fine settimana. Ci è capitato di vederlo più di una volta.
• Escalation: che cosa succede al 75% dello SLA? Al 90%? Alla violazione? Notifiche, reinstradamento, aumento di priorità, avvisi al responsabile, tutto tramite autoflow.
• Dashboard SLA: predisponete viste di conformità per team leader e responsabili. Diventeranno la vista operativa quotidiana.

Regole di instradamento

Impostate l’instradamento:

1. Definite i criteri di instradamento: lingua, competenza di prodotto, livello tecnico, segmento di clientela, canale.
2. Create i team: raggruppate gli agenti in modo che i criteri corrispondano ai team. Siate realistici e non assegnate competenze che gli agenti non hanno.
3. Costruite le regole di instradamento: associate gli attributi del caso a team o responsabili. Definite soluzioni di riserva per quando non è disponibile nessuno con il profilo giusto (coda, team leader, escalation).
4. Impostate i limiti di capacità per canale: i casi telefonici richiedono piena attenzione, i casi via e-mail possono procedere in parallelo.

Knowledge base

V2 si collega a una knowledge base esterna: gli agenti la consultano dall’agent desktop e allegano gli articoli alle risposte. Il lavoro riguarda quindi meno la configurazione e più i contenuti:

• Scegliete e collegate il sistema di conoscenza per tempo, perché è un’integrazione come le altre.
• Definite la tassonomia: prodotto, argomento, articolo. Tenetela abbastanza piatta da permettere agli agenti di trovare i contenuti in due clic, non in cinque.
• Scrivete i primi articoli: concentratevi sui 20 tipi di caso con più volume. Coprono la maggior parte delle domande quotidiane.
• Stabilite cicli di revisione: gli articoli invecchiano. Impostate fin dal primo giorno una revisione trimestrale con responsabili nominati per ogni articolo, e monitorate quali articoli gli agenti usano e quali ignorano.

Suggerimenti AI

Service Cloud V2 suggerisce una categoria per il caso e mostra i casi simili. L’utilità di questi suggerimenti dipende dai vostri dati storici:

1. Ripulite lo storico: categorie usate in modo incoerente nel vecchio sistema insegnano all’AI la stessa incoerenza. Consolidatele prima della migrazione.
2. Decidete come gli agenti usano il suggerimento: accettarlo, correggerlo o ignorarlo. Le correzioni servono solo se le categorie che le sostengono sono chiare.
3. Misurate dopo il go-live: monitorate, per categoria, quanto spesso gli agenti modificano il suggerimento. Una categoria corretta di continuo indica di solito un problema di tassonomia, non di AI.

Partite presto. Non aspettate il go-live per scoprire che “contestazione fattura” finisce sempre in “richiesta generica”. Le funzionalità generative come Joule e il Digital Service Agent sono una decisione separata, con licenze proprie; pianificatele come fase successiva.

Fase 3: integrazione ERP (settimane da 6 a 10, in parallelo alla fase 2)

Per i team di assistenza B2B, l’integrazione con l’ERP è spesso la parte più preziosa dell’intera implementazione. Gli agenti hanno bisogno del contesto del cliente (storico ordini, stato della garanzia, base installata, fatturazione) senza cambiare sistema.

I contenuti di integrazione standard di SAP

SAP fornisce l’integrazione tra Service Cloud V2 e i propri ERP come contenuto preconfigurato su SAP Integration Suite (Cloud Integration). Comprende, tra l’altro:

• Business partner: account e contatti, in modo bidirezionale tra V2 e l’ERP
• Prodotti: l’anagrafica prodotti di S/4HANA da usare nei processi di assistenza
• Equipment e prodotti registrati: gli equipment dell’ERP come prodotti registrati in V2, la base per garanzie e base installata
• Codici e dati organizzativi come le organizzazioni commerciali
• Documenti successivi, per esempio ordini di assistenza o ordini di vendita creati nell’ERP a partire dal processo di assistenza

Lo storico ordini e i documenti di fatturazione vengono di solito mostrati nel caso tramite mashup o interrogazioni mirate, invece di essere replicati in blocco. SAP documenta la configurazione nel suo percorso di apprendimento sull’integrazione di Sales e Service Cloud V2 con S/4HANA e, per ECC, nella guida all’integrazione con SAP ERP.

Il contenuto standard copre gli scenari B2B più comuni. Ciò che resta sono di solito campi personalizzati, dati specifici di settore o modelli di dati legacy che richiedono estensioni. Se usate anche SAP Sales Cloud V2, il nostro articolo su S/4HANA Public Cloud e Sales Cloud V2 come stack integrato mostra come un’unica dorsale ERP eviti di costruire l’integrazione due volte, e la nostra guida all’integrazione tra Service Cloud V2 e S/4HANA Public Cloud approfondisce il flusso dal caso alla risoluzione.

Decisioni sull’architettura di integrazione

Tre domande da chiarire presto.

Replicare o consultare? I dati anagrafici (business partner, prodotti, prodotti registrati) vengono replicati. Per i dati transazionali è una questione di volumi: qualche migliaio di ordini per cliente si può mostrare in tempo reale tramite mashup, centinaia di migliaia di documenti storici non vanno copiati nel sistema di assistenza.

S/4HANA o ECC? Con SAP S/4HANA Public Cloud lavorate con API rilasciate da SAP e con i pacchetti standard su Integration Suite. Con ECC vi serve inoltre l’add-on di integrazione SAP nell’ERP, e la replica bidirezionale dei business partner richiede ECC 6.0 EhP8; le release precedenti replicano clienti e contatti in una sola direzione. In entrambi i casi mettete a budget mappatura, gestione degli errori e monitoraggio: il contenuto preconfigurato riduce il lavoro, non lo elimina.

Escalation verso Field Service Management. Se i casi passano ai tecnici, l’integrazione con FSM crea una chiamata di assistenza in FSM a partire dal caso V2. FSM gestisce pianificazione e invio dei tecnici, e gli aggiornamenti di stato tornano al caso, così agente e cliente vedono l’avanzamento. Trattatela come un filone di lavoro separato e prevedete da 2 a 4 settimane, a seconda della complessità della vostra configurazione FSM.

Test di integrazione (in parallelo)

Testate ogni integrazione singolarmente, poi da un capo all’altro:

1. Test delle interfacce: ogni chiamata restituisce i dati attesi per input validi e non validi.
2. Test di integrazione: i dati passano correttamente tra i sistemi in condizioni normali.
3. Gestione degli errori: che cosa succede quando S/4HANA non è disponibile? Timeout, nuovi tentativi e che cosa vede l’agente nel frattempo.
4. Test di volume: lavorate con dati in scala di produzione. Un’interfaccia che funziona con 10 record può cedere con 10’000.

Fase 4: test e migrazione (settimane da 9 a 13)

Pulizia dei dati

Pulite i dati prima della migrazione, non dopo. Priorità:

• Eliminate i duplicati di account e contatti nel sistema di origine. Migrare i duplicati raddoppia il lavoro di pulizia.
• Uniformate i valori dei campi: codici paese, formati dei numeri di telefono, valori di stato, nomi delle categorie. Dati incoerenti mandano in crisi regole di instradamento e report.
• Archiviate i record obsoleti: vi servono davvero in V2 50’000 casi chiusi del 2019? Migrate ciò che gli agenti consultano davvero e archiviate il resto. Di solito bastano da 12 a 18 mesi.
• Verificate i campi obbligatori: V2 ha campi obbligatori che il vostro sistema di origine potrebbe non imporre. Individuate le lacune prima della migrazione, non durante.

Test di accettazione utente (UAT)

L’UAT non significa “cliccare sulle schermate e dire che va bene”. Strutturatelo.

Script di test per ruolo:

• Agente di assistenza: creare un caso tramite ogni canale. Categorizzare, instradare, inoltrare, risolvere, chiudere. Verificare che i timer SLA partano e si fermino correttamente. Testare la ricerca nella knowledge base e il suggerimento di categoria dell’AI.
• Team leader: gestione delle code, assegnazione manuale, dashboard SLA, report del team, escalation.
• Responsabile dell’assistenza: visibilità trasversale tra i team, dashboard KPI, gestione delle eccezioni, modifiche di configurazione.
• Cliente (simulato): inviare una richiesta tramite portale, e-mail e chat, ricevere aggiornamenti di stato, confermare la notifica di risoluzione.

Testate ogni integrazione da un capo all’altro:

• Create un caso e verificate che i dati d’ordine di S/4HANA compaiano nel caso.
• Inoltrate a FSM e verificate che la chiamata di assistenza venga creata con i dati corretti e che lo stato torni indietro.
• Ricevete una chiamata in entrata e verificate che lo screen pop mostri chi chiama e crei il caso (se la CTI è nel perimetro).
• Inviate un caso tramite il portale e verificate che arrivi in V2 con il contesto cliente corretto.

Testate i casi limite:

• Violazione dello SLA: l’escalation scatta?
• Agente non disponibile: l’instradamento di riserva funziona?
• Invio duplicato: come lo gestisce il sistema?
• Allegati di grandi dimensioni: i limiti vengono rispettati?
• Caso creato fuori orario: il cronometro SLA si comporta correttamente?

Coinvolgete nell’UAT agenti veri, non solo membri del team di progetto. Gli agenti trovano problemi che sfuggono agli esperti di processo, perché guardano il lavoro in modo diverso.

Test di prestazione

Eseguite test di prestazione con volumi realistici:

• Capacità di creazione dei casi: se il lunedì mattina ricevete 500 casi all’ora, testate con 500 casi all’ora.
• Tempi di risposta della ricerca: ricerca nella knowledge base e ricerca dei casi con dati in scala di produzione.
• Tempi di caricamento delle dashboard: dashboard SLA con migliaia di casi aperti.
• Latenza delle integrazioni: recupero dei dati da S/4HANA sotto carico concorrente e, in particolare, latenza dello screen pop. Gli agenti notano tutto ciò che supera i due secondi.

Pianificazione del cutover

Scrivete un runbook di cutover, una checklist passo dopo passo per il fine settimana del go-live:

1. Migrazione finale dei dati (delta rispetto all’ultima prova)
2. Commutazione delle integrazioni (puntare le integrazioni al tenant di produzione)
3. Modifiche a DNS e instradamento delle e-mail (posta in entrata verso V2)
4. Smoke test: un caso per canale, una verifica per ogni sistema collegato
5. Abilitazione degli utenti e verifica dell’SSO
6. Criteri e procedura di rollback (definiteli prima che servano)

Provate il cutover almeno una volta e cronometratelo. Un cutover che “dovrebbe durare 4 ore” ma ne richiede 12 significa agenti fermi il lunedì mattina.

Fase 5: go-live e hypercare (go-live verso la settimana 13, poi quattro settimane)

Checklist di deployment

Prima della commutazione:

• Tutti i difetti emersi nell’UAT risolti o accettati come problemi noti con soluzioni alternative documentate
• Test di prestazione superati con volumi in scala di produzione
• Prova di cutover completata entro la finestra prevista
• Formazione degli agenti erogata e verificata, non solo pianificata
• Team di supporto informato e pronto per l’hypercare
• Procedura di rollback documentata e testata
• Monitoraggio attivo: volume dei casi, conformità SLA, errori di sistema, stato delle integrazioni
• Comunicazione inviata agli agenti: data del go-live, istruzioni di accesso, contatti di supporto, limitazioni note

Formazione degli agenti

La formazione non è un webinar di un’ora il venerdì prima del go-live. È ciò che decide l’adozione.

Settimana −2: formazione in aula (da 4 a 6 ore per gruppo di agenti)

• Navigazione e gestione dei casi per ogni tipo di caso
• Procedure per canale: e-mail, telefono (con CTI se prevista), chat contemporanee
• Visibilità degli SLA: che cosa significano i timer, che cosa fare quando scorrono, come “In attesa del cliente” li sospende
• Ricerca nella knowledge base e allegato degli articoli
• Suggerimenti di categoria dell’AI: che cosa fanno, quando correggerli
• Esercitazioni pratiche nel tenant di formazione

Settimana −1: pratica assistita (da 2 a 3 giorni)

• Gli agenti gestiscono casi simulati nel tenant di formazione
• Un formatore è disponibile per domande in diretta
• Gli errori più comuni vengono intercettati prima di arrivare in produzione

Settimana 1: sistema di affiancamento

• Affiancate a ogni agente un referente del gruppo UAT che conosce il sistema
• I referenti rispondono alle domande in tempo reale, direttamente sul posto
• Così la maggior parte delle domande di routine non arriva al team di progetto

I primi 30 giorni

Il go-live è l’inizio del periodo di verifica, non il traguardo.

Controlli quotidiani (settimana 1):

• Volume dei casi rispetto alla base attesa: passa tutto da V2?
• Conformità SLA rispetto al target concordato
• Tasso di accettazione dei suggerimenti di categoria dell’AI
• Tasso di errore delle integrazioni: obiettivo sotto l’1%
• Domande degli agenti: tracciatele tutte, rispondete in fretta, aggiornate il materiale formativo

Controlli settimanali (settimane da 2 a 4):

• Instradamento: i casi arrivano all’agente giusto alla prima assegnazione?
• Lacune di conoscenza: quali tipi di caso sono ancora senza articoli?
• Feedback degli agenti: sessioni strutturate di 30 minuti, non chiacchiere in corridoio
• Andamento SLA: in miglioramento, stabile o in peggioramento?
• Correzioni di categoria: gli agenti modificano sistematicamente certe categorie?

Fine della settimana 4: revisione di uscita dall’hypercare

• Tutti i difetti critici e ad alta gravità risolti
• Conformità SLA stabile sopra il target concordato
• Adozione confermata: gli agenti accedono ogni giorno, nessun caso gestito fuori da V2
• La knowledge base copre i tipi di caso con il volume più alto
• Passaggio formale al team di supporto con runbook documentati

Errori comuni e come evitarli

Questi schemi si ripresentano di continuo, e ciascuno si può evitare.

Dati sporchi

Che cosa succede: i team migrano dati account con il 30% di duplicati, contatti senza indirizzo e-mail e storici dei casi con categorie incoerenti. Le regole di instradamento si rompono, i report sono sbagliati e gli agenti diffidano del sistema dal primo giorno.

Come evitarlo: pulite i dati nel sistema di origine prima della migrazione: eliminate i duplicati, uniformate, verificate i campi obbligatori. È un lavoro poco appariscente ed è lo sforzo meglio speso dell’intero progetto. Prevedete da 2 a 3 settimane, separate dalla migrazione vera e propria.

Configurazione eccessiva

Che cosa succede: il team configura 30 tipi di caso, 47 stati del ciclo di vita, 200 regole di instradamento e 15 livelli di SLA. Nessuno sa spiegare come si incastri tutto, nessuno sa quale regola abbia causato un errore e ogni modifica diventa rischiosa.

Come evitarlo: partite dal minimo: da 5 a 8 tipi di caso, 7 stati del ciclo di vita, regole di instradamento che si spiegano ciascuna in una frase. La complessità si può aggiungere dopo il go-live, quando i dati di utilizzo reali la giustificano. Toglierla quando gli agenti hanno già preso le loro abitudini è molto più difficile.

Trascurare l’esperienza degli agenti

Che cosa succede: il progetto ottimizza per il reporting direzionale e la conformità ai processi. Il modulo del caso ha 40 campi obbligatori, gli agenti passano più tempo sui metadati che sui clienti, il tempo di gestione aumenta e il morale cala.

Come evitarlo: coinvolgete gli agenti nella progettazione e testate ogni modulo con loro prima del go-live. Se un caso standard richiede più di circa tre minuti di interazione con il sistema, semplificate il modulo. Il reporting può usare il contesto del caso e i dati derivati dall’AI; non servono 40 campi per caso.

Tagliare la formazione

Che cosa succede: il budget finisce o i tempi slittano, e la formazione si riduce a una sessione di due ore il giorno prima del go-live. Gli agenti partono confusi, costruiscono soluzioni di ripiego e continuano a usare l’e-mail in parallelo. Sei mesi dopo, la direzione si chiede se il sistema “funzioni”.

Come evitarlo: proteggete il budget della formazione fin dall’inizio. Da quattro a sei ore di formazione in aula più due o tre giorni di pratica assistita sono il minimo. Una formazione scarsa costa mesi di adozione debole.

Lanciare tutto insieme

Che cosa succede: il team cerca di andare in produzione lo stesso giorno con AI, knowledge base, CTI, integrazione FSM, portale clienti e analisi avanzate. Il progetto si allunga a sei mesi e ogni dipendenza aggiunge rischio.

Come evitarlo: definite un go-live minimo praticabile. Tappa 1: gestione dei casi di base, e-mail, SLA, instradamento di base, dati account da S/4HANA. Tappa 2 (go-live più 4 settimane): altri canali, suggerimenti AI, knowledge base. Tappa 3 (go-live più 8 settimane): integrazione FSM, CTI, analisi avanzate. Ogni tappa porta valore e poggia su una base stabile.

Tempi di riferimento

I tempi dipendono da tre variabili: il numero di agenti, il numero di integrazioni e la quantità di sviluppo personalizzato. Le durate indicate valgono fino al go-live; l’hypercare si aggiunge.

Semplice (circa 8 settimane)

• Da 10 a 30 agenti
• 1-2 canali (e-mail e modulo web)
• Nessuna integrazione ERP, oppure solo l’integrazione standard dei business partner
• Nessuna CTI
• Ciclo di vita del caso standard con instradamento di base
• Migrazione dati minima (solo account e contatti)

Standard (da 10 a 16 settimane)

• Da 50 a 150 agenti
• 3-4 canali (e-mail, telefono, chat, modulo web)
• Integrazione S/4HANA: sincronizzazione account, prodotti, prodotti registrati, contesto degli ordini
• SLA con regole per fascia di clientela ed escalation
• Suggerimenti di categoria dell’AI basati su uno storico dei casi ripulito
• Knowledge base con 50-100 articoli iniziali
• Migrazione dati moderata: account, contatti, casi aperti, articoli di conoscenza

Enterprise (da 4 a 6 mesi)

• Oltre 200 agenti in più regioni e fusi orari
• Tutti i canali, social media inclusi tramite un fornitore terzo
• Più integrazioni ERP (S/4HANA più ECC o un ERP di terze parti)
• CTI con una piattaforma di contact center (Cisco, Genesys o simili)
• Integrazione FSM per l’escalation verso l’assistenza sul campo
• Portale self-service per i clienti con tracciamento dei casi
• Estensioni personalizzate per workflow specifici di settore
• Migrazione dati complessa da più sistemi di origine
• SLA multilingua e su più fusi orari, con calendari lavorativi regionali

Sono intervalli, non promesse. La fase di definizione del perimetro serve proprio a trasformarli in un piano realistico per la vostra situazione.

Per le organizzazioni di assistenza svizzere, la nostra pagina sulla consulenza SAP CX in Svizzera spiega come componiamo e conduciamo i progetti Service Cloud V2 in quattro lingue.

Domande frequenti

Quanto dura un’implementazione di SAP Service Cloud V2?

Dipende dal perimetro. Un progetto semplice (da 10 a 30 agenti, e-mail e modulo web, nessuna integrazione ERP) va in produzione in circa 8 settimane. Un’implementazione B2B standard (da 50 a 150 agenti, 3-4 canali, integrazione S/4HANA, suggerimenti AI) richiede da 10 a 16 settimane fino al go-live, seguite da circa quattro settimane di hypercare. I progetti enterprise con più integrazioni, CTI, FSM ed estensioni personalizzate richiedono da 4 a 6 mesi. È la fase di definizione del perimetro a stabilire in quale categoria rientrate.

Serve S/4HANA per usare Service Cloud V2?

No, ma aiuta molto i team B2B. Service Cloud V2 è un prodotto SaaS a sé e funziona anche senza un ERP SAP. I team di assistenza B2B hanno però quasi sempre bisogno dello storico ordini, dei dati di garanzia e dei dati prodotto durante la gestione dei casi. SAP fornisce contenuti di integrazione preconfigurati su SAP Integration Suite sia per S/4HANA sia per SAP ERP (ECC). Con ECC serve inoltre l’add-on di integrazione SAP, e la replica bidirezionale dei business partner richiede ECC 6.0 EhP8.

Possiamo implementare Service Cloud V2 senza SAP Activate?

Si può, ma noi non lo faremmo. SAP Activate dà al progetto una struttura precisa che intercetta per tempo le cause tipiche di fallimento: perimetro poco chiaro, requisiti dimenticati e test insufficienti. La metodologia non è un peso burocratico; è una checklist che tiene il progetto in carreggiata. La adattiamo alle dimensioni e alla complessità di ogni progetto, come descritto in come lavoriamo.

Che differenza c’è tra questa guida e la guida alla migrazione?

La nostra guida alla migrazione tratta il passaggio da SAP Cloud for Customer (Service Cloud V1) a V2: migrazione dei dati da un sistema di assistenza SAP esistente, revisione delle integrazioni ed esercizio in parallelo. Questa guida tratta l’introduzione di V2 come nuovo sistema, qualunque cosa sostituisca. Le fasi di SAP Activate sono le stesse, ma il punto di partenza e i rischi cambiano.

Prossimi passi

Se state pianificando un’implementazione di Service Cloud V2, partite dalle quattro domande sul perimetro illustrate sopra: mappate il modello di assistenza, censite i canali, documentate gli SLA e disegnate il quadro delle integrazioni. Questa base rende tutto ciò che segue più rapido ed economico.

Un riferimento pubblicato: intelligentfood è andata in produzione con una piattaforma Sales e Service su V2 in tre mesi, collegata al proprio ERP. Se vi serve una stima realistica dei tempi o un secondo parere sul vostro perimetro, contattateci. Nessuna presentazione commerciale, solo una conversazione sulla vostra situazione.

Se state ancora scegliendo un partner di implementazione, la nostra panoramica sulle migliori società di consulenza SAP CX in Svizzera e la nostra guida per trovare un unico partner per Cloud ERP e CRM spiegano che cosa cercare quando il progetto di assistenza dipende dall’ERP. La pagina della soluzione SAP Service Cloud V2 descrive che cosa realizziamo dall’inizio alla fine, compresi team, referenze e residenza dei dati.