Atención al cliente con IA para marketplaces: carriles de compradores, vendedores y confianza

¿Por qué falla un solo chatbot en un marketplace?

Yo construyo las integraciones y acciones que permiten a los agentes de eesel leer de otros sistemas, así que gran parte de mi semana se va en una pregunta: ¿qué necesita ver la IA y qué tiene permitido cambiar? En una tienda de una sola marca la respuesta es sencilla. En un marketplace se divide en dos, porque quien escribe puede ser el comprador o el vendedor del mismo pedido, y les corresponden respuestas distintas.

Imagina un paquete marcado como entregado que el comprador dice que nunca llegó. El comprador quiere un reembolso. El vendedor quiere su pago. Un bot entrenado con un solo centro de ayuda citará la política del comprador al vendedor o la del vendedor al comprador, y ambas cosas están mal. La garantía de devolución del dinero de eBay muestra cuánta estructura hay detrás de ese único caso: el vendedor tiene 3 días hábiles para responder, cualquiera de las partes puede pedir a eBay que intervenga entre los 3 y los 21 días hábiles, y los pedidos de 750 $ o más requieren confirmación con firma como prueba de entrega.

Lo he visto desde dentro. En mayo de 2026, un gran marketplace de reparto de comida nos pidió dos bases de conocimiento separadas dentro de un mismo centro de ayuda de Zendesk, una para clientes y otra para restaurantes. Esa petición es todo el problema en una frase. También llevamos años poniendo agentes de IA en colas de soporte reales y viendo cómo bots que suenan seguros dan respuestas erróneas, y por eso cada despliegue de eesel se simula ahora primero con tickets históricos. En un marketplace, una respuesta equivocada puede costarte caro en los dos lados del mismo pedido.

¿Qué tickets de marketplace puede gestionar la IA y cuáles necesitan a una persona?

Clasifico los tickets de marketplace con una sola prueba: ¿hay una única respuesta correcta guardada en algún sistema? Si es así, la IA puede responder sola. Si la respuesta depende de juzgar quién tiene razón, decide una persona y la IA hace la preparación. Ese es el núcleo de un buen enrutamiento de tickets en una plataforma de dos lados.

Las cuatro primeras filas son el volumen. También son donde la mayoría de los bots de marketplace se quedan cortos, porque responden desde el centro de ayuda en lugar de desde el sistema de pedidos. «Los pagos suelen llegar en 2 o 3 días» no es una respuesta a «¿dónde está mi pago?». La respuesta real es un estado y una fecha, y vive en tu proveedor de pagos. La mitad inferior de la tabla es donde se mantiene, de forma permanente, un paso con intervención humana.

¿Cómo separas compradores, vendedores y confianza y seguridad en carriles?

Tres carriles cubren casi todo. El carril de compradores gestiona pedidos, entregas y reembolsos. El carril de vendedores gestiona pagos, comisiones, anuncios y verificación. El carril de confianza y seguridad gestiona estafas, anuncios falsos y robos de cuenta, y se salta la cola.

Cada carril necesita tres cosas propias: un conjunto de conocimiento, un conjunto de acciones permitidas y una persona o equipo que recoja lo que la IA les pasa. La separación del conocimiento es lo más importante. Tu política de reembolsos para compradores y tu política de reembolsos para vendedores se contradirán a propósito, y una IA que lea las dos las mezclará. Es el mismo problema que la atención al cliente multimarca, solo que con dos audiencias en lugar de dos tiendas.

Probablemente tu helpdesk ya pueda hacer la separación, aunque importa el plan que tengas:

En Zendesk, la forma más económica que he visto de modelar compradores y vendedores es una marca de vendedores más segmentos de usuarios, con los registros de vendedores guardados como objetos personalizados relacionados con los tickets. Si los agentes solo deben ver su propio carril, es otra cuestión de permisos, que mis notas sobre el control de acceso de agentes de soporte tratan.

smava es el ejemplo más claro que puedo señalar de mantener separadas dos audiencias dentro de un mismo helpdesk. smava y Finanzcheck comparten un Zendesk, y eesel gestiona unos 27,000 tickets al mes entre ambos, redactando a partir de unas 820 macros y artículos del centro de ayuda que se mantienen separados por marca. Un carril de vendedores y uno de compradores funcionan igual: un helpdesk, dos conjuntos de conocimiento que nunca se mezclan.

¿A qué carril va este ticket?

Aquí tienes la lógica de los carriles como algo que puedes recorrer con clics. Elige un ticket y te muestra el carril, lo que la IA tiene permitido hacer y quién termina el trabajo.

Elige un ticket para ver su carril, lo que la IA puede hacer y quién lo termina. Este es mi punto de partida para una cola de marketplace; tu equipo de políticas fija las reglas finales.

¿Cómo conectas la IA con los datos de pedidos y pagos en vivo?

Las consultas de los carriles de compradores y vendedores solo funcionan si la IA puede leer tus sistemas en tiempo real. Responder «¿dónde está mi pago?» desde el centro de ayuda te da un calendario genérico. Responderlo desde la API de pagos te da «tu pago de 412 $ está en tránsito y debería llegar el jueves». La segunda respuesta cierra el ticket, que es todo el sentido del soporte de seguimiento de pedidos y la automatización de WISMO.

Los pagos son donde el carril de vendedores se juega la vida, y la documentación de Connect de Stripe explica por qué esos tickets te llegan a ti. Si un vendedor no ve los fondos esperados, Stripe dice que «need to contact the platform they work with», porque la plataforma controla la configuración y los calendarios de pagos. Así que cada pregunta sobre pagos es tu ticket, no el de Stripe. La misma página enumera los estados de pago que una IA debería comunicar: pendiente, en tránsito, pagado, fallido y cancelado.

Los pagos fallidos son un buen ejemplo de ticket que la IA puede gestionar casi por completo. Cuando un pago falla, Stripe marca esa cuenta bancaria con error y pausa los pagos programados hacia ella, y la plataforma puede generar un enlace para que el vendedor actualice sus propios datos bancarios. Eso es una consulta más un enlace, algo que la IA hace bien. La misma página señala que la plataforma puede bloquear una cuenta bancaria en toda la plataforma por fraude, y esa acción corresponde a una persona.

Las retenciones por verificación funcionan igual. La documentación de verificación de Stripe dice que «typically disables payouts» si no se recibe la información requerida antes del plazo, y cada requisito viene con un error en lenguaje claro que el vendedor puede atender. Adyen usa un reloj parecido: según su resumen de verificación, los vendedores tienen 30 días para resolver los problemas antes de que se detengan los pagos y 60 días antes de que ya no puedan aceptar pagos. Una IA que lee los requisitos pendientes y le dice al vendedor exactamente qué subir ahorra un intercambio de mensajes en cada uno de estos casos.

Así es la fontanería, desde el lado de la ingeniería. Quieres cuatro lecturas y casi ninguna escritura:

1. Pedidos: estado, artículos, eventos de seguimiento, desde la base de datos de tu marketplace o Shopify.
2. Reembolsos: emitido o no, importe, fecha.
3. Pagos: estado, fecha de llegada, código de fallo, por cuenta de vendedor.
4. Requisitos de la cuenta: qué verificación está pendiente y para cuándo.

Los webhooks lo mantienen actualizado. La página de webhooks de Connect de Stripe dice que toda integración de Connect debería escuchar eventos, y los que le importan a un equipo de soporte son account.updated, payout.failed y charge.dispute.created. Me gusta que el webhook de pago fallido abra un ticket en el carril de vendedores antes de que el vendedor escriba. Un «tu pago ha fallado, aquí tienes el enlace para arreglarlo» proactivo es mejor que un correo confuso tres días después.

Para las escrituras, la regla que sigo es simple: todo lo que mueva dinero o cambie una cuenta espera a una persona. Eso incluye reembolsos, liberaciones de pagos, reversiones de comisiones y bloqueos de cuentas. Si quieres una plantilla sobre quién aprueba qué, mi matriz de aprobación de reembolsos presenta una, y la gestión de excepciones de soporte cubre los casos límite.

¿Cómo debe gestionar la IA las disputas entre compradores y vendedores?

Aquí es donde los intereses enfrentados son más agudos, y donde yo nunca dejaría que la IA tomara partido. Ambas partes son tus clientes. Lo que la IA puede hacer es que la persona que decide sea mucho más rápida y mucho más coherente.

La coherencia importa más de lo que la gente espera. Aquí un anfitrión describe cómo era el soporte de disputas en un gran marketplace de alquileres:

"... The side you wins is the side you can say the magic words that specific agent wants to hear."

reverend_gonzo, Hacker News

Cuando el resultado depende del agente que te toque, ambas partes pierden confianza. La solución es un paquete de pruebas estándar que se vea igual siempre, construido antes de que una persona abra el caso.

Mi paquete de pruebas tiene cinco partes: el registro del pedido, el seguimiento del transportista, el hilo completo de mensajes entre comprador y vendedor, una captura del anuncio tal como estaba en el momento de la compra y el historial de reembolsos y disputas de ambas partes. La IA los reúne, señala lagunas («el vendedor no ha respondido en 3 días hábiles») y redacta una nota para cada parte cuando la persona decide. Esa última parte es fácil de saltarse, y no debería. La parte que pierde merece una explicación clara, escrita en el lenguaje de su carril.

Los plazos varían mucho según el tipo de marketplace, así que codifica los tuyos en lugar de copiar los de otro. Un marketplace de bienes físicos se apoya en el seguimiento y la prueba de entrega: eBay pide a los vendedores que respondan en 3 días hábiles, y el proceso de casos de Etsy permite a los compradores abrir un caso cuando ha pasado la fecha estimada de entrega y 48 horas después de escribir al vendedor. Un marketplace de servicios no tiene número de seguimiento, así que se apoya en hitos y mensajes. Upwork da a los freelancers 7 días naturales para presentar una disputa de precio fijo, y el Centro de resolución de Fiverr acepta automáticamente una solicitud que no se responde en 48 horas. Si gestionas una plataforma de servicios, tu paquete de pruebas cambia el seguimiento por los archivos entregados y el alcance acordado.

Quién paga también importa, y decide cómo debe redactar la IA. En Sharetribe, «only marketplace operators can cancel a transaction and initiate a refund» por defecto, y un pedido en disputa se cancela con reembolso completo a los 60 días si nadie actúa. Un temporizador así es exactamente lo que la IA debería hacer visible en el paquete de pruebas, para que nada caduque en silencio.

¿En qué se diferencian los contracargos de las disputas entre compradores y vendedores?

Un contracargo puede venir del mismo pedido, pero es un proceso distinto con un juez distinto. En una disputa entre comprador y vendedor, decides tú según tu propia política. En un contracargo, decide el emisor de la tarjeta del comprador y estás contra el reloj de la red.

Las reglas de Stripe conviene conocerlas al detalle, porque son estrictas:

• El plazo es corto. La guía de respuesta a disputas de Stripe dice que la ventana suele ser de 7 a 21 días según la red de la tarjeta, y no cumplirla supone una pérdida automática.
• Tienes una sola oportunidad. «You've only one opportunity to submit your response», según la misma página. Sin ediciones, sin enlaces, sin audio ni vídeo, y con un límite de 4,5 MB para las pruebas combinadas.
• El historial de soporte es una prueba. Stripe indica a los comercios que guarden un registro de toda la comunicación con el cliente, porque pasa a formar parte del caso. Tu helpdesk es un archivo de disputas lo hayas planeado o no.
• Cuesta dinero en cualquier caso. En EE. UU., Stripe cobra 15 $ cuando llega una disputa y otros 15 $ si la contestas, y la segunda tarifa se devuelve si ganas.

Quién asume la pérdida depende de cómo estén configurados tus pagos. La página de disputas de Connect de Stripe dice que en los cargos de destino y en los cargos y transferencias por separado, «Stripe debits dispute amounts and fees from your platform account», y luego puedes revertir la transferencia para recuperarlo del vendedor. En los cargos directos se debita el saldo del vendedor. El valor predeterminado de Adyen es parecido: la plataforma paga primero y puede trasladar el coste al vendedor o dividirlo por pago.

Así que el trabajo de la IA en un contracargo es acotado: detectar el evento charge.dispute.created, abrir un ticket con la fecha límite en el asunto y reunir las pruebas del pedido, la prueba de entrega y el hilo de soporte. Una persona de finanzas revisa y envía. Si quieres el detalle desde el lado del soporte, mis guías sobre IA para disputas de pago y consultas de contracargos profundizan más.

¿Qué controles necesita el carril de confianza y seguridad?

Los reportes de estafas y anuncios falsos son los tickets donde importan tanto la velocidad como la contención. Quien reporta necesita sentirse escuchado de inmediato, y la IA no debe avisar ni castigar a nadie por su cuenta. Equivocarse en la otra dirección es igual de malo, como descubrió este usuario de Facebook Marketplace:

"Last year, I reported a number of people, who were trying to scam me (via Messenger messages related to Marketplace listings). Not only did Facebook did not see anything wrong with the accounts and scammy messages, I was flagged for sending useless reports."

lukaslalinsky, Hacker News

Estos son los cinco controles que configuro para este carril:

1. Enrutamiento prioritario. Los reportes se saltan la cola normal y llegan al equipo de confianza y seguridad. El enrutamiento basado en habilidades de tu helpdesk se encarga de ello; el trabajo de la IA es etiquetar bien el ticket a la primera.
2. Conservación de pruebas. La IA guarda el anuncio, los mensajes y los datos de la cuenta en el momento del reporte, porque los estafadores editan o borran rápido.
3. Acciones restringidas. La IA puede confirmar la recepción y etiquetar. No puede bloquear, suspender, reembolsar ni escribir a la cuenta reportada. Son barreras de protección de la IA que fijas una vez y nunca aflojas.
4. Conciencia de suplantación. Los vendedores reciben mensajes de estafadores que se hacen pasar por tu equipo de soporte. Un antiguo vendedor de Etsy describió «20+ daily messages from scammers pretending to be buyers or Etsy support». Tu IA nunca debe pedir contraseñas ni datos de pago, y debe decirlo en sus respuestas.
5. Apelaciones y registro de auditoría. Cada acción sobre una cuenta se registra con quién la aprobó. Cuando un vendedor apela una suspensión, la persona que lo revisa ve todo el historial en un solo lugar.

Los robos de cuenta merecen su propia regla. Si un vendedor escribe «alguien ha cambiado mis datos bancarios», trátalo como urgente y enrútalo de inmediato a una persona. Las herramientas de pagos de Stripe permiten a una plataforma bloquear una cuenta bancaria en toda la plataforma o rechazar una cuenta por robo, pero esas son decisiones de tu equipo, no de la IA. Para el patrón general de traspasos limpios, consulta mis notas sobre la gestión de escalaciones con IA.

¿Cómo lo desplegaría?

Empezaría por las consultas, no por las disputas, y probaría antes de que nada salga en vivo. Una secuencia que he visto funcionar:

1. Semana 0: mapear y conectar. Toma 300 tickets recientes y clasifícalos en los tres carriles. Conecta acceso de lectura a pedidos, reembolsos, pagos y requisitos de cuenta. Escribe la lista de acciones restringidas.
2. Semanas 1 a 2: simular. Ejecuta la IA sobre tickets históricos de cada carril y compara sus respuestas con lo que tu equipo envió realmente. Mi guía de pruebas previas al lanzamiento y mi cuadro de mando del piloto explican cómo puntuarla.
3. Semanas 3 a 4: consultas en vivo. El estado del pedido, del reembolso y del pago y las preguntas sobre comisiones salen sin una persona. Todo lo demás es solo borrador.
4. Semanas 5 a 8: paquetes de pruebas. La IA empieza a preparar paquetes de disputas y contracargos. Las personas siguen decidiendo cada uno.
5. Continuo: etiquetado de confianza y seguridad. Activa el etiquetado prioritario para los reportes, con cero acciones de cuenta para la IA, nunca.

El paso de simulación es donde los marketplaces encuentran sorpresas. Una típica: la IA da a un vendedor la política de devoluciones del comprador porque un vendedor preguntó «¿cómo funcionan las devoluciones?». Es un problema de separación del conocimiento, y quieres encontrarlo en una repetición de tickets pasados, no en la bandeja de entrada de un vendedor real. Mi guía de pilotos de soporte con IA incluye la versión de cuatro semanas de este plan.

¿Qué deberías medir en una plataforma de dos lados?

La tasa de desviación es la cifra principal equivocada para un marketplace. Un comprador que recibe una respuesta de un bot y se rinde cuenta como desviado, igual que un vendedor que se queda callado y publica en otro sitio. Mido cada métrica dos veces, una por cada lado.

Separar el CSAT por lado es lo que más defiendo. Los vendedores suelen ser un grupo más pequeño con un valor de vida mucho mayor, y un carril de vendedores que se degrada en silencio no aparecerá en una puntuación combinada. Para las definiciones, mis desgloses de métricas de IA para CX y de tickets repetidos repasan cada una.

Los vendedores te dirán cuándo falla el carril de vendedores, normalmente en público. Aquí un pequeño empresario hablando de una retención de pago:

"We are affected by this as Etsy is currently holding about 4000 of our Euros... The worst thing about it is that we raised a support request for this, for which you have to jump through really stupid hoops, and have not even heard back from them in weeks. Not even a boilerplate response."

handmadeta, Hacker News

Una retención de pago puede ser la decisión correcta por motivos de riesgo. Semanas de silencio nunca lo son. Una IA que lee el motivo de la retención y responde el mismo día, aunque sea con «tus fondos están retenidos por una comprobación de verificación, esto es lo que necesitamos», convierte esa publicación en un ticket que nunca se escribe.

¿Cómo encaja eesel en un equipo de soporte de marketplace?

eesel es un compañero de IA que se une al helpdesk que ya usas, incluidos Zendesk, Freshdesk y Gorgias, además de HubSpot. Aprende de tu centro de ayuda y de tickets anteriores, y puedes ejecutar un agente distinto por carril, cada uno con su propio conocimiento e instrucciones.

La parte de datos en vivo es la que más trabajo. El ajuste Network Access de eesel permite a un agente llamar a tus propias API, de modo que puede consultar pedidos, reembolsos o pagos en vivo. Permites un dominio y defines la cabecera de autenticación, y eesel adjunta las credenciales a cada solicitud, así que la IA nunca las ve. Los datos de pedidos de Shopify se conectan mediante la integración con Shopify. Los permisos de acciones te permiten configurar cada acción para que se ejecute sola, pida aprobación o quede desactivada, que es como los reembolsos y los cambios de cuenta se quedan detrás de una persona.

Si tus ingenieros prefieren trabajar desde una terminal, la CLI de eesel ejecuta el mismo compañero y espacio de trabajo desde la línea de comandos. Puedes revisar aprobaciones pendientes, leer el registro de actividad de cada ejecución y editar las instrucciones permanentes del agente, y agentes de programación como Claude Code también pueden manejarla. Para un marketplace que ya gestiona sus sistemas de pedidos y pagos como código, eso mantiene las reglas del agente de soporte junto a todo lo demás.

Dos casos de clientes muestran los carriles en la práctica. SamCart, una plataforma a través de la cual venden más de 75,000 negocios, usa eesel en su soporte a vendedores: un agente responde a los tickets de Freshdesk y otro gestiona el chat del sitio web, ambos respondiendo a partir de unos 280 artículos del centro de ayuda. El agente responde solo mientras no haya un compañero asignado, y cuando un vendedor pide una persona, el ticket se etiqueta para el traspaso y el agente se detiene. Rúngne muestra el lado del comprador: eesel gestionó unos 2,100 tickets de Gorgias en un mes, respondiendo preguntas de dónde está mi pedido y de stock con datos de Shopify, mientras que las cancelaciones, los artículos dañados, los paquetes perdidos y las disputas de aduanas van a personas.

Los límites, con honestidad: eesel no decide disputas ni envía respuestas a contracargos por ti, y yo tampoco querría que lo hiciera. Su auditoría SOC 2 Type II está en curso, con el periodo de observación comenzando el 1 de octubre de 2026. Los precios están en la página de precios: un plan gratuito con 100 créditos y planes Teammate desde $299 al mes por 500 créditos, donde un ticket o un chat equivale a un crédito. Si estás comparando una capa de IA independiente con la IA integrada de tu helpdesk, comparé ambas en mi comparativa de capa de IA.

Prueba eesel con la cola de tu marketplace

Si tus compradores y vendedores reciben las mismas respuestas enlatadas, eesel puede dar a cada lado su propio carril dentro del helpdesk que ya usas: consultas de pedidos y pagos en vivo para los tickets fáciles, paquetes de pruebas para las disputas y cada decisión sobre dinero en manos de tu equipo. Cada despliegue empieza con una simulación sobre tus tickets históricos, para que veas cómo responde a compradores y vendedores antes que nadie.

Prueba eesel gratis con 100 créditos, o reserva una demo y trae una muestra de tickets de compradores y vendedores para que mapeemos tus carriles juntos.