Cómo redactar respuestas a tickets de HubSpot con IA (RAG + OpenAI), y cuándo la IA debe callar

La IA en atención al cliente funciona mejor cuando escribe el primer borrador y un agente humano pulsa enviar. Construimos un sistema de generación aumentada por recuperación (RAG) que redacta respuestas a tickets de HubSpot con OpenAI para el equipo de soporte de una empresa dental del Reino Unido, usando solo respuestas que el equipo ya había aprobado. En las seis semanas posteriores al lanzamiento, el tiempo medio de primera respuesta bajó un 42 % y el tiempo medio de cierre de un ticket bajó un 59 %, mientras el equipo gestionaba un 41 % más de tickets al día. La IA redacta un borrador completo en aproximadamente la mitad de los tickets y calla en el resto, que es como está diseñada. Así funciona, qué consiguió, cuánto cuesta un ticket y dónde se queda corta la inteligencia artificial en el servicio al cliente.

Los resultados: respuestas más rápidas con más carga de trabajo

El sistema se puso en marcha el 10 de agosto de 2026. El cliente comparó los 100 días anteriores (del 2 de mayo al 9 de agosto) con los 44 posteriores (del 10 de agosto al 22 de septiembre):

Los tiempos de respuesta mejoraron en todos los percentiles, de los tickets más rápidos a los más lentos: el percentil 90 pasó de unas 67 horas a unas 51.

Hay tres matices que van junto a esas cifras:

• Es una comparación antes/después, no una prueba controlada. El comportamiento de los clientes se mantuvo estable (1,14 tickets por cliente antes y 1,15 después) y el sistema de borradores fue el cambio principal del periodo, pero no se pueden descartar otros factores. Las cifras proceden de los informes internos del cliente.
• La IA redacta aproximadamente la mitad de los tickets. Escribió un borrador completo en el 52,1 % de los tickets. En el resto, el agente recibe un resumen del hilo hecho por la IA y los datos del cliente, y escribe la respuesta.
• Todavía no podemos decir cuántos borradores se envían sin editar. Los agentes valoraron solo 59 de unos 1.600 tickets, una muestra demasiado pequeña y autoseleccionada para sacar una tasa.

Qué debe hacer la IA en atención al cliente (y qué no)

Casi todas las conversaciones sobre IA en la empresa empiezan por sustituir personas. En atención al cliente ese enfoque produce los dos fallos que todo el mundo ha visto: un bot que afirma con seguridad una política de reembolso que no existe y un cliente que no consigue hablar con nadie.

Este sistema hace algo más acotado. Cuando llega un ticket de soporte, la IA lo lee y prepara una respuesta sugerida dentro de HubSpot. El agente la lee, la corrige si hace falta y la envía. La IA nunca envía nada al cliente.

Esa única decisión cambia lo que significa hacerlo bien:

• Un borrador erróneo cuesta segundos, no un cliente. El agente lo detecta antes de que salga.
• "No lo sé" es una respuesta válida. La IA puede no generar borrador, y esa resulta ser la señal más útil de todo el sistema.
• La responsabilidad sigue en el agente. La IA apoya al equipo de soporte; no lo sustituye.

La tecnología

Con este tamaño no hace falta una base de datos vectorial. Con una base de conocimiento de pocos cientos de documentos, comparar todos los vectores en memoria lleva milisegundos.

La arquitectura: un flujo RAG con una persona al final

HubSpot envía un webhook cada vez que cambia un ticket. El webhook solo encola el trabajo y responde al momento; un proceso en segundo plano hace el resto:

1. Primero, reglas simples. Los tickets cerrados, los vacíos y las notificaciones internas automáticas se descartan con código antes de llamar a ningún modelo de IA.
2. Leer el hilo. Se limpian las respuestas citadas y las firmas del correo. Si el último mensaje es del equipo de soporte, no hay pregunta abierta y no se intenta ningún borrador.
3. Buscar al cliente. El contacto de HubSpot del ticket se cruza con los registros de la empresa para montar un bloque breve de datos verificados: fecha de compra, plan de pago, fase del pedido y citas.
4. Analizar el ticket. Una llamada a GPT-4o mini devuelve el tema, un resumen corto, una de 17 categorías, el tipo de remitente y las preguntas distintas que contiene el mensaje. El spam se queda aquí.
5. Recuperar los documentos. Se buscan en la base de conocimiento los 12 documentos con más probabilidad de responder al ticket.
6. Generar el borrador. Una segunda llamada redacta la respuesta usando solo esos documentos y los datos verificados del cliente, o se abstiene.
7. Mostrarlo al agente. Una tarjeta dentro del ticket de HubSpot muestra el resumen, el borrador y las notas internas para el agente.

El modelo responde con una estructura fija, no con texto libre:

{
  "can_draft": true,
  "abstain_reason": "",
  "draft_text": "Hello Sarah,\n\nYour refund was approved on ...\n\nKind regards,",
  "used_document_ids": [42],
  "uncovered_topic": ""
}

can_draft: false es un resultado normal, y used_document_ids registra de qué documentos aprobados salió la respuesta.

Recuperación: por qué combinar palabras clave y embeddings

La recuperación es la "R" de RAG, y es donde muchos proyectos de IA para atención al cliente fallan sin que se note. Si el documento correcto no llega al modelo, el modelo no puede usarlo.

Hacemos dos búsquedas y las combinamos:

• Búsqueda por palabras clave (BM25): encuentra términos exactos, como el nombre de un producto, una financiera o un término concreto de una política.
• Búsqueda semántica (embeddings de OpenAI y similitud del coseno): encuentra significado, de modo que "quiero que me devuelvan el dinero" localiza un documento titulado "¿Cuánto tarda un reembolso?".

Los dos rankings se combinan con fusión de rangos recíprocos, así que un documento que cualquiera de las dos búsquedas sitúe arriba entra en la lista. Si una búsqueda no está disponible, la otra sigue sola. Una búsqueda caída nunca hace que se descarte un documento.

Dos decisiones pesaron más que el algoritmo:

• Una pregunta por documento, con la pregunta como título. Los documentos se escriben como pregunta el cliente, que es justo lo que compara la recuperación.
• La similitud del coseno solo forma la lista de candidatos. No decide si un ticket tiene respuesta. Eso lo decide el modelo de lenguaje después de leer los documentos.

Cómo evitamos que la IA se invente cosas

El paso de generación funciona con unas pocas reglas:

• Datos solo de documentos aprobados. El modelo no puede afirmar un precio, una fecha o un plazo que no aparezca en un documento recuperado.
• Datos del cliente solo de la base de datos. La fecha de compra, el plan de pago y las citas salen de los registros de la empresa, nunca de lo que escribió el cliente.
• Los huecos se quedan a la vista. Si un documento dice [Importe del reembolso] y no se dispone del dato, el marcador se queda en el borrador para que lo complete el agente. Un hueco visible es más seguro que una cifra inventada.
• El texto del cliente son datos, no instrucciones. El ticket va delimitado en el prompt, así que "ignora tus instrucciones anteriores" se trata como algo que escribió un cliente, no como una orden.
• Las notas internas nunca llegan al modelo. Cada documento puede llevar una nota para agentes ("comprueba la fecha del contrato antes de enviar"). El agente la ve en la tarjeta de HubSpot. El modelo no la recibe, así que no puede colarse en una respuesta.

Un hallazgo de las pruebas que merece la pena compartir: cuando un ticket tenía varias preguntas y pedíamos al modelo que las valorase todas en una sola llamada, se abstenía en torno al 64 % de los tickets de prueba que debería haber redactado. Comprobar cada pregunta en su propia llamada y redactar después una única respuesta conjunta lo resolvió.

Cuando la IA se abstiene, la base de conocimiento mejora

Cada ticket que la IA no puede responder indica que falta algo en la base de conocimiento. Lo convertimos en una lista de trabajo:

1. Cada dos semanas se recogen los tickets en los que la IA se abstuvo. Se excluyen el spam, los tickets ya respondidos y los mensajes que no son de clientes.
2. Los temas se agrupan por significado con los mismos embeddings, de modo que diez formas de hacer la misma pregunta son una sola laguna.
3. Una laguna entra en la lista cuando ha aparecido en tres tickets distintos.
4. Alguien del equipo de soporte escribe la respuesta aprobada. Al guardarla se crea un documento nuevo en la base de conocimiento, y la IA ya redacta con él en el siguiente ticket.
5. Si la IA sigue absteniéndose en un tema que ya tiene respuesta, la laguna se reabre, porque el documento nuevo no está cumpliendo su función.

Los agentes también pueden valorar cada borrador como correcto o incorrecto, con un motivo cuando es incorrecto. Esos avisos alimentan una segunda lista: los documentos que producen malos borradores. La primera lista muestra lo que la IA no sabe responder. La segunda, lo que responde mal.

Este ciclo es la vía prevista para que suba la cobertura del 52,1 %: cada laguna resuelta pasa un grupo de tickets de "solo resumen" a "con borrador".

Cuánto cuesta un ticket

No hay licencias por usuario para la IA, solo el consumo de la API de OpenAI. Son estimaciones a partir de precios de tarifa publicados (GPT-4o mini a 0,15 $ por millón de tokens de entrada y 0,60 $ por millón de tokens de salida; text-embedding-3-small a 0,02 $ por millón de tokens), no importes facturados.

Supuestos por llamada:

• Análisis: unos 2.500 tokens de entrada (instrucciones, la lista de categorías y el ticket) y unos 150 de salida.
• Borrador: unos 4.900 tokens de entrada (reglas, 12 documentos de unos 200 tokens cada uno, datos del cliente y el ticket) y unos 250 de salida.
• Embeddings: unos 300 tokens por el ticket. Los embeddings de los documentos están en caché.

Coste estimado por ticket:

Eso son unos 1,40 $ por cada 1.000 tickets de una sola pregunta. Un ticket se vuelve a procesar cada vez que el cliente responde, así que la cifra real por ticket es varias veces mayor, y aun así deja a un equipo de soporte de este tamaño con una factura de IA de unos pocos dólares al mes. El coste del proyecto está en la construcción y en la base de conocimiento, no en el modelo.

Un modelo pequeño es suficiente porque los datos salen de los documentos y no de la memoria del modelo.

Dónde se queda corto

Los borradores con IA no sirven para todo:

• La mitad de los tickets sigue sin borrador. La cobertura depende de la base de conocimiento, y crece respuesta aprobada a respuesta aprobada.
• No ve imágenes. Los clientes adjuntan fotos a menudo. La tarjeta avisa de que el hilo contiene una imagen para que el agente la revise.
• Vale lo que valga la base de conocimiento. Un documento vago o erróneo produce borradores vagos o erróneos en todos los tickets con los que encaje.
• Necesita datos de cliente limpios. Si el ticket no se puede asociar a un registro de cliente, el borrador no tiene datos personales con los que trabajar.
• Cuesta recoger valoraciones. Valorar un borrador es opcional y pocos agentes lo hacen. Además, un "correcto" vale menos que un "incorrecto", porque un agente que no conoce la respuesta puede dar por bueno un error escrito con seguridad.

Cuándo usar borradores con IA, un chatbot o ninguno

El patrón no es exclusivo del sector dental ni de HubSpot. El mismo diseño RAG encaja en cualquier equipo de soporte que responda una y otra vez las mismas preguntas a partir de un conjunto de respuestas aprobadas: clínicas, aseguradoras, financieras, comercio electrónico o software.

En ScaleWave construimos IA para atención al cliente que redacta a partir de tus propias respuestas aprobadas y mantiene a tus agentes al mando. Si tu equipo pasa el día reescribiendo las mismas respuestas en HubSpot o en otra herramienta de soporte, estaremos encantados de revisar tus tickets y enseñarte qué parte podría asumir un sistema de borradores con IA.