Ofreciendo "soporte privado" como parte de una comunidad de soporte público

Característica
1

He estado pensando en esto por un tiempo y decidí lanzar mis ideas al grupo y preguntarles a todos qué piensan.

En los últimos meses, he hablado con bastantes personas que intentan configurar un soporte directo al cliente, donde un equipo de soporte resuelve problemas confidenciales específicos del cliente, como complemento a su foro de soporte comunitario público existente.
La mayoría de esas soluciones involucran los plugins ‘assign’, ‘solved’ y ‘ticket’, y luego hay múltiples enfoques (pero parece que no hay una bala de plata y por eso estoy creando este tema).

Solución n.º 1: Crear categorías/grupos separados para cada cliente

Esto solo funciona cuando tienes una cantidad relativamente pequeña de clientes, no cuando tienes cientos.

Solución n.º 2: La descrita por schungx “Cómo usar Discourse como un sistema privado de soporte/tickets”

El principal inconveniente aquí es: “(…) que estás creando una plataforma de tickets dedicada, o que al menos no habrá superposición entre los usuarios de tu interfaz web de Discourse y aquellos que solicitan tickets de soporte”.

Pero este tema aborda uno de los problemas principales: “Miraste el sistema de seguridad/permisos y no encuentras lo que quieres: básicamente, los permisos puros de Crear y Crear/Responder no existen”. Volveré a esto más abajo.

Solución n.º 3: Bandejas de entrada de grupo.

La idea original de Sam “Discourse como un portal de soporte por correo electrónico privado” que se convirtió en bandejas de entrada de grupo. Configuras una bandeja de entrada de grupo, la asignas a tu equipo de soporte, y todos pueden enviar mensajes por correo electrónico a la bandeja de entrada.
Esta es ahora la solución preferida y funciona.

Sin embargo, no me gusta mucho.

En mi opinión (!), hay una serie de inconvenientes en este enfoque, y los tres principales son:

  • Los mensajes enviados al grupo de Soporte son difíciles de encontrar (de hecho, en mi humilde opinión, todos los mensajes son difíciles de encontrar si no tienes una notificación en la que hacer clic) y, aunque el personal de soporte tiene una buena visión general, un usuario no. Donde los usuarios del personal que trabajan en los tickets ven una bandeja de entrada de grupo separada, los usuarios que han creado los tickets solo pueden encontrarlos entre sus mensajes privados ‘regulares’.
  • Falta de soporte de etiquetas en los mensajes privados: Solo el personal puede etiquetar los mensajes privados y los usuarios no pueden ver ni filtrar por etiquetas.
  • No hay un “lugar” al que uno pueda ir y enviar un mensaje. La posibilidad de enviar un mensaje al equipo de Soporte debe anunciarse explícitamente en algún lugar (y me resulta difícil encontrar un lugar lógico para esto, la mayoría de las veces termina en algún tipo de banner).

En resumen, para mí se siente un poco “añadido” y un compromiso entre los temas de categoría y los mensajes privados.

#4 Temas privados

Esta idea se ha propuesto varias veces (también aquí aquí y aquí), y ya mencioné los permisos de “crear” y “crear/responder” anteriormente.

¿Qué pasaría si hubiera algún tipo de categoría de “buzón de entrega” donde las personas pudieran iniciar un tema e interactuar con el personal de soporte (básicamente: un grupo), donde solo ellos y los miembros de ese grupo pudieran ver el tema?
Esa sería una bala de plata para este caso de uso. Tendríamos una categoría de “soporte” claramente definida donde cada usuario puede ver sus (y solo sus) tickets de soporte. Todo estaría en un solo lugar y podrías usar etiquetas y todo.

Pero tanto @codinghorror como @sam nos han dicho muchas veces que los permisos específicos de tema no van a suceder (lo cual entiendo perfectamente, ya que añade mucha complejidad).

Veo dos caminos a seguir: usar las bandejas de entrada de grupo #3 y esperar que se resuelvan esos inconvenientes, o darle otra oportunidad a la idea de temas privados #4.

Mientras tanto, han surgido algunos plugins que juegan con implementan permisos por tema, como Restricted Replies - solo permite que ciertos grupos respondan en una categoría y Discourse Private Replies que hace que las respuestas sean invisibles para todos excepto para el iniciador del tema (y el personal)… y parece factible… así que he estado considerando darle otra oportunidad a esto en un plugin.

Pero.

Antes de continuar con esto, me interesaría escuchar

  • si otras personas comparten mi opinión con respecto a las bandejas de entrada de grupo, ya que soy consciente de que estas desventajas percibidas podrían ser muy subjetivas.
  • cualquier (!!) comentario sobre la idea del plugin de temas privados
24 Me gusta
4

Este es, de hecho, un muy buen tema para discutir.

Las respuestas privadas podrían ser bifurcadas para llegar a algo similar a tu idea. Pero requerirá a alguien que sepa lo que está haciendo o discutiendo, tal vez con el autor del plugin si se trata de una bifurcación de plugin patrocinada. Con el patrocinio, sería genial explorar una forma de concepto de financiación colectiva.

El buzón de grupo es una gran idea, sin embargo, en mi opinión, el sistema de MP necesita tener una opción de búsqueda fácil de usar, o marcadores de grupo con una opción de carpeta. Es decir, solicitudes del Cliente A de octubre de 2020.

7 Me gusta
5

Sin conocer el contexto original, los permisos específicos del tema parecen una perspectiva mucho más amplia (y como dijiste, mucho más compleja) que lo que se requeriría para que funcione el #4.

La forma en que yo me imagino que esto funcionaría es extendiendo los permisos de categoría para incluir “Ver Propios”. Similar a como son ahora los permisos, uno de “Ver” o “Ver Propios” debe ser permitido para un grupo que ha sido añadido.

Como permitir “Crear” automáticamente permite “Responder”, “Ver Propios” automáticamente permitiría “Crear” - una categoría donde solo puedes ver tus propios temas sería algo inútil si no puedes crear temas.

Creo que esto solo necesitaría dos cambios adicionales en el territorio de los permisos. Cuando los grupos a los que pertenece el usuario actual solo otorgan permiso “Ver Propios”:

  1. La lista de temas debería filtrarse a los temas creados por el usuario actual.
  2. Se debería denegar el acceso a los temas a menos que el tema haya sido creado por el usuario actual.

Sospecho que en realidad hay complejidad adicional al tratar con cosas como la lista de temas más recientes, pero probablemente (¿quizás?) no una cantidad enorme de trabajo extra.

Actualmente no ofrecemos soporte privado en Discourse, así que no tengo experiencia de primera mano, pero creo que mis propias percepciones están en línea con las tuyas.

La descubribilidad es importante, tanto para encontrar dónde pedir soporte como para revisar las consultas de soporte actuales y pasadas, lo que parece ser potencialmente desafiante con el enfoque de los mensajes privados de grupo.

7 Me gusta
6

¡Gracias por tus comentarios! Doy la casualidad de que soy el autor de ese plugin específico, y nosotros (Communiteq) estamos preparados para invertir en esto si sentimos que es la dirección correcta. Así que esas cosas no serán un problema.

Sí, eso suena correcto.

Sin embargo, todavía me cuesta un poco entender cómo se estructuraría exactamente, ya que Ver propio implica Crear, Crear implica Responder y Responder implica Ver.
Pero no queremos que Ver propio implique Ver.

8 Me gusta
7

Sí, veo eso. Debería haber prestado más atención.

:clinking_beer_mugs::smiling_face_with_sunglasses::vulcan_salute::sparkles:

5 Me gusta
8

Sí, esto parece ser más complicado de lo que pensaba. Parece que Responder en realidad no implica Ver, pero que a un grupo se le añadan permisos de categoría en general sí lo hace.

Los permisos son una enumeración donde un grupo tiene exactamente uno de readonly, create_post o full. Averiguar si un usuario puede responder/crear en una categoría dada se reduce a obtener una lista de todas las categorías donde el usuario forma parte de un grupo que tiene (create_post o full) para responder o (full) para crear un tema y comprobar si la categoría relevante está entre esa lista.

Crear temas es fácil, tener un valor adicional en la enumeración como full_own simplemente funciona con él añadido a la constante TOPIC_CREATION_PERMISSIONS en category.rb. Si el usuario tiene full o full_own para la categoría relevante, puede crear un tema.

Las respuestas son más complicadas, pero creo que sería apropiado añadir un alcance adicional que devuelva todas las categorías donde el usuario tiene full_own. Algo como:

  OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
  scope :own_topic_post_create_allowed,  -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }

Luego, en post_guardian.rb, can_create_post? necesita una condición adicional como:

    (!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
      !parent ||
      !parent.category ||
      Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
      (parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
    )

Sin embargo, ver solo los propios temas y garantizar que esto sea cierto en la página de categoría relevante, la última, la búsqueda y cualquier otro lugar parece mucho más desafiante. No lo he descubierto.

6 Me gusta
9

Creo que lo más fácil aquí es la puerta número 3, mejorar las bandejas de entrada de grupo para que funcionen bien al brindar soporte a las personas que inician sesión, no solo a las que envían correos electrónicos para recibir soporte.

Sus principales quejas sobre las bandejas de entrada de grupo parecen ser la falta de funcionalidad en el extremo del usuario, lo cual es legítimo si sus usuarios inician sesión para seguir los tickets y también usan correos electrónicos para hablar con otras personas en el sitio. No he encontrado esto mucho hasta ahora en nuestro uso de bandejas de entrada de grupo para brindar soporte aquí en meta. La mayoría de las personas a las que brindamos soporte a través de las bandejas de entrada de grupo nunca inician sesión; la mayoría usa su propio correo electrónico y, por lo tanto, puede usar su correo electrónico para organizar y archivar su correspondencia con nosotros como mejor les parezca.

Tengo algunos usuarios con los que me comunico a través de @support-teams aquí en meta, así que les preguntaré cómo funciona para ellos y si tienen alguna sugerencia. También haré algunas pruebas más por mi cuenta para ver cómo funciona esto ahora. Me parece que la solicitud es:

  • permitir que los usuarios que no son personal vean las etiquetas de mensajes (actualmente solo el personal ve las etiquetas. ¿Quizás podamos usar grupos de etiquetas para esto, para proporcionar algunas etiquetas que los no personal puedan ver en los mensajes? :thinking: )
  • proporcionar un enlace a las bandejas de entrada de grupo en el menú de mensajes para los usuarios cuando envían mensajes a grupos, para ver sus propios mensajes con grupos (esto ya funciona para el personal, no estoy seguro de cómo funciona para los no personal. Hay problemas aquí con la bandeja de entrada frente al archivo, que no se controlan individualmente por usuario)
  • proporcionar un enlace para iniciar un nuevo mensaje a un grupo (creo que esto existe en la página del grupo si se permite enviar mensajes al grupo)

La capacidad de iniciar un nuevo mensaje a un grupo es algo que incluso yo he notado, como miembro del grupo @support-teams para brindar soporte por correo electrónico de Discourse for Teams. Si quiero iniciar un nuevo mensaje del equipo de soporte, tengo que incluir tanto al equipo de soporte como la dirección de correo electrónico de la persona a la que quiero escribir. Esto es un poco torpe.

Además, la forma en que usamos las bandejas de entrada de grupo, generalmente no cerramos los mensajes como lo haríamos con los temas cuando se resuelven. Simplemente los archivamos. Esto nos permite sacarlos de nuestra vista cuando se resuelven, pero también permite que el cliente haga un seguimiento por correo electrónico y mueva el mensaje de regreso a la bandeja de entrada.

5 Me gusta
10

Este es un punto bastante interesante que no había considerado realmente. Con el soporte por correo electrónico es muy común que los clientes encuentren correos electrónicos antiguos y respondan a ellos en lugar de enviar un nuevo correo electrónico. Si un tema se cierra, probablemente será confuso en el mejor de los casos cuando vean que su correo electrónico es rechazado.

Detrás de la puerta número 4, de cualquier manera que eso pudiera suceder, probablemente sería difícil para el personal identificar los temas que no han sido tratados si no se pueden cerrar, especialmente con un mayor número de personal de soporte. El plugin Solved no ayudará realmente aquí porque el cliente podría responder a un tema antiguo y los diversos miembros del personal de soporte no sabrán si necesita atención o si otro miembro del personal ya lo ha resuelto.

6 Me gusta
11

No estoy seguro de que jugar con full, create_post y readonly sea el camino correcto, ya que full y create_post implican “ver todo” en muchos lugares. No será fácil crear un plugin mantenible de esa manera. Además, creo que no sería muy intuitivo.

Además, sería genial si el autor del tema pudiera añadir personas adicionales (por ejemplo, un colega) al tema, por ejemplo, mencionándolos, y en ese caso este mecanismo no sería suficiente.

En este momento, mi idea es dejar los permisos intactos y añadir una sección debajo de los grupos de seguridad:

Habilitar temas privados en esta categoría
Permitir que los siguientes grupos vean todos los temas [x personal de soporte] [x soporte de ventas]

Hice algo similar en el plugin de respuestas privadas, pero entonces para las publicaciones en un tema en lugar de temas en una categoría.
Creo que llegaré bastante lejos con algunos parches en TopicGuardian.

Sí, esa podría ser una fruta muy fácil de alcanzar. Tu resumen de mi solicitud es preciso, y encontré dos cosas más que pondrían los mensajes a la par con los temas.

  • Cuando busco en el foro, tengo que añadir explícitamente in:private a mi consulta de búsqueda para buscar mis mensajes. A veces, realmente no recuerdo si algo era un tema (más o menos público) o un mensaje privado a un grupo. ¿Por qué no incluirlos por defecto?

  • Además, creo que sería bueno que hubiera un enlace simple a los mensajes en la pestaña derecha del menú hamburguesa. Sí, está el icono del sobre, pero tiene una lista de mensajes, y no un enlace a la pantalla de mensajes en /my/messages. Esa pantalla parece estar oculta.

Los elementos en el menú desplegable son en parte los mismos que las pestañas en la siguiente pantalla, excepto por Mensajes y Insignias. Así que cuando necesito ir a mis mensajes, siempre hago clic en Resumen y luego en Mensajes.

Compara los elementos en el menú desplegable

image
image334×312 7.34 KB

con las pestañas en la pantalla de perfil

image

Hay Resumen, Actividad, Invitaciones y Preferencias en ambos, pero Borradores en uno e Notificaciones, Mensajes e Insignias en el otro. Así que “Mensajes” me parece muy oculto (lo mismo ocurre con Notificaciones e Insignias, pero no las uso tan a menudo).

7 Me gusta
12

Buen punto. No estoy seguro de cuál es el razonamiento detrás de esta barrera. También he notado que cuando estás en tus mensajes, añade in:personal por defecto, ¡lo cual es bueno! Pero no añade, por ejemplo, in:support-teams para buscar solo en la bandeja de entrada del grupo mensajes, lo cual creo que sería una buena idea. La búsqueda avanzada tampoco tiene una forma fácil de filtrar por la bandeja de entrada del grupo, que yo sepa. (cc @pmusaraj)

Screen Shot 2022-01-19 at 12.08.43 PM
Screen Shot 2022-01-19 at 12.08.43 PM535×179 13.5 KB

Esta es una buena idea, pero creo que hay un problema de espacio en ese menú desplegable: no quieres tener más de 7 elementos en esa lista. Además, para la mayoría de las comunidades, no creemos que queramos promocionar los mensajes… ¡queremos que la gente hable en público! Para aquellos que hablan por mensaje, el menú desplegable de notificaciones y las notificaciones por correo electrónico, etc., proporcionan acceso justo a tiempo a los mensajes que requieren atención.

Dicho esto, estamos trabajando activamente en mejoras para el sistema de menús (palabra clave: sideburger), así que tendremos en cuenta este problema. La barra lateral en Discourse for Teams ya proporciona acceso rápido a las bandejas de entrada de grupos y a las etiquetas seguidas, lo que podemos incorporar al núcleo de Discourse junto con el proyecto sideburger.

Así es como se ve ahora cuando estoy en la bandeja de entrada del grupo Kabissa, en mi sitio de Discourse for Teams:

Screen Shot 2022-01-19 at 12.15.36 PM
Screen Shot 2022-01-19 at 12.15.36 PM234×304 4.45 KB

5 Me gusta
13

Me pregunto sobre la designación de grupos como grupos de soporte y tener una entrada de menú hamburguesa basada en esto, con estos estados:

  • 0 grupos designados para soporte, sin entrada de menú
  • 1 grupo designado, una entrada “Mensaje de soporte” que inicia un mensaje al grupo

  • 1 grupos designados, una entrada “Soporte” que enlaza a una página muy parecida a Grupos, mostrando todos los grupos designados con botones de Mensaje

Quizás la entrada de menú adicional y la página sean excesivas. ¿Una sección generada adicional en la página Acerca de?

No es totalmente obvio, pero esto está en la pestaña de mensajes, la flecha hacia abajo en la parte inferior de la lista de mensajes te llevará a la pantalla /my/messages. No menos clics que Resumen, luego Mensajes, pero una carga de página menos.

Si fuera un usuario que envía un mensaje a Kabissa, ¿ese tema estaría principalmente asociado con el grupo de alguna manera, o el tema no tendría más que mi usuario y el grupo Kabissa con acceso permitido?

Si se asocia principalmente con el grupo, ¿sería factible mostrar esa bandeja de entrada de Kabissa en mi página de mensajes de la misma manera, aunque obviamente solo incluya mensajes a los que tengo acceso?

6 Me gusta
14

Cuando probé esto aquí en meta, al crear un usuario tl0, pude navegar a la página del grupo de equipos de soporte y seleccionar el botón Mensaje para enviar un mensaje al grupo. Una vez que envié el mensaje, aterrizó en mi carpeta de mensajes enviados. Así que eso está funcionando, aunque tal vez un poco demasiado enterrado para algunos casos. Siempre puedes agregar enlaces al menú de hamburguesa como mejor te parezca para adaptarlos a los propósitos de tu sitio, o en un banner en tu página de inicio, etc. Entonces, ¿no veo que haya mucho más que deba hacerse aquí?

La bandeja de entrada de Kabissa en esa captura de pantalla solo se muestra a las personas del grupo de Kabissa. Las personas que envían mensajes a Kabissa verían los mensajes en sus propios mensajes.

5 Me gusta
15

Ten en cuenta que existe in:all. Eso mostrará tanto mensajes públicos como personales en una sola búsqueda.

Si recuerdo bien la historia, la idea era imponer una separación entre los mensajes personales y los temas públicos. Minimizar cualquier confusión sobre lo que es público y lo que es personal. Dicho esto, las bandejas de entrada de grupo difuminan bastante esa separación.

8 Me gusta
16

Estaba pensando en aumentar la descubribilidad de los grupos específicos de soporte. Añadir enlaces al menú hamburguesa sería adecuado para una comunidad con un único grupo de soporte (lo cual es ideal para mis propios propósitos), pero una comunidad con muchos grupos de soporte podría beneficiarse de una página o sección en la página “acerca de” generada para grupos específicos.

En retrospectiva, esto probablemente sea más adecuado para un plugin si una comunidad lo necesita.

Lo que intentaba preguntar, quizás torpemente, era si el modelo tiene actualmente suficiente información para hacer posible (en el futuro) mostrar a los usuarios bandejas de entrada filtradas para los grupos con los que interactúan pero a los que no pertenecen. Esto se relaciona con la preocupación de @RGJ de que los mensajes enviados a los grupos son difíciles de encontrar.

Por ejemplo, yo, como usuario normal en tu sitio de Discourse para Equipos, podría ver una bandeja de entrada de Kabissa en mis mensajes que muestre todos los mensajes que he enviado al grupo Kabissa. (O probablemente mensajes en los que soy participante).

Mi sospecha es que no es así, probablemente solo tenga los participantes en los que basarse, que podrían ser cualquier número de usuarios y grupos.

7 Me gusta
17

¡Es genial que esto se esté popularizando! Eso es porque encuentro que Discourse es un sistema fabuloso para tickets de soporte privados y, cuando funciona, funciona maravillosamente.

Sé muy bien que esto no es para lo que está diseñado Discourse, y que estoy tratando de forzar a Discourse a hacer algo que no se supone que deba hacer, pero entre las bandejas de entrada privadas frente a la gloria y las características completas de los temas principales, elegiría lo último cualquier día y seguiría intentando forzarlo…

4 Me gusta
18

Esto es algo que queremos soportar, (figurativa y literalmente), pero no queremos ser forzados a un rincón de "herramienta de soporte". :wink: Si tienes comentarios específicos sobre cómo mejorar Discourse en este rol, háznoslo saber.

Siempre estamos escuchando :ear::hugs:

8 Me gusta
19

¡Me encanta la idea! Incluso desde nuestra comunidad tenemos solicitudes de tickets de soporte separados de su bandeja de entrada de usuario. Este tipo de categoría en la que los usuarios solo pueden ver sus propios tickets sería de gran ayuda.

4 Me gusta
20

¡Gracias!

Usamos un grupo de Mensajes Privados para soporte privado; funciona bien. La principal queja de los usuarios intensivos del sistema de soporte es la incapacidad de buscar en sus mensajes.

Hemos intentado enseñarles que deben agregar el código in:personal a la consulta de búsqueda para poder buscar en sus mensajes, pero no es intuitivo y, francamente, no he visto a ninguno de los usuarios lograr hacerlo, simplemente se rinden y se quejan de que no pueden buscar sus mensajes.

Ni siquiera entienden para qué sirve esta “sugerencia” debajo del cuadro de búsqueda.

image
image540×119 1.78 KB

Y si van a la búsqueda avanzada, podrían ser lo suficientemente avanzados como para marcar el botón de radio “buscar mensajes”, pero todo empieza a parecer extraño cuando eso agrega las palabras in:personal y se rinden en ese punto.

Si hubiera una forma mucho más intuitiva de buscar mensajes que no implicara agregar código al cuadro de búsqueda, sería una mejora masiva.

Si no, simplemente usar un lenguaje más intuitivo, por ejemplo, el código “in:messages” sería una mejora leve.

6 Me gusta
21

¿O tal vez simplemente hacer que la búsqueda incluya mensajes privados de forma predeterminada?

4 Me gusta
22

¡De hecho, eso sería maravilloso!

Una opción “Buscar MP por defecto” (que normalmente está desactivada) sería realmente ideal.

De esa manera, las preocupaciones sobre los usuarios que se confunden entre los resultados de búsqueda de temas normales y temas de MP (que no tengo) podrían equilibrarse con el hecho de que las personas no puedan buscar temas de MP en absoluto (que sí tengo).

3 Me gusta