Versão 2.84.0
O módulo de Atendimentos recebeu melhorias e, agora, será possível registrar protocolos classificados como anônimos e/ou confidenciais. A novidade contribui para a efetividade de ações de compliance ao garantir o anonimato e a confidencialidade de informações em determinadas ocorrências, a exemplo de casos de denúncia de assédio no ambiente organizacional ou solicitação do cliente para tratativas anônimas.
Para que um atendimento possa ser classificado como anônimo e/ou confidencial, é necessário que previamente seja cadastrado um Tipo de ocorrência (menu Administração > Configurações Gerais > Tipo de ocorrência > +Novo), habilitando-se a(s) flag(s):
- Anônimo: Para ocultar as informações do Cliente.
- Confidencial: Para ocultar todas as informações do Atendimento.
Caso um Tipo de Ocorrência que exija anonimato e/ou confidencialidade seja selecionado durante o registro de um atendimento, no protocolo suas informações ficarão ocultas em parte ou na sua totalidade para os usuários em geral.
IMPORTANTE: Para visualizar as informações contidas em protocolos de atendimentos anônimos e/ou confidenciais, é necessário possuir as seguintes permissões habilitadas para o respectivo Perfil de usuário (menu Administração > Usuários > Perfil > (aba) Configurações gerais):
- Listar atendimentos anônimos
- Listar atendimentos confidenciais
Saiba mais sobre os Atendimentos Anônimos e Confidenciais.
Todos os alertas de monitoramento cadastrados na plataforma estão sendo exibidos corretamente na respectiva tela de listagem (menu Administração > Atendimentos > Alertas de monitoramento).
Foi corrigido o cenário em que, quando um Supervisor criava dois ou mais alertas de monitoramento, apenas o primeiro alerta criado por ele era listado na tela. Na correção, foram realizados ajustes na listagem de Alertas de monitoramento nos casos em que o Supervisor tiver mais de um alerta configurado e cadastrar a mesma fila em mais de um alerta de monitoramento.
Agora, quando um mesmo Supervisor criar mais de um alerta de monitoramento, todos eles serão devidamente cadastrados e exibidos na tela de listagem de Alertas de Monitoramento.
Além disso, foi corrigido o cenário na aba “Detalhes” da tela de Monitoramento (Estatísticas > Monitoramento) que fazia com que o botão para Redefinir filas do agente (
Com as melhorias realizadas, o botão de Redefinir filas do agente passa a ser visualizado normalmente pelo Supervisor que, ao clicá-lo, conseguirá acessar o pop-up para realizar a referida ação.
IMPORTANTE:
- O botão para a redefinição de filas só ficará disponível para agentes reais, não sendo exibido para o Bot, por exemplo.
- Só será possível redefinir as filas de um Atendente logado se ele não estiver realizando atendimento, não sendo a redefinição permitida se houver card de atendimento na sua tela.
A criação de um novo grupo de monitoramento, realizada por meio do menu Administração > Atendimentos > Grupo de monitoramento > +Novo, está funcionando normalmente e sem a ocorrência de erro na tela de listagem, ainda que os campos da tela de cadastro (“Nome” e/ou “Descrição”) sejam preenchidos com scripts maliciosos.
Foi corrigido o cenário em que, quando scripts maliciosos de alerta ou de imagem eram inseridos no campo “Nome” e/ou “Descrição” durante o cadastro de um grupo de monitoramento, eles eram executados, provocando quebra de tela.
Foi realizado tratamento nos campos afetados para que não executem comandos JavaScript e, agora, esses dados serão exibidos como textos simples nas colunas, não sendo produzido nenhum efeito na tela de Grupo de Monitoramento.
A tela de cadastro de Atendimentos (LemonDesk > Atendimentos > +Novo) está funcionando conforme o esperado e os registros de atendimentos estão sendo salvos normalmente.
Foi corrigido o cenário em que, ao tentar salvar um atendimento, o Atendente visualizava um pop-up com a mensagem “Operação não foi realizada”. No entanto, ainda assim, os dados e o atendimento ficavam salvos na plataforma. Na resolução, foram realizados ajustes para que os atendimentos sejam devidamente salvos quando, na sua criação, o Atendente não selecionar uma Solução ou selecionar uma Solução sem Etapas configuradas.
Além disso, foi identificado um cenário em que, quando um cliente cadastrado na plataforma tinha suas informações dos campos “Tipo de Cliente” ou “Região” alteradas, ele era retornado para o usuário como um novo cliente e a plataforma não permitia o novo cadastro.
Como regra da busca, a verificação do cliente existente era feita por meio dos dados do campo “Código”, “Tipo de Cliente” e “Região”. Quando essas três condições não eram atendidas, a plataforma o interpretava como um cliente ainda não cadastrado e tentava criar um novo registro, ainda que o cliente com o respectivo Código já tivesse sido cadastrado.
Na resolução, foram feitos ajustes para que a pesquisa para verificação da existência do cliente cadastrado no banco de dados seja feita buscando apenas pelo seu Código. Agora, com as melhorias implementadas, quando se buscar pelo Código de um cliente já cadastrado na plataforma, ainda que seus dados de “Tipo de Cliente” e/ou “Região” tenham sofrido alterações, ele será identificado normalmente e o registro do atendimento será salvo conforme o esperado.
Para garantir o pleno funcionamento desses recursos, foram realizadas alterações nas regras aplicáveis à configuração de Etapas dentro de um Fluxo de Solução. Com os ajustes feitos, também foi corrigido o cenário que ocorria ocasionalmente em que campos extras da Etapa não eram exibidos quando, após iniciada a Etapa, clicava-se em Cancelar para retornar à tela de Atendimentos.
Saiba mais sobre as Regras dos Fluxos de Etapas no Citrus.
