Em ambientes grandes do Salesforce Field Service (SFS), o gerenciamento de redes de prestadores de serviço externas exige um equilíbrio delicado entre a segurança da plataforma e o desempenho de agendamento. Este guia compara dois padrões arquitetônicos principais: o padrão tradicional baseado em território e o novo padrão de compartilhamento baseado em conta para regular o acesso e a gestão dos contratados externos. Neste artigo, analisamos em profundidade para ajudar as organizações a escolher a estrutura básica que melhor suporta suas metas operacionais e entender as desvantagens de cada opção.

Essa opção de padrão afeta a eficiência do agendamento, a utilização de recursos e a produtividade do supervisor. Ao selecionar a abordagem certa, as empresas garantem uma experiência contínua para equipe interna e parceiros externos enquanto mantêm a escalabilidade de longo prazo da solução.

Além de ganhos operacionais imediatos, essa escolha fundamental determina a prontidão de uma organização para serviço autônomo. O padrão de compartilhamento baseado em conta fornece a visibilidade unificada dos dados necessária para que a Agentforce, e especificamente o agente de agendamento para o Field Service, realize uma avaliação holística sem ser restrita por silos de dados artificiais. O compartilhamento baseado em conta também habilita o Data Cloud a agregar métricas de desempenho do prestador de serviços com mais eficiência, permitindo uma análise comparativa competitiva contínua enquanto mantém o isolamento de dados rigoroso necessário em ambientes de vários fornecedores.

• Selecione seu padrão com base na sobreposição competitiva. Se prestadores de serviço externos competirem com recursos internos ou outros externos em territórios compartilhados, o compartilhamento baseado em conta provavelmente será a escolha arquitetonicamente correta. O compartilhamento baseado em território é adequado apenas quando os prestadores de serviço recebem áreas/trabalhos de serviço exclusivos e não sobrepostos.
• Evite expansão de território. Criar territórios de prestadores de serviço dedicados para alcançar o isolamento de dados quando não for necessário introduz uma erupção da hierarquia que diminui a eficiência e o desempenho do agendamento e aumenta significativamente a sobrecarga administrativa em escala. O compartilhamento baseado em conta elimina esse padrão de problema.
• Criar a base para o agendamento conduzido por IA. O Agendamento do agente para o Field Service e o mecanismo de otimização terão um desempenho melhor quando tiverem visibilidade total do pool de recursos. A estrutura isolada de compartilhamento baseada em território evita isso; o compartilhamento baseado em conta é a base arquitetônica desejada.

Na última década, as redes de prestadores de serviço no serviço de campo evoluíram de extensões ad hoc de equipes internas para ecossistemas estratégicos e deliberadamente estruturados em indústrias, incluindo telecomunicações, serviços públicos, serviços domiciliares e muito mais. Muitas operações de campo agora dependem de prestadores de serviço juntamente com funcionários de tempo integral, exigindo regras claras para acesso, visibilidade e controle de envio.

Conforme as organizações crescem no Salesforce Field Service, a maneira como eles projetam e gerenciam esses recursos externos, seja por meio de padrão de estilo de território, compartilhamento centrado em conta ou híbridos, determina diretamente com que segurança e eficiência eles podem agendar trabalho em uma equipe combinada.

Este guia é destinado a partes interessadas técnicas e estratégicas responsáveis pelo design, o desempenho e a escalabilidade das implementações do Salesforce Field Service:

• Solução e arquitetos técnicos: Para avaliar o impacto de diferentes padrões de compartilhamento sobre a eficiência do agendamento e da otimização.
• Líderes de operações de serviço de campo: Para entender as compensações entre diferentes personalidades de prestadores de serviço, como prestadores de serviço nomeados, empresas prestadoras de serviço e trabalhadores ocasionais.
• Administradores do Salesforce: Para obter percepções sobre como os territórios de serviço e as tabelas de compartilhamento de plataforma são usados para gerenciar requisitos de segurança complexos.

A personalidade do prestador de serviço no escopo determina diretamente a arquitetura de compartilhamento apropriada. Cada categoria tem implicações distintas para como o acesso no nível do registro é estruturado, como o Otimizador percebe a disponibilidade do recurso e como a solução é dimensionada:

• Contratado nomeado: Um recurso externo individual que é tratado de modo similar a um funcionário interno. Um prestador de serviço nomeado requer uma licença de usuário dedicada. O modelo de compartilhamento espelha padrões de acesso do técnico interno, tornando-o a personalidade de prestador de serviço de menor complexidade para suporte.
• Empresa Contratada: Uma entidade de terceiros que gerencia sua própria equipe. Em SFS, as empresas prestadoras de serviço são representadas como Recursos com base em capacidade, em que a organização pai agenda e atribui trabalho à empresa, em vez de a um indivíduo específico.
• Trabalhador ocasional: Um usuário que opera temporariamente em vários territórios. A personalidade mais arquitetonicamente complexa. Relacionamentos temporários de vários territórios significam que os limites de compartilhamento baseados em território são quebrados, portanto, a visibilidade é gerenciada dinamicamente no nível do registro, em vez de por meio de atribuição geográfica estática.

Esses padrões são complexos porque a organização pai e as metas do prestador de serviço costumam estar tecnicamente em conflito.

1. Objetivos divergentes: A organização pai se concentra principalmente na satisfação do cliente e no trabalho/acordo contratado (por exemplo, preferências de recurso, serviço rápido e oportuno e gerenciamento de como o trabalho e as horas são distribuídos entre prestadores de serviço). Os prestadores de serviço, por outro lado, geralmente se concentram em maximizar o trabalho atribuído enquanto minimizam o tempo de deslocamento e o custo operacional.

2. Competição: Diferentemente dos funcionários internos, diferentes empresas prestadoras de serviço costumam ser concorrentes diretos. Embora a organização pai precise de uma visão holística da região (transparência), os prestadores de serviço exigem isolamento estrito das operações uns dos outros (isolamento).

3. Integridade da marca: Para o cliente final, o trabalhador representa sua marca, o que geralmente exige que a matriz veja atualizações de status em tempo real. No entanto, os prestadores de serviço costumam guardar suas operações internas em um sistema fechado, ou “caixa negra”.

4. Visibilidade e segurança: Embora um território de serviço compartilhado geralmente implique visibilidade universal de todos os recursos atribuídos, os ambientes de vários prestadores de serviço exigem um padrão de segurança mais detalhado. Para manter a integridade competitiva e a privacidade dos dados, é essencial impedir que os prestadores de serviço acessem os nomes, agendas ou informações de recursos proprietários uns dos outros.

O design do prestador de serviço no Salesforce Field Service abrange três modelos operacionais distintos, cada um afetando a visibilidade do recurso, a propriedade do despacho e o licenciamento:

1. Alocação de capacidade externa
2. Autoagendamento do parceiro
3. Despacho interno conduzido

Alocação de capacidade externa (capacidade fora da plataforma): O prestador de serviço gerencia sua equipe externamente e fornece uma capacidade definida (por exemplo, 10 horas disponíveis) em vez de agendas individuais de técnico. Essa capacidade é tratada como um grupo de horas ou itens de trabalho para fins de agendamento.

Agendamento automático do parceiro: Os gerentes de prestadores de serviço fazem login no Salesforce por meio de um site da experiência para agendar suas próprias equipes. Eles exigem isolamento estrito de outros parceiros.

Envio interno: Os supervisores internos agendam os técnicos do prestador de serviço diretamente. Os prestadores de serviço usam o aplicativo Field Service Mobile para execução.

Nesse padrão, o Território de serviço serve como o limite de segurança principal. Cada empresa prestadora de serviço é atribuída ao próprio território “filho” exclusivo.

• Redes de parceiros de pequena escala
• Parceiros com regiões geográficas estritamente não sobrepostas
• Situações em que o trabalho do prestador de serviço é fundamentalmente diferente do trabalho de recurso interno, eliminando a concorrência (por exemplo, prestadores de serviço externos tratam apenas de “instalações do tipo A”, enquanto recursos internos tratam de todos os outros tipos de trabalho)

• Configuração simplificada: Usa configuração e automação de Território do usuário padrão.
• Limpar agrupamento de dados: Garante fácil visibilidade de dados e gerenciamento de segurança simplificado por meio de objetos de Território de serviço padrão.

• Eficiência de otimização: O mecanismo não pode avaliar recursos entre limites de território, impedindo o agendamento ideal e o roteamento eficiente.
• Sprawl de território: Criar um número maior de territórios para um número muito baixo de recursos leva a uma sobrecarga de agendamento.
• Desempenho de Gantt: Grandes hierarquias (1K + territórios) podem causar gargalos de desempenho significativos, bem como riscos de atingir os limites da plataforma.

Este guia apresenta uma nova abordagem de solução: Compartilhamento baseado em conta (implementado por meio das regras de compartilhamento baseadas em critérios nativos do Salesforce, o mesmo mecanismo de plataforma usado para conceder acesso a registros com base em valores de campo). O compartilhamento baseado em conta separa a visibilidade da geografia. Os territórios continuam grandes e contínuos, enquanto a visibilidade é gerenciada por meio das tabelas de compartilhamento da plataforma com base em um relacionamento de conta. Em termos práticos, as regras de compartilhamento baseadas em critérios avaliam um campo no registro (como ServiceResource.Company) e compartilham automaticamente esse registro com o grupo adequado. O compartilhamento baseado em critérios é o mecanismo que faz o compartilhamento baseado em conta funcionar sem código personalizado no nível do registro.

• Ecossistemas em grande escala em que uma proporção significativa da força de trabalho consiste em recursos externos
• Áreas urbanas em que vários prestadores de serviço cobrem os mesmos códigos postais
• Cenários em que os recursos internos e externos são capazes de executar o mesmo trabalho (por exemplo, “instalações do tipo A”), mas as regras de negócios ditam uma lógica específica para seleção de recurso (por exemplo, preferência de recurso interno em determinados cenários)

• Utilização máxima e ROI: O mecanismo avalia todo o pool regional, encontrando o recurso “melhor” para cada trabalho
• Escalabilidade: Dá suporte a um grande número de prestadores de serviço/recursos externos sem aumentar as contagens de territórios
• Gestão consolidada: Equipe interna gerencia uma visualização, em vez de centenas de pastas isoladas (territórios filho)

• Esforço de desenvolvimento: Exige automação personalizada (Flow ou Apex) para gerenciar as tabelas de compartilhamento
• Compartilhamento de associação: Exige compartilhamento explícito de registros de Membro do território de serviço (STM)

Para mão de obra externa (dimensão de Alocação de capacidade externa), os arquitetos podem usar Recursos baseados em capacidade para representar o “resumo” da mão de obra de um prestador de serviço.

• Capacidade: Use isso quando o prestador de serviço gerenciar seu próprio envio e roteamento. Seu foco principal é no volume total de trabalho que eles podem realizar, em vez da pessoa específica que está realizando.
• Indivíduo: Use isso quando precisar de visibilidade granular do dia de um técnico. Os recursos baseados em indivíduo permitem que você gerencie a localização exata, a disponibilidade em tempo real e atribuições de trabalho específicas como se fossem equipe interna.

Antes de projetar seu padrão de prestador de serviço do Field Service, use essa árvore de decisão para determinar a arquitetura de compartilhamento adequada.

Árvore de decisão de seleção de padrão de compartilhamento do prestador de serviços

Árvore de decisão para selecionar um padrão de compartilhamento de prestador de serviço no Salesforce Field Service. A partir de se os recursos externos estão em uso, a árvore ramifica por tipo de recurso e exclusividade de trabalho para recomendar compartilhamento baseado em território ou compartilhamento baseado em conta.

O núcleo desse padrão é uma camada de automação que converte o relacionamento de ServiceResource.AccountId ou ServiceResource.Company (Empresa do prestador de serviços) em registros de compartilhamento de plataforma.

Para verificar o acesso adequado para o supervisor e o recurso em serviço em um site da experiência, o acesso precisa ser controlado por meio de:

• Regra de compartilhamento de recurso em serviço: Concede acesso com base em um critério (conta/empresa)
• Regra de compartilhamento de território de serviço: Concede acesso com base em um critério (nome do território/ID)

Ao usar o compartilhamento baseado em conta, certifique-se de considerar a experiência do Field Service Mobile e a visibilidade do registro para os técnicos atribuídos.

• Compartilhamento de recurso atribuído: A funcionalidade SFS padrão concede automaticamente a um recurso atribuído acesso ao Compromisso de serviço e à sua ordem de trabalho pai. Essa configuração fornece ao técnico as informações necessárias para executar o trabalho sem exigir regras de compartilhamento personalizadas adicionais para o trabalho atribuído.
• Riscos de visibilidade: Enquanto o trabalho atribuído é tratado nativamente, tenha cuidado com compromissos não atribuídos ou futuros que não têm associação de Conta ou Território. Se os padrões para toda a organização (OWDs) não forem gerenciados estritamente ou se os conjuntos de compartilhamento forem muito amplos, os compromissos não atribuídos poderão estar visíveis a todos os usuários em um território consolidado.
• Associação conta-território: Certifique-se de que todos os compromissos de serviço estejam explicitamente vinculados a uma conta e território. Essa vinculação permite uma filtragem limpa no aplicativo móvel e verifica se não ocorre vazamento de dados para trabalho não atribuído no pool regional.

• Requisito: 10 prestadores de serviço diferentes fornecem instalação de fibra em Londres.
• Contexto: Na abordagem de compartilhamento baseada em território, Londres seria dividida em 10 territórios sobrepostos. Os supervisores ficariam com dificuldade para ver a disponibilidade nas proximidades, levando a tempos de deslocamento altos.
• Recomendação: Compartilhamento baseado em conta. Implemente um território de serviço unificado “Great London” usando compartilhamento baseado em conta para manter a segurança dos dados granular. O compartilhamento baseado em conta mantém o gerenciamento do prestador de serviço A isolado para seus respectivos recursos, enquanto o Otimizador de SFS mantém a visibilidade interfuncional de todos os técnicos internos e externos. Essa abordagem de agendamento completa facilita uma lógica de roteamento mais eficiente que pode reduzir os deslocamentos em mais de 20% por meio do agendamento completo (estimulação direcional baseada em observações de campo em implantações do cliente do SFS), criando melhorias imediatas na utilização de recursos e maior responsividade ao serviço.

• Requisito: Um fornecedor fornece até 40 “slots” para reparos de caldeira diariamente, mas gerencia o envio do próprio técnico.
• Contexto: Gerenciar 40 registros de recursos individuais aumenta a sobrecarga desnecessária.
• Recomendação: Recurso baseado em capacidade vinculado à conta do fornecedor. Um registro de recurso representa a capacidade diária total do fornecedor, mantendo o Gantt limpo e evitando a necessidade de gerenciar registros de técnicos de prestadores de serviço individuais.

• Requisito: Uma empresa de serviços públicos integra 50 pequenos prestadores de serviço locais durante a temporada de tempestades para realizar reparos de estouro.
• Contexto: Criar e excluir 50 territórios a cada estação é um grande fardo administrativo e afeta negativamente a flexibilidade do mecanismo de agendamento e otimização.
• Recomendação: Compartilhamento baseado em conta. Crie um território geográfico permanente “Sobrecarga”. Quando um prestador de serviço estiver integrado, simplesmente crie sua conta e vincule seus recursos a ela. A camada de automação lida com a visibilidade instantaneamente sem exigir um novo design de hierarquia de territórios.

• Requisito: Para vazamentos de gás de alta prioridade, o técnico mais próximo deve ser despachado, não importa para qual prestador de serviço ele trabalha.
• Contexto: O compartilhamento baseado em território cria lacunas de cobertura em que a tecnologia mais próxima pode estar em um território diferente e, portanto, inacessível à lógica de agendamento.
• Recomendação: Compartilhamento baseado em conta. Ao consolidar fornecedores em um único território grande, o mecanismo realiza uma pesquisa completa com base em deslocamento em todo o conjunto de fornecedores, reduzindo os tempos de resposta para incidentes de segurança críticos.

• Requisito: Um parceiro HVAC especializado tem um direito legal exclusivo de 10 anos para atender uma área remota ou condado rural.
• Contexto: Não há outros prestadores de serviço operando nessa região geográfica, e o parceiro gerencia seu próprio agendamento e despacho totalmente.
• Recomendação: Compartilhamento baseado em território. Nesse cenário, um Território de serviço dedicado é a escolha mais eficiente. Como não há sobreposição geográfica com outros parceiros, o isolamento fornecido pelo limite de território corresponde perfeitamente aos requisitos legais e operacionais sem automação de compartilhamento adicional.

O compartilhamento baseado em conta separa a visibilidade da geografia vinculando o acesso em nível de registro a um identificador de conta/empresa comum compartilhado entre o usuário supervisor e seus registros de Recurso em serviço. O mecanismo de compartilhamento baseado em critérios nativos da plataforma avalia esse campo e concede ou revoga automaticamente o acesso sem alterar a hierarquia de territórios.

Os três componentes arquitetônicos necessários são:

1. Um campo de identificador comum nos objetos Usuário e Recurso em serviço vinculando-os à conta do prestador de serviço.
2. Grupos públicos agregando todos os usuários do Supervisor por empresa do prestador de serviços, portanto, as regras de compartilhamento se aplicam de modo uniforme.
3. Regras de compartilhamento baseadas em critérios que avaliam o identificador e concedem ao grupo público adequado acesso a registros relevantes.

Em vez de usar territórios como limites, use Grupos públicos para agregar supervisores que precisam da mesma visibilidade. Os supervisores veem territórios específicos, ordens de trabalho e compromissos de serviço por meio da associação em grupos públicos baseados em território.

• Criação de grupo: Crie um grupo público para cada empresa prestadora de serviço.
• Atribuição de membro: Adicione os usuários relevantes da Comunidade de parceiros ( supervisores) ao respectivo grupo público do prestador de serviço.

Aproveite regras de compartilhamento baseadas em critérios para conceder ao grupo público acesso a registros específicos.

• Critérios de compartilhamento de recurso em serviço: As regras de compartilhamento de recurso em serviço aplicam a visibilidade do técnico por prestador de serviço combinando o identificador da empresa/conta no registro Recurso em serviço com o Grupo público do prestador de serviço correspondente.
  • Permissões de nível de acesso de leitura/gravação para permitir que os supervisores agendem e atualizem atribuições.
• Critérios de compartilhamento de território de serviço: Use os critérios de compartilhamento de território de serviço para configurar a lógica para acesso restrito ao território. Conceda aos supervisores acesso aos amplos territórios geográficos em que eles estão autorizados a trabalhar. Exemplo:
  • Critérios: ServiceTerritory.Name É Igual a “Atlanta”.
  • Compartilhado com: Grupos públicos de prestadores de serviço relevantes (por exemplo, prestador de serviço A, prestador de serviço B, prestador de serviço C).
  • Nível de acesso: Ler/Gravar

Para obter orientação de implementação detalhada, consulte a documentação oficial do Salesforce:

• Regras de compartilhamento baseadas em critérios
• Grupos públicos
• Acionadores do Apex para gerenciamento de registro de compartilhamento automatizado

Quando implementado corretamente, o compartilhamento baseado em conta oferece:

• Visibilidade unificada: Os supervisores veem todos os recursos relevantes em todo o território sem reatribuição manual de território.
• Acesso dinâmico: Conforme as atribuições de prestadores de serviço mudam, as regras de compartilhamento ajustam automaticamente a visibilidade sem intervenção do administrador.
• Isolamento competitivo: Cada prestador de serviço vê apenas seus próprios recursos, mantendo a privacidade dos dados.
• Arquitetura dimensionável: Novos prestadores de serviço podem ser integrados simplesmente criando uma conta e um grupo público, com regras de compartilhamento que lidam com o restante automaticamente.

Conforme as organizações de serviço de campo mudam de modelos reativos para proativos, sua escolha de padrão arquitetônico define o “teto de inovação” para agilidade operacional de longo prazo.

• Habilitar IA e aprendizado de máquina: O compartilhamento baseado em conta verifica se o mecanismo tem visibilidade de todo o conjunto de recursos para encontrar a melhor correspondência, em vez de ser restrito por silos de dados. Como evita silos de território ineficientes, o Agendamento do agente para Field Service (assistente de agendamento habilitado por IA no Salesforce) fornece padrões de deslocamento mais lógicos e atribuições de técnico sem ser limitado por microrretórios isolados. Essa abordagem maximiza a otimização completa, melhorando diretamente os KPIs de viagem e a prontidão do técnico. O compartilhamento baseado em conta dá suporte ao agendamento conduzido por IA dando ao mecanismo visibilidade de todo o pool de recursos, permitindo a correspondência “verdadeira melhor” em vez de ser restrita por silos de dados artificiais.
• Escalabilidade arquitetônica: O compartilhamento baseado em território costuma encontrar um “mural de desempenho” devido à sua dependência de territórios isolados. Conforme a rede de prestadores de serviço aumenta, a eficácia do mecanismo de agendamento é neutralizada por limites artificiais que o impedem de alcançar a capacidade disponível em territórios adjacentes. Além disso, quando o compartilhamento baseado em território requer um novo território e ajustes manuais para cada parceiro, o compartilhamento baseado em conta simplifica o crescimento. As organizações integram centenas de parceiros prestadores de serviço simplesmente criando registros de Conta e Recurso em serviço associado, deixando a estrutura de território geográfico principal inalterada e com desempenho.

Este guia se concentrou principalmente em implementações líquidas e novas. No entanto, muitas organizações já estão executando o compartilhamento baseado em território em escala e têm um débito significativo da hierarquia de territórios. A migração do compartilhamento baseado em território para o compartilhamento baseado em conta em um ambiente de produção ativo introduz riscos arquitetônicos distintos para avaliar antes de qualquer trabalho de transição começar. Esta seção aborda as três dimensões críticas de uma migração do sistema existente: avaliando o estado atual, determinando a estratégia de transição e gerenciando riscos de migração.

• Avaliando o desvio de território: Antes de qualquer planejamento de migração, quantifique a hierarquia de territórios atual. As principais perguntas de diagnóstico são: Quantos territórios existem apenas para impor o isolamento do prestador de serviço versus limites geográficos genuínos? Qual é a proporção de territórios filho específicos do prestador de serviços para territórios pai operacionais? Algum território é compartilhado entre recursos internos e externos ou é totalmente isolado? Essa auditoria distingue a estrutura geográfica verdadeira do débito de isolamento acumulado. Territórios criados exclusivamente para controle de visibilidade do parceiro são fortes candidatos à eliminação sob compartilhamento baseado em conta. Territórios que codificam uma geografia operacional genuína (zonas de agendamento, regiões de SLA, limites regulatórios) são preservados e não são confundidos com o controle de acesso.
• Viabilidade de transição híbrida: Para organizações em escala, uma transição completa de compartilhamento baseado em território para compartilhamento baseado em conta raramente é recomendada; em vez disso, uma transição híbrida reduz o risco integrando novos prestadores de serviço em compartilhamento baseado em conta enquanto mantém coortes de compartilhamento baseadas em território legadas até a próxima janela de renovação. A abordagem híbrida é arquitetonicamente viável, desde que a automação de compartilhamento baseada em conta esteja estritamente delimitada para o identificador de conta/empresa, permitindo que recursos sem esse ID permaneçam no acesso baseado em território sem interrupção. Trate o estado híbrido como uma arquitetura temporária, não um modelo de operação permanente.
• Principais riscos de migração: As migrações existentes do sistema apresentam três riscos arquitetônicos críticos que exigem uma mitigação proativa. Primeiro, as recriações de tabela de compartilhamento acionadas por novas regras baseadas em critérios são intensivas em recursos; agende cortes durante janelas de baixa atividade para evitar lacunas de visibilidade do supervisor causadas por recálculos de execução longa. Segundo, ordens de trabalho em trânsito correm o risco de perda de visibilidade durante a transição; mantenha associações de território paralelas ou preencha previamente o compartilhamento para registros ativos até que sejam fechados. Por fim, ajuste as políticas de otimização e agendamento à medida que a remoção de territórios filho turna o pool de recursos. Teste, realize execuções de linha de base e capture métricas para confirmar que os limites geográficos permanecem efetivos e que os ganhos de eficiência são realmente realizados.

Dada a escalabilidade e otimização do ROI, recomendamos a abordagem de compartilhamento baseada em conta para organizações do Field Service de alto crescimento que gerenciam vários prestadores de serviço concorrentes em regiões geográficas sobrepostas. Embora o compartilhamento baseado em território ofereça uma configuração mais simples e declarativa, o compartilhamento baseado em conta permite que as organizações aproveitem todo o potencial do mecanismo de Agendamento e otimização. Ao desacoplar a visibilidade da geografia, as organizações podem manter uma configuração de território que seja dimensionada com o negócio e proporcione estes resultados:

• Eficiência operacional: Agregar recursos em um único pool permite que o mecanismo encontre o verdadeiro técnico “melhor” para cada trabalho, reduzindo o tempo de deslocamento e os custos operacionais.
• Níveis de serviço aprimorados: O agendamento abrangente reduz os atrasos de serviço identificando qual recurso contratado está mais disponível/mais próximo, acelerando o tempo de atendimento e melhorando diretamente a satisfação do cliente.
• Produtividade do supervisor: A equipe interna pode gerenciar uma visualização regional consolidada em vez de alternar entre territórios “filhos” isolados.

O compartilhamento baseado em território é mais adequado para operações de prestador de serviço altamente isoladas com territórios/áreas geográficos estritamente não sobrepostos.

Escolher um padrão arquitetônico é a primeira etapa. A execução bem-sucedida requer alinhamento contínuo com as melhores práticas do Salesforce e as funcionalidades da plataforma.

Próximas etapas:

• Audite sua paisagem: Revise sua hierarquia de territórios atual e a utilização de recursos externos. Identifique quaisquer “territórios de prestadores de serviço” criados apenas para o isolamento do parceiro. Se sua hierarquia estiver confusa com esses silos, avalie os benefícios e o esforço da migração para compartilhamento baseado em conta.
• Validação de sandbox: Crie um protótipo do padrão de compartilhamento baseado em conta em um sandbox completo ou parcial e teste a visibilidade de ponta a ponta de todos os ângulos:
  • Usuários internos (administradores, supervisores e técnicos internos): Confirme o acesso adequado. Alguns usuários internos devem ter acesso geral.
  • O usuário Gerente do prestador de serviços: Verifique se o escopo da visibilidade é estritamente para a própria equipe.
  • Tecnicos do contratado (recursos externos): Confirme se o acesso está adequadamente restrito apenas ao trabalho atribuído.
  • Um rigoroso teste da visibilidade organizacional é essencial para evitar vazamentos de dados entre parceiros concorrentes.
• Benchmarking de desempenho e avaliação de ROI: Aproveite o Hub de otimização e os Painéis de Inteligência do Field Service para obter percepções sobre a redução do tempo de deslocamento, a utilização de recursos e as melhorias no tempo de resposta, fornecendo os dados necessários para justificar a mudança arquitetônica para as partes interessadas. Essa análise de antes e depois também pode ser repetida em produção quando a transição estiver em andamento.
• Fase piloto: Quando o teste de sandbox estiver concluído, inicie um piloto em fases em um ou dois territórios em que os recursos internos e externos se sobrepõem geograficamente, idealmente, espelhando aqueles testados no sandbox. Valide a lógica de compartilhamento com um grupo de usuários pequeno e controlado antes que uma distribuição mais ampla seja recomendada antes da implantação completa.
• Escalabilidade da Solução: Confirme se qualquer automação personalizada (Flow ou Apex) necessária para gerenciar tabelas de compartilhamento e registros de membro do território de serviço (STM) foi projetada para sustentabilidade a longo prazo. A solução deve usar padrões de design modulares (por exemplo, Estruturas do acionador) e garantir que a lógica seja criada para lidar com atribuições de recursos de alto volume de modo contínuo dentro dos limites do controlador de plataforma.

Todos os padrões neste guia exigem validação em um ambiente de sandbox antes da implantação da produção. O comportamento de implementação pode variar de acordo com a configuração da organização, o volume de dados e as regras de negócios.

Documentação da plataforma (Salesforce Official):

• Guia do desenvolvedor do Field Service: Referência principal para objetos de dados do Field Service, APIs e personalização
• Referência de objeto ServiceResource: Documentação da API para o objeto SR
• Referência de objeto ServiceTerritoryMember: Documentação da API para o objeto STM
• Regras de compartilhamento baseadas em critérios: Guia de segurança oficial para implementar as regras de compartilhamento subjacentes ao compartilhamento baseado em conta
• Guia do desenvolvedor de acionadores do Apex: Referência para a camada de automação personalizada exigida pelo compartilhamento baseado em conta
• Práticas recomendadas do acionador do Apex: Padrões recomendados do Salesforce para desenvolvimento de acionador escalonável

Artigos de ajuda do Salesforce

• Orientações para a configuração de prestadores de serviço de campo: Orientação para configurar recursos do prestador de serviço no Salesforce Field Service
• Definir recursos baseados em capacidade: Documentação oficial para configurar recursos com base em capacidade referenciada no artigo
• Como o mecanismo de otimização do Field Service funciona? Referência de Otimização do Field Service. Orientação para execuções de otimização, também relevantes para as vantagens de compartilhamento baseadas em conta e o ROI referenciados no artigo.
• Configurar o Hub de otimização: Guia de configuração para o Hub de otimização referenciado na seção Próximas etapas
• Visão geral do Experience Cloud: Configuração da Comunidade de parceiros para compartilhamento baseado em conta (Gerenciamento na plataforma)

Salesforce Trailhead/Aprendizagem

• Princípios do Field Service: Módulo básico que abrange territórios, recursos e horários de operação
• Agendamento do Field Service: Conceitos de agendamento que sustentam a discussão de otimização neste guia
• Otimização do Field Service: Aprofunde-se na configuração de otimização e nas políticas de agendamento
• Salesforce Security e Quem vê o quê: Regras de compartilhamento e fundamentos de segurança de dados
• Criar um portal do parceiro com o Experience Cloud: Guia prático para a configuração do parceiro do Experience Cloud referenciada no artigo

Indústria e contexto estratégico

• Salesforce State of Service Report, 7a Edição: A edição mais recente, que pesquisa 6.500 profissionais de serviço em todo o mundo, com percepções dedicadas sobre o Field Service, a adoção de IA e tendências de produtividade de técnicos diretamente relevantes para os argumentos de ROI neste artigo.
• Agentforce for Field Service: A plataforma de serviço de campo desenvolvida com IA da Salesforce, diretamente relevante para a IA e uma discussão de futuro na Seção 13. O pool de recursos unificado de compartilhamento baseado em conta está maximizando a inteligência de agendamento da Agentforce.
• Guia de mercado da Gartner para gerenciamento de serviço de campo: A análise mais recente do Gartner do panorama de mercado do FSM (assinatura do Gartner necessária).

Mor Epstein
Senior Success Architect, Salesforce Field Service

Com uma experiência em Engenharia Industrial da Georgia Tech e um MBA, Mor é um consultor confiável com um histórico comprovado de desbloqueio e aceleração de implementações do Field Service críticas para a missão. Sua experiência global voltada para o cliente, combinada com a solução prática de problemas orientada por dados, a posicionam como um recurso adequado para organizações de serviço de campo em todo o mundo. Mor se destaca em orientar os clientes pela jornada de Agendamento e otimização, ajudando as organizações a aproveitar todo o potencial do agendamento inteligente para alcançar ganhos mensuráveis na eficiência e na entrega de serviços.

Lee Ephrati
Senior Success Architect, Salesforce Field Service

Lee é um arquiteto técnico altamente experiente com mais de 10 anos de experiência em entrega e consultoria do Salesforce, especializado em arquiteturas do Field Service e design de soluções móveis. Lee se concentra em alinhar estruturas organizacionais complexas com a plataforma SFS nativa e aplicativo móvel para gerar o máximo de ROI operacional para empresas globais. Com uma mentalidade que prioriza o cliente e um Knowledge abrangente da plataforma, Lee traz uma abordagem consultiva que fornece consistentemente valor duradouro para clientes do Salesforce em todo o mundo.