A tela Grupo de Atendente (Administração > Atendimentos > Grupo de Atendente > (botão) +Novo) recebeu o bloco Canais de Atendimento com o campo para seleção dos canais disponíveis na plataforma.
Dessa forma, o Atendente visualiza na listagem da tela Atendimentos apenas os Protocolos dos canais para os quais esse permissionamento reflete na configuração.
Se o Administrador não selecionar algum Canal de Atendimento para os Atendentes nessa configuração Grupo de Atendente, então esses Atendentes podem ver todos os Atendimentos da listagem.
* Confira como configurar Grupo de Atendente.
A plataforma redirecionava os Atendentes que já tinham realizado o primeiro atendimento ao fluxo de atendimento, antes que todos os Atendentes disponíveis fizessem um atendimento.
Esse comportamento causava uma distribuição desigual e sobrecarga para alguns Atendentes, porque novos cards não eram ofertados aos Atendentes que ainda não tinham realizado atendimento.
Após a melhoria, as regras para a oferta de cards são as seguintes:
– Os cards tocam para todos os Atendentes logados que ainda não realizaram algum atendimento.
– O card é ofertado ao Atendente que acaba de logar na fila, mesmo que outros Atendentes já tenham realizado atendimento.
– Se todos os Atendentes logados já realizaram algum atendimento, o próximo card é ofertado ao Atendente que passou o tempo de descanso e finalizou atendimento a mais tempo.
– O card é ofertado ao Atendente que não atingiu a quantidade de atendimentos simultâneos configurada pelo Administrador, considerando também as regras anteriores.
– Os cards não aceitos são ofertados novamente conforme as regras anteriores.
Foi verificado que a plataforma enviava ao cliente o código de ação citrus-finish-session como uma mensagem durante o atendimento via Chat. Essa mensagem causava a falta de compreensão nos clientes.
Para correção foi removido da plataforma o caractere \n que era enviado pelo bot junto a esse código de finalização da sessão. A partir de agora o cliente recebe corretamente as mensagens do fluxo de atendimento.
Os novos Comentários deixaram de ser visíveis ao acessar um Atendimento, mesmo após a plataforma exibir a mensagem “Comentário adicionado com sucesso“. Porém, na tela de listagem dos Atendimentos, ao clicar no botão (+) “Informações detalhadas” esses Comentários eram visíveis normalmente.
Esse cenário ocorreu devido a adição de um Comentário com conteúdo HTML de formato inválido, com 2 aspas duplas (” “) na propriedade <style>. Dessa forma a sequência de caracteres do conteúdo se perdia por não compreender o que era abertura e fechamento.
Foi ajustada a regra da plataforma para substituição de 1 aspa dupla (“) quando adicionado conteúdo HTML nos Comentários. Assim os Comentários são carregados corretamente.
Acontecia a criação de outro Atendimento quando o cliente respondia o email do comentário de um Atendimento em andamento.
Foi implementada outra forma de identificar o Protocolo ao processar os emails via IMAP. Com a configuração na tela Layout padrão de email de notificação (Administração > Configurações Gerais > Layout padrão de emails de notificação), agora pode ser ativado em quais templates de email um reply-to é adicionado com o número do Protocolo.
Com essa melhoria a resposta do cliente ao comentário de um Atendimento é salva corretamente nesse Atendimento.
Os Artigos aprovados não eram visualizados pelos usuários. Foi realizado o ajuste na tela Artigo (Base de conhecimento > Artigo) com a retirada da flag “Visível para o cliente” e adicionada a regra ao campo Status.
Agora quando o campo Status estiver com as seguintes opções selecionadas: “Rascunho” ou “Em validação”, o Artigo não fica visível para usuários. O Artigo somente é visível para usuários se o campo Status estiver selecionado com a opção “Aprovado”, e o Setor do usuário estiver adicionado na seção Setores.
Para clientes com permissão de acesso a plataforma somente é necessário que o Artigo esteja com o Status “Aprovado”. Dessa forma, a validação de Artigos visíveis em tela acontece por regra padrão da plataforma.
Identificado que ao iniciar uma conversa com o Chatbot, o cliente após preencher email e senha para autenticação na tela inicial do Webchat, esse email e senha estavam visíveis na conversa.
Com o ajuste na regra da plataforma para não salvar a primeira mensagem recebida pelo Bot quando o canal Webchat possui o Fluxo alternativo configurado, esse cenário não acontece mais, pois a primeira mensagem que vai para o Bot é o login e senha do cliente que solicita atendimento.
Durante a ação do botão Importar clientes na tela Clientes (Administração > Configurações Gerais > Clientes), a plataforma salvava, em todos os registros de clientes existentes na base, os dados de Campos Extras do último arquivo CSV importado. Esse cenário causava a duplicação dos dados e informações incorretas de clientes.
Com a correção na regra de processamento do arquivo CSV, foi eliminado o comportamento de loop, e ajuste na velocidade da ação pela quantidade de linhas e colunas de registro. Assim, a importação de clientes é realizada corretamente e em menor tempo.
Powered By EazyDocs