Un’organizzazione di supporto risponde a tre domande diverse: a cosa ha diritto questo cliente, chi gli risponde e da dove entra la richiesta. Service Cloud le tratta con tre famiglie di strumenti separate — entitlement management, routing, canali — e l’esame le mescola apposta: la risposta sbagliata è quasi sempre lo strumento giusto per l’altra domanda.
Entitlement: la promessa scritta
Un entitlement rappresenta l’unità di supporto a cui il cliente ha diritto — phone support, web support, un livello di servizio. Si abilita da Setup → Entitlement Settings → Enable Entitlement Management. Nella stessa pagina si stringono due lookup filter che l’esame ama: limitare la lookup Asset allo stesso account del case e la lookup Entitlement ai soli entitlement attivi, così l’agente non aggancia per sbaglio un contratto scaduto o di un altro cliente.
Abilitare non basta: l’entitlement si vede solo se l’admin aggiunge la related list Entitlements ai page layout di Account, Contact e Asset, i campi Entitlement Name, SLA Policy Start Time e SLA Policy End Time al layout del case, e concede la field-level security su quei campi ai profili degli agenti. Un entitlement «invisibile» è quasi sempre layout o FLS, non licenze.
| Oggetto | A cosa risponde |
|---|---|
| Service Contract | il contratto commerciale con l’account: Start Date, End Date, Term (months) |
| Entitlement | a cosa ha diritto il cliente: periodo di validità, SLA Policy, collegabile ad account, contact, asset o service contract |
| Entitlement Process | in quanto tempo va servito: la timeline applicata al case |
| Milestone | il singolo passo obbligatorio (First Response, Resolution Time) |
| Milestone Action | cosa succede in automatico: success, warning, violation |
L’entitlement da solo verifica il diritto, il processo misura il tempo: esistono entitlement senza processo, non milestone senza processo.
Il processo e l’orologio
Si crea da Setup → Entitlement Processes con Type = Case, poi si dichiarano l’ingresso (per esempio based on case created date) e l’uscita (based on when case is closed). Il campo Business Hours sul processo è il cuore di metà delle domande: se valorizzato, il conteggio delle milestone avanza solo durante l’orario dichiarato; se lasciato vuoto il processo ragiona 24/7.
Ogni milestone dentro il processo porta Time Trigger (Minutes), un Order e i criteri che la fanno scattare (Case: Priority equals High, Account: Support Level equals Gold). Le sue azioni si dividono in tre famiglie, e la distinzione è esattamente ciò che l’esame chiede:
- Success action — quando la milestone viene completata in tempo;
- Warning action — prima della target date, per avvisare che la scadenza si avvicina;
- Violation action — dopo, quando la promessa è stata mancata.
Ciascuna porta un proprio time trigger e una workflow action, tipicamente un email alert con Recipient Type (Case Owner, un ruolo, un utente scelto). «Il manager va avvisato quando la promessa di prima risposta salta» è una violation action su una milestone First Response, con le business hours del team sul processo. Non è una escalation rule: quella riassegna un case per anzianità, non misura un impegno contrattuale legato al livello di supporto.
Il campo Recurrence Type della milestone (No Recurrence, Independent, Sequential) serve quando lo stesso passo deve ripetersi a ogni risposta del cliente.
⚠️ Trailhead avverte che chiudere il case non completa da solo la milestone: serve un’automazione che la marchi completata. È una configurazione da fare, non un limite immutabile: è il tipo di vincolo che le release recenti hanno reso dichiarativo.
Knowledge: l’articolo al posto della risposta riscritta
Lightning Knowledge usa i record type dell’oggetto Knowledge al posto dei vecchi article type e le data category per classificare gli articoli e governarne la visibilità per gruppo di utenti. Un articolo vive per versioni e attraversa gli stati Draft → Published → Archived: si lavora a una nuova versione senza togliere dal sito quella pubblicata. Dal Case Feed l’agente cerca l’articolo nel componente Knowledge, lo allega al case o lo inserisce nella risposta email, mentre Einstein Article Recommendations gli propone i pertinenti. Gli stessi articoli, con le data category giuste, alimentano la knowledge base di un sito Experience Cloud: scritti una volta, servono agente e cliente.
I canali: dove agente e cliente si incontrano
| Superficie | Cosa abilita | Segnale nello scenario |
|---|---|---|
| Web-to-Case | form pubblico, HTML generato da Salesforce | visitatore anonimo, nessun login, nessun follow-up |
| Email-to-Case | casella di supporto instradata a case | «i clienti scrivono a un indirizzo» |
| Chat / messaging | conversazione sincrona con l’agente | «parlare in tempo reale dal sito» |
| Experience Cloud site | cliente autenticato: apre case, ne rivede lo stato e le risposte, cerca la knowledge base | «self-service», «dopo il login», «vedere i propri case» |
| Agentforce Service Console + Case Feed | il posto di lavoro dell’agente: canali, macro, Knowledge in un’unica schermata | l’agente, non il cliente |
| Omni-Channel | distribuisce il lavoro agli agenti | «in base al carico», «all’agente giusto» |
Due confini restano fermi: Web-to-Case crea un case e finisce lì — se il cliente deve tornare a vedere stato e risposte serve un sito Experience Cloud con utenti esterni autenticati; e Omni-Channel non è un canale d’ingresso, è il motore che assegna.
Routing: la coda non basta più
| Queue-based routing | Skills-based routing | |
|---|---|---|
| Criterio | appartenenza alla coda + capacity | skill richieste dal work item |
| Configurazione | Service Channel, Routing Configuration, Presence Status |
Skills, skill assegnate agli agenti, regole campo → skill |
| Risponde a | «distribuisci equamente» | «solo chi parla francese ed è formato su quel prodotto» |
| Allentamento | — | Drop Additional Skills Timeout rilassa i requisiti col passare del tempo |
La Routing Configuration governa comunque Routing Model (Least Active, Most Available), Units of Capacity, Priority e Push Timeout. Quando i requisiti sono congiunti — lingua e competenza di prodotto — moltiplicare le code non risolve: la risposta è lo skills-based routing. Salesforce sta spostando la configurazione su Enhanced Omni-Channel, con Unified Routing, Omni-Channel Flow e capacità primary contro interruptible: è la parte più mobile del dominio, verificala alla fonte prima di darla per acquisita in una certa release.
Estendere la piattaforma senza scrivere codice dentro l’org
| Prodotto | Quando è la risposta |
|---|---|
| API standard (SOAP, REST, Bulk, Metadata, Tooling, Streaming) | accesso puntuale ai dati o ai metadati dell’org |
| Platform Events | messaggi asincroni pubblicati e sottoscritti, «radio transmission from sender to receiver» |
| Salesforce Connect | dati esterni visti come oggetti, senza copiarli |
| Heroku | app web su larga scala, in altri linguaggi, con dati sincronizzati via Heroku Connect |
| MuleSoft (Anypoint Platform) | un layer d’integrazione riusabile: ogni sistema esposto una volta come API gestita e riutilizzabile da più progetti |
| MuleSoft Composer | integrazioni point-to-point dichiarative fra sistemi |
| AppExchange | la funzionalità esiste già come pacchetto |
«Una dozzina di sistemi back-office, ciascuno con la sua API, e un livello d’integrazione unico e riusabile» descrive l’API-led connectivity di MuleSoft, non le API di Salesforce e non Heroku.
Trappole tipiche d’esame
- Warning contro violation. «Avvisa prima che scada» è una warning action; «avvisa quando è già saltata» è una violation action. Confonderle costa la domanda anche se il resto della configurazione è giusto.
- Business hours dichiarate, non sottintese. Se la promessa vale «solo in orario di ufficio»,
Business Hoursva valorizzato sull’entitlement process: senza, il contatore corre anche di notte e la milestone risulta violata il lunedì mattina. - Entitlement contro escalation rule. L’entitlement misura una promessa legata al livello di servizio; l’escalation rule riassegna o notifica per anzianità del case. Uno scenario che parla di contratto Gold o Platinum è entitlement management.
- Web-to-Case contro Experience Cloud. Se il cliente deve fare login, riaprire i propri case, leggere le risposte dell’agente e cercare negli articoli, serve un sito Experience Cloud: un form Web-to-Case non restituisce nulla al cliente dopo l’invio.
- Code moltiplicate contro skill. Due requisiti che devono valere insieme sullo stesso agente sono skills-based routing; creare una coda per ogni combinazione è la distrazione tipica, e l’Omni-Channel queue-based da solo non la risolve.
- Nomi aggiornati. La console del supporto oggi è l’Agentforce Service Console; Einstein Copilot non esiste più, si chiama Agentforce, e Agent Builder è l’Agentforce Builder. Le feature Einstein di classificazione e raccomandazione, invece, il nome Einstein ce l’hanno ancora.