Zammad: Ação "Responder" na IU confusa

Criado em 7 nov. 2016  ·  19Comentários  ·  Fonte: zammad/zammad

Quando um novo tíquete aparece, ele tem estas opções diretamente abaixo da mensagem:

Auf intern setzen / antworten / abspalten

O campo de texto abaixo, onde você pode inserir uma resposta (preenchido com "Antwort eingeben oder Dateien wählen") não cria uma resposta para o cliente, apenas cria uma "nota".

Ao meu lado na primeira vez, qualquer pessoa para quem eu mostrei isso digitou sua resposta neste campo, presumindo que o cliente receba a resposta do tíquete. Acho que essa é uma armadilha em potencial para os agentes e deve ficar mais clara na IU:

  • deixe o campo de texto de lado e apenas deixe ações abaixo da mensagem como "Auf intern setzen / antworten / kommentieren / abspalten"

  • ou torne o formulário "antworten" o padrão e "kommentieren" (ou "Notiz hinzufüggen") a opção.

UUI enhancement frontend / JS app

Comentários muito úteis

Sim, estamos tratando de ambos ao mesmo tempo.

Em algumas empresas, muitas comunicações acontecem dentro do tíquete antes que o cliente obtenha uma resposta: colegas dão conselhos, informações adicionais dos desenvolvedores são solicitadas, etc. Atualmente, esses agentes de comentários estão felizes por poderem começar a escrever diretamente a comunicação interna usando o grande campo de entrada .

Por outro lado, o grande campo de entrada se parece totalmente com um campo de resposta e ainda tem o espaço reservado "Digite a resposta". Portanto, este é um grande erro da nossa parte (historicamente, o comportamento padrão era "resposta", mas mudamos para "nota").

Poderíamos introduzir uma opção para escolher "nota" ou "resposta via canal inicial" como padrão. Precisamos manter isso genérico porque os tickets podem começar como e-mails, mas também como tweets, chamadas telefônicas escritas etc. Para este caso, enfrentamos o desafio de escolher qual será o padrão inicial e se o padrão será não "note", então podemos deixar os agentes acostumados com o sistema atual infelizes.

Uma ideia mais favorável que temos em mente agora é ocultar a grande entrada e, em vez disso, apresentar grandes botões de ação com "responder", "responder a todos", "encaminhar", "nota" + canais adicionais possíveis que você poderia usar para se comunicar com o consumidor. Google Mail, Mail.app e provavelmente muitos outros aplicativos lidam com isso desta forma:

screen shot 2018-11-12 at 15 00 24

Clicar em um dos botões de ação mostraria a grande entrada, selecione o canal correto e focalize automaticamente sua entrada para a entrada para que você não precise de outro clique para começar a digitar.

Todos 19 comentários

Eu acho que seria melhor ser configurável qual é o padrão.

E seria bom ver que o campo PARA está pré-preenchido com o endereço de e-mail do cliente e no campo CC deve haver todos os endereços que estão em contato com o tíquete.

Realmente preciso enviar um ping aqui. Por que o campo-TO não está pré-preenchido? Eu estava testando o inferno fora de mim e não conseguia entender porque o e-mail buscado não recebia uma resposta. Um software tão incrível falha no que é mais importante ...

Quando começamos a usar o zammad, demoramos uma semana para começar a nos perguntar por que ninguém respondeu às nossas respostas de suporte. Zammad é ótimo, mas este é um desaster UX. Os clientes fazem perguntas, portanto, "digite a resposta" implica que isso será enviado ao cliente.

Por que não "responder" em vez de "adicionar nota"?

É um ótimo software, mas também me confundiu muito. Por favor, considere priorizar este problema mais alto. Relacionado: https://github.com/zammad/zammad/issues/938

+1

Também precisamos da possibilidade de alterá-lo para responder por e-mail por padrão. É bastante confuso para novos usuários do Zammad.

A resposta por e-mail como padrão (como opção) seria muito útil, acontece muitas vezes que uma resposta é apenas adicionada ao sistema de tíquetes e não é enviada para o abridor de tíquetes.

Eu cometo esse erro pelo menos uma vez por semana, então posso confirmar claramente que este é um problema real de IU.

@mrflix - Você acha que pode abordar isso no mesmo escopo do # 1135 que discutimos ontem?

Sim, estamos tratando de ambos ao mesmo tempo.

Em algumas empresas, muitas comunicações acontecem dentro do tíquete antes que o cliente obtenha uma resposta: colegas dão conselhos, informações adicionais dos desenvolvedores são solicitadas, etc. Atualmente, esses agentes de comentários estão felizes por poderem começar a escrever diretamente a comunicação interna usando o grande campo de entrada .

Por outro lado, o grande campo de entrada se parece totalmente com um campo de resposta e ainda tem o espaço reservado "Digite a resposta". Portanto, este é um grande erro da nossa parte (historicamente, o comportamento padrão era "resposta", mas mudamos para "nota").

Poderíamos introduzir uma opção para escolher "nota" ou "resposta via canal inicial" como padrão. Precisamos manter isso genérico porque os tickets podem começar como e-mails, mas também como tweets, chamadas telefônicas escritas etc. Para este caso, enfrentamos o desafio de escolher qual será o padrão inicial e se o padrão será não "note", então podemos deixar os agentes acostumados com o sistema atual infelizes.

Uma ideia mais favorável que temos em mente agora é ocultar a grande entrada e, em vez disso, apresentar grandes botões de ação com "responder", "responder a todos", "encaminhar", "nota" + canais adicionais possíveis que você poderia usar para se comunicar com o consumidor. Google Mail, Mail.app e provavelmente muitos outros aplicativos lidam com isso desta forma:

screen shot 2018-11-12 at 15 00 24

Clicar em um dos botões de ação mostraria a grande entrada, selecione o canal correto e focalize automaticamente sua entrada para a entrada para que você não precise de outro clique para começar a digitar.

Botões grandes seriam uma boa solução.

Eu mesmo tive o mesmo problema esta noite. O que seria necessário para resolver isso?

Qualquer cronograma para este problema?

Sem cronograma ainda.
Esta é uma lista de pendências de recursos e vamos resolvê-la quando houver tempo. :-)

Atualmente, nos concentramos na base de conhecimento.
Bloquearei esse problema para uma discussão mais aprofundada, pois não houve mais nenhuma entrada útil além de empurrar o problema. Isso é para reduzir o ruído de quem está assistindo a esse repo.

Sem sorte para votação (na postagem inicial).
Por favor , não poste mais comentários sobre o quanto você deseja e quando acontecerá, pois então bloquearei a conversa novamente.

Estava confuso com isso também.

Do ponto de vista da UX, sugiro a seleção padrão para o canal através do qual o ticket foi aberto e fazendo (observe) a última seleção possível. (porque será usado mais raramente)

O botão de resposta sempre usa o mesmo canal de onde veio a mensagem para responder.
Ou seja, se o botão de resposta estiver disponível. Se não for, você terá que responder por meio de uma nota ou artigo por telefone.

O botão de resposta sempre usa o mesmo canal de onde veio a mensagem para responder.
Ou seja, se o botão de resposta estiver disponível. Se não for, você terá que responder por meio de uma nota ou artigo por telefone.

Tem certeza de que não fez isso por causa de sua versão SaaS e forçando os usuários a usá-la?

Gosta desse software legal, mas ter uma UX tão ruim como você pode ver impede as pessoas de usá-lo.

Por que você não pode simplificar como você fez em sua versão SaaS? Como se você tivesse todos esses recursos, dê para nós, mas não nos dê a opção de simplesmente responder ao tíquete por e-mail.

Talvez esteja faltando alguma coisa, mas como respondo diretamente ao cliente por e-mail? https://www.screencast.com/t/Rd7NM0l38

Eu estava lutando para encontrar isso por meses, repassei as configurações 8 vezes em todas as opções, mas não conseguia descobrir. Talvez seja eu, mas felizmente encontrei este problema no Github e vejo que as pessoas estão enfrentando o mesmo problema.

Você tem uma maneira muito simples de fazer isso em seu SaaS, mas não na versão Open Source. Posso estar errado, mas isso me diz que você está fazendo isso de propósito, então você converte usuários do sistema operacional em usuários SaaS pagos.

Por favor corrija-me se eu estiver errado.

@shtefcs Desculpe pelo seu problema, mas esta é uma questão técnica, não um bug.
Tecnicamente, isso não é diferente de nossa oferta de SaaS - a diferença é que você compra padrão e não tem uma conta de e-mail.

Eu sugiro dar uma olhada nas configurações do seu grupo e talvez consultar a documentação.
Se você ainda tiver problemas, crie uma postagem na comunidade em https://community.zammad.org .

Se estiver interessado em nosso suporte de nível comercial, você pode verificar https://zammad.com/pricing#selfhosted se estiver interessado.

Como este problema não teve nenhum feedback útil, irei bloqueá-lo apenas para colaboradores.
Por favor, não me entenda mal, isso é para reduzir o ruído neste repositório, o que nos ajuda a nos concentrar na correção de problemas.

Esta página foi útil?
0 / 5 - 0 avaliações