Zammad: Mejorar / reelaborar el encabezado del mensaje de los correos reenviados

@mantas @MrGeneration - IIRC acordamos enviar el nombre en lugar de la dirección de correo electrónico para evitar filtrar direcciones de correo electrónico internas, ¿verdad? ¿Cuál fue exactamente el caso de uso / historia de usuario que estábamos tratando de cubrir? Lo confundí.

@thorsteneckel Sí, la privacidad de los agentes era la principal preocupación.

¿Historia de usuario para reenviar el encabezado u omitir la dirección de correo electrónico?

Cómo la dirección de un agente (u otro correo interno) terminaría en un correo electrónico reenviado.

Tomado del perfil de usuario del sistema

Para aclarar mi historia de usuario con imágenes y un caso de uso real. Por lo tanto, a veces recibimos correos electrónicos en nuestro zammad autohospedado, por ejemplo, de autoridades o personas que necesitan apoyo, pero simplemente escribieron a la dirección de correo electrónico incorrecta (por ejemplo, info @ en lugar de soporte @) y generalmente solo reenviamos este correo electrónico / ticket a nuestra instancia de zammad alojada en la que trabaja nuestro servicio de atención al cliente. Así que simplemente haga clic en Adelante, ingrese la dirección support @ y haga clic en Actualizar. Luego, esperamos que se adjunte el correo electrónico del remitente del correo electrónico original, para que nuestro servicio de atención al cliente pueda responderlos directamente sin tener que volver a pasar por nuestro zammad autohospedado. Realmente no veo un problema de fuga de correo electrónico aquí, por eso insisto en que esta función debería estar allí / configurable.

Para una explicación ilustrada -> antes y después (tenga en cuenta el correo electrónico agregado en el encabezado de reenvío):

Si bien estoy de acuerdo en que es un posible problema de privacidad si sale mal, también dije que sería un buen caso de uso que podría habilitar manualmente:

Técnicamente, Zammad debería utilizar el FROM del artículo que está reenviando.
¿Quizás esta debería ser una configuración opcional que por defecto no muestra la dirección de correo?

También señalé que Zammad siempre debe asegurarse de no compartir las direcciones de correo de los agentes:

Si bien estoy de acuerdo con el correo electrónico, este es un problema potencial.
No desea, en ningún momento, decirle al destinatario cuál es la dirección de correo de los agentes.

Si le dice a alguien la dirección de correo del agente, el agente podría recibir solicitudes de servicio directamente
lo que técnicamente va en contra del sentido de Zammad como software de asistencia técnica.

Estoy de acuerdo en la parte del cliente, pero tendremos que asegurarnos de que sea solo la dirección del cliente (sin
ticket.agent permisos).

En resumen: personalmente estoy de acuerdo con Martin y también recuerdo que los usuarios me preguntaron sobre esto. (por ejemplo, durante las demostraciones) Creo que esto afectaría al menos al 60% de nuestra base de usuarios que querría hacerlo.

También estoy en el caso de uso de @martinseener

¿Qué tal una de las siguientes opciones de reenvío?

• incluir todas las direcciones de correo electrónico
• incluir solo direcciones de clientes
• no se incluye dirección de correo electrónico

Supongo que el último sería el predeterminado

Otro problema relacionado es el correo electrónico, incluido al responder. También podría seguir esta configuración para evitar más confusión.

Creo que solo debería afectar el reenvío, ya que responder a través de la interfaz de usuario mantiene intactos a los destinatarios al responder al artículo. También puedo optar por eliminar un destinatario si es necesario, lo que también tendría que suceder dentro del campo de texto, lo que podría ser problemático y confuso para el usuario. Personalmente, no me gustaría eso.

Para el reenvío, "incluir todas las direcciones de correo electrónico" solo debería afectar al artículo que está reenviando.
Potencialmente, tendrás muchas más personas comunicándose dentro del mismo ticket, lo que haría que Zammad proporcione más direcciones de correo de las que debería, en mi opinión.

Esto también garantizará que Zammad se oriente sobre la forma en que funcionan los clientes de correo.
Si Zammad se comporta de manera similar a un cliente de correo, el usuario se sentirá como en casa.

Pero esa es mi opinion

Creo que solo debería afectar el reenvío, ya que responder a través de la interfaz de usuario mantiene intactos a los destinatarios al responder al artículo.

También guarda nombre y hora. Sin embargo, algunas personas quieren que se incluya el encabezado completo. Si ya estamos agregando una configuración, no veo por qué no extenderla a este bit. Agrega una molestia casi nula para nosotros, sin complejidad adicional de UX, pero puede ayudar a alguien.

Para el reenvío, "incluir todas las direcciones de correo electrónico" solo debería afectar al artículo que está reenviando.

Absolutamente. Solo afecta a la línea de reenvío de metadatos. No se toca ningún contenido del artículo en sí.

Entonces, desde mi punto de vista, si pudiéramos tener lo siguiente, cubriría todos los casos de uso posibles:

1. sin reenvío de correos electrónicos o encabezados completos (valor predeterminado actual)
2. reenvío de la dirección de correo electrónico original del remitente (consulte mi ejemplo anterior)
3. reenvío del remitente del correo electrónico original + otros destinatarios (principalmente lo que hace Thunderbird. Incluye el remitente original + todas las personas en CC con nombre + correo electrónico
4. reenviar encabezado completo (lo que hace thunderbird por defecto)

no 4 sería el estilo de reenvío "thunderbird", aunque esto tal vez sea demasiado para un sistema de tickets predeterminado, pero al menos lo haría por defecto en 1. lo cual estaría bien para la mayoría de las personas, incluido mi caso de uso, pero puede configurar 1- 4 - tal vez por integración de cola / correo electrónico. entonces puede ajustar su flujo de trabajo tanto como sea posible. (o déjelo como una configuración global que también estaría bien, supongo).
Se adjunta el número 4. Reenvío predeterminado de Thunderbird.

Tal vez como ejemplo para el número 3, podría imaginar algo como esto.

Así que 1-3 todavía "luciría" como zammad y el No 4 estaría en estilo thunderbird - tal vez también citado como se muestra en el ejemplo anterior pero con encabezado completo. Sería muy bueno tener eso y tal vez no sea demasiado difícil de escribir (con suerte)

Buen punto sobre los correos electrónicos CCd.

El encabezado completo sería un poco más complicado. En este momento, no almacenamos el encabezado de correo electrónico sin procesar en la base de datos. ¿Cuántas personas realmente lo usarían en comparación con ser una buena opción para tener en el menú desplegable de configuraciones?

@MrGeneration ¿cuál es su opinión sobre la opción "solo clientes" para evitar que se compartan los correos electrónicos de los agentes?

Creo que la opción 1-3 sería suficiente entonces. El encabezado completo es más "agradable de tener", pero tampoco veo un beneficio real allí.

Estoy de acuerdo, solo vería las opciones 1-3 como opciones útiles.

Independientemente de los detalles de la opción, Zammad no siempre debe proporcionar direcciones de correo a los agentes.
Sin embargo, lo que podemos hacer es proporcionar las direcciones de correo de Zammads. Entonces, si aparecen dentro de un TO o CC, no estaría de más si aún los proporcionáramos durante el reenvío, si corresponde.

@martinseener 1-3 de su lista o de mi lista? Incluiste una opción adicional con CC mientras que mi lista tiene una opción solo para clientes :)

Personalmente, prefiero incluir los correos electrónicos con CC siempre que se incluya un correo electrónico.

@MrGeneration, ¿lo leí correctamente que no deberíamos tener una opción para reenviar correos electrónicos de agentes? Pude ver que eso es un problema con el flujo de trabajo del agente como cliente.

Sí, básicamente tu lista @mantas . Por lo tanto, no hay direcciones de agentes, sino direcciones de destino / CC de clientes u otras personas.

@MrGeneration ¿Lo leí correctamente que no deberíamos tener una opción para reenviar correos electrónicos de agentes a
¿todos? Pude ver que eso es un problema con el flujo de trabajo del agente como cliente.

No, lo que quise decir:
Puede reenviar todos los artículos de tipo de comunicación (como ya es posible).
Sin embargo, Zammad filtrará cualquier dirección de correo electrónico del agente que aparezca en la lista de direcciones para que el reenvío se asegure de no proporcionar direcciones de correo a los agentes para mantenerlos privados y seguros.

Eso es lo que intenté decir: ese artículo podría reenviarse, pero el correo electrónico del agente no se reenviaría y no habría ninguna opción para permitirlo :)

¿Cómo funcionaría en una situación de agente como cliente? ¿Trataría a ese agente como cliente por tipo de remitente (por lo tanto, incluido el correo electrónico) o como agente por función (por lo tanto, anulando el correo electrónico)?

Mi error. En mi opinión, Zammad no manejaría que el agente sea cliente como cliente.
Sin embargo, es posible que desee volver a consultar a Thorsten o Martin, porque esa es solo mi opinión.

No estoy seguro de si ya está fusionado, pero recuerdo haber visto algo así en nuestras sucursales privadas de trabajo en progreso recientemente ... IIRC el caso de uso fue que en las grandes empresas un departamento puede ser cliente de otro departamento.

Zammad por defecto conoce todas las direcciones de correo electrónico con el permiso ticket.agent - No creo que necesites más en este momento. Además de extender las pruebas más adelante si es necesario.

@MrGeneration # 2815 es un predecesor / duplicado de esto, ¿verdad?

@thorsteneckel parece que sí

¿Puedo obtener una lista de escenarios / casos de uso para cada una de las opciones posibles y una estimación de cuánto porcentaje de nuestra base de usuarios la usaría?

Así que he estado hablando con Mantas internamente y esto es básicamente lo que salió de eso.
Consta de dos partes: la Parte 1 describe las diferencias entre las respuestas y los reenvíos para tener el mismo punto de vista y la Parte 2 ofrece posibles casos de uso y un porcentaje que creo que debería ser adecuado.

No tengo ninguna prueba de esos números a continuación en absoluto: si necesitáramos números reales, tendríamos que iniciar una encuesta.

También estoy de acuerdo con el número 2815: este es un duplicado. Sin embargo, como este problema tiene más información, sugeriría cerrar el problema 2815 o cambiar tan pronto como hayamos determinado cómo proceder para mantener el problema breve y, con suerte, no causar confusión.

Bueno entonces....

Espero que lo siguiente ayude a comprender mejor los alcances.

Respuestas

Cuando responda a un correo, no importa si está en Zammad o no, donde su cliente de correo cita el texto anterior, agregará un texto de cita breve, por ejemplo, como On 24th December 2020 John Doe wrote: seguido de la cita.

Esto es útil si cita varios textos de tal vez incluso varios correos (que Zammad sí admite). Siempre usa el remitente del artículo, por lo que básicamente el nombre para mostrar del FROM.

Una respuesta por correo siempre contiene el remitente original. De hecho, al presionar responder, su destinatario siempre será el remitente del correo al que responde.
Esto significa que siempre tienes toda la información para poder comunicarte con el remitente original de ese correo. No se necesita una dirección de correo electrónico dentro de la introducción de la solicitud.

Hacia adelante

Se supone que los reenvíos, al menos por lo general, envían información a otro tercero. No importa si se trata de otro sistema Zammad o de un individuo.
Por lo general, reenvía un correo porque

• o desea compartir información con un tercero "para su información"
• el remitente eligió la dirección de correo incorrecta, usted no es responsable, pero debe ayudar al remitente a reenviar el correo a la persona / sistema responsable

Durante el proceso de reenvío (porque TO y CC no están precargados), perderá la información de quién se originó ese correo electrónico.
Esta es la razón principal por la que el texto de introducción de la cita proporciona la dirección de correo como, por ejemplo: On 24th December 2020 John Doe <[email protected]> wrote:

Esto permitirá que el destinatario se ponga en contacto directo con John si es necesario. Si simplemente responde a un mensaje reenviado, responderá al remitente de reenvío, que en este caso sería Zammad y el destinatario equivocado.

Esto hace que los agentes

• pensar en ese problema (no estamos proporcionando la dirección de correo) y, por lo tanto, insertar manualmente la dirección de correo del cliente para permitir que el destinatario del reenvío se comunique con el cliente
• o tener otra pregunta del destinatario de reenvío "¿a quién se lo enviaré?" (causando ping pong innecesario)
• o el destinatario de reenvío para simplemente responder al correo y obligar a los agentes a reenviar esta información al cliente

Es por eso que Zammad debería permitir que los administradores proporcionen esta información durante los reenvíos. De hecho, creo que esta debería convertirse en la opción predeterminada para nuevas instancias . En las instancias existentes, creo que esto por defecto debería estar deshabilitado.

Ahora a los casos de uso (ahora se complica).

1. (valor predeterminado actual) citar solo el nombre de visualización

Actualmente, al reenviar un correo de Zammad a un tercero, Zammad utilizará On 24th December 2020 John Doe wrote: como texto de cotización.
Si bien le dice quién escribió el mensaje, esto también requiere que el destinatario del correo conozca a John Doe y, por lo tanto, la dirección de correo a la que escribir.

Personalmente, creo que hay un caso de uso en el que quieres que Zammad haga exactamente eso:

• Si está apoyando a sus clientes pero no maneja el segundo o tercer nivel, reenviará el correo de sus clientes a su segundo / tercer nivel con tal vez información adicional que proporcionó anteriormente.
  
  
  
  • en este caso de uso, no desea que su cliente se dé cuenta de que en realidad no está haciendo toda la palabra difícil, sino que simplemente "delega" las solicitudes a otra persona.
  
  
  • Para proteger a su cliente, solo proporcionará su nombre, pero no su dirección de correo
  
  
  • Para garantizar la calidad de la respuesta al cliente (o porque su segundo nivel usa un idioma diferente al de su cliente), está imponiendo respuestas en el correo reenviado para ir a Zammad.
  
  
  • esto le da el control total de qué información se enviará a su cliente
  
  

Personalmente, creo que este caso de uso es válido para ~ 20% de nuestra base de usuarios.
Es por eso que creo que solo deberíamos tener esto activado como predeterminado para actualizar las instalaciones para permitir la compatibilidad con versiones anteriores. Esto también garantiza que los usuarios no se encuentren con un nuevo comportamiento que no quieren y conocen.

2. cite solo el nombre para mostrar y la dirección de correo electrónico DE

Esto proporcionará solo la dirección de correo electrónico del remitente.
Esto puede ser útil si sus clientes trabajan mucho con CC para informar a sus jefes, pero no desea que la parte receptora de su reenvío vea todas esas direcciones.

Personalmente, creo que este caso de uso afecta a menos del 10% de nuestra base de usuarios. Honestamente, no puedo pensar en un caso de uso (excepto el muy delgado de arriba) en el que querrías información a medias

3. (predeterminado para instancias nuevas) cite el nombre para mostrar y todos los destinatarios del correo original

Especialmente si usa muchos CC para informar a más de una persona, sería mejor proporcionarle al destinatario de reenvío todas las direcciones de correo porque

• Reduce la carga de trabajo del remitente original para garantizar que todas las personas reciban la información.
• el destinatario del reenvío puede proporcionar la información a todos los destinatarios originales si es necesario
• el destinatario del delantero podría ver mejor los alcances o las prioridades (por ejemplo, si el director ejecutivo también está informado, es posible que desee dar prioridad a su respuesta: D)

Con este paso nos acercaremos al comportamiento de otros clientes de correo.
Esto ayuda al agente / usuario porque

• Zammad se comporta como el usuario está acostumbrado desde su cliente de correo
• Cambiar de un cliente de correo electrónico normal a Zammad ya no duele tanto si al menos se comporta de manera similar a un cliente de correo (aunque sigue siendo diferente)
• el agente ahorra tiempo para hacer otras cosas

Al final, se supone que Zammad debe ayudar a los agentes, no proporcionar más carga de trabajo; x

Creo que esto afectará al 70% o más de la base de usuarios.
Personalmente prefiero este comportamiento.

Creo que los comportamientos 1 y 3 son las formas más importantes de cómo funciona Zammad.

Mantas señaló que podría resultar confuso simplemente omitir la dirección de correo del agente y, por lo tanto, sugirió al usuario la dirección de correo del grupo.

Sin embargo, me preocupa que esto pueda dar lugar a informes de errores porque Zammad podría elegir una dirección de correo que el usuario crea que es la incorrecta.

La otra posibilidad además de eliminar agentes o utilizar una dirección de correo de Zammad sería utilizar John Doe <redacted> para agentes.

¡Lo he leído y estaría de acuerdo con todo! Gracias por este gran escrito. Me encantaría ver a 3 entrar en Zammad. 2. es quizás "bueno tener" si no agrega demasiada molestia, ya que también lo veo como un método con una base de usuarios muy pequeña.

Para la última parte, en mi opinión, debería reenviar correos como Nombre del agente + Correo de grupos como Martin S. <support@> , para que al menos sepa el nombre del Agente detrás para una respuesta (si necesita responder, puede di "Hola Martín, me reenviaste un correo por el que todavía tengo una pregunta" o algo. ¿Qué opinas?

Para todo lo demás que escribiste ->: 100: de tu lado :) Espero verlo pronto, podemos usarlo finalmente y ahorrar algo de tiempo de trabajo.

Muchas gracias chicos @martinseener @MrGeneration y @mantas ❤️

Estoy convencido y totalmente de tu lado. Para seguir nuestra filosofía, omitiremos las opciones 1 y 2 por completo y reemplazaremos el comportamiento predeterminado actual (2) con 3 para todas las instancias.

IIRC esta fue la intención original del anterior PR # 3014. Ahora que especificamos los requisitos y los casos de uso / historias de usuarios con más detalle, puedo verlo con más claridad. ¡Gracias!

Dependiendo del tamaño del cambio, consideraré tenerlo también a 3.4.

¡Esperamos revisar el MR!

¿Alguna preferencia sobre el estilo exacto?

Estaba haciendo clic en varios clientes de correo electrónico y me estoy preparando para el estilo Thunderbird default propuesto por @martinseener

Cuando se agregan más detalles, es mucho más fácil de leer que el estilo de respuesta humana. Incluso si no almacenamos encabezados completos, podríamos imitar este estilo con los detalles que obtuvimos.

@thorsteneckel ¿Qué enfoque prefiere para ocultar los correos electrónicos de los agentes? Imprimiendo solo el nombre o name <redacted> , name <[email protected]> ?

@mantas estoy de acuerdo. Al agregar más información, algo que sea legible y familiar (Thunderbird) sea quizás una buena opción.
@thorsteneckel de mi punto de vista, tal vez sea bueno tener solo el nombre sin un correo electrónico parcialmente redactado, ya que entonces es fácil adivinar el correo electrónico completo. Luego, simplemente podría ingresar el correo electrónico completo, por lo que diría todo o nada.

Apple mails usa (básicamente) el mismo formato:

From: Marcel <[email protected]>
Subject: Re: [zammad/zammad] Make forwarding original FROM mail header configurable in UI/config (#3091)
Date: 19. June 2020 at 10:11:16 CEST
To: zammad/zammad <[email protected]>
Cc: Thorsten <[email protected]>, Mention <[email protected]>
Reply-To: zammad/zammad <reply+AA5RV25L5H5YCFNQT3KMG3547BKCJEVBNHHCMNFNPQ@reply.github.com>

👍

¿Alguien puede agregar un breve aviso sobre cómo proceder internamente con este ticket ahora? ¿Existe alguna hoja de ruta o un plan aproximado sobre cuándo estará disponible?

Estamos trabajando activamente en ello. Me aseguraré de que no se quede atascado en el limbo :)

Hola @martinseener , ¡gracias a @mantas ! El lanzamiento estará disponible en unos 30 minutos a partir de ahora. Puede actualizar su Zammad a través del administrador de paquetes del sistema y debería estar listo para funcionar. Esperamos sus comentarios 🚀

JFI: Accidentalmente presionaré "actualizar" en su instancia paga en la configuración alojada más adelante (~ 19: 00 - 20:00). Así que mañana será un día mejor. 🙌

@thorsteneckel @mantas @MrGeneration muchas gracias por eso. Acabo de actualizar a 3.4.0-1594825410.4cacfa4b a través de mi administrador de sistema (también a ES 7.8). Cuando ahora reenvíe, el encabezado completo es visible allí. ¡Bien! Sin embargo, una pregunta sobre los archivos adjuntos. No veo una opción para reenviar el correo, incluido el archivo adjunto, si lo hay. ¿Hay alguna forma de reenviarlos también (por defecto)? ¿Quizás un boleto adicional?

Zammad siempre debe reenviar con archivos adjuntos.
Su problema suena como el siguiente error: https://github.com/zammad/zammad/issues/2942

@MrGeneration lo siento. Creo que cometí un error.
Descarté el Borrador de reenvío y volví a presionar Adelante. Ahora veo que el archivo adjunto está en la parte de reenvío y cuando lo envío, el archivo adjunto también se envía realmente. Así que no hay problema aquí.