Dans les environnements Salesforce Field Service (SFS) à grande échelle, la gestion des réseaux de sous-traitants externes nécessite un équilibre délicat entre la sécurité de la plate-forme et les performances de planification. Ce guide compare deux modèles architecturaux principaux : Le modèle traditionnel basé sur le territoire et le nouveau modèle de partage basé sur le compte pour régir l’accès et la gestion des sous-traitants externes. Dans cet article, nous examinons en profondeur les deux options afin d’aider les organisations à choisir la structure de base qui répond le mieux à leurs objectifs opérationnels, et pour comprendre les compromis de chaque option.

Ce choix de modèle affecte l’efficacité de la planification, l’utilisation des ressources et la productivité du répartiteur. En sélectionnant l’approche appropriée, les entreprises garantissent une expérience transparente à la fois au personnel interne et aux partenaires externes tout en préservant l’évolutivité à long terme de leur solution.

Au-delà des gains opérationnels immédiats, ce choix fondamental détermine la préparation d’une organisation à un service autonome. Le modèle de partage basé sur le compte fournit la visibilité des données unifiée requise pour qu’Agentforce, et plus précisément l’agent de planification pour Field Service, effectue une évaluation globale sans être restreint par des silos de données artificiels. Le partage basé sur le compte permet également à Data Cloud d’agréger plus efficacement les métriques de performance des sous-traitants, ce qui permet une analyse comparative concurrentielle transparente tout en préservant l’isolation rigoureuse des données requise dans les environnements multifournisseurs.

• Sélectionnez votre modèle en fonction du chevauchement concurrentiel. Si des sous-traitants externes sont en concurrence avec des ressources internes ou externes dans des territoires partagés, le partage basé sur le compte est probablement le choix architecturalement correct. Le partage basé sur le territoire est approprié uniquement lorsque les sous-traitants reçoivent des zones de service/emplois exclusifs, sans chevauchement.
• Évitez l’étalement des territoires. La création de territoires de sous-traitants dédiés pour isoler les données lorsque cela n’est pas nécessaire entraîne un gonflement de la hiérarchie qui dégrade l’efficacité et les performances de la planification, et augmente considérablement les charges administratives à l’échelle. Le partage basé sur le compte élimine ce schéma problématique.
• Établissez les bases de la planification pilotée par l’IA. L’agent de planification pour Field Service et le moteur d’optimisation offrent de meilleures performances lorsqu’ils ont une visibilité complète du pool de ressources. La structure cloisonnée du partage basé sur le territoire l’empêche. Le partage basé sur le compte est la fondation architecturale souhaitée.

Au cours de la dernière décennie, les réseaux de sous-traitants dans l’assistance sur site sont passés d’extensions ponctuelles d’équipes internes à des écosystèmes stratégiques et délibérément structurés dans l’ensemble des secteurs d’activité, y compris les télécommunications, les services publics, les services à domicile et davantage. De nombreuses opérations sur site font maintenant appel à des sous-traitants et à des employés à temps plein, ce qui nécessite des règles claires pour l’accès, la visibilité et le contrôle de la répartition.

À mesure que les organisations s’adaptent à Salesforce Field Service, la façon dont elles conçoivent et gèrent ces ressources externes, que ce soit par le biais d’un modèle de territoire, d’un partage centré sur le compte ou d’hybrides, détermine directement la sécurité et l’efficacité avec lesquelles elles peuvent planifier leur travail au sein d’une force de travail mixte.

Ce guide s’adresse aux parties prenantes techniques et stratégiques responsables de la conception, des performances et de l’évolutivité des implémentations Salesforce Field Service :

• Architectes de solutions et techniques : Évaluer l’impact de différents modèles de partage sur l’efficacité de la planification et de l’optimisation.
• Responsables des opérations de Field Service : Pour comprendre les compromis entre les différents profils de sous-traitants, tels que les sous-traitants nommés, les sociétés de sous-traitance et les travailleurs occasionnels.
• Administrateurs Salesforce : Recueillez des connaissances sur l’utilisation des territoires de service et des tableaux de partage de plate-forme pour gérer les exigences de sécurité complexes.

Le profil de sous-traitant concerné détermine directement l’architecture de partage appropriée. Chaque catégorie a des implications distinctes sur la structure de l’accès au niveau de l’enregistrement, la perception de la disponibilité des ressources par l’optimiseur et l’échelle de la solution :

• Sous-traitant nommé : Une ressource externe individuelle traitée de la même façon qu’un employé interne. Un sous-traitant nommé nécessite une licence utilisateur dédiée. Le modèle de partage reflète les modèles d’accès des techniciens internes, ce qui en fait le profil de sous-traitant le moins complexe à prendre en charge.
• Société sous-traitante : Une entité tierce qui gère sa propre force de travail. Dans SFS, les entreprises sous-traitantes sont représentées en tant que Ressources basées sur la capacité, où l’organisation parente planifie et attribue le travail à l’entreprise plutôt qu’à une personne spécifique.
• Travailleur occasionnel : Un utilisateur qui opère temporairement à travers plusieurs territoires. Le profil le plus complexe sur le plan architectural. Les relations transitoires entre plusieurs territoires signifient que les frontières de partage basées sur le territoire sont brisées. Par conséquent, la visibilité est gérée dynamiquement au niveau de l’enregistrement plutôt que par une attribution géographique statique.

Ces modèles sont complexes, car l’organisation parente et les objectifs de l’entrepreneur sont souvent en contradiction technique.

1. Objectifs divergents : L’organisation parente se concentre principalement sur la satisfaction des clients et le travail contractuel (par exemple, les préférences en ressources, le service rapide et opportun, et la gestion de la répartition du travail et des heures entre les sous-traitants). Par contre, les sous-traitants s’efforcent généralement d’optimiser le travail attribué tout en réduisant les temps de trajet et les coûts opérationnels.

2. Concurrence : Contrairement aux employés internes, les différentes entreprises sous-traitantes sont souvent des concurrents directs. Bien que l’organisation parente ait besoin d’une vue globale de la région (transparence), les sous-traitants exigent une isolation stricte de leurs opérations respectives (isolation).

3. Intégrité de la marque : Pour le client final, l’agent représente votre marque, ce qui nécessite souvent que l’entreprise mère affiche les mises à jour de statut en temps réel. Cependant, les sous-traitants protègent souvent leurs opérations internes dans un système fermé, ou « boîte noire ».

4. Visibilité et sécurité : Un territoire de service partagé implique généralement une visibilité universelle de toutes les ressources attribuées, mais les environnements multi-sous-traitants nécessitent un schéma de sécurité plus nuancé. Pour préserver l’intégrité concurrentielle et la confidentialité des données, il est essentiel d’empêcher les sous-traitants d’accéder aux noms propriétaires, aux planifications ou aux informations sur les ressources des autres sous-traitants.

La conception de sous-traitants dans Salesforce Field Service couvre trois modèles opérationnels distincts, chacun affectant la visibilité des ressources, la propriété de la répartition et les licences :

1. Allocation de capacité externe
2. Auto-planification de partenaires
3. Répartition interne

Allocation de capacité externe (capacité hors plate-forme) : Le sous-traitant gère sa main-d’œuvre à l’externe et fournit une capacité définie (par exemple, 10 heures disponibles) plutôt que des horaires individuels de technicien. Cette capacité est traitée comme un compartiment d’heures ou d’éléments de travail à des fins de planification.

Auto-planification de partenaires : Les responsables sous-traitants se connectent à Salesforce via un site Experience pour planifier leurs propres équipes. Ils nécessitent un isolement strict des autres partenaires.

Répartition interne : Les répartiteurs internes planifient directement les techniciens sous-traitants. Les sous-traitants utilisent l’application mobile Field Service pour l’exécution.

Dans ce schéma, le territoire de service sert de frontière principale de sécurité. Chaque société sous-traitante est attribuée à son propre territoire « Enfant » unique.

• Réseaux de partenaires à petite échelle
• Partenaires avec des zones géographiques strictement non superposées
• Situations dans lesquelles le travail des sous-traitants est fondamentalement différent du travail des ressources internes, ce qui élimine la concurrence (par exemple, les sous-traitants externes gèrent uniquement les « installations de type A », alors que les ressources internes gèrent tous les autres types de travail)

• Configuration simplifiée : Utilise la configuration et l’automatisation standard de Territoire utilisateur.
• Regroupement clair des données : Facilite la visibilité des données et simplifie la gestion de la sécurité avec des objets Territoire de service standard.

• Efficacité d’optimisation : Le moteur ne peut pas évaluer les ressources à travers les frontières du territoire, ce qui empêche une planification optimale et un acheminement efficace.
• Étendue du territoire : La création d’un plus grand nombre de territoires pour un nombre très faible de ressources entraîne des frais généraux de planification.
• Performance du diagramme de Gantt : Les grandes hiérarchies (1 000+ territoires) peuvent entraîner d’importants goulets d’étranglement des performances ainsi que des risques d’atteindre les limites de la plateforme.

Ce guide présente une nouvelle approche de solution : Partage basé sur le compte (implémenté via les règles de partage natives basées sur des critères de Salesforce, le même mécanisme de plate-forme utilisé pour accorder l’accès aux enregistrements basé sur les valeurs de champ). Le partage basé sur le compte dissocie la visibilité de la géographie. Les territoires restent vastes et continus, tandis que la visibilité est gérée via les tableaux de partage de la plate-forme en fonction d’une relation de compte. Concrètement, les règles de partage basées sur des critères évaluent un champ de l’enregistrement (par exemple ServiceResource.Company) et partagent automatiquement cet enregistrement avec le groupe approprié. Le partage basé sur des critères est le moteur qui permet le fonctionnement du partage basé sur le compte sans code personnalisé au niveau de l’enregistrement.

• Écosystèmes à grande échelle où une proportion importante de la main-d’œuvre est constituée de ressources externes
• Zones urbaines où plusieurs sous-traitants couvrent les mêmes codes postaux
• Scénarios dans lesquels des ressources internes et externes sont capables d’exécuter le même travail (par exemple, des « installations de type A »), mais où les règles métiers imposent une logique spécifique pour la sélection des ressources (par exemple, la préférence des ressources internes dans certains scénarios)

• Utilisation maximale et retour sur investissement : Le moteur évalue l’ensemble du bassin régional, trouvant la “meilleure” ressource pour chaque emploi
• Évolutivité : Prend en charge un grand nombre de sous-traitants/ressources externes sans augmenter le nombre de territoires
• Gestion consolidée : Le personnel interne gère une vue plutôt que des centaines de dossiers cloisonnés (territoires enfants)

• Effort de développement : Nécessite une automatisation personnalisée (Flux ou Apex) pour gérer les tableaux Partage
• Partage d’appartenance : Nécessite le partage explicite des enregistrements Membre du territoire de service (STM)

Pour la force de travail externe (dimension Allocation de capacité externe), les architectes peuvent utiliser Capacity-Based Resources pour représenter le « résumé » de la force de travail d’un sous-traitant.

• Capacité : Utilisez-le lorsque le sous-traitant gère sa propre répartition et son propre acheminement. Vous vous concentrez principalement sur le volume total de travail qu’ils peuvent réaliser plutôt que sur la personne spécifique qui l’exécute.
• Individu : Utilisez-le lorsque vous avez besoin d’une visibilité précise sur la journée d’un technicien. Les ressources individuelles permettent de gérer leur emplacement exact, leur disponibilité en temps réel et des attributions de tâches spécifiques comme s’il s’agissait d’un personnel interne.

Avant de concevoir votre modèle de sous-traitant Field Service, utilisez cet arbre de décision pour déterminer l’architecture de partage appropriée.

Arbre de décision pour la sélection du modèle de partage des sous-traitants

Arborescence de décision pour la sélection d’un modèle de partage de sous-traitants dans Salesforce Field Service. En commençant par l’utilisation de ressources externes, l’arborescence se branche par type de ressource et exclusivité de tâche pour recommander le partage basé sur le territoire ou le partage basé sur le compte.

Le cœur de ce schéma est une couche d’automatisation qui convertit la relation ServiceResource.AccountId ou ServiceResource.Company (société sous-traitante) en enregistrements de partage de plate-forme.

Pour vérifier l’accès approprié du répartiteur et de la ressource de service dans un site Experience, l’accès doit être contrôlé via :

• Règle de partage de ressource de service : Accorde l’accès en fonction de critères (compte/entreprise)
• Règle de partage de territoire de service : Accorde l’accès en fonction de critères (nom/ID du territoire)

Lors de l’utilisation du partage basé sur le compte, assurez-vous de prendre en compte l’expérience Field Service Mobile et la visibilité des enregistrements pour les techniciens attribués.

• Partage de ressources attribuées : La fonctionnalité SFS standard accorde automatiquement à une ressource attribuée l’accès au rendez-vous de service et à son ordre d’exécution parent. Cette configuration fournit au technicien les informations nécessaires pour exécuter la tâche sans avoir besoin de règles de partage personnalisées supplémentaires pour le travail attribué.
• Risques de visibilité : Bien que le travail attribué soit géré en natif, soyez prudent en cas de rendez-vous non attribués ou futurs sans association à un compte ou à un territoire. Si les paramètres par défaut de l’organisation (OWD) ne sont pas strictement gérés ou si les ensembles de partages sont trop larges, les rendez-vous non attribués peuvent être visibles pour tous les utilisateurs d’un territoire consolidé.
• Association compte-territoire : Assurez-vous que tous les rendez-vous de service sont explicitement liés à un compte et à un territoire. Cette liaison permet un filtrage propre dans l’application mobile et vérifie que les données ne fuient pas pour un travail non attribué dans la piscine régionale.

• Exigence : 10 entrepreneurs différents fournissent l’installation de fibre à Londres.
• Contexte : Dans l’approche du partage basé sur le territoire, Londres serait divisée en 10 territoires qui se chevauchent. Les répartiteurs auraient du mal à voir la disponibilité à proximité, ce qui entraînerait des temps de trajet élevés.
• Recommandation : Partage basé sur le compte. Implémentez un territoire de service « Grand Londres » unifié en utilisant le partage basé sur le compte pour maintenir une sécurité des données précise. Le partage basé sur le compte maintient la gestion du sous-traitant A isolée de ses ressources respectives, tandis que l’optimiseur SFS maintient la visibilité transversale de tous les techniciens internes et externes. Cette approche de planification complète facilite une logique d’acheminement plus efficace qui peut réduire les déplacements de plus de 20 % grâce à la planification complète (estimation directionnelle basée sur des observations sur le terrain dans les déploiements clients SFS), ce qui améliore immédiatement l’utilisation des ressources et améliore la réactivité du service.

• Exigence : Un fournisseur fournit jusqu’à 40 « créneaux » pour les réparations de chaudières par jour, mais gère la répartition de ses propres techniciens.
• Contexte : La gestion de 40 enregistrements de ressource individuels ajoute des frais inutiles.
• Recommandation : Ressource basée sur la capacité liée au compte fournisseur. Un enregistrement de ressource représente la capacité quotidienne totale du fournisseur, ce qui permet de garder le diagramme de Gantt propre et d’éviter d’avoir à gérer les enregistrements de techniciens sous-traitants individuels.

• Exigence : Une entreprise de services publics fait appel à 50 petits entrepreneurs locaux pendant la saison des tempêtes pour réparer les surtensions.
• Contexte : La création et la suppression de 50 territoires chaque saison est une lourde charge administrative qui impacte négativement la flexibilité du moteur de planification et d’optimisation.
• Recommandation : Partage basé sur le compte. Créez un territoire géographique « Overflow » permanent. Lorsqu’un sous-traitant est intégré, il suffit de créer son compte et d’y associer ses ressources. La couche d’automatisation gère instantanément la visibilité sans nécessiter une refonte de la hiérarchie des territoires.

• Exigence : Pour les fuites de gaz prioritaires, le technicien le plus proche doit être dépêché, quel que soit l’entrepreneur pour lequel il travaille.
• Contexte : Le partage basé sur le territoire crée des écarts de couverture où la technologie la plus proche peut se trouver dans un autre territoire, et donc inaccessible à la logique de planification.
• Recommandation : Partage basé sur le compte. En regroupant les fournisseurs dans un seul grand territoire, le moteur effectue une recherche complète basée sur le trajet à travers l’ensemble du pool de fournisseurs multiples, réduisant ainsi les temps de réponse en cas d’incidents de sécurité critiques.

• Exigence : Un partenaire spécialisé en CVC a un droit légal exclusif de 10 ans pour desservir une région éloignée ou un comté rural.
• Contexte : Aucun autre sous-traitant n’opère dans cette zone géographique, et le partenaire gère entièrement sa propre planification et répartition.
• Recommandation : Partage basé sur le territoire. Dans ce scénario, un territoire de service dédié est le choix le plus efficace. Comme il n’y a pas de chevauchement géographique avec d’autres partenaires, l’isolement fourni par la frontière du territoire répond parfaitement aux exigences légales et opérationnelles sans partage supplémentaire de l’automatisation.

Le partage basé sur le compte sépare la visibilité de la géographie en associant l’accès au niveau de l’enregistrement à un identifiant de compte/entreprise commun partagé entre l’utilisateur répartiteur et ses enregistrements Ressource de service. Le moteur de partage natif basé sur des critères de la plate-forme évalue ce champ et accorde ou révoque automatiquement l’accès sans changer la hiérarchie des territoires.

Les trois composantes architecturales requises sont les suivantes :

1. Un champ d’identificateur commun aux objets Utilisateur et Ressource de service qui les associent à leur compte de sous-traitant.
2. Groupes publics agrégeant tous les utilisateurs du répartiteur par entreprise sous-traitante, les règles de partage s’appliquent uniformément.
3. Règles de partage basées sur des critères qui évaluent l’identificateur et accordent au groupe public approprié l’accès aux enregistrements appropriés.

Au lieu d’utiliser des territoires comme frontières, utilisez des Groupes publics pour agréger les répartiteurs qui ont besoin de la même visibilité. Les répartiteurs voient des territoires, des ordres de travail et des rendez-vous de service spécifiques via l’appartenance à des groupes publics basés sur le territoire.

• Création de groupe : Créez un groupe public pour chaque entreprise sous-traitante.
• Attribution de membre : Ajoutez les utilisateurs de communauté de partenaires (répartiteurs) appropriés à leur groupe public sous-traitant respectif.

Tirez parti des règles de partage basées sur des critères pour accorder au Groupe public l’accès à des enregistrements spécifiques.

• Critères de partage des ressources de service : Les règles de partage de ressource de service appliquent automatiquement la visibilité par technicien sous-traitant en mappant l’identifiant de l’entreprise/du compte dans l’enregistrement Ressource de service avec le groupe public sous-traitant correspondant.
  • Le niveau d’accès autorise la lecture/écriture pour permettre aux répartiteurs de planifier et de mettre à jour les attributions.
• Critères de partage de territoire de service : Utilisez les critères de partage de territoire de service pour configurer la logique de l’accès restreint au territoire. Accordez aux répartiteurs l’accès aux vastes territoires géographiques où ils sont autorisés à travailler. Exemple :
  • Critères : ServiceTerritory.Nom égal à “Atlanta”.
  • Partagé avec : Groupes publics d’entrepreneurs pertinents (par exemple, entrepreneur A, entrepreneur B, entrepreneur C).
  • Niveau d’accès : Lecture/Écriture

Pour un guide d’implémentation détaillé, consultez la documentation officielle de Salesforce :

• Règles de partage basées sur des critères
• Groupes publics
• Déclencheurs Apex pour la gestion automatisée des enregistrements de partage

Lorsqu’il est correctement implémenté, le partage basé sur le compte fournit :

• Visibilité unifiée : Les répartiteurs affichent toutes les ressources pertinentes dans l’ensemble du territoire sans réattribution manuelle du territoire.
• Accès dynamique : À mesure que les attributions de sous-traitants changent, les règles de partage ajustent automatiquement la visibilité sans intervention de l’administrateur.
• Isolement concurrentiel : Chaque sous-traitant affiche uniquement ses propres ressources, préservant la confidentialité des données.
• Architecture évolutive : Les nouveaux sous-traitants peuvent être intégrés en créant simplement un compte et un groupe public, les règles de partage gérant automatiquement les autres.

À mesure que les organisations d’assistance sur site passent de modèles réactifs à des modèles proactifs, leur choix de modèle architectural pose le « plafond d’innovation » pour l’agilité opérationnelle à long terme.

• Activation de l’IA et de l’apprentissage machine : Le partage basé sur le compte vérifie que le moteur a une visibilité sur l’ensemble du pool de ressources pour trouver la meilleure correspondance plutôt que d’être restreint par des silos de données. Comme il évite les silos de territoire inefficaces, l’Agent de planification pour Field Service (assistant de planification piloté par l’IA dans Salesforce) fournit des schémas de déplacement et des attributions de techniciens plus logiques sans être limité par des micro-territoires isolés. Cette approche maximise l’optimisation complète, en améliorant directement les indicateurs de performance clés de déplacement et la préparation des techniciens. Le partage basé sur le compte prend en charge la planification pilotée par l’IA en donnant au moteur une visibilité sur l’ensemble du pool de ressources, ce qui permet une correspondance réellement optimale plutôt que d’être restreint par des silos de données artificiels.
• Évolutivité architecturale : Le partage basé sur le territoire rencontre souvent un « mur de performance » en raison de sa dépendance à des territoires isolés. À mesure que le réseau de sous-traitants se développe, l’efficacité du moteur de planification est neutralisée par des frontières artificielles qui l’empêchent d’atteindre la capacité disponible dans les territoires adjacents. De plus, lorsque le partage basé sur le territoire nécessite un nouveau territoire et des ajustements manuels pour chaque partenaire, le partage basé sur le compte simplifie la croissance. Les organisations intègrent des centaines de partenaires sous-traitants en créant simplement un Compte et les enregistrements Ressource de service associés, laissant la structure géographique principale du territoire inchangée et performante.

Ce guide s’est concentré principalement sur les nouvelles implémentations. Cependant, de nombreuses organisations gèrent déjà le partage basé sur le territoire à grande échelle et supportent une dette importante de la hiérarchie des territoires. La migration depuis le partage basé sur le territoire vers le partage basé sur le compte dans un environnement de production live entraîne des risques architecturaux distincts à évaluer avant tout début de travail de transition. Cette section traite des trois dimensions critiques d’une migration de système existant : évaluer l’état actuel, déterminer la stratégie de transition et gérer les risques de migration.

• Évaluation de l’expansion du territoire : Avant toute planification de migration, quantifiez la hiérarchie des territoires actuelle. Les principales questions de diagnostic sont les suivantes : Combien de territoires existent-ils uniquement pour imposer l’isolement des entrepreneurs par rapport à de véritables frontières géographiques ? Quel est le ratio entre les territoires enfants spécifiques à un entrepreneur et les territoires parents opérationnels ? Des territoires sont-ils partagés entre ressources internes et externes, ou ont-ils été totalement cloisonnés ? Cet audit distingue la véritable structure géographique de la dette d’isolement accumulée. Les territoires créés exclusivement pour le contrôle de la visibilité des partenaires sont de solides candidats à l’élimination dans le cadre du partage basé sur le compte. Les territoires qui codent une véritable géographie opérationnelle (zones de planification, régions d’accord de niveau de service, frontières réglementaires) sont préservés et ne sont pas confondus avec le contrôle d’accès.
• Viabilité de la transition hybride : Pour les organisations à l’échelle, il est rarement recommandé de passer du partage basé sur le territoire au partage basé sur le compte. Au lieu de cela, une transition hybride réduit les risques en intégrant de nouveaux sous-traitants au partage basé sur le compte tout en maintenant les cohortes de partage basées sur le territoire héritées jusqu’à leur prochaine période de renouvellement. L’approche hybride est architecturalement viable à condition que l’automatisation du partage basé sur le compte soit strictement limitée à l’identificateur compte/entreprise, ce qui permet aux ressources sans cet ID de rester sur l’accès basé sur le territoire sans interruption. Traitez l’état hybride comme une architecture temporaire, pas comme un modèle opérationnel permanent.
• Principaux risques de migration : Les migrations de systèmes existants introduisent trois risques architecturaux critiques qui nécessitent une atténuation proactive. Premièrement, les reconstructions de tableaux de partage déclenchées par de nouvelles règles basées sur des critères nécessitent beaucoup de ressources. Planifiez des coupures pendant les périodes de faible activité afin d’éviter les écarts de visibilité entre les répartiteurs dus à de longs recalculs. Deuxièmement, les ordres d’exécution en vol risquent de perdre en visibilité pendant la transition. Maintenez les appartenances à des territoires parallèles ou préremplissez le partage des enregistrements actifs jusqu’à leur fermeture. Pour terminer, ajustez les stratégies d’optimisation et de planification en retirant des territoires enfants pour déplacer le pool de ressources. Testez, prenez des exécutions de référence et capturez des métriques pour confirmer l’efficacité des frontières géographiques et des gains d’efficacité.

Compte tenu de l’évolutivité et de l’optimisation du retour sur investissement, nous recommandons l’approche de partage basé sur le compte pour les organisations Field Service à forte croissance qui gèrent plusieurs sous-traitants concurrents dans des zones géographiques superposées. Le partage basé sur le territoire offre une configuration plus simple et déclarative, mais le partage basé sur le compte permet aux organisations d’exploiter tout le potentiel du moteur de planification et d’optimisation. En dissociant la visibilité de la géographie, les organisations peuvent gérer une configuration de territoire qui s’adapte à l’activité et produit les résultats suivants :

• Efficacité opérationnelle : L’agrégation des ressources dans un pool unique permet au moteur de trouver le véritable « meilleur » technicien pour chaque tâche, réduisant ainsi les temps de trajet et les coûts opérationnels.
• Niveaux de service avancés : La planification complète réduit les délais de service en identifiant la ressource contractée la plus disponible/la plus proche, en accélérant le délai de service et en améliorant directement la satisfaction client.
• Productivité du répartiteur : Le personnel interne peut gérer une vue régionale consolidée plutôt que de basculer entre des territoires « enfants » cloisonnés.

Le partage basé sur le territoire est plus adapté aux opérations très cloisonnées des sous-traitants avec des territoires/zones géographiques strictement non superposés.

Le choix d’un modèle architectural est la première étape. Une exécution réussie nécessite un alignement continu sur les meilleures pratiques Salesforce et les capacités de la plate-forme.

Étapes suivantes :

• Audit de votre paysage : Vérifiez votre hiérarchie de territoires actuelle et l’utilisation des ressources externes. Identifiez les « territoires sous-traitants » créés uniquement pour l’isolement des partenaires. Si votre hiérarchie est encombrée par de tels silos, évaluez les avantages et les efforts de la migration vers le partage basé sur le compte.
• Validation Sandbox : Prototypez le modèle de partage basé sur le compte dans une organisation sandbox complète ou partielle et testez la visibilité de bout en bout sous tous les angles :
  • Utilisateurs internes (administrateurs, répartiteurs et techniciens internes) : Confirmez l’accès approprié. Certains utilisateurs internes devraient avoir un accès général.
  • Utilisateur du gestionnaire sous-traitant : Vérifiez que la visibilité est strictement limitée à leur propre force de travail.
  • Techniciens de l’entrepreneur (ressources externes) : Vérifiez que l’accès est correctement limité au travail qui leur a été attribué.
  • Un test rigoureux de la visibilité organisationnelle est essentiel pour éviter les fuites de données entre partenaires concurrents.
• Évaluation des performances et du retour sur investissement : Exploitez les tableaux de bord Plate-forme d’optimisation et Intelligence Field Service pour recueillir des connaissances sur la réduction des temps de trajet, l’utilisation des ressources et l’amélioration des temps de réponse, en fournissant les données nécessaires pour justifier le changement architectural aux parties prenantes. Cette analyse avant et après peut également être répétée en production une fois la transition en cours.
• Phase pilote : Une fois les tests en sandbox terminés, lancez un pilote progressif dans un ou deux territoires où les ressources internes et externes se chevauchent géographiquement, idéalement en reflétant celles testées en sandbox. Validez la logique de partage avec un petit groupe d’utilisateurs contrôlé avant de recommander un déploiement plus large avant le déploiement complet.
• Évolutivité de la solution : Vérifiez que toute automatisation personnalisée (Flow ou Apex) requise pour gérer les Tableaux de partage et les enregistrements Membre du territoire de service (STM) est conçue pour la durabilité à long terme. La solution doit utiliser des modèles de conception modulaires (par exemple, des infrastructures de déclenchement) et s’assurer que la logique est élaborée pour gérer de façon transparente les attributions de ressources à haut volume dans les limites du gouverneur de plate-forme.

Tous les modèles de ce guide doivent être validés dans un environnement sandbox avant le déploiement en production. Le comportement d’implémentation peut varier selon la configuration de l’organisation, le volume de données et les règles métiers.

Documentation de la plate-forme (officiel Salesforce) :

• Field Service Developer Guide : Référence principale pour les objets de données, les API et la personnalisation Field Service
• Référence de l’objet ServiceResource : Documentation d’API pour l’objet SR
• Référence de l’objet ServiceTerritoryMember : Documentation d’API pour l’objet STM
• Règles de partage basées sur des critères : Guide de sécurité officiel pour l’implémentation des règles de partage qui sous-tendent le partage basé sur le compte
• Guide du développeur sur les déclencheurs Apex : Référence de la couche d’automatisation personnalisée requise par le partage basé sur le compte
• Meilleures pratiques pour les déclencheurs Apex : Modèles recommandés par Salesforce pour le développement de déclencheurs évolutifs

Articles d’aide Salesforce

• Lignes directrices relatives à la configuration de sous-traitants Field Service : Guide de configuration des ressources des sous-traitants dans Salesforce Field Service
• Définir des ressources basées sur la capacité : Documentation officielle pour la configuration de ressources basées sur les capacités référencées dans l’article
• Comment fonctionne le moteur d’optimisation Field Service ? Référence Field Service Optimization. Guide pour les exécutions d’optimisation, également pertinent pour les avantages du partage basé sur le compte et le retour sur investissement référencé dans l’article.
• Configuration de la plate-forme d’optimisation: Guide de configuration de la plate-forme d’optimisation référencé dans la section Étapes suivantes
• Vue d’ensemble Experience Cloud : Configuration de Partner Community pour le partage basé sur le compte (Gestion sur la plate-forme)

Salesforce Trailhead/Apprentissage

• Les bases de Field Service : Module de base couvrant les territoires, les ressources et les heures ouvrables
• Planification Field Service : Concepts de planification qui sous-tendent la discussion sur l’optimisation dans ce guide
• Optimisation de Field Service : Exploration approfondie de la configuration de l’optimisation et des stratégies de planification
• Salesforce Security et qui voit quoi : Règles de partage et principes fondamentaux de la sécurité des données
• Élaboration d’un portail partenaire avec Experience Cloud : Guide pratique de configuration des partenaires Experience Cloud référencé dans l’article

Industrie et contexte stratégique

• Rapport sur l’état de service Salesforce, 7e édition : L’édition la plus récente, qui a interrogé 6 500 professionnels du service dans le monde, avec des connaissances dédiées sur Field Service, l’adoption de l’IA et les tendances de productivité des techniciens directement pertinentes pour les arguments de retour sur investissement dans cet article.
• Agentforce for Field Service : La plate-forme Field Service pilotée par l’IA de Salesforce, directement pertinente à la discussion sur l’IA et la préparation pour l’avenir à la section 13. Le pool unifié de ressources pour le partage basé sur le compte maximise l’intelligence de planification d’Agentforce.
• Guide du marché Gartner pour la gestion Field Service : L’analyse Gartner la plus récente du paysage du marché de la gestion Field Service (abonnement Gartner requis).

Mor Epstein
Architecte senior Success, Salesforce Field Service

Doté d’une formation en génie industriel de Georgia Tech et d’un MBA, Mor est un conseiller de confiance qui a fait ses preuves dans le déblocage et l’accélération des implémentations Field Service critiques. Son expérience globale de la clientèle, combinée à la résolution pratique de problèmes pilotés par les données, la positionne comme une ressource incontournable pour les organisations d’assistance sur site dans le monde entier. Mor excelle à guider les clients à travers le parcours de planification et d’optimisation, aidant les organisations à exploiter tout le potentiel de la planification intelligente pour obtenir des gains mesurables en efficacité et en livraison de services.

Lee Ephrati
Architecte senior Success, Salesforce Field Service

Lee est un architecte technique hautement expérimenté avec plus de 10 ans d’expérience en livraison et conseil Salesforce, spécialisé dans les architectures Field Service et la conception de solutions mobiles. Lee se concentre sur l’alignement des structures organisationnelles complexes avec la plate-forme SFS native et l’application mobile afin de générer un retour sur investissement opérationnel maximal pour les entreprises internationales. Avec un état d’esprit axé sur le client et une connaissance approfondie de la plate-forme, Lee apporte une approche consultative qui offre constamment une valeur durable pour les clients de Salesforce dans le monde entier.