Centro de serviços compartilhados: TI, RH, financeiro e compras atendendo a rede, cada torre com fila e prazo próprios

É o modelo em que as áreas de apoio deixam de existir repetidas em cada unidade e passam a atender todas a partir de uma estrutura só. TI, RH, financeiro, compras, jurídico e operações viram prestadores internos, com serviço definido, prazo acordado e volume medido. O nome aparece também como central de serviços compartilhados e pela sigla CSC. Na SULTS, cada uma dessas áreas tem seu próprio catálogo de serviços com assuntos, formulários e SLAs específicos.

Na prática, seis: TI, RH, financeiro, compras, jurídico e operações. Redes grandes acrescentam marketing, engenharia ou logística, e a lista é decisão da empresa, não regra do modelo. Uma área entra quando já tem demanda repetida das unidades e alguém que responda por ela. Na SULTS, cada torre é um departamento do catálogo, com os assuntos, os formulários e os prazos dela.

Torre é como o CSC chama cada área de serviço, com equipe, serviços publicados e prazo próprios. Para a unidade, a torre não aparece como organograma: ela vê um menu de assuntos e escolhe o que precisa. O catálogo da SULTS funciona como esse menu guiado, em que o solicitante não precisa saber para quem enviar o chamado, basta escolher o assunto e o sistema direciona.

O CSC é o modelo organizacional: quais áreas atendem a rede, com que serviço e com que prazo. A service desk é a ferramenta que opera esse modelo, com catálogo, fila e relógio. Quem procura software para centro de serviços compartilhados está procurando a ferramenta de um modelo que já decidiu adotar. Na SULTS, a mecânica está na service desk e o modelo é o que esta página descreve.

Três coisas. O pedido deixa de ser favor e passa a ter prazo publicado. A fila deixa de ser a caixa de entrada de uma pessoa e passa a ser da torre, com cobertura quando alguém sai de férias. E o resultado deixa de ser percepção e passa a ser número por unidade. A divisão entre o que fica na matriz e o que fica na unidade está no guia de gestão de filiais, e na SULTS ela fica registrada.

O assunto escolhido decide o dono do pedido. Em uma admissão, o assunto de RH abre o processo e o acesso a sistema entra como um segundo pedido na torre de TI, cada um com o prazo dele. Se o pedido nasceu na torre errada, o atendente transfere e a SULTS registra quem transferiu, para quem e quando; a inclusão de apoio adiciona observadores que interagem sem assumir a titularidade.

Cada assunto de cada torre tem o próprio prazo, porque um acordo único faria o pedido simples esperar o prazo do complexo. Uma rede pode acordar, como referência, acesso a sistema em 4 horas e reembolso em 2 dias úteis, e cada torre discute a lista dela. O caminho é medir no painel da SULTS o tempo real que cada assunto leva hoje e prometer a partir desse histórico.

O próprio catálogo é o acordo: ele lista o que cada torre atende e cada assunto carrega o prazo que aquela torre se compromete a cumprir. Mudança de catálogo ou de prazo vai por Comunicados, com relatório de leitura de quem leu e quem não leu. Não existe aceite formal do acordo assinado dentro da SULTS: o acordo é a configuração do prazo e a divulgação dela.

Sim, sem precisar ligar para a matriz. Solicitantes e equipes sabem exatamente em que pé está cada demanda, sem precisar cobrar atualizações, e cada interação fica no histórico com data e hora. O gerente da unidade abre e acompanha pelo app nativo para Android e iOS da SULTS, o mesmo em que executa o checklist do dia, então não há um segundo acesso para decorar.

Por dois caminhos que se completam. O primeiro é a nota do atendimento: ao ser resolvido o chamado, o solicitante dá nota de 1 a 5 estrelas e comentário, consolidados por atendente, departamento e período. O segundo é o NES da SULTS, em que o consultor registra o sentimento da unidade em relação a cada área a cada visita, com peso por área no score. Uma campanha de NPS pode ir para quem abriu chamado nos últimos 90 dias.

O custo é conta da rede, não da ferramenta. O que entra no custo de cada torre e como ele é distribuído entre as unidades é critério da empresa, calculado fora da plataforma. O que a SULTS entrega é a base: volume por unidade, por assunto e por departamento, tempo médio de primeira resposta e de solução e taxa de cumprimento de SLA, exportáveis em Excel/CSV. A plataforma não calcula custo por chamado nem faz rateio.

Quatro dão o retrato de uma unidade: quantos pedidos ela abre, em quais assuntos, quanto tempo cada torre levou para atendê-la e que nota ela deu. Na SULTS isso sai do ranking de unidades que mais abrem chamados, dos assuntos mais frequentes, dos tempos médios e da taxa de cumprimento de SLA, com filtro por localidade. Unidade muito acima da média costuma indicar treinamento ou equipamento, não má vontade.

Pelo caminho inverso ao do pedido. A matriz cria o chamado exigindo ação da unidade, com responsável e prazo, e acompanha no mesmo painel. Quando a cobrança é da rede inteira, a SULTS dispara um chamado para 50, 100 ou todas as unidades, e cada uma recebe uma cópia com prazo e histórico próprios, o que dispensa a planilha de controle paralela.

Só quem a empresa autorizar. Os três níveis de permissão limitam o atendente aos chamados em que é responsável ou aos do próprio departamento, e o módulo de Segurança da SULTS leva o controle a módulo, menu, tela e registro, com autenticação de dois fatores e histórico de login. A discussão do caso fica em mensagens internas invisíveis ao solicitante. Não há SSO nem login por diretório corporativo.

Pode, e é o arranjo comum em rede grande: o mesmo catálogo serve loja própria, filial, clínica, restaurante e unidade franqueada, com os assuntos que cabem a cada tipo. O que muda é quem vê o quê, e as visões estruturadas por Rede, Unidade e Regional da SULTS resolvem isso. A unidade vê os pedidos dela; o regional vê a região dele; a diretoria vê a rede.

O alerta chega antes: notificação automática por e-mail e push para o atendente e para quem acompanha, com tempo de agir. A decisão é de quem coordena a torre, que pode reforçar o atendimento ou passar o chamado para outra pessoa como transferência, que fica registrada no histórico. Na SULTS o sistema não reatribui sozinho, e o estouro, quando acontece, fica registrado e entra na taxa de cumprimento.

Pode, e é assim que o combinado no atendimento não morre no encerramento. Na SULTS, tarefas de acompanhamento são criadas diretamente do chamado, demandas complexas viram projetos com cronograma Gantt e chamados recorrentes geram treinamentos na Universidade Corporativa. O ganho prático é que o que foi prometido passa a ter responsável e prazo, em vez de ficar na última mensagem da conversa.

Pela API. A SULTS tem API pública documentada em developers.sults.com.br, e os tokens são geridos pelo módulo de Segurança, que mostra em tempo real se as integrações estão funcionando. Não há conector pronto de ERP, de folha de pagamento nem de sistema financeiro: a ligação é construída pelo time de tecnologia da empresa a partir da documentação.

Não. Não há base de conhecimento, portal de artigos nem atendimento automático respondendo no lugar da torre. A dúvida administrativa que se repete, como regra de reembolso ou de férias, é tratada de outro jeito na SULTS: o catálogo guia o solicitante até o assunto certo, o formulário dinâmico já pede as informações necessárias, o comunicado antecipa a mudança de regra e o treinamento fecha a lacuna.

Pedindo uma demonstração. Vale levar duas torres de verdade, com os assuntos e os prazos que a empresa quer acordar, e ver o catálogo das duas montado na tela. A cobrança da SULTS é por unidade ativa, com usuários ilimitados por unidade, então não existe custo por atendente; os módulos de cada plano estão em planos.