En entornos de Salesforce Field Service (SFS) a gran escala, la gestión de redes de contratistas externos requiere un delicado equilibrio entre la seguridad de la plataforma y el desempeño de la programación. Esta guía compara dos patrones arquitectónicos principales: el patrón tradicional basado en territorio y el nuevo patrón de colaboración basado en cuentas para regular el acceso y la gestión de los contratistas externos. En este documento, revisamos en profundidad para ayudar a las organizaciones a elegir la estructura fundamental que mejor admite sus objetivos operativos y para comprender las ventajas de cada opción.

Esta opción de patrón afecta a la eficiencia de la programación, la utilización de recursos y la productividad del despachador. Seleccionando el enfoque correcto, las compañías garantizan una experiencia transparente tanto para el personal interno como para los socios externos mientras mantienen la escalabilidad a largo plazo de su solución.

Más allá de las ganancias operativas inmediatas, esta opción fundamental determina la preparación de una organización para el servicio autónomo. El patrón de colaboración basado en cuentas proporciona la visibilidad de datos unificada requerida para Agentforce, y específicamente el Agente de programación para Field Service, para realizar una evaluación holística sin estar restringido por silos de datos artificiales. El uso compartido basado en cuentas también permite a Data Cloud agregar mediciones de desempeño de contratistas de forma más efectiva, permitiendo una evaluación comparativa competitiva transparente mientras mantiene el aislamiento riguroso de datos requerido en entornos de múltiples proveedores.

• Seleccione su patrón basándose en solapamiento competitivo. Si los contratistas externos compiten con recursos internos u otros recursos externos en territorios compartidos, la colaboración basada en cuentas es probablemente la opción arquitectónicamente correcta. La colaboración basada en territorios es apropiada solo cuando los contratistas reciben áreas de servicio/trabajos exclusivos y no solapados.
• Evite la expansión del territorio. La creación de territorios de contratistas exclusivos para lograr el aislamiento de datos cuando no es necesario introduce un exceso de jerarquía que degrada la eficiencia y el desempeño de la programación y aumenta significativamente la carga administrativa a escala. La colaboración basada en cuentas elimina este patrón de problemas.
• Cree las bases para la programación dirigida por IA. El Agente de programación para Field Service y el motor de optimización tendrán un mejor desempeño cuando tengan visibilidad completa del conjunto de recursos. La estructura en silos de colaboración basada en territorios lo evita; la colaboración basada en cuentas es la base arquitectónica deseada.

En el último decenio, las redes de contratistas en el servicio sobre el terreno han evolucionado de ampliaciones ad hoc de equipos internos a ecosistemas estratégicos deliberadamente estructurados entre industrias, incluidas las telecomunicaciones, los servicios públicos, los servicios a domicilio y otras. Muchas operaciones de campo ahora dependen de contratistas junto con empleados a tiempo completo, lo que requiere reglas claras para el acceso, la visibilidad y el control de despachos.

A medida que las organizaciones se amplían en Salesforce Field Service, la forma en que diseñan y gestionan estos recursos externos (ya sea a través de patrones de estilo de territorio, colaboración centrada en cuentas o híbridos) configura directamente la seguridad y eficiencia con la que pueden programar trabajo entre una plantilla laboral combinada.

Esta guía está dirigida a partes interesadas técnicas y estratégicas responsables del diseño, el desempeño y la capacidad de ampliación de implementaciones de Salesforce Field Service:

• Arquitectos técnicos y de soluciones: Para evaluar la repercusión de diferentes patrones de colaboración en la eficiencia de la programación y optimización.
• Líderes de operaciones de servicio de campo: Para comprender las compensaciones entre diferentes personas contratistas, como Contratistas nombrados, Compañías contratistas y Trabajadores ocasionales.
• Administradores de Salesforce: Para obtener perspectivas sobre cómo se utilizan los territorios de servicio y las tablas de colaboración de plataforma para gestionar requisitos de seguridad complejos.

La persona contratista en ámbito determina directamente la arquitectura de colaboración apropiada. Cada categoría tiene distintas implicaciones sobre cómo se estructura el acceso a nivel de registro, cómo percibe el Optimizador la disponibilidad de recursos y cómo se amplía la solución:

• Contratista nombrado: Un recurso externo individual que se trata de forma similar a un empleado interno. Un contratista nombrado requiere una licencia de usuario exclusiva. El modelo de colaboración refleja patrones de acceso de técnicos internos, lo que lo convierte en la persona de contratista de menor complejidad a la que dar asistencia.
• Compañía contratista: Entidad externa que gestiona su propia plantilla laboral. En SFS, las compañías contratistas se representan como Recursos basados en capacidad, donde la organización principal programa y asigna trabajo a la compañía en vez de a un individuo específico.
• Trabajador ocasional: Un usuario que opera temporalmente entre múltiples territorios. La persona más compleja arquitectónicamente. Las relaciones transitorias entre múltiples territorios significan que los límites de colaboración basados en territorios se interrumpen, de modo que la visibilidad se gestiona de forma dinámica a nivel de registro en vez de a través de asignaciones geográficas estáticas.

Estas pautas son complejas porque la organización principal y los objetivos del contratista a menudo están en desacuerdo técnicamente.

1. Objetivos divergentes: La organización principal se centra principalmente en la satisfacción del cliente y el trabajo/acuerdo contractual (por ejemplo, preferencias de recursos, servicio rápido y oportuno y gestión de cómo se distribuye el trabajo y las horas entre contratistas). Por el contrario, los contratistas se centran habitualmente en maximizar el trabajo asignado mientras minimizan el tiempo de desplazamiento y el costo operativo.

2. Competición: A diferencia de los empleados internos, las diferentes compañías contratistas son a menudo competidores directos. Aunque la organización matriz necesita una visión integral de la región (transparencia), los contratistas requieren un aislamiento estricto de las operaciones de los demás (aislamiento).

3. Integridad de marca: Para el cliente final, el trabajador representa su marca, que a menudo requiere que la compañía matriz vea actualizaciones de estado en tiempo real. Sin embargo, los contratistas a menudo protegen sus operaciones internas en un sistema cerrado o “caja negra”.

4. Visibilidad y seguridad: Aunque un territorio de servicio compartido normalmente implica visibilidad universal de todos los recursos asignados, los entornos de múltiples contratistas requieren un patrón de seguridad más matizado. Para mantener la integridad competitiva y la privacidad de los datos, es esencial evitar que los contratistas accedan a los nombres de propiedad, las programaciones o la información de recursos de los demás.

El diseño de contratistas en Salesforce Field Service abarca tres modelos operativos distintos, cada uno afectando a la visibilidad de los recursos, la propiedad de los despachos y las licencias:

1. Asignación de capacidad externa
2. Programación automática de socios
3. Despacho dirigido por internos

Asignación de capacidad externa (capacidad fuera de la plataforma): El contratista gestiona su plantilla de trabajo de forma externa y proporciona una capacidad definida (por ejemplo, 10 horas disponibles) en vez de programaciones de técnicos individuales. Esta capacidad se trata como un depósito de horas o elementos de trabajo para fines de programación.

Programación automática de socios: Los gestores de contratistas inician sesión en Salesforce a través de un sitio de Experience para programar sus propios equipos. Requieren un aislamiento estricto de otros socios.

Despacho dirigido interno: Los despachadores internos programan técnicos contratistas directamente. Los contratistas utilizan la aplicación móvil Field Service para la ejecución.

En este patrón, el Territorio de servicio sirve como el límite de seguridad principal. Cada Compañía contratista está asignada a su propio territorio “Niño” exclusivo.

• Redes de socios a pequeña escala
• Socios con regiones geográficas estrictamente no solapadas
• Situaciones donde el trabajo de contratista es fundamentalmente diferente del trabajo de recursos internos, eliminando la competencia (por ejemplo, los contratistas externos solo gestionan “instalaciones de tipo A”, mientras que los recursos internos gestionan todos los otros tipos de trabajo)

• Configuración simplificada: Utiliza la configuración y automatización estándar de Territorio de usuario.
• Borrar depósito de datos: Garantiza una visibilidad de datos sencilla y una gestión de seguridad simplificada a través de objetos Territorio de servicio estándar.

• Eficiencia de optimización: El motor no puede evaluar recursos entre límites de territorio, evitando una programación óptima y un enrutamiento eficiente.
• Distensión de territorio: La creación de un mayor número de territorios para un número muy bajo de recursos lleva a gastos generales de programación.
• Desempeño de Gantt: Grandes jerarquías (1K+ territorios) pueden causar cuellos de botella de desempeño significativos, así como riesgos de alcanzar límites de plataforma.

Esta guía presenta un nuevo enfoque de solución: Compartición basada en cuentas (implementada a través de reglas de colaboración basadas en criterios nativas de Salesforce, el mismo mecanismo de plataforma utilizado para otorgar acceso a registros basándose en valores de campo). La colaboración basada en cuentas desvincula la visibilidad de la geografía. Los territorios permanecen grandes y continuos, mientras que la visibilidad se gestiona a través de las tablas de colaboración de la plataforma basándose en una relación de cuenta. En términos prácticos, las reglas de colaboración basadas en criterios evalúan un campo en el registro (como ServiceResource.Company) y comparten automáticamente ese registro con el grupo apropiado. La colaboración basada en criterios es el motor que hace que la colaboración basada en cuentas funcione sin código personalizado a nivel de registro.

• Ecosistemas a gran escala donde una proporción significativa de la fuerza de trabajo consiste en recursos externos
• Áreas urbanas donde varios contratistas cubren los mismos códigos postales
• Escenarios donde los recursos internos y externos son capaces de ejecutar el mismo trabajo (por ejemplo, “instalaciones de tipo A”), pero las reglas de negocio dictan una lógica específica para la selección de recursos (por ejemplo, preferencia de recursos internos en ciertos escenarios)

• Utilización máxima y ROI: El motor evalúa todo el conjunto regional, encontrando el “mejor” recurso para cada trabajo
• Escalabilidad: Admite un gran número de contratistas/recursos externos sin aumentar los conteos de territorios
• Gestión consolidada: El personal interno gestiona una vista en vez de cientos de carpetas en silos (territorios secundarios)

• Esfuerzo de desarrollo: Requiere automatización personalizada (Flujo o Apex) para gestionar las tablas Colaboración
• Compartición de pertenencia: Requiere colaboración explícita de registros de Miembro de territorio de servicio (STM)

Para plantilla externa (dimensión Asignación de capacidad externa), los arquitectos pueden utilizar Recursos basados en capacidad para representar el “resumen” de la plantilla de un contratista.

• Capacidad: Utilice esto cuando el contratista gestione su propio despacho y enrutamiento. Su enfoque principal está en el volumen total de trabajo que pueden realizar en vez de la persona específica que lo realiza.
• Individual: Utilice esto cuando necesite visibilidad granular del día de un técnico. Los recursos basados en particulares le permiten gestionar su ubicación exacta, la disponibilidad en tiempo real y las asignaciones de trabajos específicas como si fueran personal interno.

Antes de diseñar su patrón de contratista de Field Service, utilice este árbol de decisiones para determinar la arquitectura de colaboración apropiada.

Árbol de decisiones de selección de patrón de colaboración de contratista

Árbol de decisiones para seleccionar un patrón de colaboración de contratista en Salesforce Field Service. A partir de si los recursos externos están en uso, el árbol se bifurca a través del tipo de recurso y la exclusividad de trabajo para recomendar la colaboración basada en territorio o basada en cuenta.

El núcleo de este patrón es una capa de automatización que convierte la relación ServiceResource.AccountId o ServiceResource.Company (Compañía contratista) en registros de colaboración de plataforma.

Para verificar el acceso apropiado para el despachador y el recurso de servicio en un sitio de Experience, el acceso debe controlarse a través de:

• Regla de colaboración de recursos de servicio: Otorga acceso basándose en un criterio (cuenta/compañía)
• Regla de colaboración de territorio de servicio: Otorga acceso basándose en un criterio (nombre/Id. de territorio)

Cuando utilice la colaboración basada en cuentas, asegúrese de tener en cuenta la experiencia Field Service Mobile y la visibilidad de registros para técnicos asignados.

• Compartición de recursos asignados: La función SFS estándar otorga automáticamente a un recurso asignado acceso a la Cita de servicio y su Orden de trabajo principal. Esta configuración proporciona al técnico la información necesaria para ejecutar el trabajo sin requerir reglas de colaboración personalizadas adicionales para el trabajo asignado.
• Riesgos de visibilidad: Aunque el trabajo asignado se gestiona de forma nativa, tenga cuidado con las citas futuras o no asignadas que carecen de una asociación Cuenta o Territorio. Si los valores predeterminados de toda la organización (OWD) no están gestionados de forma estricta, o si los conjuntos de colaboración son demasiado amplios, las citas no asignadas podrían ser visibles para todos los usuarios en un territorio consolidado.
• Asociación Cuenta-Territorio: Asegúrese de que todas las citas de servicio están vinculadas explícitamente a una cuenta y un territorio. Esta vinculación permite un filtrado limpio dentro de la aplicación móvil y verifica que no se produce una fuga de datos para el trabajo no asignado que se encuentra en el grupo regional.

• Requisito: 10 contratistas diferentes proporcionan instalación de fibra en Londres.
• Contexto: En el enfoque de colaboración basado en territorios, Londres se dividiría en 10 territorios superpuestos. Los despachadores tendrían dificultades para ver la disponibilidad cercana, lo que llevaría a tiempos de desplazamiento altos.
• Recomendación: Compartición basada en cuentas. Implemente un territorio de servicio del “Gran Londres” unificado utilizando la colaboración basada en cuentas para mantener la seguridad de datos granular. La colaboración basada en cuentas mantiene la gestión del contratista A en silos con sus recursos respectivos, mientras que el Optimizador de SFS mantiene la visibilidad interfuncional de todos los técnicos internos y externos. Este enfoque de programación completa facilita una lógica de enrutamiento más eficiente que puede reducir el desplazamiento en más de un 20% a través de una programación completa (estimación direccional basada en observaciones de campo entre implementaciones de clientes de SFS), creando mejoras inmediatas en la utilización de recursos y una capacidad de respuesta de servicio mejorada.

• Requisito: Un proveedor proporciona hasta 40 “ranuras” para reparaciones de calderas diariamente pero gestiona su propio despacho de técnico.
• Contexto: La gestión de 40 registros de recursos individuales agrega gastos generales innecesarios.
• Recomendación: Recurso basado en capacidad vinculado a la cuenta de proveedor. Un registro de recurso representa la capacidad diaria total del proveedor, manteniendo el gráfico de Gantt limpio y evitando la necesidad de gestionar registros de técnicos contratistas individuales.

• Requisito: Una compañía de servicios públicos incorpora 50 pequeños contratistas locales durante la temporada de tormentas para gestionar reparaciones de sobretensiones.
• Contexto: La creación y eliminación de 50 territorios cada temporada es una carga administrativa importante, y afecta negativamente a la flexibilidad del motor de programación y optimización.
• Recomendación: Compartición basada en cuentas. Cree un territorio geográfico “Desbordamiento” permanente. Cuando se incorpora un contratista, simplemente cree su cuenta y vincule sus recursos a ella. La capa de automatización gestiona la visibilidad al instante sin requerir un rediseño de jerarquía de territorios.

• Requisito: Para fugas de gas de alta prioridad, se debe enviar al técnico más cercano independientemente del contratista para el que trabaje.
• Contexto: La colaboración basada en territorios crea brechas de cobertura donde la tecnología más cercana podría estar en un territorio diferente y, por lo tanto, inaccesible para la lógica de programación.
• Recomendación: Compartición basada en cuentas. Al consolidar proveedores en un único territorio grande, el motor realiza una búsqueda completa basándose en el desplazamiento entre todo el conjunto de múltiples proveedores, reduciendo los tiempos de respuesta para incidentes de seguridad críticos.

• Requisito: Un socio de HVAC especializado tiene un derecho legal exclusivo de 10 años para dar servicio a un área remota o condado rural.
• Contexto: No hay otros contratistas operando en esta geografía, y el socio gestiona su propia programación y despacho completamente.
• Recomendación: Compartición basada en territorios. En este escenario, un territorio de servicio exclusivo es la opción más eficiente. Dado que no hay solapamiento geográfico con otros socios, el aislamiento proporcionado por el límite de territorio coincide perfectamente con los requisitos legales y operativos sin más automatización de colaboración.

La colaboración basada en cuentas separa la visibilidad de la geografía vinculando el acceso a nivel de registro a un identificador de cuenta/compañía común compartido entre el usuario despachador y sus registros de Recurso de servicio. El motor de colaboración basado en criterios nativo de la plataforma evalúa este campo y otorga o revoca automáticamente el acceso sin cambiar la jerarquía de territorios.

Los tres componentes arquitectónicos requeridos son:

1. Campo de identificador común en los objetos Usuario y Recurso de servicio que los vinculan a su cuenta de contratista.
2. Grupos públicos que agregan todos los usuarios de Despachador por compañía contratista, de modo que las reglas de colaboración se aplican de forma uniforme.
3. Reglas de colaboración basadas en criterios que evalúan el identificador y otorgan el acceso de Grupo público apropiado a registros relevantes.

En vez de utilizar territorios como límites, utilice Grupos públicos para agregar despachadores que requieren la misma visibilidad. Los despachadores ven territorios, órdenes de trabajo y citas de servicio específicos a través de la pertenencia a grupos públicos basados en territorios.

• Creación de grupos: Cree un grupo público para cada compañía contratista.
• Asignación de miembros: Agregue los Usuarios de comunidad de socios relevantes (despachadores) a su Grupo público de contratista respectivo.

Aproveche las reglas de colaboración basadas en criterios para otorgar el acceso del Grupo público a registros específicos.

• Criterios de colaboración de recursos de servicio: Las reglas de colaboración de recursos de servicio aplican la visibilidad por técnico contratista comparando el identificador de compañía/cuenta en el registro Recurso de servicio con el Grupo público de contratista correspondiente.
  • El nivel de acceso permite la lectura/escritura para permitir a los despachadores programar y actualizar asignaciones.
• Criterios de colaboración de territorios de servicio: Utilice los criterios de colaboración de territorios de servicio para configurar la lógica para el acceso restringido de territorios. Otorgue a los despachadores acceso a los amplios territorios geográficos donde están autorizados a trabajar. Ejemplo:
  • Criterios: ServiceTerritory.Name ES IGUAL A “Atlanta”.
  • Compartido con: Grupos públicos de contratistas relevantes (por ejemplo, Contratista A, Contratista B, Contratista C).
  • Nivel de acceso: Lectura/escritura

Para obtener directrices de implementación detalladas, consulte la documentación oficial de Salesforce:

• Reglas de colaboración basadas en criterios
• Grupos públicos
• Desencadenadores Apex para la gestión automatizada de registros de colaboración

Cuando se implementa correctamente, la colaboración basada en cuentas entrega:

• Visibilidad unificada: Los despachadores ven todos los recursos relevantes en todo el territorio sin reasignación manual de territorios.
• Acceso dinámico: A medida que cambian las asignaciones de contratistas, las reglas de colaboración ajustan automáticamente la visibilidad sin intervención del administrador.
• Aislamiento competitivo: Cada contratista solo ve sus propios recursos, manteniendo la privacidad de los datos.
• Arquitectura ampliable: Los nuevos contratistas se pueden incorporar simplemente creando una cuenta y un grupo público, con reglas de colaboración gestionando el resto automáticamente.

A medida que las organizaciones de servicio de campo cambian de modelos reactivos a proactivos, su elección de patrón arquitectónico establece el “techo de innovación” para la agilidad operativa a largo plazo.

• Activación de la IA y el aprendizaje automático: La colaboración basada en cuentas verifica que el motor tiene visibilidad de todo el conjunto de recursos para encontrar la mejor coincidencia en vez de estar restringido por silos de datos. Como evita silos de territorio ineficientes, el Agente de programación para Field Service (asistente de programación con tecnología de IA dentro de Salesforce) proporciona patrones de desplazamiento más lógicos y asignaciones de técnicos sin estar limitado por microterritorios aislados. Este enfoque maximiza la optimización completa, mejorando directamente los KPI de desplazamiento y la preparación de los técnicos. La colaboración basada en cuentas admite la programación dirigida por IA proporcionando al motor visibilidad de todo el conjunto de recursos, lo que permite una coincidencia “verdaderamente óptima” en vez de estar restringida por silos de datos artificiales.
• Escalabilidad arquitectónica: La colaboración basada en territorios a menudo encuentra un “muro de desempeño” debido a su dependencia de territorios aislados. A medida que crece la red de contratistas, la eficacia del motor de programación se neutraliza por límites artificiales que le impiden alcanzar la capacidad disponible en territorios adyacentes. Además, donde la colaboración basada en territorios requiere un nuevo territorio y ajustes manuales para cada socio, la colaboración basada en cuentas simplifica el crecimiento. Las organizaciones incorporan cientos de socios contratistas simplemente creando una Cuenta y registros de Recurso de servicio asociados, dejando la estructura de territorio geográfico principal intacta y con desempeño.

Esta guía se ha centrado principalmente en nuevas implementaciones netas. Sin embargo, muchas organizaciones ya están ejecutando la colaboración basada en territorios a escala y arrastran una deuda de jerarquía de territorios significativa. La migración de la colaboración basada en territorios a la colaboración basada en cuentas en un entorno de producción en vivo presenta distintos riesgos arquitectónicos a evaluar antes de que comience cualquier trabajo de transición. Esta sección aborda las tres dimensiones críticas de una migración del sistema existente: evaluación del estado actual, determinación de la estrategia de transición y gestión de riesgos de migración.

• Evaluación de la expansión del territorio: Antes de cualquier planificación de migración, cuantifique la jerarquía de territorios actual. Las preguntas de diagnóstico clave son: ¿Cuántos territorios existen únicamente para aplicar el aislamiento de contratistas frente a límites geográficos genuinos? ¿Cuál es la proporción de territorios secundarios específicos del contratista con respecto a territorios principales operativos? ¿Hay territorios compartidos entre recursos internos y externos, o se han aislado completamente? Esta auditoría distingue la estructura geográfica verdadera de la deuda de aislamiento acumulada. Los territorios creados exclusivamente para el control de visibilidad de socios son buenos candidatos para su eliminación bajo colaboración basada en cuentas. Los territorios que codifican geografía operativa genuina (zonas de programación, regiones de SLA, límites reguladores) se mantienen y no se combinan con el control de acceso.
• Viabilidad de transición híbrida: Para organizaciones a escala, rara vez se recomienda una transición completa de colaboración basada en territorio a colaboración basada en cuenta; en su lugar, una transición híbrida reduce el riesgo al incorporar nuevos contratistas bajo colaboración basada en cuenta mientras mantiene cohortes de colaboración basadas en territorio heredadas hasta su siguiente plazo de renovación. El enfoque híbrido es arquitectónicamente viable siempre que la automatización de colaboración basada en cuentas tenga un ámbito estricto al identificador de cuenta/compañía, permitiendo que los recursos sin ese Id. permanezcan en el acceso basado en territorio sin interrupciones. Trate el estado híbrido como una arquitectura temporal, no como un modelo operativo permanente.
• Riesgos de migración clave: Las migraciones de sistemas existentes presentan tres riesgos arquitectónicos críticos que requieren mitigación proactiva. En primer lugar, las reconstrucciones de tablas de colaboración desencadenadas por nuevas reglas basadas en criterios consumen recursos; programe cortes durante periodos de baja actividad para evitar brechas de visibilidad de despachador causadas por nuevos cálculos de larga ejecución. En segundo lugar, las órdenes de trabajo en vuelo corren el riesgo de perder visibilidad durante la transición; mantenga suscripciones de territorios paralelas o complete previamente la colaboración para registros activos hasta que se cierren. Finalmente, ajuste las políticas de programación y optimización a medida que la eliminación de territorios secundarios cambia el conjunto de recursos. Pruebe, realice ejecuciones de línea base y capture mediciones para confirmar que los límites geográficos siguen siendo efectivos y que las ganancias de eficiencia se realizan realmente.

Dada la capacidad de ampliación y el desempeño de las inversiones de optimización, recomendamos el enfoque de colaboración basado en cuentas para organizaciones de Field Service de alto crecimiento que gestionan múltiples contratistas competidores en regiones geográficas solapadas. Aunque la colaboración basada en territorios ofrece una configuración declarativa más sencilla, la colaboración basada en cuentas permite a las organizaciones liberar todo el potencial del motor de programación y optimización. Desvinculando la visibilidad de la geografía, las organizaciones pueden mantener una configuración de territorios que se amplía con el negocio y entrega estos resultados:

• Eficiencia operativa: Agregar recursos en un único conjunto permite al motor encontrar el verdadero “mejor” técnico para cada trabajo, reduciendo el tiempo de desplazamiento y los costos operativos.
• Niveles de servicio mejorados: La programación integral reduce los retrasos en el servicio identificando qué recurso contratado está más disponible/cercano, acelerando el tiempo para servir y mejorando directamente la satisfacción del cliente.
• Productividad de despachador: El personal interno puede gestionar una vista regional consolidada en vez de alternar entre territorios secundarios aislados.

La colaboración basada en territorios es la más adecuada para operaciones de contratistas con gran silo con territorios/áreas geográficos estrictamente no solapados.

La selección de un patrón arquitectónico es el primer paso. La ejecución correcta requiere una alineación continua con las mejores prácticas de Salesforce y las funciones de la plataforma.

Siguientes pasos:

• Auditar su panorama: Revise su jerarquía de territorios actual y la utilización de recursos externos. Identifique cualquier “territorio de contratista” creado únicamente para el aislamiento de socios: si su jerarquía está abarrotada de dichos silos, evalúe los beneficios y el esfuerzo de migrar a la colaboración basada en cuentas.
• Validación de sandbox: Prototipe el patrón de colaboración basado en cuentas en un entorno sandbox completo o parcial y pruebe la visibilidad de extremo a extremo desde todos los ángulos:
  • Usuarios internos (administradores, despachadores y técnicos internos): Confirme el acceso apropiado. Algunos usuarios internos deben tener acceso de forma general.
  • Usuario Gerente de contratista: Verifique que la visibilidad tiene un ámbito estricto para su propia plantilla laboral.
  • Técnicos del contratista (recursos externos): Confirme que el acceso está restringido correctamente solo a su trabajo asignado.
  • Es esencial realizar pruebas rigurosas de visibilidad organizativa para evitar la fuga de datos entre socios competidores.
• Comparación de desempeño y evaluación del desempeño: Aproveche el Núcleo de optimización y los tableros de inteligencia de Field Service para obtener perspectivas sobre la reducción del tiempo de desplazamiento, la utilización de recursos y las mejoras del tiempo de respuesta, proporcionando los datos necesarios para justificar el cambio arquitectónico a las partes interesadas. Este análisis de antes y después también se puede repetir en producción una vez que se realiza la transición.
• Fase piloto: Una vez completadas las pruebas de sandbox, inicie un piloto por fases en uno o dos territorios donde los recursos internos y externos se solapan geográficamente, idealmente, reflejando los probados en el sandbox. Valide la lógica de colaboración con un pequeño grupo de usuarios controlado antes de que se recomiende una implementación más amplia antes de la implementación completa.
• Escalabilidad de la solución: Confirme que cualquier automatización personalizada (Flujo o Apex) requerida para gestionar registros de Tablas de colaboración y Miembro de territorio de servicio (STM) está diseñada para la sostenibilidad a largo plazo. La solución debe utilizar patrones de diseño modulares (por ejemplo, marcos de trabajo de desencadenador) y garantizar que la lógica está construida para gestionar asignaciones de recursos de gran volumen sin problemas dentro de los límites del regulador de plataforma.

Todos los patrones de esta guía requieren validación en un entorno sandbox antes de la implementación de producción. El comportamiento de implementación puede variar en base a la configuración de la organización, el volumen de datos y las reglas de negocio.

Documentación de plataforma (oficial de Salesforce):

• Guía del desarrollador de Field Service: Referencia principal para objetos de datos de Field Service, API y personalización
• Referencia de objeto ServiceResource: Documentación de API para el objeto SR
• Referencia de objeto ServiceTerritoryMember: Documentación de API para el objeto STM
• Reglas de colaboración basadas en criterios: Guía de seguridad oficial para la implementación de las reglas de colaboración que sustentan la colaboración basada en cuentas
• Guía del desarrollador de desencadenadores Apex: Referencia para la capa de automatización personalizada requerida por la colaboración basada en cuentas
• Mejores prácticas de Apex Trigger: Patrones recomendados por Salesforce para el desarrollo de desencadenadores ampliables

Artículos de Ayuda de Salesforce

• Directrices para la configuración de contratistas de Field Service: Directrices para la configuración de recursos de contratista en Salesforce Field Service
• Definir recursos basados en capacidad: Documentación oficial para la configuración de recursos basados en capacidad a la que se hace referencia en el artículo
• ¿Cómo funciona el Motor de optimización de Field Service? Referencia de Optimización de Field Service. Directrices para las ejecuciones de optimización, también relevantes para las ventajas de colaboración basadas en cuentas y el desempeño de las inversiones al que se hace referencia en el artículo.
• Configurar Núcleo de optimización: Guía de configuración para Núcleo de optimización a la que se hace referencia en la sección Siguientes pasos
• Descripción general de Experience Cloud: Configuración de comunidad de socios para colaboración basada en cuentas (Gestión en plataforma)

Salesforce Trailhead / Aprendizaje

• Fundamentos de Field Service: Módulo fundacional que cubre territorios, recursos y horarios laborales
• Programación de servicio de campo: Conceptos de programación que sustentan el debate de optimización en esta guía
• Optimización de Field Service: Profundizar en las políticas de programación y configuración de optimización
• Seguridad de Salesforce y quién ve qué: Reglas de colaboración y fundamentos de seguridad de datos
• Crear un portal de socios con Experience Cloud: Guía práctica para la configuración de socio de Experience Cloud a la que se hace referencia en el artículo

Industria y contexto estratégico

• Informe sobre el estado del servicio de Salesforce, 7a edición: La edición más reciente, encuestando a 6.500 profesionales de servicio en todo el mundo, con perspectivas dedicadas sobre Field Service, la adopción de IA y las tendencias de productividad de los técnicos directamente relevantes para los argumentos de ROI en este documento.
• Agenteforce para Field Service: La plataforma de servicio de campo con tecnología de IA de Salesforce, directamente relevante para el debate sobre IA y preparación para el futuro en Sección 13. El conjunto de recursos unificados de colaboración basado en cuentas está maximizando la inteligencia de programación de Agentforce.
• Guía de Gartner Market para Gestión de Field Service: El análisis de Gartner más actual del panorama del mercado de FSM (se requiere suscripción de Gartner).

Mor Epstein
Arquitecto sénior de éxito, Salesforce Field Service

Con una experiencia en Ingeniería Industrial de Georgia Tech y un MBA, Mor es un asesor de confianza con un historial probado de desbloqueo y aceleración de implementaciones de Field Service de misión crítica. Su experiencia global de cara al cliente, combinada con la resolución de problemas dirigida por datos, la posiciona como un recurso de referencia para organizaciones de servicio de campo en todo el mundo. Mor destaca en guiar a los clientes por la trayectoria de Programación y optimización, ayudando a las organizaciones a liberar todo el potencial de la programación inteligente para lograr ganancias mensurables en eficiencia y entrega de servicios.

Lee Ephrati
Arquitecto sénior de éxito, Salesforce Field Service

Lee es un Arquitecto Técnico altamente experimentado con más de 10 años de experiencia en entrega y asesoramiento de Salesforce, especializado en arquitecturas de Field Service y diseño de soluciones móviles. Lee se centra en alinear estructuras organizativas complejas con la plataforma SFS nativa y la aplicación móvil para impulsar el máximo desempeño de las inversiones (ROI) operativas para empresas globales. Con una mentalidad de cliente primero y Knowledge integral de la plataforma, Lee aporta un enfoque consultivo que entrega de forma coherente un valor duradero para clientes de Salesforce en todo el mundo.