👤 Para quem cuida do RH e acabou de clonar o HRSD
🔐 Disponível para todos os planos (os agentes de IA exigem o Pipefy AI habilitado)
🎯 Para quem clonou o HRSD e precisa deixá-lo pronto para operar
Um pedido de férias chega no e-mail, um atestado no WhatsApp, uma dúvida de holerite em outra thread, e o time de RH passa o dia procurando anexo, conferindo saldo na planilha e respondendo a mesma pergunta pela décima vez. Cada solicitação segue por um caminho diferente, e quando o volume cresce, o que era atendimento vira garimpo.
O HRSD já chega com essa operação montada: um portal único onde o colaborador abre e acompanha suas demandas, cinco fluxos de RH prontos e agentes de IA que fazem a triagem antes de a demanda chegar na mão de alguém. Ao terminar este artigo, você vai ter o portal no ar, os cinco processos configurados para a sua empresa e um card de teste rodando em cada um, da abertura até a resolução.
📖 O que você vai entender aqui:
O que você tem nas mãos agora
Você não precisa construir esse fluxo do zero, apenas adapta o que já veio para a realidade da sua empresa.
Ao clonar, você recebe cinco processos principais, cada um cobrindo uma frente do dia a dia do RH: Gestão de Benefícios, Gestão de Férias, Gestão de Holerites, Gestão de Atestados e Reembolsos de Despesas. Junto vem um pipe auxiliar, o [AUX] Despesas, que sustenta a análise individual de cada comprovante dentro do fluxo de reembolso.
Na frente do colaborador ficam dois portais. O Portal do (a) Colaborador (a) é onde a pessoa tira dúvidas sobre férias, remuneração e benefícios, envia atestado, confere saldo, solicita férias e acompanha o andamento de tudo em um só lugar. O Portal do (a) Gestor (a) é onde a liderança envia solicitações, consulta políticas, acompanha pedidos e responde pendências.
O que muda o seu dia a dia é que dentro desses processos já existem agentes de IA embutidos, cada um plugado na fase certa: o agente de férias interpreta o pedido e valida saldo e regras logo na triagem, o agente de atestados lê o documento anexado e extrai os dados antes da análise humana, o de benefícios faz a pré-análise da solicitação, o de holerites organiza o demonstrativo e, no reembolso, um agente tria cada comprovante e outro consolida a solicitação inteira.
Cada pipe clonado nasce com o nome terminando em "(Copy 1)". Renomeie os cinco processos antes de compartilhar com o time, seguindo o padrão de nomenclatura da sua empresa, para não confundir com o template original.
As integrações com sistemas externos (folha de pagamento, controle de ponto, ERP e afins) não vêm clonadas no template. Os pipes, os portais, os databases e os agentes você recebe prontos, mas cada conexão com um sistema de fora precisa ser construída de acordo com o seu ambiente e as credenciais da sua empresa.
Conecte o cadastro de colaboradores antes de tudo
Antes de configurar qualquer processo, resolva a peça que todos eles usam: o cadastro de colaboradores. Vários agentes não leem o saldo de férias, a data de admissão ou o nome direto do card. Eles buscam esse dado no cadastro conectado pelo campo Dados Solicitante, um campo do tipo Database Connection que aponta para a sua base de pessoas.
Aponte esse campo para o database de colaboradores da sua empresa e confira que o saldo de férias e a data de admissão estão preenchidos lá. É esse cadastro que alimenta a análise do agente de férias e a conferência de identidade do agente de atestados.
Como saber se ficou certo: abra um card de teste e verifique se o campo Dados Solicitante traz os dados da pessoa. Se o agente de férias, ao rodar, disser que o saldo está ausente mesmo com a pessoa cadastrada, o campo ainda aponta para a base do template, não para a sua, ou o saldo não está preenchido no cadastro.
Sem o cadastro conectado, o agente conclui que o dado não existe e devolve uma análise incompleta. Essa é a configuração que sustenta todo o resto, então faça antes de qualquer outra.
Configure para o seu processo
A operação já vem desenhada. O seu trabalho agora é apontar cada processo para a realidade da sua empresa: suas políticas, seus prazos e as regras que cada agente deve seguir. Comece pelo processo de maior volume na sua operação e siga para os demais.
Gestão de Férias
O pedido de férias entra pelo portal e cai na fase Triagem, onde o agente de IA lê a solicitação, consulta o saldo no cadastro conectado e avalia o pedido contra as regras de fracionamento, antecedência e abono. Ele registra a recomendação, mas não aprova nada: quando há saldo, o card segue para a Aprovação do Gestor e depois para a Validação do RH.
O ajuste principal aqui é o conhecimento do agente. Anexe as políticas de férias da sua empresa (a política corporativa, o manual operacional, o calendário e o FAQ) no Knowledge do agente. É de lá que ele tira saldo mínimo, prazos e o que conta como exceção. Sem esses documentos, ele não tem contra o que validar.
Como saber se ficou certo: crie um card de teste com uma pessoa que tenha saldo cadastrado. Se o agente devolve a recomendação e o card avança para a Aprovação do Gestor, a triagem está lendo as fontes certas. Se ele trava dizendo que falta informação, confira se o cadastro está conectado e se as políticas estão no Knowledge.
Gestão de Atestados
O atestado chega na fase Recebimento do Atestado, onde o agente de IA lê o arquivo anexado, extrai os dados (tipo de documento, datas, duração, profissional) e compara com o formulário e com o cadastro do colaborador. Em seguida o card segue para a Validação e Aprovação, onde uma pessoa do RH decide. Se houver pendência, a automação leva o card para a Revisão de Pendências e aciona o colaborador.
O agente de atestados classifica e orienta, mas há um limite que é da própria configuração dele e você deve manter: ele não aprova, não recusa nem interpreta diagnóstico. Ele encaminha para a fase certa e sinaliza quando o caso precisa do Departamento Pessoal ou da Saúde Ocupacional. Anexe a sua política de atestados e ausências no Knowledge para que os critérios de encaminhamento sejam os da sua empresa.
Como saber se ficou certo: suba um atestado de teste em um card. Se o agente preenche os campos de dados extraídos e o card vai para a Validação e Aprovação, a leitura está funcionando. Se os campos ficam vazios, confira se o arquivo foi anexado no campo que o agente lê.
Sem documento anexado, o agente não tem o que ler. Deixe claro no portal que o envio do arquivo é obrigatório para a abertura da solicitação.
Gestão de Benefícios
A solicitação de benefício entra na fase Solicitação Recebida e segue para Em Análise, onde o responsável avalia e registra o status. O agente de benefícios faz uma pré-análise da solicitação antes da revisão humana, lendo o tipo de pedido, os campos preenchidos e os documentos anexados.
O ajuste é o mesmo padrão dos demais: anexe as suas tabelas, normas e manuais de benefícios no Knowledge do agente, e confira que o campo de responsável pela análise aponta para o time certo da sua empresa.
Como saber se ficou certo: abra uma solicitação de teste. Se ela chega em Em Análise com a pré-análise do agente preenchida e um responsável atribuído, o fluxo está pronto.
Gestão de Holerites
Esse processo organiza a consulta e a guarda dos demonstrativos de pagamento. Ele tem duas fases por tempo de vida do documento, Holerites -3 meses e Holerites +3 meses, e uma automação move o card de uma para a outra quando o holerite completa três meses. O agente de leitura de holerite organiza o descritivo do demonstrativo para consulta.
Aqui o trabalho é menos de conhecimento e mais de integração: é o seu sistema de folha que alimenta os holerites. Confira o caminho pelo qual o demonstrativo chega ao card e lembre que essa conexão externa precisa ser construída para o seu ambiente.
Como saber se ficou certo: registre um holerite de teste e confira se o descritivo é lido e se, ao passar o tempo configurado, o card migra para a fase de +3 meses.
Reembolsos de Despesas
Este é o processo com a arquitetura mais rica, e vale entender antes de configurar. Ele trabalha em dois níveis. O pipe principal, Reembolsos de Despesas, é a solicitação inteira. O pipe auxiliar, [AUX] Despesas, recebe uma despesa por card. Quando o colaborador registra uma solicitação, cada despesa vira um card no auxiliar.
No auxiliar, o agente de triagem lê cada comprovante individualmente, extrai valor, data, estabelecimento e o identificador do documento, compara com o lançamento e classifica a despesa. No pipe principal, um segundo agente, o consolidador, junta o resultado de todas as despesas e encaminha a solicitação para a Aprovação do Gerente, para o processamento ou de volta para correção. A divisão é proposital: o agente de triagem analisa, o consolidador só agrega, e a decisão final de aprovar continua com o gerente e o financeiro.
No Knowledge dos dois agentes vai a mesma política de reembolso da sua empresa. É ela que define limites, categorias aceitas e o que exige revisão financeira.
Como saber se ficou certo: registre uma solicitação de teste com uma despesa. Se um card aparece no [AUX] Despesas, é triado pelo agente, e a solicitação no pipe principal recebe a consolidação e avança para a Aprovação do Gerente, a esteira dos dois níveis está ligada corretamente.
A verificação de duplicidade de comprovantes não é feita pela IA, e sim por uma integração externa. Como toda integração, ela não vem clonada e precisa ser construída no seu ambiente. Enquanto ela não existir, trate as despesas aptas por revisão manual.
Deixe os agentes de IA precisos no seu contexto
Os agentes já vêm escritos e testados. O que faz um agente errar depois do clone quase nunca é o texto dele, e sim como ele está ligado ao seu pipe. Quatro pontos resolvem a maioria dos casos.
Primeiro, o conhecimento. Todo agente decide com base nos documentos anexados no Knowledge dele. Troque os documentos do template pelas políticas da sua empresa e mantenha uma única fonte por regra, para não haver duas versões da mesma política divergindo.
Segundo, o campo real. O agente aponta para os campos do card por apelidos, e esses apelidos precisam corresponder aos campos que existem no seu pipe. Quando um agente diz que um dado está ausente mesmo com o campo preenchido, quase sempre ele está procurando pelo nome errado. Confira que os campos citados na configuração existem de fato, com o rótulo certo.
Terceiro, quem decide se o caso é do agente. Cada comportamento é acionado por um gatilho e uma condição configurados no Pipefy, por exemplo o tipo de solicitação escolhido pelo colaborador. Quem decide qual comportamento roda é o Pipefy, pela condição, nunca a IA julgando sozinha se o caso é dela. É isso que evita dois agentes agirem no mesmo card ao mesmo tempo.
Quarto, e o mais importante de todos: o agente recomenda, a pessoa decide. Nenhum agente do HRSD aprova, recusa ou valida por conta própria. Ele entrega a análise organizada e encaminha; a decisão final continua com o RH, o gestor ou o financeiro. Mantenha isso ao adaptar qualquer agente.
-
Saiba mais: Como criar seu primeiro AI Agent: passo a passo
As automações que já vêm ligadas
O HRSD chega com as automações da esteira prontas. Elas são o que faz o card andar sozinho de uma fase para a outra e o que aciona os agentes no momento certo. Antes de operar, conheça as principais para não desligar nenhuma por engano.
- Em Gestão de Férias: quando o colaborador tem saldo, o card move para a Aprovação do Gestor; aprovado pelo gestor, vai para a Validação do RH; aprovado pelo RH, segue para a Comunicação e Planejamento; negado pelo gestor ou pelo RH, vai para as Solicitações Recusadas. O agente validador de saldo também é acionado por automação nessa esteira.
- Em Gestão de Atestados: quando o campo do atestado válido é atualizado, o card move para a Validação e Aprovação; havendo pendência, move para a Revisão de Pendências e dispara o e-mail ao colaborador. O agente de leitura do atestado roda por automação no recebimento.
- Em Gestão de Holerites: quando o holerite completa três meses, o card migra para a fase de +3 meses, e o agente de leitura é acionado quando o demonstrativo é gerado.
- Em Reembolsos de Despesas: as automações movem a solicitação entre triagem, aprovação do gerente, processamento e rejeição, e disparam os e-mails de retorno ao colaborador em cada desfecho.
Se precisar ajustar uma dessas automações, edite em vez de recriar. Recriar do zero é o caminho mais comum para quebrar a esteira, porque uma automação nova pode não apontar para a mesma fase ou campo que a original.
Coloque para rodar
Antes de abrir o portal para a empresa, rode um card de teste em cada processo e acompanhe o caminho inteiro. Em cada um, verifique quatro coisas: se o agente preenche os campos que deveria ao entrar na fase, se a automação move o card para a fase certa, se o responsável é atribuído e se o portal reflete o andamento para quem abriu a solicitação.
Priorize nos testes os casos de fronteira, aqueles bem no limite da política, como um pedido de férias sem saldo suficiente ou um atestado sem arquivo anexado. É neles que se descobre se o agente registra a lacuna em vez de inventar o dado. Leia também os logs do agente, e não só o resultado no card: o log mostra o raciocínio e revela quando ele buscou um campo pelo nome errado.
Membros, acesso e higiene do template
O HRSD lida com dado sensível em quase todos os processos: atestado médico, holerite, salário, reembolso. Antes de adicionar o time, revise a privacidade de cada pipe e garanta que só as pessoas certas veem cada processo. Deixe os pipes privados e adicione apenas o time responsável por cada frente de atendimento.
Confira também se ficou algum resíduo de teste no template, como um endereço de e-mail fixo no destinatário de uma automação ou um dado de exemplo em um card. Remova antes de operar, para que a primeira solicitação real não dispare um aviso para o lugar errado.
- Cadastro de colaboradores conectado no campo Dados Solicitante, com saldo e admissão preenchidos
- Políticas de cada processo anexadas no Knowledge dos agentes correspondentes
- Cinco pipes renomeados, sem o sufixo "(Copy 1)"
- Um card de teste rodado em cada processo, com o agente preenchendo os campos ao mudar de fase
- Automações da esteira conferidas e nenhuma desligada por engano
- Pipes privados, com acesso restrito ao time de cada processo
- Resíduos de teste removidos e integrações externas mapeadas para o seu ambiente
