Skip to main content
SAP Service Cloud V2: Cosa è cambiato e perché è importante
Insights · ·6 min di lettura

SAP Service Cloud V2: Cosa è cambiato e perché è importante

Spadoom Editorial

SAP CX Practice

Condividi

SAP Service Cloud V1 (il lato service di C4C) faceva il suo lavoro. I ticket arrivavano, gli agenti li lavoravano, i case venivano chiusi. Ma il sistema mostrava la sua età: opzioni di routing limitate, categorizzazione basilare e un modello di estensione che rendeva ogni personalizzazione un rischio.

Service Cloud V2 è una ricostruzione da zero. Stesso nome, prodotto nuovo. Se lo state valutando per una nuova implementazione o pianificate una migrazione da V1, ecco cosa è effettivamente cambiato.

Nuovo case management

Il case management di V2 è fondamentalmente diverso. In V1, un ticket era un record piatto con campi di stato. In V2, un case è un’entità strutturata con un proprio motore di lifecycle.

Gestione lifecycle dei case. I case attraversano stati configurabili con transizioni definite. Voi stabilite quali stati permettono quali azioni, chi può attivare le transizioni e cosa succede automaticamente a ogni passaggio. Questo sostituisce il semplice campo di stato con un motore di workflow completo.

Gerarchia dei case. V2 supporta nativamente relazioni padre-figlio tra case. Un problema cliente complesso può generare sotto-case per team diversi — fatturazione, tecnico, logistica — mentre il case padre traccia la risoluzione complessiva. V1 richiedeva workaround per questo.

Tracking SLA. I Service Level Agreement sono integrati nell’entità case. Gli SLA di tempo di risposta e tempo di risoluzione si attivano automaticamente in base a priorità del case e livello del cliente. Gli agenti vedono timer con conto alla rovescia. I manager vedono dashboard di compliance SLA. V1 aveva supporto SLA basico; V2 lo rende operativo.

Routing omnicanale

V1 instradava i case per assegnazione manuale o regole basilari. V2 introduce routing reale:

Routing basato sulle competenze. Definite le competenze degli agenti (lingua, expertise prodotto, livello di certificazione) e instradate i case verso agenti che possono effettivamente gestirli. Niente più “assegna al team e spera che la persona giusta lo prenda.”

Gestione code. I case entrano in code con ordinamento per priorità. Gli agenti possono lavorare dalle code o ricevere assegnazioni automatiche basate su capacità e matching delle competenze.

Agnostico rispetto al canale. Email, telefono, chat, social media, form web — V2 li tratta tutti come fonti di case con routing unificato. Gli agenti vedono un’unica inbox indipendentemente da come il cliente ha fatto contatto.

Bilanciamento del carico. V2 distribuisce i case basandosi sul carico di lavoro degli agenti. Se un agente ha 15 case aperti e un altro ne ha 5, i nuovi case vanno a chi ha capacità. V1 non considerava affatto il carico di lavoro.

Classificazione assistita dall’AI

Qui V2 fa il salto più grande:

Categorizzazione automatica. Quando arriva un case, l’AI di V2 legge la descrizione e suggerisce categoria, sottocategoria e priorità. Per problemi comuni (reset password, richieste di fatturazione, domande standard sui prodotti), l’AI è sufficientemente precisa da classificare senza intervento dell’agente.

Analisi del sentiment. V2 analizza il linguaggio del cliente e segnala il sentiment negativo. I clienti frustrati vengono prioritizzati automaticamente. Gli agenti vedono un indicatore di sentiment prima di aprire il case.

Soluzioni suggerite. Basandosi sul contenuto del case, V2 suggerisce articoli dalla knowledge base e passaggi di risoluzione da case passati simili. Gli agenti non partono da zero — partono con contesto rilevante.

Apprendimento continuo. Il modello AI migliora man mano che gli agenti correggono i suoi suggerimenti. Dopo qualche mese di dati reali, l’accuratezza della classificazione raggiunge tipicamente l’80-90% per le categorie di case più frequenti.

Architettura API-first

Come Sales Cloud V2, Service Cloud V2 è costruito API-first. Ogni operazione disponibile nell’interfaccia è disponibile tramite API REST.

Perché questo conta per il service: gli ambienti service hanno più integrazioni del sales. Sistemi telefonici, chatbot, knowledge base, strumenti field service, ERP — tutti devono comunicare con il sistema di case management. La copertura API completa di V2 rende queste integrazioni più pulite e affidabili.

Estensioni custom su BTP. Il vecchio modello di estensione V1 (PDI) non c’è più. Le estensioni girano su SAP BTP — Node.js, Java, CAP, Cloud Foundry. Per scenari service, questo significa che potete costruire logica di escalation personalizzata, connettori a sistemi esterni o strumenti agente specializzati senza toccare il core di Service Cloud.

Integrazione event-driven. V2 pubblica eventi (case creato, case aggiornato, SLA violato) su SAP Event Mesh. Le vostre estensioni reagiscono agli eventi in tempo reale invece di interrogare per cambiamenti. Questa è la base di un’architettura pulita e manutenibile.

Cosa significa per la migrazione

Se siete su V1 e state considerando V2, ecco il quadro onesto:

Non è un aggiornamento. Come per Sales Cloud, Service Cloud V2 è una reimplementazione. La vostra configurazione V1, gli oggetti custom e le integrazioni non si trasferiscono direttamente.

Le regole di routing vanno riprogettate. Il motore di routing V2 è più potente ma completamente diverso. Le vostre regole di assegnazione V1 devono essere riprogettate per il modello basato su competenze di V2.

Migrazione knowledge base. Se avete una knowledge base in V1, serve pianificazione per la migrazione. La gestione della conoscenza in V2 è integrata con le funzionalità AI — un buon momento per ristrutturare i contenuti.

Formazione agenti. L’interfaccia è diversa. I workflow sono diversi. La visibilità SLA è diversa. Gli agenti hanno bisogno di formazione strutturata, non solo di un’email “ecco il nuovo sistema.”

Rielaborazione integrazioni. Ogni integrazione V1 va rivista. Endpoint API e modelli dati sono cambiati. Prevedete tempo di sviluppo per le integrazioni.

Pianificate 4-6 mesi. Per un’organizzazione service di medie dimensioni (20-50 agenti), un’implementazione V2 focalizzata richiede 4-6 mesi. Ambienti complessi con personalizzazioni pesanti richiedono di più.

Cosa ha imparato Spadoom

Abbiamo implementato Service Cloud V2 insieme a Sales Cloud V2 per diversi clienti. Osservazioni chiave:

Partite dal routing. Il motore di routing è il miglioramento più grande e il più complesso da configurare. Fatelo bene presto — influenza tutto a valle.

L’AI ha bisogno di dati. L’AI di classificazione ha bisogno di dati case reali per addestrarsi. Importate case storici se li avete. Aspettatevi che l’accuratezza AI migliori nei primi 2-3 mesi.

L’omnicanale è un cambiamento di processo, non solo di tecnologia. Se i vostri agenti attualmente lavorano in code email e telefoniche separate, passare a un’inbox unificata cambia il loro flusso di lavoro. Pianificate per questo.

Le estensioni BTP ripagano velocemente. I progetti V2 più efficaci che abbiamo realizzato includono almeno un’estensione BTP — uno strumento di escalation personalizzato, un connettore knowledge esterno o un dashboard di reporting specializzato.


State valutando SAP Service Cloud V2 per la vostra organizzazione service? Vi illustriamo cosa è realistico per il vostro setup. Contattateci.

SAPService CloudSAP Service Cloud V2Customer ServiceMigration
Prossimo passo

Soluzioni per Servizio

Scopri come SAP Service Cloud V2 può trasformare il tuo business.

Articoli correlati

Chiedi a un esperto