Visibilidad de tickets en el portal de clientes de HubSpot: quién ve cada ticket y cómo controlarlo

¿Cómo funciona la visibilidad de tickets en el portal de clientes de HubSpot?

El portal de clientes (HubSpot ahora llama a la versión actualizada el portal de soporte) es una página de inicio de sesión donde los clientes pueden ver, responder y enviar tickets. Necesita Service Hub Professional o Enterprise. Dos controles independientes deciden lo que un cliente encuentra ahí:

1. Qué tickets pueden ver. Una configuración de permisos combinada con las asociaciones del ticket a contactos y empresas.
2. Qué ven dentro de cada ticket. Las propiedades que muestras como columnas, más el hilo de la conversación.

Construyo las integraciones de eesel, incluida la de HubSpot, y he aprendido que los permisos de HubSpot son solo tan buenos como los datos de asociación que hay debajo. Nuestro agente de HubSpot lee cada ticket junto con los contactos, empresas y negocios asociados a él (documentación de eesel para HubSpot), y una asociación desordenada se nota enseguida en una respuesta confusa. El portal funciona igual. Hace exactamente lo que dicen las asociaciones, y un cliente ve lo que sea que el CRM vincule con él.

Dos límites importan antes de empezar:

• Solo aparecen tickets. Las conversaciones que no están asociadas a un ticket no aparecen. Eso incluye chat, Facebook Messenger, formularios y mensajes de correo de equipo en la bandeja de entrada o el help desk. Pero un ticket no necesita una conversación para aparecer.
• Los archivos adjuntos sensibles se quedan dentro de HubSpot. Con la configuración de Sensitive Data activada, los clientes no pueden abrir esos archivos en el portal.

Fuente: precios de HubSpot Service Hub. Mi artículo sobre precios de HubSpot y la reseña de HubSpot van más allá del portal.

¿Qué Customer Ticket Permission deberías elegir?

En Service > Customer Portal > Tickets, la sección Customer Ticket Permissions tiene tres opciones (documentación de HubSpot):

«Asociado con» tiene un significado más amplio que «enviado». La propia etiqueta de HubSpot dice que los clientes ven los tickets que han «submitted or been added to», así que añadir a un compañero a los contactos de un ticket le da acceso, incluso con la configuración más estricta.

La opción selected es más reciente, y los equipos la pidieron durante años. Una idea de la HubSpot Community de 2024 explica por qué:

"For some customers allowing everyone to see all tickets from everyone else would open a hugh data-security issue, e.g., if some projects we work with are confidential."

svamann, HubSpot Community

Ese es el caso de Selected customers. Para configurarlo, haz clic en Manage contact properties y añade un filtro. Yo crearía una propiedad de casilla dedicada, algo como Portal: sees company tickets, en lugar de reutilizar Job title o Lifecycle stage. Un puesto cambia cuando alguien asciende. Una casilla solo cambia cuando alguien de tu equipo decide que debe cambiar. Una trampa de la documentación: el filtro se aplica al cerrar el panel, pero tienes que guardar la vista para que persista.

Cuando el acceso de empresa está activado, los clientes obtienen dos pestañas: My view (tickets asociados a su contacto) y Organization view (tickets asociados a su empresa principal). También puedes renombrar «Tickets» a algo que digan tus clientes, como Orders, Cases o Requests.

Si vienes de Zendesk, esta es la versión de HubSpot del acceso a tickets a nivel de empresa. Mi guía de soporte B2B en Zendesk y el artículo sobre la configuración del portal de Freshdesk muestran cómo lo gestionan los otros dos.

¿Por qué aparecen los tickets en el lugar equivocado, o no aparecen?

Casi todos los problemas de visibilidad del portal se reducen a las asociaciones. La configuración de permisos solo lee las asociaciones y nada más, así que un ticket con la empresa equivocada asociada aparecerá para las personas equivocadas.

Estas reglas vienen de la documentación de HubSpot sobre asociar registros y asociación automática de empresas:

• Los tickets heredan la empresa principal del contacto. «For tickets, the associated contact's primary company will be automatically associated», salvo que hayas desactivado Associate Ticket to a Contact's Primary Company.
• La primera empresa es la principal por defecto. La empresa que se asoció primero sigue siendo la principal hasta que alguien la cambia.
• En el portal solo cuenta la empresa principal. Organization view muestra los tickets de la empresa principal del cliente. Los tickets de una segunda empresa, no principal, no aparecen ahí, y nada en la configuración muestra a una empresa matriz los tickets de una filial.
• Las empresas se emparejan por el dominio del correo. Con la asociación automática activada, sandra@example.com se une a la empresa cuyo dominio es example.com. Los subdominios crean empresas separadas, así que @example.com y @info.example.com se convierten en dos registros.
• Las direcciones de correo gratuitas normalmente no obtienen empresa. Un contacto de Gmail o Hotmail solo obtiene una empresa si su propiedad Website URL coincide con una.
• Los dominios duplicados hacen que HubSpot elija una empresa por ti. Si dos empresas comparten un dominio, HubSpot elige una y «it is not possible to select which company the contacts should be automatically associated with».

Esta es la trampa que más perjudica a los equipos B2B. Un contacto de un contratista, una agencia o un revendedor tiene su propio empleador como empresa principal. Abre un ticket sobre el proyecto de tu cliente real. El ticket hereda la agencia como su empresa, así que aparece en la Organization view de la agencia, no en la de tu cliente.

Hay una segunda versión de esta trampa. Algunos equipos descubren que HubSpot asocia los tickets con su propio registro de empresa en lugar del del cliente, como describe un hilo de la HubSpot Community. Esto suele pasar cuando tu propio personal figura como contacto en el ticket. La solución es añadir tu propio dominio a la lista de dominios excluidos (HubSpot permite hasta 1,000 dominios excluidos) y mantener a los empleados fuera de los tickets de clientes como contactos.

Cuando un ticket no aparece en absoluto, revisa esto en orden:

1. ¿La conversación está adjunta a un ticket? Los chats y los hilos de Messenger sin ticket nunca aparecen.
2. ¿Está asociado el contacto correcto? Mira la barra lateral del registro del ticket, no la línea De del correo.
3. ¿Lo está ocultando un filtro de visibilidad de tickets? (Más sobre eso más abajo.)
4. ¿Estás probando como un cliente real? Si has iniciado sesión en HubSpot, el portal se salta el login y te muestra el listado de tickets. Prueba en una ventana privada como un contacto real. Un usuario de la HubSpot Community que no podía ver sus tickets de prueba descubrió que «was my cache».
5. ¿Acabas de pasarte a help desk? Un Community Champion reportó que tras una migración a help desk, los tickets de formulario del portal no quedaban vinculados al contacto correcto y desaparecían de la vista del cliente. Su solución fue poner la bandeja de entrada predeterminada del portal en Help Desk.

Si las reglas de enrutamiento y asociación forman parte de una limpieza mayor, mis guías sobre enrutamiento de tickets de HubSpot y limpieza del CRM de HubSpot profundizan más.

¿Cómo filtras qué tickets aparecen en el portal?

El permiso decide de quién son los tickets que un cliente puede ver. El filtro Ticket visibility decide qué tipos de tickets aparecen siquiera. En la pestaña Tickets, haz clic en Select ticket properties, luego en Add filter y fija criterios sobre cualquier propiedad de ticket (documentación de HubSpot).

Tres filtros que yo pondría en la mayoría de las cuentas:

• Pipeline es tu pipeline de soporte. Los pipelines internos (escalaciones a desarrollo, disputas de facturación que gestiona tu equipo de finanzas, proyectos de onboarding) no deberían aparecer solo porque un contacto de cliente esté asociado a ellos.
• Una propiedad Show in portal que no sea No. Una sola casilla permite a un agente ocultar un ticket sensible sin moverlo a otro pipeline.
• Excluye las categorías de ticket del sistema. Si los workflows crean tickets para cosas como recordatorios de renovación, fíltralos por categoría para que los clientes no vean un ticket que nunca abrieron.

Algo que conviene saber antes de confiar en el filtro: cambia lo que lista el portal, no las asociaciones del ticket en el CRM. Si un pipeline de verdad no debe llegar nunca a un cliente, mantén a los contactos de clientes fuera de esos tickets. Mi guía de triage de tickets explica cómo mantener separadas las colas desde el principio.

¿Qué pueden ver los clientes dentro de un ticket?

Los clientes solo ven las propiedades de ticket que elijas mostrar. Por defecto son seis (documentación de HubSpot):

Puedes mostrar hasta 10 propiedades, reordenarlas y renombrarlas. En móvil, la vista de tarjeta solo muestra las dos primeras (2). Deja fuera de la lista campos internos como Priority. El propio ejemplo de HubSpot muestra Ticket name mientras elimina Priority. Los clientes también pueden hacer clic en Export to CSV, que exporta todo lo que hay en su vista actual, así que trata cada columna visible como algo que puede acabar en una hoja de cálculo.

Los hilos de conversación tienen sus propias reglas:

• Si hay más de un hilo asociado a un ticket, la guía de configuración de HubSpot dice que solo aparece el hilo original. Cuando el cliente tiene permiso para ver más de un hilo, aparecen pestañas en la parte superior del ticket para que pueda cambiar entre ellos.
• Todo lo que hay dentro de un hilo de conversación es visible para los clientes que pueden ver ese ticket. El consejo de HubSpot es usar notas y comentarios para las conversaciones internas, y crear reglas de filtrado para que los correos internos no acaben en el hilo.
• Puedes comprobar qué conversaciones aparecerán desde la tarjeta Conversations en la barra lateral derecha del registro del ticket.

La fuga a la que yo prestaría atención es la de «responder a todos». Un agente pone en copia a un compañero de ingeniería en el correo del cliente, el compañero responde «la verdad es que es un bug nuestro, lo lanzamos el martes», y esa respuesta ya está en el hilo que el cliente puede leer en el portal. Lo mismo pasa al reenviar un correo a un account manager. Si está en el hilo, es público.

¿Deberían los clientes poder cerrar o reabrir tickets?

Dos acciones de ticket están en la misma pestaña Tickets: Allow customers to reply to closed conversations y Allow customers to close tickets from the portal. Si activas el cierre, eliges la etapa de cerrado por pipeline. Si un pipeline solo tiene una etapa de cerrado, HubSpot la selecciona por ti.

Mi opinión: activa el cierre por parte del cliente, y asígnalo a una etapa separada como Closed by customer, no a tu Resolved principal. Eso mantiene honestos tus informes de resolución en el primer contacto y de tiempo de resolución, porque «el cliente se rindió» y «lo arreglamos» no deberían contar como lo mismo. Responder a conversaciones cerradas también merece activarse, siempre que un workflow reabra el ticket o avise al propietario cuando llegue una respuesta. Si no, el cliente está escribiendo en un ticket que nadie vigila, lo que puede romper silenciosamente un SLA.

¿Quién puede entrar al portal, para empezar?

La visibilidad de tickets solo importa una vez que alguien puede iniciar sesión. En la pestaña Access hay dos formas de entrar (documentación de HubSpot):

• Access group membership required. Eliges access groups y HubSpot envía a esos contactos un enlace de registro por correo. Professional permite hasta 2 access groups y Enterprise hasta 100, y el límite se comparte con tu base de conocimiento privada.
• Self-registration required. Cualquiera puede registrarse. Necesitas activar el autorregistro en la configuración de contenido privado, y deberías añadir un aviso de consentimiento para procesar datos.

Tres detalles de configuración suelen pillar a los equipos:

• Los portales en un dominio del sistema de HubSpot (como hs-sites o hubspotpagebuilder) no envían correos de membresía a un access group. Conecta primero tu propio dominio.
• Los correos de registro van a la propiedad member email del contacto, que no siempre es su correo principal.
• El portal aparece en el idioma principal de tu dominio, y HubSpot todavía no admite portales multilingües. Mi guía de traducción de HubSpot cubre soluciones alternativas para soporte multilingüe.

Los clientes suelen llegar al portal desde tu base de conocimiento de HubSpot, por eso ambos comparten un límite de access groups. Para una mirada más amplia al self-service, mis guías de portal de atención al cliente y de deflection de tickets en HubSpot son la siguiente parada.

Una auditoría de visibilidad antes del lanzamiento (unos 30 minutos)

Antes de activar el portal, o antes de cambiar el permiso en uno que ya está activo, repasa esta checklist:

1. Saca una lista de contactos con más de una empresa asociada. Comprueba que la principal es la empresa para la que trabajan, no una agencia o un empleador anterior.
2. Busca tickets asociados a tu propio registro de empresa. Elimina esa asociación y añade tu dominio a la lista de dominios excluidos.
3. Lista las empresas que comparten dominio. Fusiónalas o corrige las asociaciones a mano, porque HubSpot elige una por ti.
4. Crea la casilla Portal: sees company tickets y actívala para el admin o champion de cada cuenta, si usas Selected customers.
5. Configura el filtro de visibilidad de tickets solo en tus pipelines de cara al cliente.
6. Renombra las etapas de pipeline que suenen mal para un cliente (Waiting on dev, Escalated - angry).
7. Recorta las columnas a lo que un cliente debería poder exportar.
8. Prueba como dos contactos reales de la misma empresa en ventanas privadas, uno con la casilla y otro sin ella, y compara qué ve cada uno en My view y Organization view.

Si el portal es nuevo para ti, haz la prueba antes de invitar a tu primer access group. Es mucho más fácil explicar una configuración corregida que un correo de un cliente que vio el ticket de un compañero.

¿Qué dicen los usuarios de HubSpot sobre el portal de clientes?

Las reseñas mencionan el portal con menos frecuencia que el help desk, y el hilo común es que funciona para la mayoría de los equipos pero puede sentirse limitado en la gama alta:

"customer portal needs further work to cater for enterprise sized businesses"

Claire F., enterprise reviewer, G2

Las carencias más pedidas en la HubSpot Community coinciden con lo que he cubierto arriba: una idea de acceso a nivel de empresa ya está marcada como Delivered, y la solicitud de contactos seleccionados que vino después describe lo que hace hoy la opción Selected customers. Otras ideas del foro piden tickets de empresas filiales y tickets asociados a los negocios de un contacto. Si eso importa para la estructura de tu cuenta, de momento planifica alrededor de ello. Mis artículos sobre alternativas a HubSpot y HubSpot frente a Zendesk comparan cómo modelan las empresas otros help desks.

¿Dónde encaja la IA cuando los clientes pueden ver el ticket?

En cuanto los clientes pueden leer el ticket en el portal, importa más dónde escribe una herramienta de IA sobre ese ticket. Dos cosas que revisar en cualquier IA que conectes a HubSpot, incluido el propio Breeze Customer Agent de HubSpot:

• ¿Redacta en el hilo o en un comentario? Un borrador publicado como mensaje del hilo es público. Un borrador dejado como comentario interno no lo es.
• ¿Renombra los tickets? El nombre del ticket es la columna Subject en el portal. Una IA que reescribe títulos para la triage de tu equipo («Angry - refund - 3rd time») también está escribiendo lo que ve el cliente.

El agente de HubSpot de eesel se inclina por defecto hacia el lado seguro. Su acción Add internal comment se describe como «a comment the customer can't see», y la documentación aconseja empezar ahí: el agente redacta, una persona envía (documentación de eesel para HubSpot). También puede actualizar títulos y descripciones de tickets, así que si permites esa acción, dile en las instrucciones que mantenga los títulos amigables para el cliente.

MentorShow, una plataforma francesa de aprendizaje online, usa exactamente esta configuración. Su equipo de soporte trabaja por completo en HubSpot, y eesel deja una nota interna en las conversaciones y tickets que recoge: un análisis para el equipo, y luego un borrador de respuesta en el idioma del miembro. Antes de redactar, lee el registro de HubSpot del miembro (estado de la suscripción, próxima fecha de renovación, tickets anteriores). Entre el 8 de agosto y el 8 de septiembre de 2026 leyó cerca de 1,200 elementos de HubSpot (648 conversaciones de bandeja de entrada y 586 tickets), ejecutó 837 búsquedas en la base de conocimiento, y escribió 432 borradores para que el equipo revisara y enviara.

Prueba eesel en tus tickets de HubSpot

Si tu portal está bien configurado, el siguiente cuello de botella es la cola que hay detrás. eesel para HubSpot funciona como un nuevo compañero de equipo dentro de Service Hub. Aprende de tu base de conocimiento de HubSpot y de los tickets pasados, lee el contacto y la empresa detrás de cada ticket (en cuanto actives esas fuentes), y redacta cada respuesta como comentario interno para que nada llegue al portal hasta que tu equipo lo envíe. En cuanto confíes en él para las preguntas rutinarias, puedes dejar que responda directamente. Puedes probar eesel primero en un solo pipeline, o comparar opciones en mi resumen de la mejor IA para HubSpot.

Si prefieres configurarlo desde una terminal, la CLI de eesel permite que Claude Code, Codex o Cursor ejecuten eesel integrations connect hubspot, sincronicen tus fuentes y activen una automatización de comentarios internos, y luego hagan preguntas de prueba para revisar los borradores antes de que cualquier ticket salga en vivo. Alguien con el permiso App Marketplace Access de HubSpot aún tiene que aprobar la conexión en el navegador.