Migrare il service desk da C4C a Service Cloud V2: casi, SLA e integrazioni

SAP Service Cloud V2 non è un aggiornamento di C4C, ma una nuova implementazione: modello dati diverso, API diverse, interfaccia diversa, framework di estensione diverso. Chi tratta il passaggio come un cambio di versione se ne accorge di solito durante la migrazione dei dati, quando le corrispondenze che «dovrebbero funzionare e basta» non funzionano. Per un primo passo a prezzo fisso, il nostro assessment di readiness per la migrazione da V1 a V2 verifica il vostro panorama in 3 giorni per CHF 7’500, scalati dall’implementazione V2.

Per un’organizzazione di medie dimensioni (da 50 a 200 agenti di servizio) contate da 6 a 10 mesi dall’analisi al go-live. Questo articolo descrive le cinque fasi che usiamo per i service desk. Le ragioni di business del passaggio sono spiegate nella nostra strategia di migrazione da C4C a V2, il prodotto nella pagina della soluzione SAP Service Cloud V2.

In sintesi: passare da C4C a Service Cloud V2 significa reimplementare. Per un’organizzazione di servizio di medie dimensioni prevedete da 6 a 10 mesi in cinque fasi: analisi, riprogettazione delle integrazioni, costruzione in parallelo, migrazione dei dati, formazione e go-live. I tempi slittano soprattutto su integrazioni e formazione degli agenti: iniziate presto con entrambe.

Cosa cambia davvero in V2

SAP ha costruito Service Cloud V2 su una nuova architettura cloud-native invece di far evolvere la base di codice di C4C. SAP documenta il nuovo prodotto separatamente nel portale di aiuto di SAP Service Cloud Version 2, accanto alla documentazione di SAP Cloud for Customer. Per la migrazione contano cinque differenze:

Piattaforma tecnica. V2 gira su una piattaforma diversa, con amministrazione, monitoraggio e modello di deployment propri. La logica personalizzata gira in parallelo su SAP BTP.

Modello dati. I record di ticket piatti diventano casi strutturati con stati del ciclo di vita, gerarchie e monitoraggio SLA integrato. Campi e oggetti di business personalizzati non vengono trasferiti automaticamente.

API. V2 ha un proprio design orientato alle API. Ogni integrazione costruita sui servizi OData di C4C va ricostruita sulle API di V2.

Interfaccia. Completamente nuova e basata sui ruoli. Gli agenti hanno bisogno di formazione, non solo di un elenco delle modifiche.

Estendibilità. Le estensioni PDI/SDK di C4C non hanno un equivalente in V2; la loro logica passa a servizi BTP (Node.js, Java, CAP). È più flessibile, ma richiede competenze diverse. Per un confronto funzione per funzione, si veda SAP Service Cloud V2 vs V1: cosa è cambiato.

Come si svolge la migrazione in cinque passi?

Passo 1: analisi e inventario (2-4 settimane)

Censite tutto ciò che c’è nel vostro ambiente C4C: configurazione, campi personalizzati, oggetti di business, integrazioni, report, regole di workflow e ruoli utente. Poi classificate ogni elemento.

Migrare se serve in V2 e lo ricostruirete nel nuovo modello. Riprogettare se serve, ma V2 lo copre nativamente (le regole di routing, ad esempio, diventano routing basato sulle competenze). Dismettere se non serve più o era solo un espediente.

Questa fase evita la causa di ritardo più comune: personalizzazioni non documentate che emergono a metà progetto. Se nessuno ricorda perché esiste una regola di workflow, il team passa giorni a scoprirlo. Nei progetti in cui l’analisi è stata affrettata, è esattamente ciò che è successo.

Passo 2: riprogettazione delle integrazioni (4-6 settimane)

La maggior parte delle integrazioni C4C va ricostruita da zero. Il vantaggio è che V2 offre contenuti di integrazione SAP per S/4HANA, Sales Cloud V2, Commerce Cloud e altri prodotti SAP, quindi il design di destinazione è spesso più semplice di quello attuale.

Mappate ogni punto di integrazione, valutate le alternative native di V2 e definite l’architettura di destinazione prima che qualcuno scriva codice. È anche il momento giusto per sostituire i collegamenti punto a punto con un’integrazione basata su eventi tramite SAP Integration Suite, più facile da monitorare e mantenere. Se S/4HANA Public Cloud fa parte del vostro panorama, SAP Service Cloud V2 + S/4HANA Public Cloud: dal ticket di servizio all’ordine ERP mostra il processo di destinazione.

Passo 3: costruzione in parallelo (8-12 settimane)

Costruite V2 mentre C4C resta in produzione. Nessun passaggio big bang.

Le aree di configurazione principali sono stati e transizioni del ciclo di vita dei casi, regole di routing basate sulle competenze e profili degli agenti, classificazione dei casi basata sull’IA (che richiede casi storici), migrazione e riorganizzazione della base di conoscenza, definizioni SLA e regole di escalation.

Così potete testare, validare gli script di migrazione e formare gli utenti prima del go-live, mentre gli agenti continuano a lavorare in C4C.

Passo 4: migrazione dei dati (4-6 settimane)

Migrate casi storici, account, contatti e attività con gli strumenti di migrazione di SAP. Definite le regole di mappatura per il nuovo modello dati, eseguite più migrazioni di prova con volumi paragonabili alla produzione e concordate una finestra di passaggio chiara. Il funzionamento del Data Transfer Tool è descritto nella nostra guida passo per passo alla migrazione con DTT.

Un dettaglio sfugge facilmente: la classificazione dei casi basata sull’IA impara da casi reali. Caricate presto i casi storici, così il modello ha dati prima del go-live; altrimenti partite senza uno dei motivi principali per passare a V2.

Passo 5: formazione e go-live (2-4 settimane)

Già la nuova interfaccia richiede una formazione adeguata, e i cambiamenti nei processi vanno più a fondo: routing, visibilità degli SLA, accesso alla conoscenza e funzioni di IA funzionano diversamente da ciò che gli agenti conoscono.

Coinvolgete i key user nei test di accettazione, formate in modo pratico invece che con presentazioni e prevedete dopo il go-live 2-4 settimane di stabilizzazione con supporto all’adozione. Saltare questo passo è il modo più rapido per perdere la fiducia degli agenti nel nuovo sistema.

Quali sono gli errori più comuni?

Quasi ogni migrazione mostra gli stessi schemi.

Personalizzazioni C4C non documentate. Regole di workflow, campi calcolati e mappature di integrazione mai messi per iscritto causano i ritardi maggiori. Usate la fase di analisi per documentare tutto, anche la regola di workflow creata anni fa da un predecessore.

Trattare V2 come un semplice trasloco. Chi ricopia il proprio setup C4C tale e quale perde l’occasione di semplificare. Diversi espedienti di C4C non servono più in V2, perché gerarchie dei casi e routing basato sulle competenze sono standard.

Sottovalutare il lavoro sulle integrazioni. Ogni interfaccia C4C cambia. Dieci integrazioni significano dieci ricostruzioni, che di solito richiedono più tempo del previsto.

Trascurare la gestione del cambiamento. L’interfaccia richiede formazione, e lo stesso vale per processi, routing, visibilità degli SLA e funzioni di IA. Gli agenti non formati tornano in pochi giorni a soluzioni manuali.

Ignorare i prerequisiti di dati per l’IA. La classificazione dei casi ha bisogno di dati storici. Se li caricate tardi, andate in produzione senza IA.

Perché migrare adesso e non più tardi?

L’innovazione di SAP per il servizio avviene in V2. A settembre 2026 SAP non ha annunciato una data di fine manutenzione per C4C, e V1 riceve ancora nuovi rilasci, ma le nuove funzioni come gli agenti Joule sono pensate per V2. I piani aggiornati sono nel SAP Roadmap Explorer. Ogni trimestre su C4C aggiunge personalizzazioni e integrazioni da migrare in seguito e allarga il divario rispetto alle funzioni di IA e al modello di estensione BTP di V2.

Affrettarsi resta però peggio che aspettare. Una strategia chiara, un’analisi accurata e tempi realistici trasformano la migrazione in un miglioramento invece che in un rischio. Se state ancora decidendo, il nostro assistente di migrazione da V1 a V2 fornisce una prima stima, e il confronto V1 vs V2 approfondisce la decisione. Quando siete pronti a pianificare, parlate con il nostro team.

Domande frequenti

Service Cloud V2 è un aggiornamento di V1?

No. Service Cloud V2 è un prodotto nuovo, con modello dati, API, interfaccia utente e modello di estensione propri. Campi personalizzati, integrazioni ed estensioni di C4C (V1) non vengono trasferiti: vanno ricostruiti o riprogettati in V2.

Quanto dura una migrazione da C4C a Service Cloud V2?

Per un’organizzazione di medie dimensioni (da 50 a 200 agenti di servizio, complessità di integrazione moderata) prevedete da 6 a 10 mesi. Gli ambienti più piccoli, sotto i 50 agenti, possono concludere in 4-6 mesi; i panorami molto personalizzati richiedono da 10 a 14 mesi.

Possiamo usare V1 e V2 in parallelo durante la migrazione?

Sì, ed è consigliabile. Costruire V2 mentre C4C resta in produzione permette di testare, provare la migrazione dei dati e formare gli agenti prima del passaggio. Raccomandiamo un periodo parallelo di almeno 8-12 settimane.

Cosa succede alle nostre integrazioni C4C?

Ogni integrazione C4C va verificata e la maggior parte va ricostruita, perché API e modello dati di V2 sono diversi. I contenuti di integrazione standard di SAP per S/4HANA e altri prodotti SAP rendono spesso il design di destinazione più semplice dell’originale C4C.

Servono competenze BTP per V2?

Sì. La logica personalizzata per V2 gira in parallelo su SAP BTP (Node.js, Java o SAP CAP) invece che nel PDI/SDK di C4C. Se il vostro team non ha esperienza BTP, prevedete formazione o lavorate con un partner che ha già realizzato estensioni V2.