Caso Hospitable: automatizar consultas de soporte sin cerrar la puerta al equipo

Qué enseña el despliegue de Fin en una plataforma para alojamientos y cómo acotar una primera automatización de soporte.

Equipo enginerIT· 3 min de lectura
Conocimiento, resolución y escalado conectados

Hospitable desarrolla software para gestores de alojamientos y recibe preguntas de clientes que trabajan fuera del horario habitual. En el caso publicado por Intercom, la empresa describe el uso de Fin para absorber preguntas de soporte apoyándose en su centro de ayuda y transferir a una persona cuando el conocimiento no cubre la consulta. Intercom atribuye al despliegue la resolución inmediata de 500 consultas acumuladas, un 30% de resolución automática de las preguntas recibidas y una reducción del 95% en tiempo de respuesta. Son cifras comunicadas por proveedor y cliente, no una garantía que pueda trasladarse a otra pyme.

El problema era una cola concreta

El ejemplo no plantea sustituir toda la atención: aborda consultas repetidas y un atasco existente. Para una pyme, el equivalente puede ser el estado de un pedido, una política de devolución o instrucciones de acceso. Empieza midiendo ese grupo, su volumen y el tiempo que espera.

La base de conocimiento alimenta la respuesta

Fin se apoya en artículos de ayuda que la empresa ya mantenía. Eso desplaza parte del trabajo hacia revisar vigencia, contradicciones y huecos documentales. Si la regla de cancelación aparece en dos versiones, automatizar la respuesta amplifica la incoherencia en lugar de resolverla.

La derivación forma parte del diseño

El caso describe que una pregunta no cubierta se enruta a soporte para que una persona continúe. Copia el contexto útil, el tema y la fuente consultada para evitar pedir al cliente que empiece de cero. Define también qué sucede cuando el equipo humano está fuera de horario.

Resolver no es lo mismo que responder

Una contestación enviada no prueba que el cliente haya completado su tarea. Separa respuesta generada, confirmación del usuario y cierre real. Audita una muestra para comprobar si hubo recontacto, corrección o una acción posterior que quedó sin completar.

La métrica necesita denominador

La resolución automática publicada debe interpretarse junto con consultas elegibles, conversaciones participantes y periodo de medición. Aclara qué cuenta como resolución, si hubo encuesta y cómo se trata una reapertura. Para comparar tu piloto, conserva el mismo criterio antes y después.

Un producto software facilita delimitar la fuente

Una empresa que ya centraliza artículos y tickets puede controlar qué contenido consulta el agente. Una pyme con respuestas dispersas por correos y carpetas necesita ordenar primero sus reglas y asignar un dueño a cada artículo. El tiempo de esa preparación también forma parte del coste.

Adapta el patrón a una pyme

Selecciona un tema de alto volumen y bajo impacto, conecta solo la fuente aprobada y activa derivación ante excepciones o ausencia de respuesta. Prueba con conversaciones reales anonimizadas, sin acceso a pagos ni cambios de reserva al inicio. Revisa calidad junto a la velocidad.

Comprueba capacidad de atención posterior

Si las respuestas automáticas provocan más seguimientos, el cuello de botella puede trasladarse al equipo humano. Mide casos escalados, recontactos y tiempo hasta resolución completa. Asegura que alguien tenga capacidad para cubrir la cola antes de aumentar el porcentaje automatizado.

Qué pedir antes de replicar el caso

Solicita datos sobre alcance, fuentes, periodo, porcentaje de escalados, revisiones y costes incluidos. Contrasta qué dependía de una base de conocimiento madura y de la integración existente. Usa el caso para formular preguntas de diseño, no para prometer un 30% de resolución en tu propia operación.

Fuentes y documentación

Elige una categoría de preguntas repetidas y revisa sus respuestas oficiales.

Una fuente coherente y una derivación clara son el punto de partida del piloto.

Cuéntanos qué necesitas →