¿Flujos de trabajo recomendados para soporte y comunidad?

:wave: ¡Hola a todos!

Estamos súper emocionados de lanzar oficialmente nuestra comunidad este próximo lunes, junto con otras funciones geniales en Tiller. https://community.tillerhq.com

Por ahora, usamos Intercom para gestionar todas las consultas de soporte. Nos estamos agotando con el modelo uno a uno porque recibimos muchas de las mismas preguntas, y tener que la gente las publique en una comunidad donde nosotros (y nuestros entusiastas clientes) las respondamos ofrece un beneficio de uno a muchos. Así que hemos acelerado el proceso y estamos generando contenido inicial. Sabemos que la construcción será lenta, y el lanzamiento del lunes realmente se trata de integrarlo en la incorporación de nuevos clientes. Esperamos aprender mucho y seguir refinando.

Esperamos usarla para responder preguntas sobre nuestra suite de plantillas de hojas de cálculo de Google Finance (que están transitando a nuestra marca “playground” Tiller Labs) y para discutir flujos de trabajo recomendados que no encajan en el modelo de las plantillas tal como están construidas.

Creemos que nuestro producto es perfecto para una comunidad porque es colaborativo y excelente para los experimentadores (¡el cielo es el límite con una hoja de cálculo, ¿verdad? :rocket:)

Así que, finalmente, mi pregunta: ¿cómo nos recomendarías gestionar el flujo de nuevos temas y respuestas que ocurren en la comunidad e integrarlo en nuestros flujos de trabajo de soporte existentes?

Las respuestas de los temas no llegan a Intercom debido a sus mecanismos automáticos de detección (esperábamos que se redirigieran a una bandeja de entrada especial del equipo para que ninguna se quede sin atención). No gestionamos el soporte directamente desde nuestras bandejas de entrada de correo electrónico y nos gusta tener un sistema basado en colas para asegurarnos de no perder consultas.

Algunas ideas:

  1. Reservar un bloque de tiempo específico cada día para participar en la comunidad y hacerlo por turnos entre todo nuestro personal de soporte (pero, ¿cómo puedo asegurarme de haber leído y respondido a todo, y luego cómo sabe mi compañero de manera eficiente qué ya he abordado?)
  2. Asignar categorías o subcategorías a un compañero específico por día (yo me encargo de las preguntas sobre plantillas los lunes, miércoles y viernes) durante mi bloque programado.
  3. ¿Algo completamente diferente?

Idealmente, queremos que esto nos haga más eficientes y Intercom no se va a ir. En su lugar, lo usaremos principalmente para abordar preguntas o problemas fundamentales del producto, como las conexiones de feeds de datos bancarios que podrían involucrar datos sensibles que los usuarios no quieren compartir en la comunidad.

¡Apreciamos cualquier reflexión o idea al respecto!

Gracias,
Heather

10 Me gusta

Hola Heather. ¡Qué momentos tan emocionantes!

Primero, tengo algunas preguntas aclaratorias:

  • ¿Tu equipo es principalmente responsable del soporte o eso es solo una pequeña parte de su trabajo?
  • ¿Esta comunidad es un canal de soporte adicional (con los existentes aún en funcionamiento)?
  • ¿Tienes el respaldo de tu equipo para esta nueva iniciativa?
9 Me gusta

¡Gracias, @HAWK, es realmente muy emocionante!

Sí, mi equipo es principalmente responsable del soporte. Sí, es un canal adicional donde esperamos que los clientes publiquen y respondan preguntas relacionadas con los flujos de trabajo recomendados y las guías avanzadas que normalmente respondemos a través del canal de 1 a 1 (Intercom).

Sí, toda nuestra empresa está comprometida y respalda plenamente la comunidad! :rocket:

5 Me gusta

Genial. Gracias por la aclaración.

En mi experiencia, la clave es la flexibilidad. No existe realmente una respuesta que sirva para todos. Es posible que algunas personas tengan una afinidad natural por la comunidad, mientras que a otras no les guste tanto. En ese caso, te sugiero considerar una división del trabajo.

Si a todos (o a nadie) les encanta, los bloques de tiempo son una buena opción. Una división por categorías funciona bien si tienes expertos en la materia, pero de lo contrario no garantiza necesariamente un equilibrio justo en la carga de trabajo, ya que algunas categorías serán naturalmente más activas que otras.

Si yo fuera tú, empezaría con bloques de media jornada programados y luego volvería a evaluar al final de la primera semana para ver cómo les está funcionando a todos. Asumiendo que responderás públicamente en el sitio, será fácil ver qué preguntas quedan sin respuesta.

¿Tiene sentido?

7 Me gusta

Gracias por los comentarios aquí, @HAWK. Las cosas van bastante bien hasta ahora y está avanzando y creciendo de manera bastante orgánica.

Aún es lo suficientemente lento como para que pueda mantenerme al día con las nuevas discusiones, y tenemos algunos clientes comprometidos que también están ayudando a responder preguntas. Exactamente lo que queríamos, ¡y nos encanta!

Un desafío que prevemos en el futuro, cuando el volumen sea mucho mayor (y ya estamos viendo un poco), es que aún no hemos encontrado una forma realmente eficiente de saber qué no ha sido abordado ni por otro miembro de la comunidad ni por un compañero de trabajo. Así que, cuando inicio sesión durante mi “bloque” de tiempo, ¿cómo puedo saber rápidamente qué necesita mi atención sin tener que revisar si “este ya tiene una respuesta” o “¿solo hay un icono de perfil junto a la publicación”? Y después de abordar lo que puedo durante mi bloque, ¿cómo sabrá mi compañero de trabajo qué no ha sido atendido cuando se conecte? Parece que lo que esté marcado como “no leído” o “nuevo” para mí no aparecerá así para ella.

¿Alguna idea sobre un flujo de trabajo que ayude a gestionar esto, ya que preferiríamos usar nuestras cuentas individuales en lugar de una cuenta compartida?

Heather

1 me gusta

Definitivamente apoyo el enfoque de usar cuentas individuales, pero recomendaría esperar a ver si esto realmente se convierte en un problema. Tenemos una comunidad de soporte muy activa aquí (y un equipo de 36 personas encargadas de responder preguntas) y aún no hemos encontrado que esto sea un obstáculo.

Estamos experimentando con un indicador de “alguien ha leído esto” para los mensajes privados (que es otro canal de soporte que utilizamos), lo cual podría extenderse a los temas públicos en el futuro si mucha gente lo necesita.

8 Me gusta

Gracias por la respuesta. Dentro de tu equipo de 36 personas, ¿cómo logran saber qué no ha sido abordado por otra persona del equipo? ¿Es estrictamente revisando la propia comunidad de Discourse, donde ciertas personas son responsables de categorías específicas, o es un libre albedrío?

He descubierto que ordenar por número de respuestas me permite saber cuándo un tema de alguien aún no ha recibido una respuesta, pero esto no es un flujo de trabajo muy eficiente y tengo que hacerlo para cada categoría, ya que nuestra página de inicio está organizada por categorías en lugar de mostrar todos los mensajes por “más recientes” como en este foro de meta.

3 Me gusta

Es un libre albedrío. Generalmente hay tres estados: una pregunta ha sido respondida (no se requiere acción), una pregunta no ha sido respondida (se requiere acción) o una pregunta tiene hilos de discusión sobre el mejor curso de acción.

Sin embargo, no tienes que tener eso como tu propia página de inicio. Puedes tener “más recientes”.

6 Me gusta

Lo que pregunto es cómo puedes distinguir entre ellos. No hay una manera obvia o eficiente (al menos que yo pueda ver) para ver cuáles han sido respondidas, cuáles no, y cuáles tienen conversaciones internas (aunque actualmente no tenemos activadas las conversaciones internas).

Quizás esto sea algo que probaremos en el futuro, pero hemos intentado organizarnos en torno al concepto de “tareas por realizar”. ¿Qué intenta hacer el usuario cuando llega al foro… y asegurarnos de que pueda explorar/encontrar el contenido apropiado según su tarea, en lugar de necesitar ver un hilo con una gran oleada de actividad.

1 me gusta

Mi punto es que personalmente puedes usar la versión más reciente, sin que sea la página de inicio predeterminada para todos.

Supongo que todos leemos todos los temas. O filtramos por número de respuestas. Probablemente cada uno tenga su propio método, pero funciona.

4 Me gusta

Podrías marcar las respondidas como “Resuelto” si la respuesta dada es definitiva. Pero entiendo lo que dices… un sistema de tickets tipo:

  1. Abierto - sin respuesta
  2. Pendiente - respondido pero aún pendiente
  3. Cerrado - respondido suficientemente y cerrado.

Los “términos de ticket” dependen de las palabras que quieras usar. ¿Es esto más lo que buscas? ¿Y tener un icono que represente cada tipo?

Puedes obtener todas las publicaciones sin responder de una lista de temas añadiendo ?max_posts=1 a la URL en la barra de direcciones de tu navegador. Existe un componente de tema que puedes instalar en tu sitio y que añade un botón “Sin responder” a la navegación del sitio: Unanswered Filter.

Si deseas encontrar únicamente los temas que no han sido respondidos por miembros del personal, pero que podrían haber sido contestados por otros miembros de tu comunidad, podrías añadir una consulta de Data Explorer a tu sitio que devuelva una lista de esos temas. Ahora es posible permitir que los grupos ejecuten consultas de Data Explorer, por lo que podrías agregar la consulta a la página de tu grupo de soporte.

Una buena estrategia para repartir el trabajo de soporte entre un equipo es que los miembros del equipo sigan las categorías o los temas en los que se sienten cómodos respondiendo preguntas. Por ejemplo, yo sigo la categoría Support > WordPress, porque no espero que ningún otro miembro del equipo responda preguntas relacionadas con WordPress.

El Plugin de Asignación es muy útil para distribuir el trabajo entre un equipo. Lo utilizamos mucho en Meta, especialmente en la categoría bug.

Gran parte del trabajo de soporte que realizamos en Discourse se gestiona mediante mensajes privados enviados por correo electrónico a nuestro equipo de soporte. Utilizamos bandejas de entrada de grupos para saber qué hay que atender. Los mensajes privados que ya se han gestionado se archivan. También usamos el Plugin de Asignación para asignar mensajes privados a miembros del equipo. Hemos activado la configuración “Publicar el estado de lectura del grupo en los mensajes de grupo” para nuestro grupo de Soporte. Con esta configuración activada, podemos saber qué miembros del equipo han leído un mensaje privado.

Los susurros pueden ser útiles para el trabajo de soporte si es necesario debatir internamente antes de responder una pregunta. También se pueden usar para informar a otros miembros del personal que una solicitud de soporte está siendo atendida.

11 Me gusta

@simon,

¡Muchas gracias! Es un excelente feedback sobre cómo usar Discourse para soporte.

Estoy experimentando ahora mismo con el “filtro de no respondidos”. Gracias por compartir ese componente conmigo. ¿Es posible filtrar aún más la lista para excluir una etiqueta específica en los resultados?

También usamos Discourse para documentación y no necesariamente esperamos que esos temas requieran una respuesta. Supongo que ?max_posts=1 solo filtra la lista más reciente según el número de respuestas.

De cualquier manera, esto será de gran ayuda. También compartiré tus otros comentarios con nuestro equipo mientras seguimos refinando nuestro proceso.

¡Gracias de nuevo!
Heather

1 me gusta

No creo que esto se pueda hacer con el filtro de “sin respuesta”, pero sí se puede hacer desde la página de búsqueda avanzada de tu sitio. La sección “Dónde están los temas” de los filtros de búsqueda tiene una opción de “cero respuestas”. Selecciona esa opción y luego añade -tags:nombre-etiqueta en la barra de búsqueda para excluir una etiqueta específica de los resultados. Aquí tienes un ejemplo de consulta de búsqueda que devolverá temas sin respuestas, pero excluirá los temas etiquetados con feature: Search results for 'status:noreplies -tags:feature' - Discourse Meta.

Otra aproximación a esto sería agregar una consulta de Data Explorer a tu sitio que te proporcione los resultados que buscas. Ahora es posible permitir que los grupos ejecuten consultas de Data Explorer, por lo que esto podría ser una buena solución para un grupo responsable del soporte al cliente.

5 Me gusta

¡Esto también es genial! Gracias :slight_smile:

Bueno, por ahora es la última pregunta. ¿Hay alguna forma de tener etiquetas “ocultas”, es decir, que solo los administradores o el personal puedan ver o usar?

2 Me gusta

Sí, esto se puede hacer con Grupos de Etiquetas. Para crear un grupo de etiquetas, ve a tu página de índice de etiquetas (/tags). Selecciona “Gestionar grupos de etiquetas” en el menú superior derecho.

Crea un nuevo grupo de etiquetas con las etiquetas que deseas restringir al personal. Los grupos de etiquetas te ofrecen tres opciones para el uso de las etiquetas:

  • Las etiquetas pueden ser utilizadas por todos.
  • Las etiquetas son visibles para todos, pero solo el personal puede usarlas.
  • Las etiquetas son visibles solo para el personal.

Selecciona la última opción para que las etiquetas solo puedan ser usadas y vistas por el personal.

6 Me gusta

¿Es posible configurar Discourse para que envíe una notificación a Slack cuando un tema se asigna a un usuario en particular?

1 me gusta

No lo creo. Por ahora, las notificaciones de Slack se limitan a temas y publicaciones.

4 Me gusta