01 Contexto & Problema
O cliente ofereceu um produto de BNPL focado no leasing: os clientes solicitaram um limite de despesa aprovado, depois financiaram compras elegíveis e pagaram em prestações em tempo real em vez de pagarem na totalidade. O produto abrangia apenas artigos alugáveis como mobiliário, televisores e eletrónica de consumo, não consumíveis de baixo valor como canetas, cadernos e material de papelaria. O cliente cresceu ao integrar a opção de pagamento diretamente no site de cada retalhista: as vendas aproximam-se do retalhista, o retalhista fornece um sandbox, a equipa integra o gateway, a engenharia e o QA testam o checkout, e depois ambas as partes coordenam uma versão de produção.
Esse modelo funcionou em cinco a sete retalhistas e quebrou-se à medida que a rede crescia. Os retalhistas executavam diferentes combinações de Shopify, Magento, BigCommerce e plataformas personalizadas, diferentes caixas de pagamento, diferentes processadores de pagamento, e diferentes procedimentos sandbox e de lançamento, pelo que cada integração se tornava uma implementação permanente e ciclo de vida de suporte. Qualquer atualização da plataforma do retalhista ou alteração no checkout pode obrigar o cliente a reconstruir a integração, refazer testes de regressão e agendar um novo lançamento conjunto. Após cerca de seis meses, o programa apoiava cerca de 15 retalhistas com 60 a 70 pessoas, e o plano era 200+ retalhistas 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 retalhista uma nova dependência externa, pelo que o cliente precisava de um modelo onde o crescimento dos retalhistas deixasse de exigir crescimento proporcional em engenharia e suporte.
02 Papel e Restrições
Como AI Product Manager fui 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ção, estratégia de capacitação de retalhistas, requisitos de dados de produto e rotulagem, coordenação de engenharia e IA/ML, requisitos de API e backend, integração com cartões virtuais, 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, planeamento de implementação e gestão de stakeholders. Uma das decisões mais importantes foi determinar onde a IA deveria ou não ser utilizada: o modelo apenas respondia se um produto era elegível ao abrigo da política de produto alugável. Não determinou a solvabilidade, não definiu limites de crédito, não validou identidade, definiu os termos de reembolso, não realizou verificação do SSN nem aprovou contas, tudo isto manteve os sistemas existentes de aprovação, identidade e acordo do cliente.
As limitações eram concretas. Eliminar a dependência da implementação do lado do retalhista: nenhum retalhista deve ter de adicionar um método de pagamento, fornecer acesso sandbox, alterar o checkout, expor APIs personalizadas, atribuir programadores ou executar QA conjunto. Apoiar a elegibilidade ao nível do produto, uma vez que um retalhista podia vender tanto artigos arrendáveis como não arrendáveis, pelo que o sistema classificava artigos individuais do carrinho em vez de retalhistas inteiros, e tratava os carrinhos mistos financiando apenas a parte elegível. Trabalhar entre diferentes tecnologias de retalhistas e gerir alterações no DOM, porque a extensão ainda lê páginas do retalhista e as atualizações de página podem alterar a estrutura HTML, seletores, cartões de produtos, preços e campos de checkout. Manter a precisão aceitável da classificação, geralmente entre 85 a 90 por cento com um alvo acima de 90 e melhorando para 95. Proteja a informação do cliente (nome, morada, número de telemóvel, SSN e OTP) com encriptação, tokenização, controlos de acesso e registo de auditorias. E mais tarde, apoie o retalho físico sem integrar no sistema de ponto de venda de cada loja.
03 Abordagem do Produto
Em vez de construir uma equipa de integração de retalhistas mais eficiente, mudámos a localização da integração. O modelo original colocava a capacidade de financiamento do cliente dentro da caixa do retalhista. 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 a aplicação móvel do cliente para lojas físicas. Isso criou uma plataforma partilhada, independente do comerciante, que operava em muitos retalhistas sem que qualquer retalhista implementasse o método de pagamento do cliente.
Online, a extensão Chrome identificou o retalhista, informou o cliente de que o financiamento estava disponível, leu o carrinho e o total, enviou detalhes do produto para o backend, classificou cada artigo como alugável ou não, excluiu artigos inelegíveis, verificou o montante elegível contra o limite do cliente, apoiou o registo e verificação, apresentou o acordo, gerou um cartão virtual de uso único ou de uso limitado, e preencheu-o automaticamente no checkout padrão do retalhista. Permitir um novo retalhista tornou-se um processo gerido internamente em vez de uma integração bilateral de seis meses: recolher os dados públicos do catálogo do retalhista, rotular os produtos como locáveis ou não arrendáveis segundo a política do cliente, treinar ou atualizar o classificador em milhares de registos, validar a precisão com rótulos conhecidos, configurar a 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 retalhista, sem necessidade de sandbox, mudança de checkout ou implementação de gateway.
Na loja, estendemos a mesma capacidade à aplicação móvel. A aplicação detetou que o cliente estava dentro do geofence de uma loja; No balcão de faturação, o cliente fotografava a fatura detalhada; OCR extraiu nomes de produtos, quantidades e preços; As partidas foram normalizadas e passadas para o mesmo modelo de elegibilidade; a aplicação separava os itens elegíveis dos não elegíveis para que os produtos não alugáveis pudessem ser pagos separadamente; o total elegível foi verificado em relação ao limite; O cliente aceitou o acordo; Foi gerado um cartão virtual para o valor elegível e utilizado através do processo normal de aceitação do cartão da loja. Se o cliente saísse da geofence antes de usar o cartão, este expirava automaticamente. A geofencing não processou a transação, funcionou como um gatilho para o backend alterar o estado do ciclo de vida do cartão.
O cliente parecia precisar de uma equipa de integração maior. O verdadeiro problema era que o crescimento dependia de centenas de sistemas e calendários de lançamento de retalhistas externos. Transferir a experiência para uma extensão controlada pelo cliente e uma aplicação móvel, com cartões virtuais como camada de interoperabilidade, alterou essa dependência: os dados dos produtos do retalhista substituíram a integração de pagamentos personalizados, e cada item era decidido de forma independente.
04 Características Construídas
Deteção de retalhistas suportados
A extensão reconhece sites de retalhistas habilitados e informa o cliente que o financiamento está disponível.
Extração de carroças baseadas em DOM
A lógica DOM específica do retalhista retira informações de produtos e carrinhos da página.
Elegibilidade para produtos de IA
Cada item do carrinho é classificado como locável ou não arrendável pelo modelo partilhado.
Manuseamento de carrinhos mistos
Itens inelegíveis são excluídos, pelo que apenas a parte elegível é financiada.
Registo em 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 na caixa do retalhista.
Jornada móvel dentro da loja
A aplicação cliente existente foi alargada para financiar compras elegíveis em lojas físicas.
Geofencing de armazenamento
A aplicação deteta quando um cliente está dentro da área configurada por uma loja suportada.
Captura da conta + OCR
O cliente fotografa a conta detalhada; OCR extrai itens de linha da imagem.
Normalização de receção
OCR produção é convertida em registos estruturados de produtos, quantidades e preços.
Divisão elegível / inelegível
A aplicação mostra o que pode ser financiado e o que deve ser faturado ou pago separadamente.
Expiração desencadeada por geofensão
Sair do limite da loja antes de o usar ativa a expiração automática do cartão.
Também foram enviados: validação do limite aprovado, verificação móvel OTP, 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 na aplicação), habilitação repetível do retalhista através de formação de produto mais configuração do DOM, classificação partilhada de produtos reutilizada em ambos os canais, e um backend omnicanal único para elegibilidade, validação do cliente, acordos, cartões virtuais e análises.
Arquitetura 05
Dois canais de cliente convergiam num backend. O canal online é a Chrome extensão mais extração DOM do retalhista; O canal na loja é a aplicação móvel, além de fotografia de faturas, OCR e geofencing. Ambos utilizam os mesmos serviços essenciais para normalização de produtos, classificação de produtos arrendá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 registo de análises e auditorias. Um backend Python expõe REST APIs; um fornecedor externo de cartões compatíveis com PCI DSS emite os cartões virtuais de uso único ou de uso limitado.
A arquitetura alterou a unidade de expansão. Enquanto cada retalhista anteriormente exigia um acordo comercial, recursos técnicos do retalhista, acesso sandbox, integração de pagamentos, QA conjunto, lançamento coordenado e suporte contínuo da plataforma, um novo retalhista online requer agora principalmente preparação de dados do produto, rotulagem, treino ou validação do modelo, configuração do DOM, testes de checkout e ativação de extensões. Um novo retalhista físico requer principalmente configuração da localização da loja, cobertura de dados do produto, validação do formato do recibo, testes de OCR , testes de elegibilidade e validação de aceitação do cartão. A segurança abrange encriptação, tokenização, acesso restrito, registo de auditorias, 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 pela localização e o fornecedor compatível com PCI DSS. A fiabilidade é monitorizada por superfície: rutura do DOM online (produtos em falta, seletores inválidos, falhas de preenchimento automático), OCR variabilidade na loja (má iluminação, desfoque, dobras, abreviaturas, linhas de impostos e descontos), limites de geocerca (permissões negadas, precisão interior, desvio GPS, eventos de saída atrasados, limites de fundo do sistema operativo) e resultados do cartão virtual (falhas de emissão, timeouts do fornecedor, ativação, expiração, autorização). Os compromissos são explícitos: a independência do retalhista ainda depende do DOM do retalhista; A independência do POS depende da qualidade do recibo; Um modelo partilhado abrange dois tipos de entrada muito diferentes; O controlo de localização é limitado pela precisão da localização; e o fornecedor externo de cartões reduz a carga da infraestrutura ao mesmo tempo que adiciona dependência do fornecedor.
06 Análise e Observabilidade
A plataforma expandida precisava de medições separadas para o checkout online, desempenho OCR , precisão do modelo, comportamento de localização e resultados de pagamento, porque uma única falha podia originar-se em qualquer um deles. OCR precisão e precisão da classificação eram medidas separadamente: uma falha de classificação podia resultar de texto incorreto OCR , análise de receitas incorreta, contexto insuficiente do produto ou um erro genuíno do modelo. Tanto um funil de comércio eletrónico (o retalhista detetou → extensão aberta → carrinho extraído → classificado → montante elegível → verificado → acordo → cartão → preenchimento automático → compra) como um funil na loja (a loja detetou → geofence introduziu → fatura fotografada → OCR → itens → classificados → não locáveis, separados → elegíveis aprovados → acordo → cartão → pagamento ou expiração) foram instrumentados de ponta a ponta. O perfil de suporte também mudou: afastando-se das integrações com retalhistas, sandboxes e defeitos de gateway, passando para faturação, acordos, reembolso, OCR ou leitura de faturas, alterações ao DOM, questões de localização e autorização de cartão.
Métricas de retalhistas online
Deteção de retalhistas, extração do carrinho, erros do DOM, preenchimento automático e sucesso da compra, conversão de aprovação para compra.
Métricas de classificação
Precisão por retalhista, categoria e canal, falsas taxas locáveis e não arrendá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 geofensão
Deteção de entrada, negação de permissão, eventos de saída, cartões expirados após a saída, e tempo desde a geração até ao pagamento.
Métricas de cartão virtual
Sucesso do pedido, latência de geração, erros do fornecedor, 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 questão definida de forma restrita, consistente em ambos os canais: este produto é elegível ao abrigo da política de produto locável do cliente? As entradas online combinavam nome do produto, imagem, categoria, contexto do retalhista, descrição quando disponível, preço e quantidade, além do rótulo de formação alugável/não arrendável. As entradas feitas na loja eram descrições extraídas OCR, texto do item de recibo, quantidade, preço, contexto da loja e dados anteriores de produtos de retalhistas, que eram frequentemente muito menos descritivos do que uma página de comércio eletrónico, pelo que a normalização do produto era a mais importante no fluxo dentro da loja. O pipeline recolhia informações do produto do DOM ou recibo, normalizava texto específico do retalhista, mapeava para categorias conhecidas, avaliava a possibilidade de arrendar, devolveu o resultado, calculou o total elegível e registou o resultado e a versão do modelo para monitorização. A formação utilizou dados estruturados em folhas de cálculo (nome, imagem, categoria, retalhista, etiqueta) com milhares de exemplos por retalhista ou grupo de retalhistas, um modelo supervisionado de classificação de produtos. A precisão reportada foi de cerca de 85 a 90 por cento, com o objetivo de ultrapassar 90 e melhorar para 95; esta era a medida ao nível do projeto do cliente, sem necessidade de precisão, recordação, F1 ou avaliação auditada independentemente.
A IA respondeu apenas à elegibilidade do produto. Nunca determinou a solvabilidade, definiu limites de crédito, validou a identidade, definiu prazos de reembolso, nem realizou verificação do SSN nem aprovou contas, esses permaneciam com os sistemas existentes do cliente. Modos de falha conhecidos (um artigo não arrendável pontuado para arrendamento, um artigo arrendável incorretamente rejeitado, uma linha de receção abreviada mapeada incorretamente, um produto agrupado ou novo, uma taxonomia alterada do retalhista ou OCRdefeituosa) apontam para o passo seguinte recomendado: decisão baseada em confiança que continua automaticamente quando confiante, aplica regras determinísticas de categoria a confiança média, pede ao cliente que recupere a baixa confiança, e exclui ou encaminha para revisão quando não estiver resolvido.
08 Estado e Desfecho
A extensão Chrome suportou 100+ retalhistas em cerca de quatro meses, contra cerca de seis meses para 15 no modelo original, e acabou por permitir que os clientes usassem o produto de financiamento em 300+ retalhistas online, um aumento de aproximadamente vinte vezes em relação à base de 15 retalhistas. Um novo retalhista já não precisava de recursos técnicos, acesso sandbox, integração de gateway, QA conjunto, implementação do lado do retalhista ou lançamentos coordenados; podia ser ativada através de preparação de dados controlada internamente, rotulagem, treino de modelos, configuração do DOM, testes de verificação e ativação. A equipa original, composta por 60 a 70 pessoas, manteve-se praticamente igual, com cerca de quatro a cinco engenheiros de IA/ML adicionados para preparação de dados, treino de modelos e trabalho de precisão, pelo que a organização evitou o aumento proporcional de pessoal que o modelo antigo implicava. O trabalho de integração de retalhistas, desenvolvimento personalizado, esforço sandbox, testes conjuntos e manutenção de pagamentos específicos da plataforma foram removidos; O cliente reportou um aumento no volume de transações de checkout à medida que mais locais aceitavam o limite aprovado (reportado qualitativamente, sem valor exato fornecido). A plataforma expandiu-se depois para o retalho físico através da aplicação móvel, provando que o modelo central não se limitava ao checkout web, e os custos ligados a integrações repetidas, sandboxes, desenvolvimento de gateway, QA conjunto, coordenação de lançamentos e crescimento proporcional do suporte melhoraram, com o fornecedor de cartões virtuais como principal dependência externa remanescente.
300+
Retalhistas online apoiados
20×
Aumento da cobertura dos retalhistas
4 mo
Para 100+ retalhistas (contra 6 meses por 15)
85-90%
Precisão reportada do modelo
09 Reflexão / O Que Vem a Seguir
O que resultou foi resolver o problema da dependência em vez do problema de pessoal: uma capacidade de elegibilidade servia páginas web, carrinhos de compras e faturas extraídas OCR, cartões virtuais permitiam ao cliente operar através de fluxos de pagamento que os retalhistas já suportavam, e cada canal adicionava os seus próprios controlos (extração DOM e preenchimento automático online; OCR, geofencing e expiração do cartão na loja) numa plataforma partilhada consistente. O que eu melhoraria a seguir: formalizar a capacitação do retalhista como um produto de operações internas (upload, rotulagem, formação, validação, DOM e configuração da loja, aprovação de lançamentos, monitorização da saúde); adicionar reconciliação de recibos para que os totais, descontos e reconciliação fiscal extraídos com a fatura final; introduzir uma política de revisão de baixa confiança; reforçar os controlos de geocerca com prazos de expiração curtos, limites de montantes e transações únicas e encerramento imediato após a autorização; construir deteção automatizada de alterações de DOM através de testes sintéticos programados; relatórios separados de OCR e de IA nos dashboards; melhorar a rastreabilidade da governação do modelo (canal, retalhista, versão dos dados do modelo e de treino, entradas, confiança OCR e classificação, versão do acordo, resultado do cartão); e expandir cuidadosamente entre Android e iOS, tendo em conta as suas diferentes permissões e comportamentos de localização em segundo plano. O resultado duradouro foi uma plataforma omnicanal onde os dados dos produtos dos retalhistas substituíram a integração de pagamentos personalizados, a IA determinou a elegibilidade, os sistemas existentes geriram a identidade e o crédito, os cartões virtuais criaram interoperabilidade, e o navegador e o móvel deram ao cliente controlo sobre a distribuição, desvinculando o crescimento do negócio do esforço de engenharia.