Atendimento ao cliente com IA para marketplaces: faixas de compradores, vendedores e confiança

Resumo

Um marketplace tem dois clientes em cada transação, e muitas vezes eles querem coisas opostas. É por isso que um chatbot genérico é o formato errado. Divida a fila em uma faixa de compradores, uma faixa de vendedores e uma faixa de confiança e segurança, cada uma com seu próprio conhecimento e suas próprias regras sobre o que a IA pode fazer.

Deixe a IA cuidar sozinha das consultas: status do pedido, status do reembolso, status do repasse e detalhamento de taxas. Deixe que ela monte as evidências das disputas entre comprador e vendedor, mas mantenha uma pessoa escolhendo o vencedor. Leve denúncias de golpes e anúncios falsos para o topo da fila. E trate os chargebacks de cartão como um assunto à parte: quem decide é o emissor do cartão, a Stripe diz que você normalmente tem de 7 a 21 dias, e só há uma submissão.

A eesel funciona assim, como um teammate de IA dentro do helpdesk que você já usa: ela aprende com tickets anteriores, chama suas APIs de pedidos e repasses e é simulada contra tickets históricos antes de responder a qualquer pessoa. A SamCart roda um agente da eesel nos tickets de vendedores no Freshdesk e outro no chat do site, e a Rúngne responde perguntas sobre pedidos a partir dos dados da Shopify, enquanto as pessoas ficam com reclamações de danos e disputas.

Por que um único chatbot falha em um marketplace?

Eu construo as integrações e ações que permitem aos agentes da eesel ler dados de outros sistemas, então a maior parte da minha semana gira em torno de uma pergunta: o que a IA precisa enxergar e o que ela pode alterar? Em uma loja de marca única, a resposta é simples. Em um marketplace ela se divide em duas, porque quem escreve pode ser o comprador ou o vendedor do mesmo pedido, e cada um merece respostas diferentes.

Pense em um pacote marcado como entregue que o comprador diz que nunca chegou. O comprador quer o reembolso. O vendedor quer o repasse. Um bot treinado em uma única central de ajuda vai citar a política do comprador para o vendedor ou a política do vendedor para o comprador, e as duas opções são ruins. A própria Garantia de Reembolso do eBay mostra quanta estrutura existe por trás desse único caso: o vendedor tem 3 dias úteis para responder, qualquer um dos lados pode pedir que o eBay intervenha entre 3 e 21 dias úteis, e pedidos de US$ 750 ou mais exigem confirmação por assinatura como prova de entrega.

Eu já vi isso por dentro. Em maio de 2026, um grande marketplace de entrega de comida nos pediu duas bases de conhecimento separadas dentro de uma única central de ajuda do Zendesk, uma para clientes e outra para restaurantes. Esse pedido resume o problema inteiro em uma frase. Também passamos anos colocando agentes de IA em filas de suporte reais e vendo bots com ar confiante dar respostas erradas, e é por isso que toda implantação da eesel hoje é simulada primeiro contra tickets históricos. Em um marketplace, uma resposta errada pode custar caro aos dois lados do mesmo pedido.

Quais tickets de marketplace a IA pode resolver e quais precisam de uma pessoa?

Eu classifico os tickets de marketplace com um único teste: existe uma única resposta certa guardada em algum sistema? Se sim, a IA pode responder sozinha. Se a resposta depende de julgar quem tem razão, uma pessoa decide e a IA faz a preparação. Esse é o núcleo de um bom roteamento de tickets em uma plataforma de dois lados.

As quatro primeiras linhas são o volume. Também é onde a maioria dos bots de marketplace falha, porque respondem a partir da central de ajuda em vez do sistema de pedidos. "Os repasses costumam chegar em 2 a 3 dias" não é resposta para "onde está meu repasse?". A resposta real é um status e uma data, e ela está no seu provedor de pagamentos. A metade inferior da tabela é onde uma etapa de human-in-the-loop permanece, para sempre.

Como separar compradores, vendedores e confiança e segurança em faixas?

Três faixas cobrem quase tudo. A faixa de compradores cuida de pedidos, entrega e reembolsos. A faixa de vendedores cuida de repasses, taxas, anúncios e verificação. A faixa de confiança e segurança cuida de golpes, anúncios falsos e invasões de conta, e fura a fila.

Cada faixa precisa de três coisas próprias: um conjunto de conhecimento, um conjunto de ações permitidas e uma pessoa ou equipe que assuma o que a IA repassa. A separação do conhecimento é o que mais importa. Sua política de reembolso para compradores e sua política de ressarcimento para vendedores vão se contradizer de propósito, e uma IA que lê as duas vai misturá-las. É o mesmo problema do suporte ao cliente multimarca, só que com dois públicos em vez de duas lojas.

Seu helpdesk provavelmente já consegue fazer a separação, embora o plano em que você está faça diferença:

No Zendesk, a forma mais barata que já vi de modelar compradores e vendedores é uma marca para vendedores mais segmentos de usuários, com os registros de vendedores guardados como objetos personalizados relacionados aos tickets. Se os agentes só devem ver a própria faixa, essa é uma questão de permissões à parte, que minhas anotações sobre controle de acesso de agentes de suporte cobrem.

A smava é o exemplo mais claro que posso apontar de dois públicos mantidos separados dentro de um único helpdesk. A smava e a Finanzcheck compartilham um Zendesk, e a eesel trabalha cerca de 27,000 tickets por mês nas duas, redigindo a partir de cerca de 820 macros e artigos da central de ajuda mantidos separados por marca. Uma faixa de vendedores e uma faixa de compradores funcionam do mesmo jeito: um helpdesk, dois conjuntos de conhecimento que nunca se misturam.

Para qual faixa vai este ticket?

Aqui está a lógica das faixas como algo em que você pode clicar. Escolha um ticket e ele mostra a faixa, o que a IA pode fazer e quem conclui o trabalho.

Escolha um ticket para ver sua faixa, o que a IA pode fazer e quem conclui. Este é o meu ponto de partida para uma fila de marketplace; sua equipe de políticas define as regras finais.

Como conectar a IA aos dados de pedidos e repasses em tempo real?

As consultas nas faixas de compradores e vendedores só funcionam se a IA conseguir ler seus sistemas em tempo real. Responder "onde está meu repasse?" a partir da central de ajuda gera um cronograma genérico. Responder a partir da API de pagamentos gera "seu repasse de US$ 412 está em trânsito e deve chegar na quinta-feira". A segunda resposta encerra o ticket, que é o objetivo de suporte para rastreamento de pedidos e de automação de WISMO.

Os repasses são onde a faixa de vendedores vive ou morre, e a documentação do Stripe Connect explica por que esses tickets caem com você. Se um vendedor não vê os fundos esperados, a Stripe diz que ele "precisa entrar em contato com a plataforma com a qual trabalha", porque a plataforma controla as configurações e os cronogramas de repasse. Portanto, toda pergunta sobre repasse é um ticket seu, não da Stripe. A mesma página lista os status de repasse que uma IA deve ler em voz alta: pendente, em trânsito, pago, falhou e cancelado.

Repasses com falha são um bom exemplo de ticket que a IA consegue resolver quase por completo. Quando um repasse falha, a Stripe marca essa conta bancária com erro e pausa os repasses agendados para ela, e a plataforma pode gerar um link para o vendedor atualizar seus próprios dados bancários. Isso é uma consulta mais um link, algo que a IA faz bem. A mesma página observa que a plataforma pode bloquear uma conta bancária em toda a plataforma por fraude, e essa ação pertence a uma pessoa.

As retenções para verificação funcionam da mesma forma. A documentação de verificação da Stripe diz que ela "normalmente desativa os repasses" se as informações exigidas não forem recebidas até o prazo, e cada exigência vem com um erro em linguagem clara que o vendedor consegue resolver. A Adyen segue um relógio parecido: segundo sua visão geral de verificação, os vendedores têm 30 dias para corrigir problemas antes que os repasses parem e 60 dias antes de não poderem mais receber pagamentos. Uma IA que lê as pendências e diz ao vendedor exatamente o que enviar evita um vaivém em cada um desses casos.

Aqui está a parte técnica, do lado da engenharia. Você quer quatro leituras e quase nenhuma escrita:

1. Pedidos: status, itens, eventos de rastreamento, do banco de dados do seu marketplace ou da Shopify.
2. Reembolsos: emitido ou não, valor, data.
3. Repasses: status, data de chegada, código de falha, por conta de vendedor.
4. Pendências da conta: qual verificação está pendente e até quando.

Os webhooks mantêm tudo atualizado. A página de webhooks do Connect da Stripe diz que toda integração Connect deve escutar eventos, e os que uma equipe de suporte acompanha são account.updated, payout.failed e charge.dispute.created. Eu gosto de fazer o webhook de falha de repasse abrir um ticket na faixa de vendedores antes mesmo de o vendedor escrever. Um "seu repasse falhou, aqui está o link para corrigir" proativo vale mais que um e-mail confuso três dias depois.

Para escritas, a regra que sigo é simples: tudo o que move dinheiro ou altera uma conta espera por uma pessoa. Isso inclui reembolsos, liberação de repasses, estorno de taxas e bloqueios de conta. Se você quer um modelo de quem aprova o quê, minha matriz de aprovação de reembolsos apresenta um, e o gerenciamento de exceções no suporte cobre os casos de borda.

Como a IA deve tratar disputas entre comprador e vendedor?

É aqui que os interesses conflitantes ficam mais agudos, e onde eu nunca deixaria a IA escolher um lado. As duas partes são seus clientes. O que a IA pode fazer é tornar a pessoa que decide muito mais rápida e muito mais consistente.

A consistência importa mais do que as pessoas esperam. Aqui está um anfitrião descrevendo como era o suporte em disputas em um grande marketplace de aluguel:

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

reverend_gonzo, Hacker News

Quando o resultado depende de qual agente você pega, os dois lados perdem a confiança. A solução é um pacote de evidências padrão, igual todas as vezes, montado antes mesmo de uma pessoa abrir o caso.

Meu pacote de evidências tem cinco partes: o registro do pedido, o rastreamento da transportadora, o histórico completo de mensagens entre comprador e vendedor, uma captura do anúncio como estava na compra e o histórico de reembolsos e disputas das duas partes. A IA reúne tudo, sinaliza lacunas ("o vendedor não respondeu em 3 dias úteis") e redige uma mensagem para cada lado depois que a pessoa decide. Essa última parte é fácil de pular, e não deveria ser. O lado que perdeu merece uma explicação clara, escrita na linguagem da sua faixa.

Os prazos variam muito conforme o tipo de marketplace, então codifique os seus em vez de copiar os de outra empresa. Um marketplace de bens físicos se apoia em rastreamento e comprovante de entrega: o eBay pede que os vendedores respondam em até 3 dias úteis, e o processo de casos da Etsy permite que os compradores abram um caso depois de passada a estimativa de entrega e 48 horas após enviar mensagem ao vendedor. Um marketplace de serviços não tem código de rastreamento, então se apoia em marcos e mensagens. A Upwork dá aos freelancers 7 dias corridos para abrir uma disputa de preço fixo, e a Central de Resolução da Fiverr aceita automaticamente um pedido que não seja respondido em 48 horas. Se você opera uma plataforma de serviços, seu pacote de evidências troca o rastreamento pelos arquivos entregues e pelo escopo combinado.

Quem paga também importa, e isso define como a IA deve se expressar. Na Sharetribe, "apenas operadores do marketplace podem cancelar uma transação e iniciar um reembolso" por padrão, e um pedido em disputa é cancelado com reembolso integral após 60 dias se ninguém agir. Um cronômetro assim é exatamente o que a IA deve destacar no pacote de evidências, para que nada expire em silêncio.

Como os chargebacks são diferentes das disputas entre comprador e vendedor?

Um chargeback pode vir do mesmíssimo pedido, mas é um processo diferente, com um juiz diferente. Em uma disputa entre comprador e vendedor, você decide com base na sua política. Em um chargeback, quem decide é o emissor do cartão do comprador, e você está sujeito ao relógio da bandeira.

Vale conhecer em detalhe as regras da Stripe, porque são rígidas:

• O prazo é curto. O guia de resposta a disputas da Stripe diz que a janela costuma ser de 7 a 21 dias, dependendo da bandeira do cartão, e perder o prazo significa perder automaticamente.
• Você só tem uma chance. "Você tem apenas uma oportunidade de enviar sua resposta", segundo a mesma página. Sem edições, sem links, sem áudio ou vídeo, e um limite de 4,5 MB para o conjunto das evidências.
• O histórico de suporte é evidência. A Stripe orienta os lojistas a manter um registro de toda a comunicação com o cliente, porque ele passa a fazer parte do caso. Seu helpdesk é um arquivo de disputas, queira você ou não.
• Custa dinheiro de qualquer jeito. Nos EUA, a Stripe cobra US$ 15 quando uma disputa chega e outros US$ 15 se você contestar, com a segunda taxa devolvida se você ganhar.

Quem absorve o prejuízo depende de como seus pagamentos estão configurados. A página de disputas do Connect da Stripe diz que, em destination charges e em separate charges and transfers, "a Stripe debita os valores e as taxas da disputa da conta da sua plataforma", e você pode então reverter a transferência para recuperar o valor do vendedor. Em direct charges, o saldo do vendedor é debitado. O padrão da Adyen é parecido: a plataforma paga primeiro e pode repassar o custo ao vendedor ou dividi-lo por pagamento.

Assim, o papel da IA em um chargeback é restrito: identificar o evento charge.dispute.created, abrir um ticket com a data limite no assunto e montar as evidências a partir do pedido, do comprovante de entrega e do histórico de suporte. Uma pessoa do financeiro revisa e envia. Se você quer o detalhe do lado do suporte, meus guias sobre IA para disputas de pagamento e consultas de chargeback aprofundam o tema.

Quais controles a faixa de confiança e segurança precisa?

Denúncias de golpes e anúncios falsos são os tickets em que velocidade e contenção importam ao mesmo tempo. Quem denuncia precisa se sentir ouvido de imediato, e a IA não pode alertar nem punir ninguém por conta própria. Errar na direção oposta é igualmente ruim, como descobriu este usuário do 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

Estes são os cinco controles que configuro para essa faixa:

1. Roteamento prioritário. As denúncias pulam a fila normal e chegam à equipe de confiança e segurança. O roteamento por habilidades do seu helpdesk resolve isso; o trabalho da IA é marcar o ticket corretamente já na primeira vez.
2. Preservação de evidências. A IA salva o anúncio, as mensagens e os dados da conta no momento da denúncia, porque golpistas editam ou apagam rápido.
3. Ações restritas. A IA pode confirmar o recebimento e marcar. Ela não pode bloquear, suspender, reembolsar nem enviar mensagem à conta denunciada. Esses são guardrails de IA que você define uma vez e nunca afrouxa.
4. Atenção à falsificação de identidade. Vendedores recebem mensagens de golpe que fingem ser da sua equipe de suporte. Um ex-vendedor da Etsy descreveu "mais de 20 mensagens diárias de golpistas fingindo ser compradores ou o suporte da Etsy". Sua IA nunca deve pedir senhas ou dados de pagamento, e deve dizer isso em suas respostas.
5. Recursos e trilha de auditoria. Toda ação em uma conta é registrada com quem a aprovou. Quando um vendedor recorre de uma suspensão, quem revisa vê o histórico completo em um só lugar.

Invasões de conta merecem uma regra própria. Se um vendedor escreve "alguém alterou meus dados bancários", trate como urgente e encaminhe imediatamente a uma pessoa. As ferramentas de repasse da Stripe permitem que uma plataforma bloqueie uma conta bancária em toda a plataforma ou rejeite uma conta por invasão, mas essas são decisões da sua equipe, não da IA. Para o padrão mais amplo de transferências bem-feitas, veja minhas notas sobre gerenciamento de escalonamento com IA.

Como eu faria a implantação?

Eu começaria pelas consultas, não pelas disputas, e testaria antes de qualquer coisa entrar no ar. Uma sequência que já vi funcionar:

1. Semana 0: mapear e conectar. Pegue 300 tickets recentes e separe-os nas três faixas. Conecte acesso de leitura a pedidos, reembolsos, repasses e pendências da conta. Escreva a lista de ações restritas.
2. Semanas 1 e 2: simular. Rode a IA contra tickets históricos de cada faixa e compare as respostas com o que sua equipe realmente enviou. Meu guia de testes pré-lançamento e meu scorecard de piloto explicam como pontuar.
3. Semanas 3 e 4: consultas no ar. Status do pedido, status do reembolso, status do repasse e perguntas sobre taxas saem sem uma pessoa. Todo o resto fica apenas em rascunho.
4. Semanas 5 a 8: pacotes de evidências. A IA começa a montar pacotes de disputas e chargebacks. As pessoas continuam decidindo todos eles.
5. Contínuo: marcação de confiança e segurança. Ative a marcação prioritária para denúncias, com zero ações em contas para a IA, sempre.

A etapa de simulação é onde os marketplaces encontram suas surpresas. Um caso típico: a IA entrega a um vendedor a política de devolução do comprador porque o vendedor perguntou "como funcionam as devoluções?". Isso é um problema de separação de conhecimento, e você quer descobri-lo em uma reprodução de tickets anteriores, não na caixa de entrada de um vendedor real. Meu guia de piloto de suporte com IA traz a versão de quatro semanas desse plano.

O que medir em uma plataforma de dois lados?

A taxa de deflexão é o número de destaque errado para um marketplace. Um comprador que recebe uma resposta do bot e desiste conta como deflexionado, e um vendedor que silencia e passa a anunciar em outro lugar também. Eu meço cada métrica duas vezes, uma por lado.

Separar o CSAT por lado é o ponto que mais defendo. Os vendedores costumam ser um grupo menor com valor de vida útil muito maior, e uma faixa de vendedores que se degrada em silêncio não aparece em uma nota combinada. Para as definições, meus detalhamentos sobre métricas de IA para CX e tickets repetidos passam por cada uma delas.

Os vendedores vão avisar quando a faixa de vendedores estiver quebrada, normalmente em público. Aqui está um pequeno empresário falando sobre uma retenção de repasse:

"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

Uma retenção de repasse pode ser a decisão certa por motivos de risco. Semanas de silêncio nunca são. Uma IA que lê o motivo da retenção e responde no mesmo dia, mesmo que seja com "seus fundos estão retidos para uma verificação, e isto é o que precisamos", transforma esse post em um ticket que nunca chega a ser escrito.

Como a eesel se encaixa em uma equipe de suporte de marketplace?

A eesel é um teammate de IA que entra no helpdesk que você já usa, incluindo Zendesk, Freshdesk e Gorgias, além do HubSpot. Ela aprende com sua central de ajuda e com tickets anteriores, e você pode rodar um agente separado por faixa, cada um com seu próprio conhecimento e suas próprias instruções.

A parte de dados em tempo real é a que mais trabalho. A configuração de Network Access da eesel permite que um agente chame suas próprias APIs, para consultar pedidos, reembolsos ou repasses ao vivo. Você libera um domínio e define o cabeçalho de autenticação, e as credenciais são anexadas a cada requisição pela eesel, então a IA nunca as vê. Os dados de pedidos da Shopify se conectam pela integração com a Shopify. As permissões de ação permitem configurar cada ação para rodar sozinha, pedir aprovação ou ficar desativada, e é assim que reembolsos e alterações de conta ficam sob o controle de uma pessoa.

Se seus engenheiros preferem trabalhar em um terminal, a CLI da eesel executa o mesmo teammate e o mesmo workspace pela linha de comando. Você pode revisar aprovações pendentes, ler o log de atividades de cada execução e editar as instruções permanentes do agente, e agentes de código como o Claude Code também podem operá-la. Para um marketplace que já roda seus sistemas de pedidos e repasses como código, isso mantém as regras do agente de suporte ao lado de todo o resto.

Dois casos de clientes mostram as faixas na prática. A SamCart, uma plataforma pela qual mais de 75.000 empresas vendem, roda a eesel no suporte a vendedores: um agente responde aos tickets do Freshdesk e outro cuida do chat do site, ambos respondendo a partir de cerca de 280 artigos da central de ajuda. O agente só responde enquanto nenhum colega estiver atribuído, e quando um vendedor pede uma pessoa, o ticket é marcado para transferência e o agente para. A Rúngne mostra o lado do comprador: a eesel tratou cerca de 2,100 tickets do Gorgias em um mês, respondendo perguntas sobre onde está o pedido e sobre estoque a partir dos dados da Shopify, enquanto cancelamentos, itens danificados, pacotes perdidos e disputas alfandegárias vão para pessoas.

Os limites, com honestidade: a eesel não decide disputas nem envia respostas de chargeback por você, e eu não gostaria que o fizesse. Sua auditoria SOC 2 Type II está em andamento, com o período de observação começando em 1º de outubro de 2026. Os preços estão na página de preços: um plano gratuito com 100 créditos e planos Teammate a partir de $299 por mês com 500 créditos, em que um ticket ou um chat equivale a um crédito. Se você está comparando uma camada de IA separada com a IA nativa do seu helpdesk, comparei as duas na minha comparação de camada de IA.

Experimente a eesel na fila do seu marketplace

Se seus compradores e vendedores recebem as mesmas respostas prontas, a eesel pode dar a cada lado sua própria faixa dentro do helpdesk que você já usa: consultas em tempo real de pedidos e repasses para os tickets fáceis, pacotes de evidências para disputas e toda decisão sobre dinheiro com a sua equipe. Toda implantação começa com uma simulação nos seus tickets históricos, para que você veja como ela responde a compradores e vendedores antes de qualquer outra pessoa.

Experimente a eesel grátis com 100 créditos, ou agende uma demo e traga uma amostra de tickets de compradores e vendedores para mapearmos suas faixas juntos.