Negli ambienti Salesforce Field Service (SFS) su larga scala, la gestione delle reti di appaltatori esterni richiede un delicato equilibrio tra sicurezza della piattaforma e prestazioni di pianificazione. Questa guida confronta due schemi architettonici principali: lo schema tradizionale basato sul territorio e il nuovo schema di condivisione basato sugli account per la gestione e l'accesso degli appaltatori esterni. In questo articolo esaminiamo in dettaglio sia la struttura di base che meglio supporta i loro obiettivi operativi, sia i compromessi di ogni opzione.

Questa scelta dello schema influisce sull'efficienza di pianificazione, sull'utilizzo delle risorse e sulla produttività del dispatcher. Selezionando il giusto approccio, le aziende garantiscono un'esperienza senza interruzioni sia per il personale interno che per i partner esterni, mantenendo la scalabilità a lungo termine della loro soluzione.

Oltre ai vantaggi operativi immediati, questa scelta fondamentale determina la preparazione di un'organizzazione per un servizio autonomo. Lo schema di condivisione basato su account offre la visibilità unificata dei dati necessaria a Agentforce, e in particolare all'agente di pianificazione per Field Service, per eseguire una valutazione olistica senza essere limitati da silos di dati artificiali. La condivisione basata su account consente inoltre a Data Cloud di aggregare le metriche delle prestazioni degli appaltatori in modo più efficace, consentendo un benchmark competitivo senza interruzioni pur mantenendo il rigoroso isolamento dei dati richiesto negli ambienti multi-vendor.

• Selezionare lo schema in base alla sovrapposizione competitiva. Se gli appaltatori esterni competono con risorse interne o esterne su territori condivisi, la condivisione basata su account è probabilmente la scelta architetturalmente corretta. La condivisione basata sul territorio è appropriata solo quando gli appaltatori ricevono aree di servizio/lavori esclusivi e non sovrapposti.
• Evitare l'espansione dei territori. La creazione di territori appaltatori dedicati per ottenere l'isolamento dei dati quando non necessario introduce un aumento della gerarchia che degrada l'efficienza e le prestazioni della pianificazione e aumenta in modo significativo il sovraccarico amministrativo su larga scala. La condivisione basata su account elimina questo schema di problemi.
• Creare le basi per la pianificazione basata sull'intelligenza artificiale. L'agente di pianificazione per Field Service e il motore di ottimizzazione avranno prestazioni migliori quando avranno una visibilità completa del pool di risorse. La struttura a silo di condivisione basata sul territorio impedisce questo; la condivisione basata su account è la base architettonica desiderata.

Nell'ultimo decennio, le reti di appaltatori nel Field Service si sono evolute da estensioni ad hoc di team interni a ecosistemi strategici deliberatamente strutturati in settori quali telecomunicazioni, pubbliche utenze, servizi domiciliari e altro ancora. Molte attività sul campo ora si affidano a consulenti esterni e a dipendenti a tempo pieno, il che richiede regole chiare per l'accesso, la visibilità e il controllo delle spedizioni.

Man mano che le organizzazioni scalano Salesforce Field Service, il modo in cui progettano e gestiscono queste risorse esterne, sia attraverso uno schema basato sul territorio, la condivisione incentrata sugli account o gli ibridi, determina direttamente la sicurezza e l'efficienza con cui possono pianificare il lavoro in una forza lavoro mista.

Questa guida è destinata agli stakeholder tecnici e strategici responsabili della progettazione, delle prestazioni e della scalabilità delle implementazioni di Salesforce Field Service:

• Architetti Soluzioni e Tecnici: Valutare l'impatto dei diversi schemi di condivisione sull'efficienza di pianificazione e ottimizzazione.
• Responsabili delle operazioni di Field Service: Comprendere i compromessi tra i diversi profili degli appaltatori, ad esempio Appaltatori denominati, Società appaltatrici e Lavoratori occasionali.
• Amministratori Salesforce: Ottenere informazioni su come vengono utilizzati i territori di servizio e le tabelle di condivisione piattaforma per gestire requisiti di sicurezza complessi.

Il profilo dell'appaltatore nell'ambito determina direttamente l'architettura di condivisione appropriata. Ogni categoria ha implicazioni distinte per la struttura dell'accesso a livello di record, il modo in cui Optimizer percepisce la disponibilità delle risorse e la scalabilità della soluzione:

• Appaltatore denominato: Una singola risorsa esterna trattata in modo simile a un dipendente interno. Un appaltatore denominato richiede una licenza utente dedicata. Il modello di condivisione rispecchia gli schemi di accesso dei tecnici interni, rendendolo il profilo dell'appaltatore con la complessità più bassa da supportare.
• Società appaltatrice: Un'entità di terze parti che gestisce la propria forza lavoro. In SFS, le società appaltatrici sono rappresentate come risorse basate sulla capacità, dove l'organizzazione controllante pianifica e assegna il lavoro all'azienda anziché a una persona specifica.
• Lavoratore occasionale: Un utente che opera temporaneamente in più territori. Il personaggio architettonicamente più complesso. Le relazioni transitorie tra più territori determinano l'abbattimento dei confini di condivisione basati sul territorio, pertanto la visibilità viene gestita dinamicamente a livello di record anziché tramite assegnazione geografica statica.

Questi schemi sono complessi perché l'organizzazione controllante e gli obiettivi dell'appaltatore sono spesso tecnicamente in conflitto.

1. Obiettivi diversi: L'organizzazione controllante si concentra principalmente sulla soddisfazione dei clienti e sul lavoro/accordo contrattuale (ad esempio, preferenze delle risorse, assistenza rapida e tempestiva e gestione della distribuzione del lavoro e delle ore tra gli appaltatori). Gli appaltatori, al contrario, in genere si concentrano sulla massimizzazione del lavoro assegnato riducendo al minimo il tempo di percorso e i costi operativi.

2. Concorrenza: A differenza dei dipendenti interni, le diverse società appaltatrici sono spesso concorrenti diretti. Mentre l'organizzazione controllante necessita di una visione olistica della regione (trasparenza), gli appaltatori richiedono un rigoroso isolamento reciproco dalle attività (isolamento).

3. Integrità del marchio: Per il cliente finale, il lavoratore rappresenta il marchio, il che spesso richiede alla società controllante di visualizzare gli aggiornamenti di stato in tempo reale. Tuttavia, gli appaltatori spesso custodiscono le loro operazioni interne in un sistema chiuso, o "scatola nera".

4. Visibilità e sicurezza: Mentre un territorio di servizio condiviso in genere implica la visibilità universale di tutte le risorse assegnate, gli ambienti multi-contractor richiedono uno schema di sicurezza più sfaccettato. Per mantenere l'integrità competitiva e la privacy dei dati, è essenziale impedire agli appaltatori di accedere reciprocamente ai nomi proprietari, alle pianificazioni o alle informazioni sulle risorse.

La progettazione dell'appaltatore in Salesforce Field Service si estende su tre modelli operativi distinti, ciascuno dei quali influisce sulla visibilità delle risorse, sulla proprietà dei dispatch e sulle licenze:

1. Allocazione della capacità esterna
2. Auto pianificazione partner
3. Dispatcher a led interno

Allocazione della capacità esterna (capacità esterna alla piattaforma): L'appaltatore gestisce la forza lavoro esternamente e fornisce una capacità definita (ad esempio, 10 ore disponibili) anziché pianificazioni di singoli tecnici. Questa capacità viene considerata un bucket di ore o voci su cui lavorare ai fini della pianificazione.

Auto pianificazione partner: I responsabili degli appaltatori accedono a Salesforce tramite un sito Experience per pianificare i propri team. Richiedono un rigoroso isolamento dagli altri partner.

Internal-Led Dispatcher (Dispatcher a LED interno): I dispatcher interni pianificano direttamente i tecnici dell'appaltatore. Gli appaltatori utilizzano l'app mobile Field Service per l'esecuzione.

In questo schema, il territorio di servizio funge da confine di sicurezza principale. Ogni società appaltatrice è assegnata al proprio territorio "Bambino" univoco.

• Reti di partner su piccola scala
• Partner con aree geografiche strettamente non sovrapposte
• situazioni in cui il lavoro dell'appaltatore è fondamentalmente diverso dal lavoro delle risorse interne, eliminando la concorrenza (ad esempio, gli appaltatori esterni gestiscono solo "impianti di tipo A", mentre le risorse interne gestiscono tutti gli altri tipi di lavoro)

• Configurazione semplificata: Utilizza l'impostazione e l'automazione standard del territorio utente.
• Cancella bucket di dati: Garantisce una facile visibilità dei dati e una gestione semplificata della sicurezza tramite gli oggetti Territorio di servizio standard.

• Efficienza di ottimizzazione: Il motore non è in grado di valutare le risorse oltre i confini dei territori, impedendo una pianificazione ottimale e un instradamento efficiente.
• Espansione dei territori: La creazione di un numero maggiore di territori per un numero molto basso di risorse determina un sovraccarico di pianificazione.
• Prestazioni di Gant: Le gerarchie di grandi dimensioni (territori 1K+) possono causare colli di bottiglia significativi nelle prestazioni e rischi di superare i limiti della piattaforma.

Questa guida introduce un nuovo approccio alle soluzioni: Condivisione basata sugli account (implementata tramite le regole di condivisione native basate sui criteri di Salesforce, lo stesso meccanismo della piattaforma utilizzato per concedere l'accesso ai record in base ai valori dei campi). La condivisione basata sugli account separa la visibilità dall'area geografica. I territori rimangono ampi e continui, mentre la visibilità viene gestita tramite le tabelle di condivisione della piattaforma basate su una relazione con l'account. In termini pratici, le regole di condivisione basate sui criteri valutano un campo del record (ad esempio ServiceResource.Company) e condividono automaticamente quel record con il gruppo appropriato. La condivisione basata su criteri è il motore che fa funzionare la condivisione basata su account senza codice personalizzato a livello di record.

• Ecosistemi su larga scala in cui una percentuale significativa della forza lavoro è costituita da risorse esterne
• Aree urbane in cui più appaltatori coprono gli stessi codici postali
• Scenari in cui sia le risorse interne che quelle esterne sono in grado di eseguire lo stesso lavoro (ad esempio, "installazioni di tipo A"), ma le regole aziendali impongono una logica specifica per la selezione delle risorse (ad esempio, la preferenza delle risorse interne in alcuni scenari)

• Utilizzo massimo e ROI: Il motore valuta l'intero pool regionale, trovando la risorsa "migliore" per ogni lavoro
• Scalabilità: Supporta un numero elevato di appaltatori/risorse esterne senza aumentare il numero di territori
• Gestione consolidata: Il personale interno gestisce una visualizzazione anziché centinaia di cartelle in silo (territori controllati)

• Sforzo di sviluppo: Richiede un'automazione personalizzata (Flusso o Apex) per gestire le tabelle di condivisione
• Condivisione appartenenza: Richiede la condivisione esplicita dei record Membro territorio di servizio (STM)

Per la forza lavoro esterna (dimensione Allocazione capacità esterna), gli architetti possono utilizzare Risorse basate sulla capacità per rappresentare il "riepilogo" della forza lavoro di un appaltatore.

• Capacità: Utilizzare questa opzione quando l'appaltatore gestisce il proprio dispatching e instradamento. L'attenzione principale è rivolta al volume totale di lavoro che può eseguire anziché alla persona specifica che lo esegue.
• Persona: Utilizzarlo quando si necessita di una visibilità dettagliata della giornata di un tecnico. Le risorse basate sulle persone consentono di gestirne la posizione esatta, la disponibilità in tempo reale e le assegnazioni di lavori specifiche come se fossero personale interno.

Prima di progettare lo schema dell'appaltatore Field Service, utilizzare questo albero decisionale per determinare l'architettura di condivisione appropriata.

Albero decisionale di selezione dello schema di condivisione appaltatori

Albero decisionale per la selezione di uno schema di condivisione appaltatore in Salesforce Field Service. A partire dall'utilizzo o meno delle risorse esterne, la struttura si suddivide in rami per tipo di risorsa ed esclusività del lavoro per consigliare la condivisione basata sul territorio o basata sull'account.

Il nucleo di questo schema è un livello di automazione che converte la relazione ServiceResource.AccountId o ServiceResource.Company (Società appaltatrice) in record di condivisione piattaforma.

Per verificare l'accesso corretto per il dispatcher e la risorsa di servizio in un sito Experience, l'accesso deve essere controllato tramite:

• Regola di condivisione delle risorse di servizio: Concede l'accesso in base a un criterio (account/azienda)
• Regola di condivisione territorio di servizio: Concede l'accesso in base a un criterio (nome territorio/ID)

Quando si utilizza la condivisione basata sugli account, assicurarsi di tenere conto dell'esperienza Field Service Mobile e della visibilità dei record per i tecnici assegnati.

• Condivisione delle risorse assegnate: La funzionalità SFS standard concede automaticamente a una risorsa assegnata l'accesso all'appuntamento di servizio e al relativo ordine di lavoro controllante. Questa impostazione fornisce al tecnico le informazioni necessarie per eseguire il lavoro senza richiedere ulteriori regole di condivisione personalizzate per il lavoro assegnato.
• Rischi di visibilità: Anche se il lavoro assegnato viene gestito in modo nativo, prestare attenzione agli appuntamenti non assegnati o futuri che non hanno un'associazione Account o Territorio. Se le impostazioni predefinite organizzazione non sono gestite in modo rigoroso o se gli insiemi di condivisione sono troppo ampi, gli appuntamenti non assegnati potrebbero essere visibili a tutti gli utenti di un territorio consolidato.
• Associazione account-territorio: Assicurarsi che tutti gli appuntamenti di servizio siano esplicitamente collegati a un account e a un territorio. Questo collegamento consente un filtro pulito all'interno dell'app mobile e verifica che non si verifichino fughe di dati per il lavoro non assegnato seduto nel pool regionale.

• Requisito: 10 appaltatori differenti forniscono l'installazione della fibra a Londra.
• Contesto: Nell'approccio di condivisione basato sui territori, Londra sarebbe suddivisa in 10 territori sovrapposti. I dispatcher faticherebbero a vedere la disponibilità nelle vicinanze, causando tempi di percorso elevati.
• Consiglio: Condivisione basata sugli account. Implementare un territorio di servizio unificato "Greater London" utilizzando la condivisione basata sugli account per mantenere una sicurezza dei dati granulare. La condivisione basata sugli account mantiene la gestione dell'appaltatore A in un silo per le rispettive risorse, mentre SFS Optimizer mantiene la visibilità interfunzionale di tutti i tecnici interni ed esterni. Questo approccio di pianificazione completo facilita una logica di instradamento più efficiente che può ridurre il percorso di oltre il 20% attraverso una pianificazione completa (stima direzionale basata sulle osservazioni sul campo nelle distribuzioni dei clienti SFS), creando miglioramenti immediati nell'utilizzo delle risorse e una maggiore reattività del servizio.

• Requisito: Un fornitore fornisce fino a 40 "slot" al giorno per le riparazioni delle caldaie ma gestisce il proprio tecnico di spedizione.
• Contesto: La gestione di 40 record di singole risorse comporta un sovraccarico inutile.
• Consiglio: Risorsa basata sulla capacità collegata all'account fornitore. Un record risorsa rappresenta la capacità giornaliera totale del fornitore, mantenendo pulito il diagramma di Gantt ed evitando la necessità di gestire i record dei singoli tecnici appaltatori.

• Requisito: Una società di servizi pubblici inserisce 50 piccoli appaltatori locali durante la stagione delle tempeste per gestire le riparazioni delle sovratensioni.
• Contesto: La creazione e l'eliminazione di 50 territori ogni stagione rappresentano un onere amministrativo importante e influiscono negativamente sulla flessibilità del motore di pianificazione e ottimizzazione.
• Consiglio: Condivisione basata sugli account. Creare un territorio geografico "Overflow" permanente. Quando un appaltatore viene inserito, è sufficiente creare il suo account e collegarvi le sue risorse. Il livello di automazione gestisce istantaneamente la visibilità senza richiedere una riprogettazione della gerarchia dei territori.

• Requisito: Per le fughe di gas ad alta priorità, il tecnico più vicino deve essere inviato indipendentemente dall'appaltatore per cui lavora.
• Contesto: La condivisione basata sul territorio crea lacune di copertura in cui la tecnologia più vicina potrebbe trovarsi in un territorio diverso e quindi non raggiungibile dalla logica di pianificazione.
• Consiglio: Condivisione basata sugli account. Riunendo i fornitori in un unico grande territorio, il motore esegue una ricerca completa basata sugli spostamenti nell'intero pool multi-vendor, riducendo i tempi di risposta per gli incidenti critici di sicurezza.

• Requisito: Un partner HVAC specializzato ha un diritto legale esclusivo di 10 anni per il servizio di un'area remota o di una contea rurale.
• Contesto: Non esistono altri appaltatori che operano in questa area geografica e il partner gestisce interamente la pianificazione e l'invio.
• Consiglio: Condivisione basata sul territorio. In questo scenario, un territorio di servizio dedicato è la scelta più efficiente. Poiché non vi è sovrapposizione geografica con altri partner, l'isolamento fornito dal confine del territorio soddisfa perfettamente i requisiti legali e operativi senza ulteriore automazione della condivisione.

La condivisione basata su account separa la visibilità dall'area geografica collegando l'accesso a livello di record a un identificatore account/azienda comune condiviso tra l'utente dispatcher e i relativi record Risorsa di servizio. Il motore di condivisione nativo basato sui criteri della piattaforma valuta questo campo e concede o revoca automaticamente l'accesso senza modificare la gerarchia dei territori.

I tre componenti architettonici richiesti sono:

1. Campo identificativo comune sia agli oggetti Utente che Risorsa di servizio che li collega all'account dell'appaltatore.
2. Gruppi pubblici che aggregano tutti gli utenti Dispatcher per società appaltatrice, in modo che le regole di condivisione si applichino in modo uniforme.
3. Regole di condivisione basate su criteri che valutano l'identificatore e concedono al Gruppo pubblico appropriato l'accesso ai record pertinenti.

Anziché utilizzare i territori come confini, utilizzare Gruppi pubblici per aggregare i dispatcher che richiedono la stessa visibilità. I dispatcher visualizzano territori, ordini di lavoro e appuntamenti di servizio specifici tramite l'appartenenza a gruppi pubblici basati sui territori.

• Creazione di gruppi: Creare un gruppo pubblico per ogni società appaltatrice.
• Assegnazione membro: Aggiungere gli Utenti Partner Community (dispatcher) pertinenti al rispettivo Gruppo pubblico appaltatore.

Sfruttare le regole di condivisione basate sui criteri per concedere al Gruppo pubblico l'accesso a record specifici.

• Criteri di condivisione delle risorse di servizio: Le regole di condivisione delle risorse di servizio impongono la visibilità per tecnico appaltatore abbinando l'identificatore società/account nel record Risorsa di servizio al Gruppo pubblico appaltatore corrispondente.
  • Il livello di accesso consente la lettura/scrittura per consentire ai dispatcher di pianificare e aggiornare le assegnazioni.
• Criteri di condivisione dei territori di servizio: Utilizzare i criteri di condivisione dei territori di servizio per impostare la logica per l'accesso limitato ai territori. Concedere ai dispatcher l'accesso agli ampi territori geografici in cui sono autorizzati a lavorare. Esempio:
  • Criteri: ServiceTerritory.Name UGUALE A "Atlanta".
  • Condiviso con: Gruppi pubblici appaltatori pertinenti (ad esempio, Appaltatore A, Appaltatore B, Appaltatore C).
  • Livello di accesso: Lettura/Scrittura

Per istruzioni dettagliate sull'implementazione, vedere la documentazione ufficiale di Salesforce:

• Regole di condivisione basate su criteri
• Gruppi pubblici
• Trigger Apex per la gestione automatica dei record condivisione

Se implementata correttamente, la condivisione basata sugli account offre:

• Visibilità unificata: I dispatcher visualizzano tutte le risorse pertinenti in tutto il territorio senza riassegnazione manuale del territorio.
• Accesso dinamico: Quando cambiano le assegnazioni degli appaltatori, le regole di condivisione regolano automaticamente la visibilità senza l'intervento dell'amministratore.
• Isolamento competitivo: Ogni appaltatore vede solo le proprie risorse, mantenendo la privacy dei dati.
• Architettura scalabile: I nuovi appaltatori possono essere inseriti semplicemente creando un account e un gruppo pubblico, mentre le regole di condivisione gestiscono automaticamente il resto.

Man mano che le organizzazioni di Field Service passano da modelli reattivi a modelli proattivi, la scelta del modello architettonico definisce il "tetto massimo di innovazione" per l'agilità operativa a lungo termine.

• Abilitazione dell'intelligenza artificiale e del machine learning: La condivisione basata sugli account verifica che il motore abbia visibilità sull'intero pool di risorse per trovare la corrispondenza migliore anziché essere limitato da silos di dati. Poiché evita silos di territori inefficienti, l'agente di pianificazione per Field Service (assistente di pianificazione basato sull'intelligenza artificiale in Salesforce) offre schemi di viaggio e assegnazioni di tecnici più logici senza essere limitato da microterritori isolati. Questo approccio massimizza l'ottimizzazione completa, migliorando direttamente i KPI di percorso e la preparazione dei tecnici. La condivisione basata sugli account supporta la pianificazione basata sull'intelligenza artificiale offrendo al motore visibilità sull'intero pool di risorse, consentendo la corrispondenza "true best" anziché essere limitata da silos di dati artificiali.
• Scalabilità architettonica: La condivisione basata sul territorio spesso incontra un "muro di prestazioni" a causa della dipendenza da territori isolati. Man mano che la rete di appaltatori cresce, l'efficacia del motore di pianificazione viene neutralizzata da confini artificiali che impediscono di raggiungere la capacità disponibile nei territori adiacenti. Inoltre, quando la condivisione basata sul territorio richiede un nuovo territorio e modifiche manuali per ogni partner, la condivisione basata sugli account semplifica la crescita. Le organizzazioni integrano centinaia di partner appaltatori semplicemente creando un account e i record Risorsa di servizio associati, lasciando inalterata e performante la struttura geografica centrale del territorio.

Questa guida si è concentrata principalmente sulle nuove implementazioni di rete. Tuttavia, molte organizzazioni stanno già eseguendo la condivisione basata sul territorio su larga scala e hanno un debito significativo nella gerarchia dei territori. La migrazione dalla condivisione basata sul territorio alla condivisione basata sugli account in un ambiente di produzione live introduce rischi architettonici distinti da valutare prima di iniziare qualsiasi lavoro di transizione. Questa sezione affronta le tre dimensioni critiche di una migrazione del sistema esistente: valutazione dello stato attuale, determinazione della strategia di transizione e gestione dei rischi di migrazione.

• Valutazione dell'espansione dei territori: Prima di qualsiasi pianificazione della migrazione, quantificare la gerarchia dei territori corrente. Le domande diagnostiche chiave sono: Quanti territori esistono esclusivamente per imporre l'isolamento degli appaltatori rispetto ai confini geografici reali? Qual è il rapporto tra territori controllati specifici dell'appaltatore e territori controllanti operativi? Esistono territori condivisi tra risorse interne ed esterne o sono stati completamente isolati? Questo audit distingue la vera struttura geografica dal debito di isolamento accumulato. I territori creati esclusivamente per il controllo della visibilità dei partner sono candidati all'eliminazione nell'ambito della condivisione basata sugli account. I territori che codificano la vera area geografica operativa (zone di pianificazione, regioni SLA, confini normativi) vengono mantenuti e non vengono confusi con il controllo degli accessi.
• Viabilità della transizione ibrida: Per le organizzazioni su larga scala, un passaggio completo dalla condivisione basata sul territorio alla condivisione basata sugli account è raramente consigliabile; al contrario, una transizione ibrida riduce il rischio inserendo nuovi appaltatori nella condivisione basata sugli account mantenendo le coorti di condivisione basate sul territorio legacy fino alla finestra di rinnovo successiva. L'approccio ibrido è architetturalmente valido a condizione che l'automazione della condivisione basata su account sia limitata all'identificativo account/azienda, consentendo alle risorse senza quell'ID di rimanere nell'accesso basato sul territorio senza interruzioni. Considerare lo stato ibrido come un'architettura temporanea, non come un modello operativo permanente.
• Principali rischi di migrazione: Le migrazioni di sistemi esistenti introducono tre rischi architettonici critici che richiedono una mitigazione proattiva. Innanzitutto, le ricostruzioni delle tabelle di condivisione attivate da nuove regole basate sui criteri richiedono molte risorse; pianificare i tagli durante le finestre di bassa attività per evitare lacune di visibilità del dispatcher causate da ricalcoli di lunga durata. In secondo luogo, gli ordini di lavoro in volo rischiano di perdere visibilità durante la transizione; mantenere appartenenze a territori paralleli o precompilare la condivisione per i record attivi fino alla chiusura. Infine, perfezionare le policy di ottimizzazione e pianificazione man mano che la rimozione dei territori controllati sposta il pool di risorse. Testare, eseguire esecuzioni di base e acquisire metriche per verificare che i confini geografici rimangano effettivi e che i guadagni di efficienza siano effettivamente realizzati.

Data la scalabilità e l'utile sul capitale investito dell'ottimizzazione, si consiglia l'approccio di condivisione basato sugli account per le organizzazioni Field Service a crescita elevata che gestiscono più appaltatori concorrenti in aree geografiche sovrapposte. Mentre la condivisione basata sul territorio offre un'impostazione più semplice e dichiarativa, la condivisione basata sugli account consente alle organizzazioni di sfruttare appieno il potenziale del motore di pianificazione e ottimizzazione. Disaccoppiando la visibilità dall'area geografica, le organizzazioni possono mantenere una configurazione del territorio che si adatta all'azienda e offre i seguenti risultati:

• Efficienza operativa: L'aggregazione delle risorse in un unico pool consente al motore di trovare il vero tecnico "migliore" per ogni lavoro, riducendo i tempi di percorso e i costi operativi.
• Livelli di servizio ottimizzati: Una pianificazione completa riduce i ritardi dell'assistenza identificando la risorsa a contratto più disponibile/vicina, accelerando il time-to-service e migliorando direttamente la soddisfazione dei clienti.
• Produttività Dispatcher: Il personale interno può gestire una visione regionale consolidata anziché passare da un territorio "controllato" all'altro.

La condivisione basata sul territorio è più adatta per le operazioni di appaltatori altamente insilati con territori/aree geografiche rigorosamente non sovrapposte.

Scegliere un modello architettonico è il primo passo. Una corretta esecuzione richiede un allineamento continuo alle procedure consigliate di Salesforce e alle funzionalità della piattaforma.

Fasi successive:

• Controllo del paesaggio: Rivedere la gerarchia dei territori corrente e l'utilizzo delle risorse esterne. Identificare eventuali "territori appaltatori" creati esclusivamente per l'isolamento dei partner: se la gerarchia è sovraffollata da tali silos, valutare i vantaggi e le attività della migrazione alla condivisione basata sugli account.
• Convalida Sandbox: Creare un prototipo dello schema di condivisione basato su account in un Sandbox completo o parziale e testare la visibilità end-to-end da tutte le angolazioni:
  • Utenti interni (amministratori, dispatcher e tecnici interni): Confermare l'accesso appropriato. Alcuni utenti interni dovrebbero avere accesso generalizzato.
  • Utente responsabile appaltatore: Verificare che la visibilità sia limitata esclusivamente al proprio personale.
  • Tecnici dell'appaltatore (le risorse esterne): Verificare che l'accesso sia correttamente limitato solo al lavoro assegnato.
  • Test rigorosi della visibilità dell'organizzazione sono essenziali per evitare fughe di dati tra partner concorrenti.
• Benchmarking delle prestazioni e valutazione del ROI: Sfruttare l'hub di ottimizzazione e i cruscotti digitali Field Service Intelligence per ottenere informazioni sulla riduzione del tempo di percorso, l'utilizzo delle risorse e i miglioramenti del tempo di risposta, fornendo i dati necessari per giustificare il passaggio all'architettura agli stakeholder. Questa analisi prima e dopo può essere ripetuta anche in produzione quando la transizione è in corso.
• Fase pilota: Al termine dei test Sandbox, avviare un programma pilota scaglionato in uno o due territori in cui le risorse interne ed esterne si sovrappongono geograficamente, idealmente, in modo analogo a quelle testate nel Sandbox. Convalidare la logica di condivisione con un piccolo gruppo di utenti controllato prima di consigliare un'implementazione più ampia prima della distribuzione completa.
• Scalabilità della soluzione: Verificare che qualsiasi automazione personalizzata (Flusso o Apex) necessaria per gestire le tabelle di condivisione e i record Membro territorio di servizio (STM) sia progettata per la sostenibilità a lungo termine. La soluzione deve utilizzare schemi di progettazione modulari (ad esempio, framework trigger) e garantire che la logica sia creata per gestire le assegnazioni di risorse a volume elevato senza interruzioni entro i limiti del governor della piattaforma.

Tutti gli schemi di questa guida richiedono la convalida in un ambiente Sandbox prima della distribuzione in produzione. Il comportamento dell'implementazione può variare in base alla configurazione dell'organizzazione, al volume di dati e alle regole aziendali.

Documentazione della piattaforma (ufficiale Salesforce):

• Guida per lo sviluppatore di Field Service: Riferimento centrale per oggetti dati, API e personalizzazione di Field Service
• Riferimento oggetto ServiceResource: Documentazione API per l'oggetto SR
• Riferimento oggetto ServiceTerritoryMember: Documentazione API per l'oggetto STM
• Regole di condivisione basate su criteri: Guida di sicurezza ufficiale per l'implementazione delle regole di condivisione alla base della condivisione basata sugli account
• Guida per lo sviluppatore dei trigger Apex: Riferimento per il livello di automazione personalizzato richiesto dalla condivisione basata sugli account
• Best practice per trigger Apex: Schemi consigliati da Salesforce per lo sviluppo di trigger scalabili

Articoli della Guida di Salesforce

• Linee guida per l'impostazione degli appaltatori Field Service: Guida per la configurazione delle risorse dell'appaltatore in Salesforce Field Service
• Definisci risorse basate sulla capacità: Documentazione ufficiale per l'impostazione delle risorse basate sulla capacità a cui si fa riferimento nell'articolo
• Come funziona il motore di ottimizzazione di Field Service? Riferimento per l'ottimizzazione di Field Service. Guida per l'esecuzione dell'ottimizzazione, pertinente anche ai vantaggi della condivisione basata sugli account e al ROI a cui si fa riferimento nell'articolo.
• Impostazione dell'hub di ottimizzazione: Guida alla configurazione per l'hub di ottimizzazione a cui si fa riferimento nella sezione Fasi successive
• Panoramica di Experience Cloud: Impostazione Partner Community per la condivisione basata su account (gestione on-platform)

Salesforce Trailhead/Apprendimento

• Nozioni di base su Field Service: Modulo di base che copre territori, risorse e ore di funzionamento
• Pianificazione Field Service: Concetti di pianificazione alla base della discussione sull'ottimizzazione in questa guida
• Ottimizzazione Field Service: Approfondimenti sulle policy di impostazione e pianificazione dell'ottimizzazione
• Salesforce Security e Chi vede cosa: Regole di condivisione e nozioni di base sulla sicurezza dei dati
• Creazione di un Portale partner con Experience Cloud: Guida pratica per l'impostazione dei partner Experience Cloud a cui si fa riferimento nell'articolo

Contesto industriale e strategico

• Rapporto sullo stato del servizio Salesforce, 7a edizione: L'edizione più recente, che intervista 6.500 professionisti dell'assistenza in tutto il mondo, con approfondimenti dedicati su Field Service, adozione dell'intelligenza artificiale e tendenze della produttività dei tecnici direttamente pertinenti agli argomenti del ROI in questo documento.
• Agenteforce per Field Service: Piattaforma di Field Service basata sull'intelligenza artificiale di Salesforce, direttamente pertinente alla discussione sull'intelligenza artificiale e a prova di futuro nella sezione 13. Il pool di risorse unificate di condivisione basato su account ottimizza l'intelligenza di pianificazione di Agentforce.
• Guida di Gartner Market per Field Service Management: L'analisi Gartner più aggiornata del panorama di mercato delle FSM (è richiesto l'abbonamento Gartner).

Mor Epstein
Architetto Senior Success, Salesforce Field Service

Con un background in Ingegneria Industriale presso Georgia Tech e un MBA, Mor è un consulente di fiducia con una comprovata esperienza nello sblocco e nell'accelerazione delle implementazioni di Field Service mission-critical. La sua esperienza globale di customer-face, combinata con la risoluzione dei problemi pratica e basata sui dati, la rende una risorsa di riferimento per le organizzazioni di Field Service in tutto il mondo. Mor eccelle nel guidare i clienti attraverso il journey di pianificazione e ottimizzazione, aiutando le organizzazioni a sfruttare appieno il potenziale della pianificazione intelligente per ottenere guadagni misurabili in termini di efficienza e fornitura di servizi.

Lee Ephrati
Architetto Senior Success, Salesforce Field Service

Lee è un architetto tecnico di grande esperienza con oltre 10 anni di esperienza nella fornitura e consulenza Salesforce, specializzato in architetture Field Service e progettazione di soluzioni mobili. Lee si concentra sull'allineamento di strutture organizzative complesse con la piattaforma SFS nativa e l'applicazione mobile per favorire il massimo ROI operativo per le aziende globali. Con una mentalità orientata al cliente e una Knowledge completa della piattaforma, Lee offre un approccio consultivo che offre costantemente valore duraturo ai clienti Salesforce in tutto il mondo.