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 rendimiento de la programación. Esta guía compara dos patrones arquitectónicos principales: el patrón tradicional basado en territorios y el nuevo patrón de colaboración basado en cuentas para regular el acceso y la gestión de contratistas externos. En este documento, revisamos tanto en profundidad para ayudar las organizaciones a elegir la estructura fundamental que mejor apoya sus objetivos operativos, como 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. Al seleccionar el enfoque correcto, las empresas garantizan una experiencia transparente tanto para el personal interno como para los socios externos, manteniendo al mismo tiempo 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 rendimiento de contratistas de forma más efectiva, permitiendo una evaluación comparativa competitiva sencilla 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 exclusivas y no solapadas.
• 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 rendimiento de la programación y aumenta significativamente el gasto administrativo 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 rendimiento cuando tengan visibilidad completa del conjunto de recursos. La estructura de 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 y deliberadamente estructurados en sectores como las telecomunicaciones, los servicios públicos, los servicios a domicilio y otros. 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 en una plantilla de trabajo combinada.

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

• Arquitectos técnicos y de soluciones: Para evaluar el impacto de diferentes patrones de colaboración en la eficiencia de programación y optimización.
• Líderes de operaciones de servicio de campo: Para comprender las compensaciones entre diferentes personas contratistas, como Contratistas nombrados, Empresas 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 implicaciones diferentes 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 para dar cobertura.
• Empresa contratista: Entidad externa que gestiona su propia plantilla de trabajo. En SFS, las empresas contratistas se representan como Recursos basados en capacidad, donde la organización principal programa y asigna trabajo a la empresa 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 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 la asignación geográfica estática.

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). Los contratistas, por el contrario, se centran habitualmente en maximizar el trabajo asignado mientras minimizan el tiempo de desplazamiento y el coste operativo.

2. Competición: A diferencia de los empleados internos, las diferentes empresas 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 empresa 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 de la competencia y la privacidad de los datos, es esencial evitar que los contratistas accedan a los nombres propios, 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 diferentes, 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 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 técnicas 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 límite de seguridad principal. Cada empresa 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 gestionan solo “instalaciones de tipo A”, mientras que los recursos internos gestionan todos los demás tipos de trabajo)

• Configuración simplificada: Utiliza la automatización y configuración estándar de Territorio de usuario.
• Depósito de datos claro: Asegúrese de 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, lo que impide 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.
• Rendimiento de Gantt: Grandes jerarquías (territorios de 1K+) pueden causar cuellos de botella de rendimiento 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 nativos 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 múltiples 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 comerciales dictan una lógica específica para la selección de recursos (por ejemplo, preferencia de recurso interno 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 el recuento de territorios
• Gestión consolidada: El personal interno gestiona una sola vista en vez de cientos de carpetas aisladas (territorios secundarios)

• Esfuerzo de desarrollo: Requiere automatización personalizada (Flow 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 de trabajo externa (dimensión Asignación de capacidad externa), los arquitectos pueden utilizar Recursos basados en capacidad para representar el “resumen” de la plantilla de trabajo 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 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 (Empresa 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/empresa)
• 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 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 estrictamente 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 explícitamente vinculadas a una cuenta y 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 altos tiempos de desplazamiento.
• 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 aislada de 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 en 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écnicos.
• 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 empresa de servicios públicos incorpora 50 pequeños contratistas locales durante la temporada de tormentas para gestionar reparaciones de aumentos.
• 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 de 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 grupo de múltiples proveedores, reduciendo los tiempos de respuesta para incidentes de seguridad críticos.

• Requisito: Un socio de climatización 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 la 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/empresa común compartido entre el usuario de despachador y sus registros de Recurso de servicio. El motor de colaboración basado en criterios nativos 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 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 empresa 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 al Grupo público apropiado acceso 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 empresa 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 empresa/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 para 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 IA y aprendizaje automático: La colaboración basada en cuentas verifica que el motor tiene visibilidad sobre todo el conjunto de recursos para encontrar la mejor coincidencia en vez de estar restringido por silos de datos. Debido a que 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, permitiendo la coincidencia “verdadera mejor” en vez de estar restringido por silos de datos artificiales.
• Escalabilidad arquitectónica: La colaboración basada en territorios a menudo encuentra un “muro de rendimiento” 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 rendimiento.

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 gran escala y arrastran una deuda considerable de la jerarquía de territorios. La migración de colaboración basada en territorios a colaboración basada en cuentas en un entorno de producción en vivo introduce distintos riesgos arquitectónicos para evaluar antes de que comience cualquier trabajo de transición. Esta sección aborda las tres dimensiones críticas de una migración de 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 del contratista 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 verdadera estructura geográfica de la deuda de aislamiento acumulada. Los territorios creados exclusivamente para el control de visibilidad de socios son candidatos sólidos 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 la colaboración basada en territorios a la colaboración basada en cuentas; en su lugar, una transición híbrida reduce el riesgo al incorporar nuevos contratistas bajo la colaboración basada en cuentas mientras mantiene cohortes de colaboración basadas en territorios 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/empresa, permitiendo que los recursos sin ese Id. permanezcan en el acceso basado en territorios 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 introducen 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 muchos recursos; programe cortes durante plazos de baja actividad para evitar brechas de visibilidad del 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 optimización y programación a medida que la eliminación de territorios secundarios cambia el grupo de recursos. Pruebe, realice ejecuciones de línea base y capture mediciones para confirmar que los límites geográficos permanecen efectivos y que las ganancias de eficiencia se realizan realmente.

Dada la capacidad de ampliación y optimización del rendimiento de las inversiones (ROI), 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 superpuestas. 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 ofrece estos resultados:

• Eficiencia operativa: Agregar recursos en un único grupo permite al motor encontrar el verdadero “mejor” técnico para cada trabajo, reduciendo el tiempo de desplazamiento y los costes operativos.
• Niveles de servicio mejorados: La programación integral reduce los retrasos en el servicio identificando qué recurso contratado está más disponible/más cerca, acelerando el tiempo de servicio y mejorando directamente la satisfacción del cliente.
• Productividad de despachador: El personal interno puede gestionar una visión 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 altamente aisladas con territorios/áreas geográficos estrictamente no superpuestos.

La selección de un patrón arquitectónico es el primer paso. La ejecución correcta requiere una alineación continua con las prácticas recomendadas 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 estos 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 generalizada.
  • Usuario Gestor de contratistas: Verifique que la visibilidad tiene un ámbito estricto para su propia plantilla.
  • Técnicos del contratista (los recursos externos): Confirme que el acceso está restringido correctamente solo a su trabajo asignado.
  • Es esencial realizar pruebas rigurosas de la visibilidad de la organización para evitar la fuga de datos entre socios competidores.
• Comparación de rendimiento y evaluación del rendimiento de las inversiones: Aproveche el Núcleo de optimización y los paneles de Field Service Intelligence 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 programa piloto por fases en uno o dos territorios donde los recursos internos y externos se superponen geográficamente, idealmente, reflejando los probados en el entorno 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 tablas de colaboración y registros de miembros de territorios 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á creada para gestionar asignaciones de recursos de gran volumen sin problemas dentro de los límites reguladores 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 basándose en la configuración de la organización, el volumen de datos y las reglas comerciales.

Documentación de plataforma (oficial de Salesforce):

• Guía del desarrollador de Field Service: Referencia principal para objetos de datos, API y personalización de Field Service
• 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 en las que se basa 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
• Prácticas recomendadas 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 ejecuciones de optimización, también relevantes para ventajas de colaboración basadas en cuentas y ROI a los que se hace referencia en el artículo.
• Configurar Núcleo de optimización: Guía de configuración para el 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

• Conceptos básicos de Field Service: Módulo fundacional que cubre territorios, recursos y horarios laborales
• Programación de Field Service: Conceptos de programación que sustentan el debate sobre optimización en esta guía
• Optimización de servicio de campo: Profundice 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 socios de Experience Cloud a la que se hace referencia en el artículo

Industria y contexto estratégico

• Informe Estado del servicio de Salesforce, 7a edición: La edición más reciente, encuesta 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 sobre el rendimiento de las inversiones 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 de IA y preparación para el futuro en la Sección 13. El grupo de recursos unificados de colaboración basado en cuentas está maximizando la inteligencia de programación de Agentforce.
• Guía del mercado de socios para la gestión de Field Service: El análisis de Gartner más reciente del panorama del mercado de FSM (se requiere suscripción de Gartner).

Mor Epstein
Arquitecto superior de éxito, Salesforce Field Service

Con 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 críticas para la misión. Su experiencia global de cara al cliente, combinada con la solución práctica de problemas dirigida por datos, la posiciona como un recurso de referencia para organizaciones de servicio de campo en todo el mundo. Mor se 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 superior 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 dirigir el máximo rendimiento de las inversiones operativas para empresas globales. Con una mentalidad de cliente primero y Knowledge integral de plataforma, Lee aporta un enfoque consultivo que entrega consistentemente un valor duradero para clientes de Salesforce en todo el mundo.