La idea suele llegar expresada más o menos así: “Queremos que la IA responda las consultas frecuentes de nuestros clientes”.
Suena razonable. Incluso simple. Conectamos el chat, cargamos los documentos de la empresa y dejamos que la IA haga lo suyo.
Hasta ahí, todo bien. El problema aparece después.
Una conversación real no llega ordenada como una pregunta frecuente. Puede mezclar una cotización con una factura, omitir un antecedente técnico o pedir una decisión que compromete a la organización. Entonces la pregunta cambia: ya no es sólo qué puede responder la IA, sino hasta dónde debería llegar antes de entregarle la responsabilidad a una persona.
HubSpot llama Customer Agent al agente de IA que conecta conocimiento y canales de atención. El caso ANAM nos permitió llevar esa idea a terreno concreto: fuentes, instrucciones, memoria, transferencias, pruebas y una operación que también tenía que demostrar su disponibilidad.
Mi lectura de este caso es simple: el trabajo difícil no es enseñarle a la IA a responder. Es decidir con evidencia qué puede responder sola y qué debe conservar para una persona.
Respuesta corta: para atender bien, una IA necesita fuentes gobernadas, memoria conversacional, límites explícitos, transferencia humana con contexto, pruebas de varios turnos y un canal realmente disponible. Si falta una de esas piezas, puede producir respuestas convincentes sin sostener una atención confiable.
Ahí está el criterio: la IA para atención al cliente no se vuelve confiable por responder más. Se vuelve confiable cuando también reconoce qué necesita preguntar, qué no puede prometer y cuándo debe detenerse.
Tabla de contenidos
- ¿Qué es un Customer Agent y en qué se diferencia de un chatbot?
- ¿Qué problema debía resolver el Customer Agent de ANAM?
- ¿Por qué cargar documentos no crea una buena respuesta?
- ¿Cómo se diseñó una base de conocimiento de 23 fuentes?
- ¿Por qué el cliente ve tres intenciones y el agente opera con cinco?
- ¿Qué debe recordar y qué no puede prometer una IA?
- ¿Cuándo transferir a una persona es la respuesta correcta?
- ¿Cómo se prueba una conversación y no sólo una respuesta?
- ¿Qué limitaciones aparecieron durante la implementación?
- ¿Por qué configurado, probado y operativo son estados distintos?
- Entonces, ¿qué necesita una IA para atender bien a tus clientes?
¿Qué es un Customer Agent y en qué se diferencia de un chatbot?
Vamos por partes.
El Customer Agent de HubSpot es un agente de IA conectado a los canales y al conocimiento de una empresa. Puede responder consultas, reunir antecedentes y transferir la conversación cuando se necesita intervención humana.
HubSpot lo describe como un agente impulsado por Breeze que utiliza el contenido existente de la organización para responder preguntas. Si no conoce una respuesta, puede pedir que se reformule la consulta o transferir la conversación a una persona. La plataforma también permite definir fuentes de contenido y configurar la transferencia humana (handoff).
¿Dónde está la diferencia? Un chatbot tradicional suele conducir al visitante por árboles, botones o respuestas predefinidas. Un agente interpreta lenguaje natural y recupera información desde distintas fuentes. Puede manejar más variaciones y conversaciones menos ordenadas.
Esa flexibilidad es justamente lo que lo vuelve más útil. Y también más delicado. Si interpreta mal una intención, elige una fuente incorrecta o avanza más allá de lo que la empresa puede respaldar, el problema ya no es una mala respuesta automática. Es una conversación atendida bajo una premisa falsa.
Por eso no basta con preguntar qué sabe hacer la IA. También hay que resolver cuatro preguntas:
- ¿Con qué fuentes puede responder?
- ¿Qué contexto debe pedir y recordar?
- ¿Qué no puede prometer y cuándo debe transferir?
- ¿Cómo comprobaremos que la operación funciona de verdad?
Prefiero, entonces, pensar en un Customer Agent como una operación, no como una caja de respuestas. Tiene que saber qué responder, pero también hasta dónde puede llegar.
¿Qué problema debía resolver el Customer Agent de ANAM?
ANAM necesitaba orientar consultas técnicas y administrativas, reunir el contexto mínimo para avanzar y transferir sólo las acciones que requerían intervención humana. El desafío era hacerlo sin convertir el chat en un formulario interminable y sin pedirle al cliente que comenzara de nuevo cuando interviniera una persona.
En el primer artículo de esta serie sobre dashboards confiables en HubSpot mostramos por qué un dashboard convincente no demuestra que los datos debajo sean confiables. Con el Customer Agent apareció el mismo principio en otra superficie: una respuesta convincente tampoco demuestra que el sistema debajo pueda sostenerla.
Las conversaciones podían seguir rutas técnicas o administrativas. Algunas llegaban limpias. Otras mezclaban necesidades: por ejemplo, solicitar una cotización y corregir una factura anterior dentro del mismo mensaje.
Ahí aparece una diferencia que me parece central: automatizar respuestas no es lo mismo que diseñar atención. Una respuesta puede ser correcta de forma aislada y aun así producir una mala experiencia. Basta con que el agente pregunte lo mismo dos veces, transfiera demasiado pronto o prometa algo que el equipo no puede cumplir.
En Efeonce abordamos el Customer Agent separando el problema en piezas. La identidad y el tono eran una; el conocimiento, otra. Las instrucciones, la memoria, las acciones, la transferencia humana, el canal y la medición también necesitaban su propio diseño y su propia prueba.
Un prompt no reemplaza una arquitectura operativa.
¿Por qué cargar documentos no crea una buena respuesta?
Cargar documentos se siente como progreso porque es visible: antes no había fuentes; ahora las hay. Pero los documentos sólo cubren aquello que el agente puede recuperar. No definen por sí solos cómo debe preguntar, qué debe recordar, cuándo necesita detenerse ni cómo transferirá una conversación.
Imaginemos que una fuente describe los plazos estándar de un análisis y otra conversación pregunta por la fecha de entrega de un servicio ya contratado. El agente puede conocer el plazo de referencia y, al mismo tiempo, no tener autoridad para comprometer una fecha concreta. Si ambos conceptos se mezclan, una respuesta aparentemente útil puede transformarse en una promesa operacional.
Lo mismo ocurre con una factura. El agente puede explicar condiciones administrativas documentadas o reunir una referencia. Eso no significa que pueda corregir un documento, confirmar una refacturación o asegurar el resultado de una revisión.
La forma más clara de verlo es separar siete piezas:
- Identidad y tono: cómo se presenta y conversa.
- Conocimiento: qué fuentes puede utilizar.
- Instrucciones: cómo clasifica, pregunta y resume.
- Memoria conversacional: qué antecedentes conserva durante el diálogo.
- Acciones: qué puede ejecutar realmente en un sistema.
- Transferencia humana: cuándo y cómo entrega la responsabilidad.
- Canal y operación real: dónde atiende y si el servicio está disponible.
En el corte revisado, ANAM tenía conocimiento, directrices, transferencia humana y canal configurados. No tenía acciones publicadas. Había dos borradores, sí, pero un borrador todavía no hace nada.
Parece una precisión menor. No lo es. Tratar un borrador como capacidad activa nos llevaría a decir que el agente puede consultar facturas, servicios o sistemas externos cuando, en realidad, todavía no tiene ese acceso.
¿Cómo se diseñó una base de conocimiento de 23 fuentes?
La base de conocimiento se diseñó organizando cada fuente por función, autoridad y vigencia, no por la carpeta o el correo donde apareció.
Veintitrés fuentes suena a una base robusta. Puede serlo. Pero el número, por sí solo, dice poco. Lo que importa es si esas fuentes se contradicen, quién responde por su vigencia y para qué tipo de decisión sirve cada una.
El inventario verificado contenía 23 fuentes en uso:
- seis archivos privados en Markdown;
- 17 respuestas cortas para situaciones críticas o formulaciones recurrentes.
Los seis archivos cubrían empresa, servicios y normas, preguntas frecuentes, cotización y captura de antecedentes, seguimiento/facturación/calidad y un catálogo técnico. Este último conservaba 356 registros técnicos. No eran 356 servicios ni 356 promesas de disponibilidad: eran registros que debían interpretarse junto con la matriz, la norma y el objetivo de la consulta.
Las respuestas cortas cumplían otro trabajo. Permitían tratar situaciones específicas —especialmente administrativas— con un lenguaje más directo. Aun así, no se asumió que una respuesta entrenada aparecería ante cualquier formulación humana. Esa conducta debía comprobarse conversando.
Antes de sincronizar, las fuentes se reconciliaron para evitar contradicciones. También se mantuvieron privadas: podían alimentar las respuestas, pero no aparecerían como citas públicas para el visitante. HubSpot advierte que el contenido privado puede utilizarse en la respuesta aunque no se cite, una razón adicional para excluir datos personales, confidenciales o sensibles.
Mi forma de resumirlo es ésta: una base de conocimiento no es un depósito de documentos. Es una arquitectura de decisiones. Cada fuente necesita propósito, vigencia, responsable y una regla para resolver contradicciones.
¿Por qué el cliente ve tres intenciones y el agente opera con cinco?
El cliente ve tres intenciones porque la interfaz debe simplificar la entrada; el agente conserva cinco rutas porque la operación necesita distinguirlas. Parece un detalle de interfaz. En realidad, define cuánto trabajo le traspasamos al cliente.
La página de entrada de ANAM ofrecía tres puertas visibles:
- Cotizar;
- Seguimiento del Servicio;
- Requerimientos de Calidad.
El agente, en cambio, clasificaba cinco rutas: Información, Cotización, Seguimiento, Facturación y Calidad. La diferencia era deliberada. Una consulta de facturación podía aparecer dentro de un seguimiento o en un mensaje libre. La información general tampoco necesitaba convertirse en un botón adicional para ser atendida.
El cliente no debería aprender nuestro organigrama ni escoger la ruta interna correcta para obtener ayuda. Debería poder explicar lo que necesita. El trabajo de separar las rutas le corresponde al sistema.
Una de las pruebas combinó una cotización de agua potable con la corrección de una factura anterior. El agente distinguió la necesidad técnica de la gestión administrativa en vez de tratarlas como una sola solicitud. Esa capacidad es más valiosa que un menú perfecto: permite conservar la conversación mientras cambia la responsabilidad.
¿Qué debe recordar y qué no puede prometer una IA?
El agente debía recordar los antecedentes relevantes que el cliente ya había entregado, sin convertir esa memoria en autoridad para decidir. En el diseño de ANAM eso incluía, según la conversación, empresa, identificación proporcionada, servicio, matriz, norma, referencias y montos mencionados.
Es algo que cualquier persona espera de una conversación: no tener que repetir lo que acaba de decir. Con una IA debería ocurrir lo mismo.
La memoria evita preguntas repetidas y mejora el resumen antes de una transferencia. Pero recordar un dato no le da autoridad para decidir sobre él.
Pedir una aclaración tampoco equivale a fallar. En dos experimentos publicados en Journal of Business Research —con 386 casos analizados entre participantes estadounidenses—, un chatbot que pedía aclarar un malentendido obtuvo resultados perceptuales similares a uno sin errores; dejar el error sin resolver sí redujo la intención de adopción. El estudio utilizó un escenario ficticio y no evaluó HubSpot ni el caso ANAM, pero refuerza una decisión prudente: ante una ambigüedad, preguntar es más responsable que completar el vacío con una suposición.
Ojo: memoria no es autoridad.
El agente no debía prometer:
- precios finales;
- fechas comprometidas;
- refacturaciones o correcciones;
- la solución de un reclamo;
- interpretaciones legales o de cumplimiento;
- resultados técnicos;
- disponibilidad no documentada;
- acciones que todavía no había ejecutado.
Esta última regla es especialmente importante. Decir “registré tu solicitud” parece una cortesía inocente, pero se convierte en una afirmación falsa si ninguna acción creó el registro. Un agente confiable distingue entre lo que explicó, lo que reunió y lo que realmente ejecutó.
¿Cuándo transferir a una persona es la respuesta correcta?
Una transferencia es correcta cuando la conversación requiere juicio, acceso operativo o capacidad de comprometer a la organización, y el agente ya reunió el contexto mínimo para que una persona pueda continuar.
Es fácil leer esa transferencia como una falla: si llegó a una persona, la IA no resolvió. Yo la veo de otra manera.
No debería ocurrir sólo porque el visitante escribió “factura”, “urgente”, “reclamo” o “cotización”. Primero puede existir información útil que el agente sí está en condiciones de entregar. Transferir ante la primera palabra sensible aumenta la carga del equipo y deja al cliente con la impresión de que la IA era apenas una puerta de entrada.
En Efeonce usamos una frontera de autonomía conversacional para ordenar esa decisión:
| Zona | Qué ocurre | Quién conserva la responsabilidad |
|---|---|---|
| Saber | La respuesta está documentada y no implica una decisión sensible. | Agente |
| Aclarar | Existe conocimiento, pero faltan antecedentes para aplicarlo. | Agente |
| Preparar | Se necesita una acción humana; el agente reúne y resume el contexto. | Agente → persona |
| Decidir | Se requiere juicio, acceso a sistemas o un compromiso de la organización. | Persona |
No es un embudo ni obliga a que cada conversación pase por las cuatro zonas. Sirve para reconocer dónde está la responsabilidad en cada momento.
Una buena transferencia puede evaluarse con cinco preguntas:
- ¿Era realmente necesario?
- ¿Ocurrió en el momento correcto?
- ¿El agente reunió el contexto mínimo?
- ¿Entregó un resumen útil?
- ¿La persona puede continuar sin pedir que el cliente repita todo?
Esa continuidad importa también fuera de este caso. En una encuesta realizada por Zendesk en junio de 2025 a 6.182 consumidores de 22 países —entre ellos Chile—, 74% declaró frustrarse cuando debe repetir información durante la atención. Es una percepción declarada por consumidores, no una medición causal del handoff, pero ayuda a entender por qué transferir contexto forma parte de la experiencia y no sólo de la eficiencia interna.
HubSpot permite configurar guías personalizadas de transferencia y contempla disparadores por defecto cuando el agente no puede responder, el visitante pide hablar con una persona o el agente está pausado. En ANAM, además, se diseñó una transferencia hacia Help Desk con un responsable funcional.
Hasta acá llega el punto que me interesa: transferir no es fracasar. Es preservar la responsabilidad cuando la conversación cruza el límite de la evidencia.
¿Cómo se prueba una conversación y no sólo una respuesta?
Se prueba con escenarios de varios turnos que exijan memoria, lenguaje natural, intención mixta, manejo de frustración, transferencia y recuperación ante fallas. Aquí es donde una demo y un sistema empiezan a separarse: una respuesta correcta, aislada, no demuestra que el agente pueda sostener una conversación.
Para ANAM se definió un guion de 39 escenarios. Esa cifra describe el diseño de la batería, no 39 pruebas ejecutadas. La evidencia recuperable permite sostener un mínimo de 24 escenarios distintos y 35 turnos o ejecuciones durante la sesión revisada.
La batería técnica conjunta acreditó 19 escenarios satisfactorios después de ajustes. Las pruebas cubrieron también materias administrativas, facturación, reclamos, seguimiento e intención mixta.
Los resultados no fueron uniformes:
- el comportamiento administrativo general resultó satisfactorio;
- la intención mixta separó correctamente las dos necesidades;
- reclamo y seguimiento resultaron satisfactorios con una limitación;
- facturación mostró un resultado favorable y otro parcial.
En algunas iteraciones, el agente reunió contexto antes de transferir. En otras, la transferencia nativa de HubSpot se anticipó a la aclaración que habíamos diseñado. Esa limitación no se ocultó ni se convirtió en una conclusión universal sobre la plataforma. Se registró como un comportamiento observado en ese corte y como una regresión pendiente.
Tampoco contábamos con una exportación completa de las transcripciones para reconstruir cada conversación. Por eso el informe utiliza la fórmula mínimo verificable y evita presentar una cobertura estimada como una medición.
Lo valioso del QA no fue confirmar que la respuesta ideal aparecía ante la pregunta ideal. Fue encontrar estos bordes. Si una prueba no incomoda al agente, probablemente está evaluando una demo, no una atención real.
¿Qué limitaciones aparecieron durante la implementación?
Encontramos seis límites que afectaban lo que podíamos afirmar sobre el agente. No invalidaban la implementación, pero sí obligaban a describirla con precisión:
- la transferencia nativa podía anticiparse a una aclaración entrenada;
- la vista previa no representaba toda la identidad CRM de un cliente real;
- una respuesta corta no garantizaba el mismo comportamiento ante cualquier formulación;
- el mensaje prellenado desde la página de entrada no era suficientemente confiable para tratarlo como contrato;
- faltaba una exportación completa de las transcripciones para reconstruir toda la sesión;
- dos acciones permanecían como borradores y, por tanto, no constituían capacidad activa.
Ojo con el alcance: son observaciones del corte evaluado, no defectos universales de HubSpot. Algunas pueden cambiar con nuevas versiones, configuración adicional o pruebas desde un contacto real.
Hasta aquí podemos decir qué ocurrió en ANAM. No podemos transformar ese recorte en una verdad general sobre la plataforma. Lo que sí corresponde es documentar la frontera y evitar que una posibilidad del producto se presente como una capacidad ya disponible en la cuenta.
¿Por qué configurado, probado y operativo son estados distintos?
Configurado, probado y operativo son estados distintos porque cada uno exige una evidencia diferente. Tener una configuración visible no demuestra que una conversación nueva pueda entrar, resolverse, transferirse y medirse.
El contraste con las cifras agregadas del proveedor es útil. HubSpot reportó en abril de 2026 que Customer Agent resolvía 65% de las conversaciones y reducía 39% el tiempo de resolución entre más de 8.000 clientes que lo habían activado. Son resultados informados por el fabricante, sin distribución ni metodología pública suficiente para extrapolarlos, y no describen el desempeño de ANAM.
También importa qué significa resolver. En la documentación vigente de HubSpot, la plataforma evalúa una conversación 72 horas después de la última respuesta del agente y exige que no haya ocurrido una transferencia humana durante esa ventana. Una cifra de resolución, por tanto, necesita definición, período y contexto antes de convertirse en evidencia.
Y después llegó la prueba más incómoda: la que no se resuelve dentro de la vista previa.
| Estado | Pregunta que debe responder la evidencia | ANAM al corte |
|---|---|---|
| Documentado por el proveedor | ¿HubSpot describe la capacidad? | Sí |
| Elegible en el portal | ¿La cuenta muestra la superficie? | Sí |
| Configurado | ¿Conocimiento, directrices, transferencia y canal están presentes? | Sí |
| Probado en vista previa | ¿Se observaron escenarios y límites? | Sí, con limitaciones |
| Verificado en operación real | ¿Acepta conversaciones nuevas reales y permite medir resultados? | No |
Al 17 de julio de 2026, el agente conservaba sus 23 fuentes, directrices, transferencia y canal. El canal de chat estaba configurado para todas las horas y 100% de cobertura. Eso describe la configuración, no una atención efectiva 24/7.
El portal mostraba las conversaciones nuevas en pausa. El bloqueo observado era una dependencia administrativa de facturación que debía resolver ANAM antes de reactivar el uso, reanudar el agente y verificar una conversación nueva real. Este artículo no publica números, montos, fechas ni otros datos sensibles de la cuenta.
Por eso, aunque resulte menos atractivo para un caso de éxito, el estado correcto es éste: Customer Agent configurado y probado en vista previa, pero no operativo para conversaciones nuevas al corte.
Y precisamente por eso vale la pena contarla. Un sistema no se vuelve operativo porque completamos la configuración o porque una demo funcionó. La operación real también forma parte del resultado.
Entonces, ¿qué necesita una IA para atender bien a tus clientes?
Si tuviera que condensar todo el caso en una respuesta, sería ésta: necesita mucho más que documentos y un chat.
Necesita conocimiento gobernado. Instrucciones que separen intención y responsabilidad. Memoria suficiente para no empezar de nuevo. Límites explícitos, transferencia con contexto, pruebas de varios turnos y una operación disponible para recibir conversaciones reales.
El caso ANAM no demuestra que un agente deba resolver cada consulta. Demuestra algo más útil: que la autonomía puede diseñarse.
Ahí está la frontera: el agente responde donde existe conocimiento confiable, pregunta donde falta contexto, prepara lo que necesita una persona y se detiene antes de decidir por la organización.
Antes de activar un Customer Agent, revisa cuatro zonas con tu equipo:
- Saber: ¿qué puede responder con evidencia?
- Aclarar: ¿qué antecedentes necesita pedir?
- Preparar: ¿qué contexto puede reunir para una persona?
- Decidir: ¿qué compromisos y acciones deben seguir siendo humanos?
Si esa frontera no está escrita, cargar más contenido sólo hará que la IA responda con más material. No necesariamente con más criterio.
Nota metodológica
Este artículo se basa en el inventario autenticado del portal ANAM, un paquete versionado de las 23 fuentes, las directrices publicadas y el informe de QA del 16 de julio de 2026. Los conteos de prueba se presentan como mínimos verificables cuando no existe evidencia suficiente para sostener una cifra mayor. El estado operativo se revisó nuevamente el 17 de julio de 2026. Las cifras externas contextualizan expectativas de atención, hallazgos experimentales y métricas del producto; no miden el desempeño de ANAM. Los conteos y estados atribuidos al caso provienen exclusivamente del inventario autenticado, la evidencia versionada y el QA descritos en esta nota.
Fuentes oficiales de producto
- HubSpot: entender Customer Agent
- HubSpot: gestionar las fuentes de contenido
- HubSpot: configurar la transferencia humana
- HubSpot: resultados agregados y modelo por resolución, abril de 2026
Evidencia externa consultada
- Sheehan, Jin y Gottlieb: efecto de los errores y las aclaraciones en la adopción de chatbots
- Zendesk CX Trends 2026: contexto continuo en la atención al cliente
Nota de autoría
Este artículo fue desarrollado con apoyo de IA a partir de la tesis y la dirección editorial de Julio Reyes. La selección final de fuentes, la verificación de afirmaciones y esta versión se revisaron bajo su dirección; la publicación se realizó con su aprobación expresa.
