✅ Noticias, temas, complementos de WEB y WordPress. Aquí compartimos consejos y las mejores soluciones para sitios web.

Reflexiones sobre los foros de apoyo basados ​​en la comunidad

22

La semana pasada, y este fin de semana, estuve leyendo los comentarios en las publicaciones de Pippin Williamson sobre la decisión de su empresa de ajustar los precios en Easy Digital Downloads (y para los curiosos, lo aplaudo).

Esa es una conversación en sí misma, y ​​hay un largo hilo de comentarios que creo que vale la pena leer para cualquier persona involucrada en el desarrollo de productos de WordPess, pero me estoy desviando porque ese es el punto de esta publicación.

Algunos lectores han dejado comentarios a lo largo de la fuente de comentarios discutiendo la noción de foros de soporte basados ​​en la comunidad. Vale la pena leer todo el hilo, pero:

  1. EDD solía ofrecer foros de soporte basados ​​en la comunidad (además de su otro soporte),
  2. Desarrollé y trabajé en productos que tenían foros de soporte basados ​​en la comunidad.

Y, en retrospectiva, no creo en absoluto que sea una sabia decisión que una tienda de productos basada en WordPress los ofrezca. Tengo mis razones, daré más detalles, pero quiero dejar en claro que estoy restringiendo esto estrictamente a WordPress porque es lo que sé.

No puedo hablar por ningún otro segmento de nuestra industria.

Foros de soporte basados ​​en la comunidad

Hace años, trabajé con un gran equipo y construimos un producto sólido, y todavía estoy orgulloso del trabajo que hicimos. Durante ese tiempo, una de las cosas que inicialmente ofrecimos fueron foros de soporte basados ​​en la comunidad.

Al principio, parecía tener sentido: cuando no respondíamos a los tickets de soporte (que era algo que sucedía con más frecuencia, solo pregúntele a Chris o Michael ), otros se ayudaban unos a otros en los foros.

Reflexiones sobre los foros de apoyo basados ​​en la comunidad

Los primeros foros de soporte basados ​​en la comunidad que usamos.

Parece un ganar-ganar, ¿verdad? Tienes a tus clientes ayudando a otros clientes, y tienes a tu equipo ayudando a clientes con problemas más grandes.

En una situación ideal, así es como puede funcionar. Pero el mundo no es una situación ideal y, por lo tanto, tampoco lo es la naturaleza de los foros de apoyo basados ​​en la comunidad.

Entonces, naturalmente, esto plantea una pregunta: ¿Qué hay de malo en los foros de soporte basados ​​en la comunidad?

Lo que realmente sucede en los foros

Cuando hay personas que ayudan a otras personas a tratar de resolver un problema con un producto pago que brinda soporte, y el soporte proviene de alguien que no es el proveedor, entonces estás buscando personas que:

  • no sé cómo se construyó el producto,
  • podría estar brindando soluciones desde un lugar con menos experiencia que usted o usted y su equipo de desarrolladores,
  • se pueden dar simplemente respuestas incorrectas por falta de experiencia.

Así que míralo de esta manera: tienes un producto que tú o tú y un equipo habéis construido. Ha sido probado, evaluado, probado, evaluado, implementado y las ventas continúan.

Entonces alguien encuentra un problema o un error. Han comprado soporte, por lo que envían un ticket que los coloca en una cola de duración indeterminable. No reciben una respuesta tan rápido como quisieran, por lo que le preguntan a alguien en los foros. Obtienen una respuesta, modifican el código central, funciona, por lo que están contentos.

Luego, usted o su equipo vuelven a su pregunta de soporte original y han encontrado un error legítimo. Eso es genial porque le permite aumentar la calidad de su software.

Pero han cambiado el código central, por lo que es probable que cualquier solución que ofrezca se encuentre con "Gracias, pero lo resolví".

Pero se resolvió todo mal.

Y dependiendo de la naturaleza de lo que esté vendiendo, esto podría introducir errores de seguridad u otros problemas de los que simplemente no se da cuenta hasta que pueda diagnosticar el problema.

Ahora, sin embargo, debe preguntarle al usuario qué hizo para solucionar su problema, auditar ese código y luego auditar su código.

En última instancia, ¿qué hace esto?

  • Los usuarios que ayudan a los usuarios pueden producir soluciones incorrectas,
  • Los usuarios que ayudan a los usuarios pueden generar más solicitudes de soporte o más largas de lo necesario,
  • El negocio está potencialmente gravado con más trabajo del necesario para corregir un error o agregar una función.
  • Y más.

Ahora bien, no soy de los que tratan de plantear un problema y luego no proporcionar una solución; sin embargo, no puedo proporcionar una solución para todas las empresas. ¿Quién puede? No conozco el modelo; No sé el modo de operación, no sé la estructura, no sé muchas cosas.

Una forma de abordar esto

Pero lo que sí sé es que los foros de soporte basados ​​en la comunidad pueden generar más problemas que los que no, aunque suene como una ventaja y un punto de venta desde el principio.

Sin embargo, estar del otro lado de esto puede cambiar esa perspectiva.

Entonces, la forma en que abordaría este problema es así:

  1. El soporte se realiza de forma individual. Los clientes envían sus tickets de soporte al equipo del problema a través de una aplicación como HelpScout y luego reciben soporte 1 a 1 del equipo.
  2. Responder inmediatamente (más o menos). Infórmele al cliente que su ticket está en línea para ser atendido, pero hay un retraso y usted está trabajando para llegar a él lo antes posible.
  3. Clasificar y priorizar. A veces, sin embargo, es necesario clasificar los tickets según su importancia. No tenga miedo de hacer esto dependiendo de la naturaleza de un boleto.
  4. Comparte el problema. Esto es opcional, pero si no va a tener foros de soporte basados ​​en la comunidad, ofrezca compartir correcciones, actualizaciones, etc. a través de un blog.

Nuevamente, así es como lo abordaría según mi experiencia, pero no es necesariamente la forma de hacerlo.

Sin embargo, si opta por no usar foros de soporte basados ​​en la comunidad, esta es una forma potencial de manejar la opción de no usar uno.

Entonces, ¿usarlos o no?

Para aquellos que puedan estar entretenidos con la idea, espero que esta publicación brinde suficientes conocimientos para que se detengan a presentarlos.

No digo que siempre sean una mala idea, pero digo que hay algunas consideraciones serias que hacer porque, en última instancia, puede estar causando que usted y su equipo tengan más tickets de soporte de los necesarios.

Fuente de grabación: tommcfarlin.com

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More