01 Contexto & Problema
O cliente ofereceu um produto BNPL focado no leasing: os clientes solicitaram um limite de gastos aprovado, depois financiaram compras elegíveis e pagaram em parcelas, em vez de pagar integralmente. O produto cobria apenas itens locáveis, como móveis, televisores e eletrônicos de consumo, não consumíveis de baixo valor como canetas, cadernos e papelaria. O cliente cresceu ao integrar sua opção de pagamento diretamente no site de cada varejista: vendas se aproximam do varejista, o varejista fornece um sandbox, a equipe integra o gateway, engenharia e QA testam o checkout, e então ambos os lados coordenam um lançamento em produção.
Esse modelo funcionava em cinco a sete varejistas e quebrou conforme a rede crescia. Os varejistas usavam diferentes combinações de Shopify, Magento, BigCommerce e plataformas personalizadas, diferentes caixas, diferentes processadores de pagamento, além de diferentes procedimentos sandbox e de liberação, então cada integração se tornava uma implementação permanente e ciclo de vida de suporte. Qualquer atualização da plataforma do varejista ou mudança no checkout pode forçar o cliente a reconstruir a integração, refazer testes de regressão e agendar uma nova atualização conjunta. Após cerca de seis meses, o programa apoiou cerca de 15 varejistas com 60 a 70 pessoas, e o plano era de 200+ varejistas no ano seguinte: uma extensão linear implicava centenas, potencialmente perto de mil, de pessoas. O verdadeiro problema não era a capacidade de desenvolvimento. A arquitetura tornou cada novo varejista uma nova dependência externa, então o cliente precisava de um modelo onde o crescimento do varejista não exigisse mais crescimento proporcional em engenharia e suporte.
02 Papel e Restrições
Como AI Product Manager , eu era responsável pela solução de ponta a ponta: estratégia de produto, definição de problemas, design da jornada do cliente, definição de casos de uso de IA, arquitetura de soluções, estratégia de capacitação de varejistas, requisitos de dados de produto e rotulagem, engenharia e coordenação IA/ML, requisitos de API e backend, integração com cartão virtual, experiências móveis e de extensão de navegador, coordenação de segurança e conformidade, análises e requisitos de desempenho do modelo, planejamento de implantação e gestão de stakeholders. Uma das decisões mais importantes foi determinar onde a IA deveria ou não ser usada: o modelo apenas respondia se um produto era elegível sob a política de produto locável. Não determinou a capacidade de crédito, não definiu limites de crédito, não validou identidade, definiu termos de pagamento, não realizou verificação de SSN nem aprovou contas, tudo isso mantendo os sistemas existentes de aprovação, identidade e acordo do cliente.
As limitações eram concretas. Elimine a dependência da implementação do lado do varejista: nenhum varejista deve precisar adicionar um método de pagamento, fornecer acesso sandbox, alterar seu checkout, expor APIs personalizadas, designar desenvolvedores ou executar QA conjunto. Apoiar a elegibilidade em nível de produto, já que um varejista poderia vender itens alugáveis e não locáveis, então o sistema classificou itens individuais do carrinho em vez de varejistas inteiros, e lidou com os carrinhos mistos financiando apenas a parte elegível. Trabalhar entre diferentes tecnologias de varejistas e gerenciar mudanças no DOM, porque a extensão ainda lê páginas do varejista e atualizações de páginas pode alterar a estrutura do HTML, seletores, cartões de produtos, preços e campos de checkout. Mantenha a precisão aceitável da classificação, geralmente entre 85 e 90 por cento com um alvo acima de 90 e melhorando para 95. Proteja as informações do cliente (nome, endereço, número de celular, SSN e OTP) com criptografia, tokenização, controles de acesso e registro de auditorias. E depois, apoie o varejo físico sem integrar ao sistema de ponto de venda de cada loja.
03 Abordagem do Produto
Em vez de construir uma equipe de integração de varejistas mais eficiente, mudamos a localização da integração. O modelo original colocava a capacidade de financiamento do cliente dentro do caixa do varejista. O modelo redesenhado colocou a experiência de financiamento dentro dos canais controlados pelo cliente: uma extensão Chrome para comércio eletrônico e o aplicativo móvel do cliente para lojas físicas. Isso criou uma plataforma compartilhada e independente do comerciante que operava em muitos varejistas sem que nenhum varejista implementasse o método de pagamento do cliente.
Online, a extensão Chrome identificou o varejista, informou ao cliente que o financiamento estava disponível, leu o carrinho e o total, enviou os detalhes do produto para o backend, classificou cada item como locável ou não locável, excluiu itens inelegíveis, conferiu o valor elegível contra o limite do cliente, apoiou o registro e verificação, apresentou o acordo, gerou um cartão virtual de uso único ou de uso limitado, e preencheu automaticamente no caixa padrão do varejista. Possibilitar um novo varejista tornou-se um processo gerenciado internamente, em vez de uma integração bilateral de seis meses: coletar os dados públicos do catálogo do varejista, rotular produtos alugáveis ou não alugáveis conforme a política do cliente, treinar ou atualizar o classificador em milhares de registros, validar a precisão contra rótulos conhecidos, configurar extração do DOM para nome do produto, preço, quantidade, categoria e total do carrinho, Teste o fluxo de ponta a ponta, depois ative o varejista, sem necessidade de sandbox, mudança de checkout ou implantação de gateway.
Na loja, estendemos a mesma capacidade para o aplicativo móvel. O aplicativo detectou que o cliente estava dentro do geofence de uma loja; No balcão de cobrança, o cliente fotografava a conta detalhada; OCR extraía nomes de produtos, quantidades e preços; As partidas foram normalizadas e passadas para o mesmo modelo de elegibilidade; o aplicativo separava itens elegíveis de não elegíveis para que produtos não locáveis pudessem ser pagos separadamente; o total elegível foi verificado em relação ao limite; o cliente aceitou o acordo; Um cartão virtual foi gerado para o valor elegível e utilizado pelo processo normal de aceitação do cartão da loja. Se o cliente deixasse a geofence antes de usar o cartão, ela expirava automaticamente. O geofencing não processou a transação, ele funcionou como um gatilho para o backend alterar o status do ciclo de vida do cartão.
O cliente parecia precisar de uma equipe de integração maior. O verdadeiro problema era que o crescimento dependia de centenas de sistemas e cronogramas de lançamento de varejistas externos. Transferir a experiência para uma extensão controlada pelo cliente e um aplicativo móvel, com cartões virtuais como camada de interoperabilidade, mudou essa dependência: os dados do produto do varejista substituíram a integração de pagamentos personalizados, e cada item era decidido de forma independente.
04 Características Construídas
Detecção de varejistas suportados
A extensão reconhece os sites de varejistas habilitados e informa ao cliente que o financiamento está disponível.
Extração de carrinho baseada em DOM
A lógica DOM específica do varejista puxa informações de produtos e carrinhos da página.
Elegibilidade para produtos de IA
Todo item do carrinho é classificado como locável ou não alugável pelo modelo compartilhado.
Manuseio em carrinho misto
Itens inelegíveis são excluídos, então apenas a parte elegível é financiada.
Registro dentro da extensão
Novos clientes criam uma conta sem sair da jornada de compras.
Cartão virtual + preenchimento automático do checkout
Um cartão de uso único ou de uso limitado é gerado e preenchido automaticamente no checkout do varejista.
Jornada móvel na loja
O aplicativo cliente existente foi ampliado para financiar compras elegíveis em lojas físicas.
Geofencing de armazenamento
O aplicativo detecta quando um cliente está dentro da área configurada de uma loja suportada.
Captura de conta + OCR
O cliente fotografa a conta detalhada; OCR extrai itens de linha da imagem.
Normalização de recebimento
OCR produção é convertida em registros estruturados de produtos, quantidade e preços.
Divisão elegível / inelegível
O aplicativo mostra o que pode ser financiado e o que deve ser faturado ou pago separadamente.
Expiração acionada por geofensão
Sair do limite da loja antes de usar aciona a expiração automática do cartão.
Também foram enviados: validação por limite aprovado, verificação de OTP móvel, validação em tempo real do SSN contra os sistemas de identidade existentes do cliente, apresentação e aceitação de acordos (na extensão e no app), habilitação repetível do varejista via treinamento de produto mais configuração do DOM, classificação compartilhada de produtos reutilizada em ambos os canais, e um único backend omnicanal para elegibilidade, validação do cliente, acordos, cartões virtuais e análises.
Arquitetura 05
Dois canais de clientes convergiam em um backend. O canal online é a extensão Chrome mais a extração DOM do varejista; O canal na loja é o aplicativo móvel, além de fotografia de contas, OCR e geofencing. Ambos utilizam os mesmos serviços principais para normalização de produtos, classificação de produtos locáveis, validação de identidade de clientes e limites de crédito, geração de acordos, emissão de cartões virtuais, gestão do ciclo de vida do cartão e análise e registro de auditorias. Um backend Python expõe REST APIs; um provedor externo de placas compatíveis com PCI DSS emite placas virtuais de uso único ou de uso limitado.
A arquitetura mudou a unidade de expansão. Enquanto cada varejista anteriormente exigia um acordo comercial, recursos técnicos do varejista, acesso sandbox, integração de pagamentos, QA conjunto, lançamento coordenado e suporte contínuo à plataforma, um novo varejista online agora exige principalmente preparação de dados do produto, rotulagem, treinamento ou validação do modelo, configuração do DOM, testes de checkout e ativação de extensões. Um novo varejista físico requer principalmente configuração por localização da loja, cobertura de dados de produtos, validação do formato do recibo, testes de OCR , testes de elegibilidade e validação de aceitação de cartão. A segurança abrange criptografia, tokenização, acesso restrito, registro de auditoria, verificação OTP, validação em tempo real do SSN, execução controlada de acordos, cartões de uso único ou de uso limitado, expiração acionada por localização e o provedor compatível com PCI DSS. A confiabilidade é monitorada por superfície: quebra do DOM online (produtos ausentes, seletores inválidos, falhas no preenchimento automático), OCR variabilidade no armazenamento (má iluminação, desfoque, dobras, abreviações, linhas de impostos e descontos), limites de geocerca (permissões negadas, precisão interna, desvio GPS, eventos de saída atrasados, limites em segundo plano do sistema operacional) e resultados de cartões virtuais (falhas de emissão, timeouts do provedor, ativação, expiração, autorização). Os trade-offs são explícitos: a independência do varejista ainda depende do DOM do varejista; A independência do POS depende da qualidade do recibo; um modelo compartilhado abrange dois tipos de entrada muito diferentes; O controle de localização é limitado pela precisão da localização; e o provedor externo de cartão reduz a carga de infraestrutura enquanto adiciona dependência do fornecedor.
06 Análise e Observabilidade
A plataforma expandida precisava de medição separada para o checkout online, desempenho OCR , precisão do modelo, comportamento de localização e resultados de pagamento, pois uma única falha poderia se originar em qualquer um deles. OCR precisão e precisão na classificação eram medidas separadamente: uma falha de classificação podia ocorrer de texto incorreto OCR , análise incorreta de recibos, contexto insuficiente do produto ou um erro genuíno do modelo. Tanto um funil de comércio eletrônico (o varejista detectou → extensão aberta → o carrinho extraído → classificado → valor elegível → confirmado → acordo → cartão → preenchimento automático → compra) quanto um funil na loja (a loja detectou geofence → inserção → conta fotografada → OCR → →itens classificados → não locáveis, separados → elegíveis aprovados → acordo →→ pagamento ou vencimento do cartão de ponta a ponta). O perfil de suporte também mudou: deixando de integrar varejistas, sandboxes e defeitos de gateway, passando para faturamento, acordos, pagamento, OCR ou leitura de faturas, mudanças no DOM, permissão de localização e questões de autorização de cartão.
Métricas de varejistas online
Detecção de varejistas, extração do carrinho, erros do DOM, preenchimento automático e sucesso do checkout, conversão de aprovação para compra.
Métricas de classificação
Precisão por varejista, categoria e canal, taxas falsas e não locáveis, e distribuição de confiança.
OCR métricas
Captura e processamento de sucesso, extração de linhas e preços, reconciliação total, recaptura e taxas de correção manual.
Métricas de geocerca
Detecção de entrada, negação de permissão, eventos de saída, cartões expirados após a saída e tempo entre a geração e o pagamento.
Métricas de cartão virtual
Sucesso da solicitação, latência de geração, erros do provedor, ativação, resultados de autorização e taxa de cartão não utilizado.
07 Camada de Decisão de IA
O modelo respondeu a uma pergunta definida de forma restrita, consistente em ambos os canais: este produto é elegível sob a política de produto locável do cliente? As entradas online combinavam nome do produto, imagem, categoria, contexto do varejista, descrição quando disponível, preço e quantidade, além do rótulo de treinamento locável/não locável. As entradas na loja eram descrições extraídas OCR, texto de item de recibo, quantidade, preço, contexto da loja e dados anteriores de produtos de varejistas, que frequentemente eram muito menos descritivos do que uma página de comércio eletrônico, então a normalização do produto era a mais importante no fluxo na loja. O pipeline capturava informações do produto do DOM ou recibo, normalizava textos específicos do varejista, mapeava para categorias conhecidas, avaliava a locabilidade, retornava o resultado, calculava o total elegível e registrava o resultado e a versão do modelo para monitoramento. O treinamento utilizou dados estruturados em formato de planilha (nome, imagem, categoria, varejista, etiqueta) com milhares de exemplos por varejista ou grupo de varejistas, um modelo supervisionado de classificação de produtos. A precisão relatada foi de aproximadamente 85 a 90%, com a meta de ultrapassar 90 e melhorar para 95; essa era a medida do cliente em nível de projeto, sem precisão, recordação, F1 ou avaliação auditada independente separada.
A IA respondeu apenas a elegibilidade do produto. Nunca determinou a capacidade de crédito, definiu limites de crédito, validou identidade, definiu prazos de pagamento, realizou verificação do SSN ou aprovou contas, essas permanecem com os sistemas existentes do cliente. Modos de falha conhecidos (um item não locável pontuado como aluguelável, um item aluguelável rejeitado incorretamente, uma linha de recibo abreviada mapeada incorretamente, um produto agrupado ou novo, uma taxonomia do varejista alterada ou OCRruim) apontam para o próximo passo recomendado: decisões baseadas em confiança que continuam automaticamente quando confiantes, aplicam regras determinísticas de categoria em confiança média, pedem ao cliente que recapture com baixa confiança, e exclui ou rotas para revisão quando não resolvido.
08 Status e Desfecho
A extensão Chrome suportou 100+ varejistas em cerca de quatro meses, contra cerca de seis meses para 15 no modelo original, e eventualmente permitiu que os clientes usassem o produto de financiamento em 300+ varejistas online, um aumento de aproximadamente vinte vezes em relação à base de 15 varejistas. Um novo varejista não precisava mais de recursos técnicos, acesso sandbox, integração de gateways, QA conjunto, implantação no lado do varejista ou lançamentos coordenados; ele podia ser habilitado por meio de preparação de dados controlada internamente, rotulagem, treinamento de modelos, configuração do DOM, testes de verificação e ativação. A equipe original, composta por 60 a 70 pessoas, permaneceu basicamente a mesma, com cerca de quatro a cinco engenheiros de IA/ML adicionados para preparação de dados, treinamento de modelos e trabalho de precisão, evitando assim o aumento proporcional de pessoal que o modelo antigo sugeria. O trabalho de integração com varejistas, desenvolvimento personalizado, esforço sandbox, testes conjuntos e manutenção de pagamentos específicos da plataforma foram removidos; O cliente relatou aumento no volume de transações de checkout à medida que mais locais aceitavam o limite aprovado (relatado qualitativamente, sem número exato fornecido). A plataforma então se estendeu para o varejo físico por meio do aplicativo móvel, provando que o modelo central não se limitava ao checkout online, e os custos ligados a integrações repetidas, sandboxes, desenvolvimento de gateway, QA conjunto, coordenação de lançamentos e crescimento proporcional de suporte melhoraram, com o provedor de cartão virtual como principal dependência externa restante.
300+
O varejo online apoiado
20×
Aumento da cobertura dos varejistas
4 mo
Para 100+ varejistas (contra 6 meses por 15)
85-90%
Precisão relatada do modelo
09 Reflexão / O Que Vem a Seguir
O que funcionou foi resolver o problema de dependência em vez do problema de pessoal: uma capacidade de elegibilidade atendia páginas web, carrinhos de compras e contas extraídas OCR, cartões virtuais permitiam que o cliente operasse por meio de fluxos de pagamento que os varejistas já suportavam, e cada canal adicionava seus próprios controles (extração e preenchimento automático do DOM online; OCR, geofencing e expiração do cartão na loja) em uma plataforma compartilhada consistente. O que eu melhoraria a seguir: formalizar a habilitação do varejista como um produto de operações internas (upload, rotulagem, treinamento, validação, DOM e configuração da localização da loja, aprovação de lançamento, monitoramento de saúde); adicionar reconciliação de recibos para que os totais extraídos, descontos e impostos reconciliem com a conta final; introduzir uma política de revisão de baixa confiança; reforçar os controles de geocerca com prazos curtos de expiração, limites de valor e transação única e fechamento imediato após a autorização; construir detecção automatizada de alterações de DOM por meio de testes sintéticos programados; relatórios separados de OCR e erros de IA nos painéis; melhorar a rastreabilidade da governança do modelo (canal, varejista, modelo e versão dos dados de treinamento, entradas, confiança OCR e classificação, versão do acordo, resultado do cartão); e expandir cuidadosamente entre Android e iOS, dado suas diferentes permissões e comportamentos de localização em segundo plano. O resultado duradouro foi uma plataforma omnicanal onde os dados dos produtos do varejista substituíram a integração de pagamentos personalizados, a IA determinou a elegibilidade, os sistemas existentes gerenciaram identidade e crédito, cartões virtuais criaram interoperabilidade, e navegador e mobile deram ao cliente controle sobre a distribuição, desvinculando o crescimento do negócio do esforço de engenharia.