Tutto ciò che facciamo realmente quando implementiamo, configuriamo e connettiamo un org Salesforce, scritto per intero. Architettura della piattaforma e oggetti, configurazione di Sales Cloud e Service Cloud, sviluppo personalizzato con Apex e Lightning, Flow automation, migrazione dati, integrazioni con il resto del tuo stack, reportistica e guida all'adozione reale. Nessun luogo comune sulle best practice generiche. Il metodo concreto.
Salesforce viene venduto come una piattaforma che fa tutto di default. Non è così. La configurazione standard si adatta quasi a nessuna azienda reale, e il gap tra ciò che viene consegnato e ciò di cui il tuo team ha davvero bisogno è esattamente dove falliscono le implementazioni. Questa guida copre quel gap per intero: come è strutturata la piattaforma, come modelliamo i dati, come automatizziamo senza creare un incubo di manutenzione, come migramo in modo pulito e come connettiamo il resto del tuo stack senza creare una rete fragile di chiamate API.
Salesforce è una piattaforma cloud multi-tenant costruita su un'architettura metadata-driven. Tutto ciò che configuri, dagli oggetti e i campi ai Flow e ai page layout, vive come metadato nel tuo org. È questo che rende possibili i deployment e il controllo di versione: stai spostando metadati tra sandbox e produzione, non codice nel senso tradizionale del termine.
La piattaforma si divide in cloud, ognuno dei quali serve una parte diversa del business. I due che implementerai più comunemente sono Sales Cloud, che gestisce pipeline, account, contatti, opportunità e lead, e Service Cloud, che aggiunge Case, routing Omni-Channel, una knowledge base e strumenti per contact center. Condividono la stessa piattaforma sottostante e possono coesistere nello stesso org.
Sopra i cloud si trova la tua personalizzazione: gli oggetti e i campi custom che modellano il tuo business specifico, il layer di automazione (Flow e Apex), il layer UI (page layout Lightning e Lightning Web Component) e il layer di integrazione che connette Salesforce agli altri tuoi sistemi. La sequenza conta perché le decisioni prese al livello del data model si propagano verso l'alto attraverso tutti gli altri layer.
Ogni intervento inizia con un audit perché lo stato di un org esistente (o i requisiti per uno nuovo) determina tutto il resto. Per gli org esistenti ci colleghiamo tramite una Connected App in sola lettura ed eseguiamo un health check strutturato. Per le nuove implementazioni conduciamo un workshop sui requisiti prima di toccare la piattaforma.
L'audit copre cinque aree:
L'output è una roadmap con le priorità ordinate. Ogni voce ha l'impatto sul business quantificato, lo sforzo per correggerla e se può essere affrontata in modo dichiarativo o richiede sviluppo. Ricevi tutto questo prima di firmare qualsiasi contratto.
Il modello a oggetti è il fondamento. Se lo sbagli, finisci con workaround sopra workaround, report che richiedono SOQL complesso per essere utili e automazioni che si rompono ogni volta che i dati cambiano forma. È qui che falliscono la maggior parte delle implementazioni poco specificate.
Salesforce fornisce oggetti standard per le entità più comuni: Account, Contact, Lead, Opportunity, Case. Sono buoni punti di partenza. La domanda è quando estenderli rispetto a quando costruire un oggetto custom. La regola è semplice:
Le relazioni tra oggetti in Salesforce sono di tipo lookup (soft, il figlio può esistere senza il padre) o master-detail (hard, eliminare il padre elimina il figlio, i rollup summary sono possibili). Scegliere in modo errato significa non poter eseguire i report di rollup necessari, o perdere dati quando i record padre vengono fusi o eliminati. Documentiamo il tipo di relazione e il comportamento di cascade-delete per ogni relazione che creiamo, perché influisce su come interroghi i dati e su cosa succede in produzione.
Una configurazione Sales Cloud ben fatta elimina l'attrito tra come vende il tuo team e ciò che il sistema si aspetta da loro. Il punto di attrito più comune in quasi ogni configurazione di default è il ciclo di vita del lead: come un nuovo nominativo diventa un contatto qualificato e quando diventa un'opportunità.
Approcciamo la configurazione Sales Cloud in quattro parti:
Il routing dei lead assegna i nuovi lead al rep, al territorio o alla coda corretta. Lo scoring dei lead (tramite campi custom, regole di scoring o una piattaforma di marketing automation connessa) mette in evidenza i lead da chiamare subito. La conversione mappa i campi del lead sul Contact, Account e Opportunity che ne derivano, in modo che nessun contesto originale vada perso. La maggior parte delle configurazioni di default perde dati alla conversione perché il field mapping non è mai stato configurato.
Le fasi delle opportunità devono riflettere come il team chiude davvero le trattative, non una metodologia di vendita generica. Intervistiamo il team, mappiamo le fasi reali sulle percentuali di probabilità che Salesforce usa per il forecasting e scriviamo criteri di ingresso e uscita per ogni fase così che il forecast sia significativo. Una pipeline con etichette di fase arbitrarie produce previsioni che nessuno si fida.
Il Collaborative Forecasting in Sales Cloud può aggregare il fatturato atteso per rep, manager e famiglia di prodotti in tempo reale. Farlo funzionare correttamente richiede che le probabilità delle fasi siano calibrate, che la gerarchia corrisponda alla struttura reale di reporting e che i record di quota siano caricati. Raramente è configurato correttamente di default perché richiede che configurazione e dati siano in posto contemporaneamente.
I rep non registreranno chiamate ed email manualmente in modo sistematico. Einstein Activity Capture o uno strumento di terze parti come Ebsta o Groove possono sincronizzare email e calendario da Gmail o Outlook automaticamente. Il compromesso è il volume di dati e i costi di storage. Configuriamo questo con retention policy che mantengono i dati utili senza far esplodere i costi di storage.
Service Cloud è costruito attorno ai Case: l'unità di lavoro per una richiesta di supporto. Le domande di configurazione sono come arrivano i case, come vengono instradati, come il team li lavora e cosa vede il cliente.
I case possono arrivare da email-to-case, form web-to-case, chiamate telefoniche (tramite integrazione CTI), chat, social e portali self-service. Ogni canale ha requisiti di setup diversi e diverse possibilità di arricchimento dati. Configuriamo prima i canali che il tuo team usa davvero, poi aggiungiamo complessità a partire da quelli.
Omni-Channel instrada gli elementi di lavoro (case, chat, chiamate) agli agenti in base a disponibilità, capacità e skill. Il modello di routing deve riflettere come è effettivamente organizzato il tuo team. Una configurazione di routing scritta per una struttura di team idealizzata che non corrisponde alla realtà metterà i case nelle code sbagliate dal primo giorno.
Gli entitlement definiscono il supporto a cui ha diritto un cliente e entro quando. Le milestone definiscono le azioni che devono avvenire entro quegli SLA. È una delle funzionalità più sottoutilizzate di Service Cloud, perché configurarla correttamente richiede che i tuoi contratti di supporto siano mappati e la logica di escalation concordata. Quando è configurata, Salesforce mostra in tempo reale quali case rischiano di violare l'SLA, che è l'unico modo per gestire un team di supporto in modo proattivo anziché reattivo.
L'automazione è dove arrivano i veri guadagni di produttività. È anche dove si accumula la maggior parte del debito tecnico, perché l'automazione aggiunta nel tempo senza un pattern di design diventa impossibile da comprendere o mantenere.
L'errore più comune che vediamo nei Flow è un singolo Flow che cerca di fare tutto innescato da una modifica di record. Inizia con due nodi di decisione e in tre anni diventa qualcosa che nessuno capisce. Separiamo le responsabilità: un Flow per processo, ogni Flow fa una cosa sola, ciascuno documentato con un campo descrizione che dice cosa fa e quando è stato rivisto l'ultima volta. Le versioni dei Flow si accumulano rapidamente; attiviamo solo una versione per Flow e puliamo le versioni inattive durante l'intervento.
Salesforce impone governor limit per proteggere l'infrastruttura condivisa da processi non controllati. I limit più colpiti sono il limite di query SOQL (100 query per transazione) e il limite DML (150 statement per transazione). Apex che esegue query dentro un loop raggiunge quasi subito il limite SOQL a qualsiasi volume di dati reale. Scriviamo tutto l'Apex con la bulkification in mente fin dall'inizio: query fuori dai loop, collezioni elaborate come insiemi. Flow è soggetto a limit diversi e la piattaforma gestisce più automaticamente la bulkification nelle versioni recenti.
La migrazione dati è il passaggio che la maggior parte delle implementazioni sottovaluta. Il lavoro non è spostare record; è decidere cosa spostare, pulirlo prima che arrivi e verificarlo dopo. I dati sporchi migrati in un org nuovo non migliorano nel tempo. Peggiorano man mano che si accumulano altri record.
Il Duplicate Management di Salesforce usa regole di matching per identificare near-duplicate prima che vengano creati e regole di duplicato per bloccarli o avvisare al salvataggio. Questo previene i duplicati futuri ma non fa nulla per quelli esistenti. Utilizziamo i Data Quality Analysis Dashboard o uno strumento dedicato (DemandTools, CRMFusion) per portare alla luce il set di duplicati esistenti, poi lavoriamo con una strategia di fusione: fusioni automatiche per le coppie ad alta confidenza, coda di revisione manuale per i casi ambigui e una regola di survivor che definisce quali campi di quale record vincono durante la fusione.
I campi dei dati sorgente raramente si mappano direttamente sui campi Salesforce. I valori dei picklist differiscono, i numeri di telefono sono in formati diversi, gli indirizzi vanno suddivisi e i record correlati devono essere risolti in Salesforce ID. Documentiamo ogni trasformazione in un migration spec prima di scrivere una riga di codice e validiamo il spec con un caricamento campione prima di eseguirlo a pieno volume.
Salesforce raramente vive in isolamento. La domanda non è se integrare, ma come, e la risposta è diversa a seconda del volume, della latenza e della criticità dei dati che fluiscono attraverso la connessione.
Le opzioni, in ordine crescente di complessità e costo di manutenzione:
Per le integrazioni in tempo reale dove la latenza conta, i Salesforce Platform Event permettono ai sistemi esterni di abbonarsi ai cambiamenti nell'org senza fare polling. Il Change Data Capture pubblica le modifiche ai record Salesforce come eventi, che i sistemi a valle possono consumare in modo affidabile senza interrogare l'API secondo uno schedule. Usiamo questi pattern per scenari ad alta frequenza e bassa latenza come gli aggiornamenti dello stato ordine o le notifiche di escalation case.
I report Salesforce di default sono un punto di partenza, non un prodotto finito. I report che il tuo team usa davvero devono essere costruiti dai dati che il tuo team traccia realmente, visualizzati al livello di accesso della persona che li legge e integrati nei workflow in cui si trovano già.
Approcciamo la reportistica su tre livelli:
L'implementazione più completa fallisce se il team non la usa. L'adozione non è un problema di formazione; è un problema di progettazione. Se il sistema è più difficile da usare del foglio Excel che ha sostituito, le persone useranno il foglio Excel.
Le decisioni che guidano l'adozione si prendono nella fase di progettazione, non in quella di formazione:
La formazione copre la meccanica, ma ciò che aumenta davvero l'adozione è la combinazione di un sistema ben progettato, un momento di go-live con una comunicazione chiara su cosa è cambiato e perché, e una persona di riferimento da chiamare quando qualcosa sembra sbagliato. Pianifichiamo una chiamata di go-live, un check-in a due settimane e una retrospettiva a quattro settimane come parte di ogni intervento.
Ogni intervento è a perimetro fisso e prezzo fisso. Il perimetro viene scritto prima che inizi qualsiasi lavoro, basato sui risultati dell'audit gratuito, e nulla si espande senza un change order firmato.
Conduciamo le implementazioni in tre fasi con punti di handover chiari:
Un unico punto di contatto. Hai una persona che gestisce la relazione, il piano di delivery e ogni escalation. Le specifiche arrivano con criteri di accettazione che il tuo team può verificare. Tutti i documenti sorgente, le mappe dati e gli script di migrazione rimangono tuoi all'handover.
Un elenco breve e onesto di ciò che non facciamo, perché spreca denaro:
Questo è il metodo completo. Quando vuoi applicarlo al tuo org, il passo successivo è un audit gratuito: un vero health check sul tuo org live, con una roadmap con le priorità, in circa una settimana, senza obblighi.
Un health check gratuito sui tuoi dati Salesforce reali, i risultati quantificati e un perimetro fisso per sistemare ciò che conta. Risultati entro una settimana.
Richiedi un audit Salesforce gratuito