Usiamo SAP Sales Cloud e Service Cloud in Spadoom. Ecco cosa abbiamo costruito.

Diciamo spesso ai clienti di non costruire teatro CRM.

Niente prima fase enorme. Niente workshop senza fine. Niente campi custom solo perché esistevano in un vecchio sistema. Partire dal lavoro. Costruire il processo. Andare live. Migliorare dopo.

Quando abbiamo deciso di usare SAP Sales Cloud V2 e SAP Service Cloud V2 per Spadoom, abbiamo dovuto applicare lo stesso criterio a noi stessi.

Abbiamo attivato le licenze dello stack a inizio 2026. Circa un mese dopo eravamo live.

Lo Scope

Abbiamo tenuto il primo rilascio volutamente snello.

Per le vendite, il processo base era chiaro:

• Acquisire lead da conversazioni reali, eventi e sito web.
• Gestire account e contatti in modo pulito.
• Tracciare opportunità senza trasformare ogni deal in un progetto amministrativo.
• Rendere visibili i follow-up.
• Dare al management contesto sulla pipeline senza costruire un mostro di reporting.

Per il service, il requisito era altrettanto pratico:

• Tracciare le richieste di supporto come case.
• Mantenere chiara la responsabilità.
• Collegare le richieste dal sito al processo di supporto.
• Rendere visibili stato e prossima azione.
• Non perdere il contesto cliente nei thread email.

Questo bastava per il go-live. Tutto il resto doveva meritarsi un posto.

Perché Sales Cloud V2

SAP posiziona Sales Cloud come CRM per l’esecuzione commerciale: lead e opportunity management, gestione account, guided selling, forecast e analytics.

La nostra domanda interna era più semplice: il team vede ciò che conta senza dover cercare?

Abbiamo configurato Sales Cloud intorno al modo in cui Spadoom vende. Raramente abbiamo una vendita transazionale. La prima conversazione spesso include architettura, integrazione, fit di prodotto e domande scomode sullo scope. Il CRM deve supportare questa realtà.

Ci siamo quindi concentrati su struttura account pulita, fasi opportunità utili, prossimi passi chiari e qualificazione sufficiente per non ripetere due volte la stessa conversazione.

Perché Service Cloud V2

SAP posiziona Service Cloud per le operazioni di servizio: case management, knowledge, automazione e processi di supporto clienti.

Per noi l’oggetto chiave è il case. Una richiesta di supporto ha bisogno di una casa. Ha bisogno di un owner. Ha bisogno di uno stato. Ha bisogno di contesto.

Prima del progetto, troppo supporto poteva ancora avvenire in posti facili da perdere: inbox, chat, note laterali. Funziona con poco volume. Inizia a far male con più clienti, più progetti e più passaggi di mano.

Service Cloud ci dà un posto unico per gestire quel lavoro.

Il Collegamento Con Il Sito

Il sito conta perché spesso è il primo punto in cui arriva una richiesta di supporto o un segnale commerciale.

Abbiamo collegato le submission del sito al processo interno, così le richieste entrano in SAP Service Cloud invece di restare in una mailbox. Non è glamour tecnico. È igiene operativa:

• La richiesta viene catturata.
• Il team giusto la vede.
• Lo stato può essere tracciato.
• La storia resta con il cliente.

È lo stesso tipo di integrazione che consigliamo ai clienti. Quindi l’abbiamo costruita per noi.

Cosa Abbiamo Personalizzato

Non abbiamo implementato un tenant demo SAP generico.

Abbiamo adattato il sistema a come lavora Spadoom:

• Fasi opportunità per deal SAP CX consulenziali.
• Categorie case che riflettono il supporto reale.
• Campi snelli per inserimento veloce, non completezza decorativa.
• Viste per chi lavora nel sistema.
• Intake dal sito collegato alle richieste di supporto.

Qui molti progetti CRM sbagliano. Restano troppo generici e nessuno usa il sistema. Oppure customizzano tutto e creano un problema di manutenzione.

La strada utile sta nel mezzo: adattare dove migliora il lavoro quotidiano, restare standard dove basta.

Cosa Abbiamo Imparato Di Nuovo

Il progetto ha confermato quello che vediamo nei progetti cliente.

Primo: la velocità nasce dalle decisioni. Il prodotto non era il collo di bottiglia. La disciplina sullo scope sì.

Secondo: la configurazione standard arriva più lontano di quanto molti pensino. Non serve risolvere ogni irritazione nel primo rilascio.

Terzo: Service Cloud diventa utile quando i case sono la casa predefinita del supporto. Se il supporto resta nelle inbox, il sistema resta decorativo.

Quarto: usare il sistema cambia il modo in cui consigliamo. Sentiamo ogni giorno i piccoli dettagli di workflow. Le nostre raccomandazioni diventano più precise.

La Forma Tecnica

Il progetto è rimasto pulito:

• SAP Sales Cloud V2 per lead, account, contatti e opportunità.
• SAP Service Cloud V2 per supporto basato su case.
• Intake dal sito collegato al processo di supporto.
• Configurazione standard prima.
• Personalizzazione dove migliora il lavoro quotidiano.
• Estensioni future fuori dallo scope del primo go-live.

Nessuna cerimonia. Nessun teatro di trasformazione. Solo un sistema che funziona.

Perché È Raro

Molti partner SAP vendono SAP CX. Meno partner gestiscono vendita e service interni sugli stessi prodotti.

Questo conta. Quando parliamo di adoption, campi, code di servizio, qualità dei lead, handover o intake dal sito, non parliamo solo da progetti cliente. Parliamo anche dal nostro sistema quotidiano.

È più difficile raccontarsela quando usi il prodotto ogni giorno.

Fonti

• Panoramica SAP Sales Cloud
• Panoramica SAP Service Cloud
• Panoramica SAP Business Technology Platform

In Sintesi

Siamo andati live circa un mese dopo l’attivazione delle licenze. Veloce, sì. Ma la parte importante arriva dopo il go-live.

Il sistema supporta ogni giorno vendite e supporto. Offre una pipeline più pulita, una coda di supporto più chiara e più contesto cliente.

Usare quello che consigliamo.

Lo facciamo. Poi miglioriamo la ricetta.