Cómo convertir quejas en redes sociales en tickets de soporte

Por qué las quejas en redes sociales pasan desapercibidas

La mayoría de los equipos de soporte monitorizan las redes sociales, pero solo lo que les llega directamente. Los servicios de asistencia con integración con X capturan las menciones directas a tu cuenta oficial. Eso funciona cuando la gente te etiqueta. Muchos no lo hacen.

La gente escribe "acme" en lugar de "@acme". Preguntan en r/sysadmin si a alguien más le falla la sincronización. Te mencionan a mitad de un comentario en Hacker News que trata de otra cosa. Nada de eso llega a un feed de menciones, y nada de eso llega a la persona de guardia.

El otro problema es la responsabilidad. Cuando el equipo de marketing detecta quejas en redes sociales, suelen quedarse en un canal de Slack de marketing hasta que alguien las reenvía. Un ticket tiene un responsable, un plazo de resolución y un estado. Un mensaje de Slack no tiene nada de eso, así que la solución es convertir la queja en un ticket lo antes posible.

Crear alertas que detecten quejas

Antes de conectar nada a tu servicio de asistencia, necesitas alertas que encuentren problemas de soporte y no cada mención a tu marca. Una alerta de KWatch exige que aparezca cada palabra clave de su lista, por lo que las comas funcionan como un AND lógico. Esto te permite combinar el nombre de tu producto con las palabras que la gente usa cuando algo falla.

Tomando «acme» como ejemplo de tu producto, un conjunto inicial sería así:

1. acme, not working y acme, broken para fallos totales

2. acme, can't login y acme, logged out para problemas con la cuenta

3. acme, refund y acme, charged para reclamaciones de facturación

4. acme, help para personas que preguntan cómo hacer algo

Cada línea es una alerta independiente. Si pusieras todas esas palabras en una sola alerta, una publicación necesitaría contener cada una de ellas para coincidir. Al cabo de una semana, observa qué alertas se activaron y cómo se expresan tus usuarios, y luego ajusta. Prueba también con tu nombre de usuario oficial como palabra clave, ya que algunas personas te etiquetan en lugar de escribir el nombre de la marca.

Los filtros mantienen la cola limpia, y aquí importan más que en ningún otro sitio, porque cada falsa coincidencia se convierte en un ticket que alguien tiene que cerrar. Añade tus propias cuentas de soporte y de marca como Usuarios excluidos, para que tus respuestas no abran nuevos tickets. En Reddit y Hacker News, activa Solo palabras completas si tu nombre es corto, de modo que "acme" no coincida con "acmeplex". Unas pocas palabras clave excluidas pueden eliminar el ruido evidente, como las ofertas de empleo que te mencionan. Mantén esa lista corta, porque una publicación se descarta en cuanto aparece cualquiera de las palabras clave excluidas. Repasamos todos los filtros en nuestro artículo sobre cómo reducir el ruido en las alertas por palabras clave.

¿Con qué rapidez te llegará una queja?

La velocidad depende de la plataforma, y conviene saberlo antes de prometer a nadie un tiempo de respuesta. Estas son las frecuencias de actualización de nuestra documentación:

Por tanto, una queja en X puede tardar hasta una hora en llegar a tu cola. Para la mayoría de los equipos de soporte, eso sigue siendo mucho más rápido que encontrarla manualmente el miércoles. Pero si tienes un SLA estricto para las @menciones directas, mantén el canal nativo de X de tu servicio de asistencia para ellas y usa alertas por palabras clave para todo lo que no puede ver, como publicaciones sin etiquetar, hilos de Reddit y comentarios de Hacker News. KWatch tampoco puede leer DMs, por lo que los mensajes privados se quedan en tus herramientas actuales.

Enviar cada queja a tu servicio de asistencia

Una vez que las alertas se están activando, el siguiente paso es sacarlas de KWatch y convertirlas en tickets. La forma más limpia es un webhook de API. Cada coincidencia llega como una carga útil JSON, y puedes configurar un webhook por alerta, de modo que tus alertas de quejas vayan al servicio de asistencia mientras que tus otras alertas vayan a otro lugar. Un webhook por alerta tiene prioridad sobre el de toda la cuenta.

Aquí tienes el payload de ejemplo de nuestra documentación:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Todos los campos que necesitas para un ticket están ahí. El campo content se convierte en la descripción, el link va en la parte superior para que el agente pueda abrir el hilo, y la query te indica qué alerta se activó. Para X, el campo de autor también incluye el nombre completo de la persona y su número de seguidores, lo que ayuda al agente a decidir qué responder primero.

En Zapier

1. Crea un Zap con Webhooks by Zapier y el disparador Catch Hook, y luego pega la URL del hook en el campo API Webhook URL de tus alertas de quejas.

2. Añade un paso de Filter si solo quieres que algunas coincidencias se conviertan en tickets. Una regla común es dejar pasar todo aquello en lo que sentiment no sea positivo, lo que descarta las publicaciones del tipo «acme solucionó mi problema en cinco minutos».

3. Añade la acción de crear ticket de tu servicio de asistencia. En Zendesk es Create Ticket. Asigna content a la descripción, crea el asunto a partir de platform y author, y añade una etiqueta como social para que sea fácil generar informes sobre estos tickets.

En n8n

El mismo flujo funciona con un nodo Webhook, un nodo IF sobre sentiment, y el nodo de Zendesk o Freshdesk configurado para crear un ticket. Si no has conectado KWatch a ninguna de estas herramientas antes, nuestra guía de Zapier y n8n explica la parte de los webhooks paso a paso.

Un apunte sobre el filtro de sentimiento: se evalúa respecto a tu palabra clave, y el sarcasmo todavía puede engañarlo de vez en cuando, así que yo lo usaría como un filtro flexible durante las primeras semanas. Envía todo, revisa qué se etiquetó como positivo y solo entonces deja que el filtro descarte tickets.

Responder a una queja en público

Un ticket originado en Reddit es un ticket atípico, porque el cliente no te lo envió a ti. La forma en que respondas determinará si resulta útil.

Yo mantendría la primera respuesta breve, pública y específica. Di quién eres, indica que has visto el problema y ofrece una solución temporal o el siguiente paso. Si necesitas los datos de la cuenta, pídeles que te envíen un mensaje directo, y nunca pidas información personal en el hilo. Cuando esté solucionado, vuelve y coméntalo. Esa última respuesta será la que encuentre en Google la siguiente persona que tenga el mismo problema.

Algunos hilos tratarán sobre temas que no puedes solucionar, como un cambio de precios que no gusta a la gente. Esos también merecen un responsable, pero normalmente es mejor etiquetarlos y enviarlos al equipo de producto en lugar de que responda soporte. Y si una queja se convierte en veinte en una hora, ya no se trata de un simple ticket de soporte. Nuestra guía sobre cómo detectar una crisis de relaciones públicas en redes sociales explica qué hacer cuando eso ocurre.

Si tu equipo de soporte también atiende una lista reducida de cuentas clave, nuestro producto hermano MultiFollow te alerta cuando personas concretas de Linkedin y X publican algo, por lo que verás la publicación de un usuario clave frustrado incluso si nunca menciona tu producto.