Documentação de Atendimento – Cliente Governança BR

2. Arquitetura do Fluxo

O fluxo do cliente Governança BR é estruturado em etapas sequenciais, responsáveis pela identificação do cliente, definição da categorização do atendimento, abertura do chamado no SIGA e posterior tratamento e encerramento da solicitação.

2.1. Autenticação e preparação do fluxo

O fluxo inicia com uma etapa de autenticação utilizada pelas integrações posteriores do processo.

Essa autenticação é necessária para operações como:

• abertura e atualização de chamados 
• envio de anexos 
• atualização de histórico 
• atualização de responsável 

2.2. Identificação do cliente

Após a autenticação, o cliente realiza sua identificação utilizando:

• CPF 

• CNPJ 

Com os dados informados, o sistema executa consultas e validações via script para:

• Localizar cadastro do cliente 
• Identificar contratos vinculados 
• Recuperar informações necessárias para as próximas integrações 

2.3. Validações iniciais

Nesta etapa são realizadas validações adicionais utilizadas para direcionamento correto do fluxo.

Entre elas:

• identificação de cliente
• coleta de informações auxiliares sobre o cadastro do cliente

 
Comportamento da validação

• Cliente identificado → segue fluxo principal (PassouPelaValidaçãoDeCliente)
• Cliente não identificado → recebe orientação para atualização cadastral e o fluxo é encerrado

2.4. Preparação de dados do atendimento

Após a identificação do cliente, o fluxo executa etapas responsáveis pela preparação dos dados utilizados ao longo do atendimento.

Nessa etapa:

• o cliente seleciona o contrato desejado para atendimento 
• o sistema registra informações necessárias para utilização nas integrações e validações posteriores 

Entre os dados preparados estão:

• contrato selecionado pelo cliente 
• ID do contato 
• ID do cliente 
• identificadores utilizados para consulta de pesquisa anterior 

2.5. Validação de cliente interno

O fluxo executa uma validação para identificar se o cliente pertence à própria estrutura interna da Governança BR.

Comportamento da validação

• Cliente interno → direcionado para fluxo específico 
• Cliente externo → segue fluxo padrão pela âncora NãoEClienteInterno

Em seguida, são coletadas informações auxiliares do cadastro do cliente, como:

• ID da localidade 

Para essa validação, o fluxo utiliza RPAs responsáveis pelas consultas e scripts que identificam se existe pesquisa pendente para o cliente.

Comportamento

• o cliente pode responder ou ignorar a pesquisa 
• responder não é obrigatório 
• enquanto existir pesquisa pendente, ela continuará sendo apresentada em novos atendimentos 

As respostas são registradas individualmente via integração.

2.7. Validação de resposta da última pesquisa

Após identificar a existência de pesquisa pendente, o fluxo executa uma condição responsável por validar se o cliente já respondeu a última pesquisa registrada.

Comportamento da validação

• Se a pesquisa já tiver sido respondida: 
  • o fluxo direciona para a âncora ContinuarAtendimento
• Caso contrário: 
  • o cliente recebe a opção de responder ou ignorar a pesquisa antes de continuar o atendimento 

Quando o cliente opta por responder:

• as perguntas são apresentadas sequencialmente 
• cada resposta é registrada individualmente via RPA/integração 
• após a última resposta, o fluxo retorna ao atendimento normalmente 

Caso o cliente opte por não responder, o atendimento também segue normalmente.

2.8. Navegação por áreas e categorização

Após as validações iniciais, o cliente navega pela estrutura de atendimento:

• Área 
• Subárea 
• Categoria 

Cada caminho percorrido possui relação direta com:

• equipe responsável 
• rastreabilidade do atendimento 
• categorização do chamado no SIGA 

Exemplo:

Pessoal → GP → Cálculos → Tenho uma dúvida

A composição considera: área, subárea, categoria e descrição informada pelo cliente.

Esses dados são utilizados tanto na estrutura quanto no título do chamado criado no SIGA.

Importante: todas essas opções do menu levam para a Âncora Abertura de chamado.

2.9. Definição do código da categoria

A abertura do chamado no SIGA depende diretamente do código da categoria selecionada.

O sistema SIGA utiliza:

• código da categoria 
• e não apenas o nome textual 

Por esse motivo, cada caminho do fluxo possui um código associado utilizado na integração de abertura do chamado.

 
2.10. Exceção: Consulta de chamados

A etapa de consulta de chamados segue um comportamento diferente do fluxo principal.

Nessa opção, o cliente pode:

• consultar chamados recentes 
• realizar busca manual de chamados 

Essa etapa não realiza abertura de novo chamado.

2.11. Abertura do chamado

Após a definição da categoria e compilação das informações do atendimento, o fluxo direciona o cliente para a âncora AberturaDeChamado.

Nessa etapa:

• o sistema exibe uma mensagem informando que o chamado está sendo registrado 
• é executado o RPA responsável pela abertura do chamado no SIGA 
• scripts realizam validações para identificar se a abertura foi concluída com sucesso 
• o número do chamado é capturado para utilização nas próximas etapas 
• após a abertura, o fluxo executa o RPA responsável pela atualização de anexos do chamado 

2.12. Validação de abertura do chamado

Após a tentativa de abertura, o fluxo executa uma condição para verificar se o chamado foi criado corretamente no SIGA.

Chamado aberto com sucesso

Quando a abertura é concluída com sucesso:

• o cliente recebe a confirmação contendo o número do chamado 
• o fluxo apresenta o menu Falar com atendente

Fluxo do menu “Falar com atendente”

Cliente escolhe “Sim”

Quando o cliente opta por falar com um atendente:

• o fluxo executa o RPA responsável pela atualização do status do chamado para EM ATENDIMENTO
• após a atualização do status, o atendimento é direcionado para a equipe correspondente 

Importante: o direcionamento para equipe humana depende da atualização prévia do status do chamado

Cliente escolhe “Não”

Quando o cliente opta por não falar com um atendente:

• o fluxo apresenta o menu Deseja algo mais? 

Comportamento:

• Sim → retorna ao início do fluxo 
• Não → finaliza o atendimento 

Para continuidade completa do fluxo operacional, incluindo resolução e encerramento do chamado, é necessário que o cliente passe pelo atendimento humano

Independentemente da equipe selecionada, os atendimentos seguem posteriormente para a âncora NotaDeAtendimento.

Falha na abertura do chamado

Caso o chamado não seja aberto corretamente:

• o sistema informa ao cliente que ocorreu um problema na abertura 

• o atendimento é direcionado automaticamente para uma equipe humana responsável pela categoria selecionada anteriormente 

Esse comportamento funciona como contingência para falhas de integração ou inconsistências durante a abertura do chamado.

2.13. Nota de atendimento e validação de resolução

Após o atendimento humano, o fluxo direciona o atendimento para a âncora Nota De Atendimento - SIGA.

Nessa etapa:

• o sistema consulta a tabulação registrada pelo atendenteutilizando os identificadores capturados anteriormente (Contact ID eChannelID)e em seguidao fluxo verifica se o atendimento foi marcado como resolvido ou não 

O processo é realizado através do RPA responsável pela validação de resolução do atendimento.

Validação de resolução do chamado

Após a consulta da tabulação, o fluxo executa a condição Atendente resolveu o chamado?

Chamado não resolvido

Quando o atendimento não é resolvido:

• o fluxo apresenta o menu Deseja algo mais?

Comportamento:

• Sim → retorna ao início do fluxo 
• Não → finaliza o atendimento 

Chamado resolvido

Quando o atendimento é marcado como resolvido:

• o fluxo segue para a âncora ResolveuOChamado

2.14. Finalização do chamado

Na âncora Resolveu O Chamado, o fluxo inicia o processo de encerramento operacional do chamado.

Inicialmente:

• o cliente recebe uma mensagem informando que o atendimento está sendo registrado 
• é executado o RPA responsável pela atualização da causa do chamado antes do encerramento 

Após isso:

• scripts validam se a causa foi atualizada corretamente 
• o fluxo executa uma condição para verificar o resultado da atualização 

Atualização realizada com sucesso

Quando a causa é atualizada corretamente:

• o fluxo executa o RPA responsável pela finalização do chamado 
• scripts validam se o chamado foi encerrado corretamente 

Em seguida:

• o fluxo executa o RPA de atualização de anexos 
• executa a rota responsável pelo envio do histórico da conversa 
• executa a rota responsável pela atualização do responsável no SIGA 

Ao final:

• o cliente recebe a confirmação de encerramento do chamado 

• o fluxo informa que será iniciada uma pesquisa de satisfação 

2.15. Pesquisa de satisfação final

Após o encerramento do chamado:

• o fluxo valida se a pesquisa poderá ser respondida 
• quando disponível, as perguntas são apresentadas sequencialmente ao cliente 
• cada resposta é registrada individualmente via integração/RPA 

Independentemente do resultado da pesquisa:

• o atendimento é finalizado ao término do fluxo 

2.16. Falha na finalização do chamado

Caso ocorra falha em qualquer integração durante a finalização:

• o fluxo executa fallback automático
• o atendimento é direcionado para a equipe humana correspondente 

Esse comportamento segue a mesma lógica aplicada nas falhas de abertura do chamado.

3. Integrações

As integrações da operação Governança BR são responsáveis pela comunicação entre o fluxo Chat Center e o sistema externo SIGA/Qualitor, sustentando etapas críticas do atendimento, desde a abertura até o encerramento dos chamados.

A comunicação ocorre através de requisições XML (RAW), executadas via Fortics IA em diferentes momentos do fluxo operacional. Essas chamadas são utilizadas principalmente para atualização de status, envio de anexos, atualização de responsável, atualização de causa, registro de histórico da conversa e gerenciamento do ciclo de vida dos chamados no SIGA.

Entre os principais processos integrados da operação estão:

• abertura e encerramento de chamados
• atualização de status do chamado
• envio de anexos
• envio de histórico da conversa
• atualização de responsável
• atualização de causa

Uma característica importante da operação é que algumas rotas foram implementadas diretamente via integração, e não através de workflows tradicionais, devido ao volume de dados trafegados durante o processamento.

As integrações da operação executam principalmente duas rotas responsáveis pelo tratamento do conteúdo do atendimento: Enviar anexo atualizado e Enviar histórico de conversa.

3.1. Integração de envio de anexos

A integração responsável pelo envio de anexos realiza uma varredura completa da conversa para localizar arquivos compartilhados durante o atendimento.

• DOC / DOCX
• Excel / XLSX
• PowerPoint / PPTX
• PNG
• JPEG / JPG

Todo arquivo identificado dentro da conversa é enviado para o SIGA/Qualitor através desta rota de integração, garantindo que os anexos compartilhados durante o atendimento fiquem vinculados corretamente ao chamado correspondente.

3.2. Integração de envio de histórico da conversa

A integração de histórico possui funcionamento semelhante ao envio de anexos, porém tratando o conteúdo textual da conversa.

O conteúdo é montado e enviado diretamente para o SIGA/Qualitor através de integração específica.

Assim como ocorreu no envio de anexos, o processamento completo do histórico diretamente em workflow apresentava limitações de tamanho, ocasionando envio parcial das informações. Como o cliente exigia o envio completo do trecho solicitado, a implementação passou a ser feita via integração para garantir integridade dos dados enviados.

3.3. Padrão de retorno das integrações

As integrações executadas no SIGA/Qualitor utilizam um padrão simples de retorno operacional:

Quando a operação é concluída com sucesso, o sistema retorna: 1

Quando ocorre qualquer falha na execução da integração, o retorno recebido é: 0

Com base nesse retorno, o fluxo executa validações responsáveis por definir a continuidade operacional do atendimento, tratamento de erros e fallback para equipes humanas quando necessário.

4. Workflows

Os workflows da operação Governança BR são responsáveis pelo tratamento das integrações executadas entre o Chat Center e o sistema SIGA/Qualitor.

De forma geral, os workflows seguem uma estrutura padronizada composta pelas etapas de recebimento dos dados da rota, tratamento das variáveis, execução da integração XML (RAW), validação da resposta recebida e retorno operacional para continuidade do fluxo.

Todas as rotas utilizam o formato RAW dentro do componente de Integração API.

O envio ocorre através de payloads codificados, contendo autenticação, definição do serviço utilizado e estrutura XML enviada ao SIGA/Qualitor.

Exemplo de estrutura utilizada:

Dentro desse formato, são utilizadas variáveis dinâmicas do fluxo para composição das requisições, como por exemplo: {{request.numeroChamado}}

4.1. Padronização de variáveis e tratamento de retorno

Um padrão importante da operação é a utilização de componentes responsáveis por centralizar os dados recebidos dentro da variável request. Essa abordagem facilita o reaproveitamento das informações ao longo das integrações e padroniza o acesso aos dados utilizados durante o fluxo.

Com isso, os próximos componentes conseguem consumir facilmente informações como: request.descritivo, request.numeroChamado, request.terceiraResposta.

Na maior parte dos cenários, os workflows da operação possuem estrutura relativamente simples, normalmente compostos por:

• request
• Integração API
• tratamento de dados
• retorno da rota

4.2. Workflow de atualização de responsável

O workflow responsável pela atualização do responsável do chamado possui uma estrutura mais complexa devido às validações necessárias para localizar corretamente o atendente dentro da base do SIGA/Qualitor.

Nesse processo, o workflow:

• realiza autenticação no Chat Center
• consulta a conversa atual do atendimento
• identifica o nome do atendente responsável
• executa integração para listar os agentes cadastrados noQualitor
• realiza o match entre o nome do atendente e os usuários retornados pelo sistema externo
• extrai código do usuário e código da equipe correspondentes
• executa a integração final de atualização do responsável do chamado

Esse é um dos workflows com maior quantidade de componentes dentro da operação devido à necessidade de validação cruzada entre os dados do Chat Center e do SIGA/Qualitor.

4.3. Workflow de atualização de causa

Outro fluxo que possui comportamento semelhante é o de atualização de causa antes da finalização do chamado.

Nesse cenário, o workflow consulta a tabulação realizada pelo atendente humano para identificar qual causa foi utilizada na resolução do atendimento.

Após essa validação, a informação é utilizada na integração responsável pela atualização da causa do chamado antes do encerramento definitivo no SIGA/Qualitor.

5. Diagnóstico Rápido / FAQ

Chamado não foi aberto no SIGA

Verificar inicialmente:

• se a integração de abertura retornou 1 ou 0
• se o código da categoria foi enviado corretamente
• se a autenticação utilizada pela integração está válida
• se o XML RAW foi montado corretamente

Em cenários de falha, o fluxo executa fallback automático para equipe humana correspondente.

Chamado não foi encerrado corretamente

Validar:

• retorno da integração de finalização
• execução da atualização de causa
• execução da atualização de responsável
• execução do envio de histórico da conversa
• execução da atualização de anexos

Caso alguma dessas etapas retorne falha, o fluxo direciona o atendimento para equipe humana responsável.

Anexos não aparecem no chamado

Verificar se:

• o arquivo compartilhado possui formato suportado
• a rota Enviar anexo atualizado foi executada corretamente
• o arquivo foi localizado durante a varredura da conversa
• a integração retornou sucesso no envio para o SIGA/Qualitor

Arquivos enviados parcialmente podem indicar falha durante processamento ou interrupção da integração.

Histórico da conversa não foi enviado completo

A operação envia apenas um trecho específico da conversa.

O histórico considerado inicia na mensagem de confirmação da abertura do chamado e finaliza quando o cliente confirma o encerramento do atendimento.

Caso o conteúdo esteja incompleto, validar:

• execução darota Enviarhistórico de conversa
• limites de processamento da integração
• retorno recebido pelo SIGA/Qualitor

Cliente não foi direcionado para equipe humana

Validar se o status do chamado foi atualizado corretamente para EM ATENDIMENTO antes da transferência.

O direcionamento para equipe humana depende diretamente dessa atualização.

Pesquisa de satisfação continua aparecendo para o cliente

A pesquisa permanece disponível enquanto existir pendência registrada no SIGA/Qualitor.

Mesmo que o cliente ignore a pesquisa em um atendimento anterior, ela poderá ser apresentada novamente em novos atendimentos até que seja respondida ou encerrada no sistema externo.

Integração retornando 0

O padrão operacional da operação considera:

1 → sucesso na integração

0 → falha na integração

Sempre que o retorno for 0, devem ser analisados:

• payload enviado
• estrutura XML RAW
• dados obrigatórios da integração
• autenticação utilizada
• tratamento de variáveis request

Workflow não está recebendo variáveis corretamente

Validar se os dados estão sendo centralizados corretamente dentro do objeto request antes da execução das integrações.

Grande parte dos workflows da operação depende diretamente desse padrão para reutilização das variáveis durante o processamento das rotas.

6. Referências

Esta seção reúne os materiais utilizados como apoio para entendimento da operação, fluxo, integrações e regras de negócio do cliente Governança BR.

Os conteúdos abaixo podem ser utilizados como complemento à documentação, principalmente em situações de análise operacional, entendimento de comportamento do fluxo ou validação de integrações específicas.

1. Gravação Fluxo Governança BR 
Material contendo a apresentação completa do fluxo Chat Center da Governança BR, incluindo navegação do cliente, categorização do atendimento, regras operacionais, abertura e encerramento de chamados e comportamento do fluxo durante o atendimento.

2. Documentação Fluxo SZ Governança BR 
Documento desenvolvido pelo time de implantação contendo descrição funcional do fluxo Chat Center, regras de navegação e comportamento operacional das integrações.

3. Gravação Integrações Governança BR 
Material contendo explicações técnicas sobre integrações GOgenier, estrutura dos workflows, tratamento de payloads, integrações XML (RAW), atualização de anexos, atualização de histórico, atualização de responsável e atualização de causa.

4. Documentação da Integradora (SIGA) 
Documentação oficial disponibilizada pelo integrador SIGA/Qualitor, contendo especificações técnicas utilizadas pelas integrações da operação.