Los equipos de atención al cliente no trabajan todo el día en el CRM.
Trabajan donde se producen las conversaciones en tiempo real: como Slack u otras aplicaciones.
En los últimos años, hemos visto cómo cada vez más empresas trasladaban la atención al cliente a canales de Slack dedicados a cada cliente. Es rápido, colaborativo y resulta natural tanto para los equipos internos como para los clientes. El problema empieza cuando esas conversaciones nunca llegan al CRM.
Esa era la situación detrás de este proyecto.
La empresa tenía una fuerte adopción de Slack para el soporte, pero su HubSpot estaba perdiendo poco a poco su papel como sistema de registro. Los tickets estaban incompletos, los SLA no eran fiables y los informes no reflejaban lo que realmente estaba sucediendo sobre el terreno.
No querían obligar a su equipo a abandonar Slack.
Querían que el CRM se pusiera al día.
Desde fuera, todo parecía ir bien. Los equipos de soporte respondían, los clientes estaban contentos y las conversaciones fluían sin problemas en Slack. Pero bajo la superficie se acumulaban importantes problemas operativos.
Las conversaciones de soporte vivían en canales como #support-client-a o #support-client-b, a menudo durante días o semanas. Mientras tanto, HubSpot sólo captaba fragmentos de esas interacciones, si es que captaba algo. Esto creaba lagunas que aparecían más tarde de forma incómoda: propiedades inconsistente de los tickets, informes engañosos sobre el tiempo de respuesta y falta de contexto al revisar el historial del cliente.
El CRM no estaba equivocado, simplemente estaba ciego.
Nuestro primer paso fue validar si la integración nativa de Slack de HubSpot podía soportar este flujo de trabajo. Lo probamos a fondo, de extremo a extremo, contra el caso de uso real.
Lo que encontramos es que la integración nativa funciona bien para notificaciones simples o registro de mensajes puntuales, pero tiene dificultades cuando Slack se convierte en la superficie de soporte principal. Las conversaciones tenían que asociarse manualmente a los tickets, los hilos no se gestionaban de forma limpia y no había una forma escalable de escuchar canales de soporte múltiples o recién creados sin una configuración constante.
Y lo que es más importante, la integración asumía que los usuarios decidieran activamente cuándo y cómo sincronizar los mensajes con el CRM. Esa suposición simplemente no se sostiene en entornos de soporte de gran volumen.
Llegados a este punto, la conclusión era clara: no se trataba de un problema de configuración, sino de arquitectura.
En lugar de pedir al equipo que adaptara su comportamiento, diseñamos la integración en torno a lo que ya hacían bien.
Slack seguiría siendo el centro operativo de soporte. HubSpot se convertiría en el registro autorizado automáticamente, en segundo plano, sin pasos manuales.
La idea central era simple: si una conversación ocurre en un canal de soporte de Slack, debería existir en HubSpot por defecto.
La solución se basa en una aplicación Slack personalizada que escucha de forma inteligente, en lugar de agresiva.
Descubre automáticamente los canales de Slack basándose en una convención de nomenclatura (por ejemplo, los canales que terminan en -support). Esto significa que los nuevos canales de los clientes se detectan automáticamente, sin necesidad de crear nuevos flujos de trabajo o integraciones cada vez.
Cuando se publica un mensaje en uno de esos canales, se crea un ticket en HubSpot. La integración intenta hacer coincidir el usuario de Slack con un contacto existente y asocia el ticket en consecuencia. El ID del canal de Slack se almacena en el ticket para que las futuras actualizaciones sepan exactamente a dónde ir.
A partir de ahí, los hilos de Slack se convierten en la columna vertebral de la conversación del ticket. El primer mensaje crea el ticket; las respuestas en el hilo se registran como correos electrónicos en el ticket. El sistema detecta si un mensaje procede de un cliente o de un miembro del personal y lo registra como entrante o saliente.
Un detalle pequeño pero crítico: en el momento en que un agente de soporte responde en Slack, se convierte automáticamente en el propietario del ticket en HubSpot. La propiedad refleja la realidad, no las reglas de asignación manual.
La integración no se detiene en el registro de mensajes.
Cuando un agente de soporte responde a un cliente por correo electrónico directamente desde HubSpot, ese correo electrónico se vuelve a publicar en la conversación original de Slack. El texto entrecomillado y las firmas se eliminan para que el mensaje siga siendo legible y relevante en Slack.
Cuando se cierra un ticket en HubSpot, Slack recibe una notificación en el mismo hilo. La conversación parece continua, aunque haya dos sistemas implicados.
Para el equipo de soporte, parece que Slack simplemente "sabe" lo que está pasando en el CRM.
Uno de los resultados más valiosos de este proyecto no tiene nada que ver con Slack: La precisión de los SLA.
Antes de la integración, los informes de tiempo de respuesta eran técnicamente correctos pero operativamente engañosos. Los tickets parecían tener primeras respuestas medidas en días, cuando en realidad el equipo había respondido en minutos, sólo que no dentro de la lógica de horas laborables del CRM.
Al alinear las marcas de tiempo de Slack con los cálculos de SLA de HubSpot, las horas de oficina y los fines de semana, los números finalmente dijeron la verdad. Lo que antes parecía un retraso de dos días se reveló como una respuesta de cinco minutos.
Esa única corrección cambió por completo la percepción interna del rendimiento.
Después del despliegue, nada cambió para el equipo de soporte - y ese era el punto.
Permanecieron en Slack. Las conversaciones siguieron siendo naturales. Los tiempos de respuesta siguieron siendo rápidos.
Lo que cambió fue todo entre bastidores: HubSpot ganó visibilidad completa, los tickets reflejaban conversaciones reales, los SLA se volvieron fiables y los informes finalmente se alinearon con la realidad.
El CRM ya no pedía atención. Se la ganó.
Si tu equipo de soporte utiliza Slack como canal de atención al cliente, trabaja con canales dedicados por cliente y depende de SLA e informes precisos, las integraciones nativas a menudo no serán suficientes.
En esos casos, el valor real proviene del diseño de sistemas en torno al comportamiento humano, no de obligar a los humanos a trabajar en torno a los sistemas.
Eso es exactamente para lo que se ha creado esta integración. Si cree que esta integración es lo que t equipo necesita, reserve una reunión rápida con nosotros para saber cómo podemos implementarla también para tu equipo.