01 Contexto y problema
El cliente ofreció un producto BNPL centrado en el alquiler: los clientes solicitaban un límite de gasto aprobado, luego financiaban las compras elegibles y devolvían el dinero en plazos en lugar de pagar la totalidad. El producto solo cubría artículos alquilables como muebles, televisores y electrónica de consumo, no consumibles de bajo valor como bolígrafos, cuadernos y material escolar. El cliente creció integrando su opción de pago directamente en la web de cada minorista: ventas se acerca al minorista, el minorista proporciona un sandbox, el equipo integra la pasarela, ingeniería y control de calidad prueban el pago, y luego ambas partes coordinan una versión de producción.
Ese modelo funcionó en cinco o siete minoristas y se fue rompiendo a medida que la red crecía. Los minoristas ejecutaban diferentes combinaciones de Shopify, Magento, BigCommerce y plataformas personalizadas, diferentes cajas, distintos procesadores de pagos, y distintos procedimientos sandbox y de liberación, por lo que cada integración se convertía en su propio ciclo de vida permanente y de soporte. Cualquier actualización de plataforma o cambio de compra del minorista podría obligar al cliente a reconstruir la integración, repetir las pruebas de regresión y programar una nueva versión conjunta. Tras aproximadamente seis meses, el programa apoyaba a unos 15 minoristas con entre 60 y 70 personas, y el plan era 200+ minoristas al año siguiente: una extensión lineal implicaba cientos, potencialmente cerca de mil, de personas. El verdadero problema no era la capacidad de desarrollo. La arquitectura convirtió a cada nuevo minorista en una nueva dependencia externa, por lo que el cliente necesitaba un modelo en el que el crecimiento minorista ya no requiriera crecimiento proporcional en ingeniería y soporte.
02 Rol y Limitaciones
Como AI Product Manager yo era responsable de la solución de extremo a extremo: estrategia de producto, definición de problemas, diseño del recorrido del cliente, definición de casos de uso de IA, arquitectura de soluciones, estrategia de habilitación de minoristas, requisitos de datos de producto y etiquetado, coordinación de ingeniería e IA/ML, requisitos de API y backend, integración de tarjetas virtuales, experiencias móviles y de extensión de navegador, coordinación de seguridad y cumplimiento, análisis y requisitos de rendimiento del modelo, planificación de despliegue y gestión de partes interesadas. Una de las decisiones más importantes fue determinar dónde debería y no debe usarse la IA: el modelo solo respondía si un producto era elegible bajo la política de producto alquilable. No determinó la solvencia, no estableció límites de crédito, validó identidad, definió términos de reembolso, realizó verificación del SSN ni aprobó cuentas, todo lo cual se mantuvo con los sistemas existentes de aprobación, identidad y acuerdo del cliente.
Las limitaciones eran concretas. Eliminar la dependencia de la implementación del lado del minorista: ningún minorista debería tener que añadir un método de pago, proporcionar acceso sandbox, cambiar su pago, exponer APIs personalizadas, asignar desarrolladores o ejecutar QA conjunto. Apoyar la elegibilidad a nivel de producto, ya que un minorista podía vender tanto artículos alquilables como no alquilables, por lo que el sistema clasificaba los artículos individuales del carrito en lugar de los minoristas completos, y gestionaba los carritos mixtos financiando solo la parte elegible. Trabajar entre diferentes tecnologías de minoristas y gestionar los cambios en el DOM, porque la extensión sigue leyendo páginas de los minoristas y las actualizaciones de página podrían modificar la estructura HTML, los selectores, las tarjetas de producto, los precios y los campos de pago. Mantener una precisión de clasificación aceptable, generalmente entre el 85 y el 90 por ciento con un objetivo superior al 90 y mejorando hacia el 95. Proteger la información del cliente (nombre, dirección, número de móvil, SSN y OTP) mediante cifrado, tokenización, controles de acceso y registro de auditorías. Y más adelante, dar soporte al comercio físico sin integrarlo en el sistema de punto de venta de cada tienda.
03 Enfoque del producto
En lugar de construir un equipo de integración minorista más eficiente, cambiamos la ubicación de la integración. El modelo original situaba la capacidad de financiamiento del cliente dentro de la caja del minorista. El modelo rediseñado situó la experiencia de financiación dentro de canales controlados por el cliente: una extensión Chrome para comercio electrónico y la aplicación móvil del cliente para tiendas físicas. Eso creó una plataforma compartida e independiente del comerciante que operaba en muchos minoristas sin que ningún minorista implementara el método de pago del cliente.
En línea, la prórroga Chrome identificó al minorista, informó al cliente de que había financiación disponible, leyó el carrito y el total, envió los detalles del producto al backend, clasificó cada artículo como alquilable o no alquilable, excluyó los artículos no elegibles, comprobó el importe elegible frente al límite del cliente, respaldó el registro y verificación, presentó el acuerdo, generó una tarjeta virtual de un solo uso o de uso limitado, y lo rellenó automáticamente en la caja estándar del minorista. Habilitar un nuevo minorista se convirtió en un proceso gestionado internamente en lugar de una integración bilateral de seis meses: recopilar los datos públicos del catálogo del minorista, etiquetar los productos alquilables o no alquilables según la política del cliente, entrenar o actualizar el clasificador en miles de registros, validar la precisión frente a etiquetas conocidas, configurar la extracción del DOM para nombre del producto, precio, cantidad, categoría y total del carrito, Prueba el flujo de extremo a extremo, luego activa el minorista, sin necesidad de sandbox, cambio de pago ni despliegue de gateway.
En tienda, extendimos la misma capacidad a la aplicación móvil. La app detectó que el cliente estaba dentro del geovallado de una tienda; en el mostrador de facturación el cliente fotografiaba la factura detallada; OCR extrajo nombres de productos, cantidades y precios; las partidas se normalizaron y pasaron al mismo modelo de elegibilidad; la aplicación separaba los artículos elegibles de los no elegibles para que los productos no alquilables pudieran pagarse por separado; el total elegible se comprobó con el límite; el cliente aceptó el acuerdo; Se generó una tarjeta virtual para el importe elegible y se utilizó mediante el proceso habitual de aceptación de la tarjeta en la tienda. Si el cliente salía de la geocerca antes de usar la tarjeta, caducaba automáticamente. La geovalla no procesó la transacción, actuó como un disparador para que el backend cambiara el estado del ciclo de vida de la tarjeta.
El cliente parecía necesitar un equipo de integración más grande. El verdadero problema era que el crecimiento dependía de cientos de sistemas y calendarios de lanzamiento de minoristas externos. Trasladar la experiencia a una extensión controlada por el cliente y una aplicación móvil, con tarjetas virtuales como capa de interoperabilidad, cambió esa dependencia: los datos de productos de los minoristas sustituyeron a la integración de pagos personalizados y cada artículo se decidió de forma independiente.
04 Características construidas
Detección de minoristas soportados
La extensión reconoce los sitios de los minoristas habilitados e informa al cliente de que hay financiación disponible.
Extracción de carros basada en DOM
La lógica DOM específica del minorista extrae información de productos y carritos de la página.
Elegibilidad para productos de IA
Cada artículo del carrito se clasifica como alquilable o no alquilable por el modelo compartido.
Manejo con carros mixtos
Los elementos no elegibles quedan excluidos, por lo que solo se financia la parte elegible.
Registro en extensión
Los nuevos clientes crean una cuenta sin abandonar el proceso de compra.
Tarjeta virtual + relleno automático de préstamo
Se genera una tarjeta de un solo uso o de uso limitado y se rellena automáticamente en la caja del minorista.
Viaje móvil en tienda
La aplicación cliente existente se amplió para financiar compras físicas elegibles.
Geovallado de la tienda
La app detecta cuando un cliente está dentro del área configurada de una tienda soportada.
Captura de factura + OCR
El cliente fotografía la factura detallada; OCR extrae elementos de línea de la imagen.
Normalización de recibos
OCR producción se convierte en registros estructurados de producto, cantidad y precio.
División elegible / no elegible
La aplicación muestra qué se puede financiar y qué debe facturarse o pagarse por separado.
Expiración desencadenada por geocerca
Salir del límite de la tienda antes de usarlo activa la caducidad automática de la tarjeta.
También se envió: validación de límite aprobado, verificación de OTP móvil, validación en tiempo real del SSN frente a los sistemas de identidad existentes del cliente, presentación y aceptación de acuerdos (en extensión e en la aplicación), habilitación repetible de minoristas mediante formación de producto más configuración DOM, clasificación compartida de productos reutilizada en ambos canales y un único backend omnicanal para elegibilidad, validación de clientes, acuerdos, tarjetas virtuales y análisis.
Arquitectura 05
Dos canales de clientes convergían en un backend. El canal online es la extensión Chrome más la extracción de DOM por minorista; El canal en tienda es la aplicación móvil, además de fotografía de facturas, OCR y geovallada. Ambos utilizan los mismos servicios básicos para la normalización de productos, clasificación de productos arrendables, validación de identidad de clientes y límites de crédito, generación de acuerdos, emisión de tarjetas virtuales, gestión del ciclo de vida de la tarjeta y análisis y registro de auditorías. Un backend Python expone REST APIs; un proveedor externo de tarjetas compatibles con PCI DSS emite las tarjetas virtuales de un solo uso o de uso limitado.
La arquitectura cambió la unidad de expansión. Mientras que antes cada minorista requería un acuerdo comercial, recursos técnicos, acceso sandbox, integración de pagos, control de calidad conjunto, lanzamiento coordinado y soporte continuo de la plataforma, un nuevo minorista online ahora requiere principalmente preparación de datos de producto, etiquetado, entrenamiento o validación del modelo, configuración del DOM, pruebas de pago y activación de extensiones. Un nuevo minorista físico requiere principalmente configuración por ubicación de tienda, cobertura de datos de producto, validación del formato de recibos, pruebas de OCR , pruebas de elegibilidad y validación de aceptación de tarjetas. La seguridad abarca cifrado, tokenización, acceso restringido, registro de auditorías, verificación OTP, validación en tiempo real del SSN, ejecución controlada de acuerdos, tarjetas de un solo uso o de uso limitado, expiración activada por ubicación y el proveedor compatible con PCI DSS. La fiabilidad se monitoriza por superficie: rotura del DOM online (productos ausentes, selectores inválidos, fallos de autollenado), OCR variabilidad en la tienda (mala iluminación, desenfoque, pliegues, abreviaturas, líneas fiscales y de descuento), límites de geocerca (permisos denegados, precisión interior, deriva GPS, eventos de salida retardados, límites en segundo plano del sistema operativo) y resultados de la tarjeta virtual (fallos en la emisión, tiempos de espera del proveedor, activación, expiración, autorización). Los compromisos son explícitos: la independencia del minorista sigue dependiendo del DOM del minorista; La independencia del POS depende de la calidad del recibo; un modelo compartido abarca dos tipos de entrada muy diferentes; El control de ubicación está limitado por la precisión de la ubicación; y el proveedor externo de tarjetas reduce la carga de infraestructura mientras añade dependencia al proveedor.
06 Analítica y Observabilidad
La plataforma ampliada necesitaba mediciones separadas para el pago online, el rendimiento OCR , la precisión del modelo, el comportamiento de ubicación y los resultados de pago, porque un solo fallo podía originarse en cualquiera de ellos. OCR precisión y precisión de clasificación se midieron por separado: un fallo de clasificación podía deberse a un texto de OCR incorrecto, análisis incorrecto de recibos, contexto insuficiente del producto o un error genuino del modelo. Tanto un embudo de comercio electrónico (el minorista detectó → extensión abierta → carrito extraído → clasificado → cantidad elegible → verificado → acuerdo → tarjeta → autocompletado → compra) como un embudo en tienda (la tienda detectó →geocerca → la factura fotografiada → OCR → las →partidas clasificadas → no alquilables, separadas → elegibles, aprobadas → acuerdo → → tarjeta pago o caducidad) estaban instrumentadas de principio a fin. El perfil de soporte también cambió: dejando de integrar con minoristas, sandboxes y defectos de pasarela, hacia facturación, acuerdos, reembolsos, OCR o lectura de facturas, cambios en el DOM, permisos de ubicación y preguntas de autorización de tarjetas.
Métricas de minoristas online
Detección de minoristas, extracción del carrito, errores del DOM, autocompletado y éxito en la compra, conversión de aprobación a compra.
Métricas de clasificación
Precisión por minorista, categoría y canal, tarifas falsas y no arrendables, y distribución de la confianza.
OCR métricas
Captura y procesamiento del éxito, extracción de líneas y precios, conciliación total, recuperación y tasas de corrección manual.
Métricas de geocerca
Detección de entrada, denegación de permiso, eventos de salida, tarjetas caducadas tras la salida y tiempo desde la generación hasta el pago.
Métricas de tarjetas virtuales
Éxito de la solicitud, latencia de generación, errores del proveedor, activación, resultados de autorización y tasa de tarjeta no utilizada.
07 Capa de Decisión de IA
El modelo respondió a una pregunta definida de forma limitada, consistente en ambos canales: ¿es este producto elegible según la política de productos alquilables del cliente? Las entradas en línea combinaban nombre del producto, imagen, categoría, contexto del minorista, descripción cuando estaba disponible, precio y cantidad, además de la etiqueta de formación alquilable/no arrendable. Las entradas en tienda eran descripciones extraídas OCR, texto de la línea de recibo, cantidad, precio, contexto de la tienda y datos de productos previos de minoristas, que a menudo eran mucho menos descriptivos que una página de comercio electrónico, por lo que la normalización del producto era lo más importante en el flujo en tienda. La cadena recopilaba información del producto del DOM o recibo, normalizaba el texto específico del minorista, mapeaba a categorías conocidas, evaluaba la rentabilidad, devolvía el resultado, calculaba el total elegible y registraba el resultado y la versión del modelo para su monitorización. La formación utilizó datos estructurados en forma de hoja de cálculo (nombre, imagen, categoría, minorista, etiqueta) con miles de ejemplos por minorista o grupo de minoristas, un modelo supervisado de clasificación de productos. La precisión reportada fue aproximadamente del 85 al 90 por ciento, con el objetivo de superar el 90 y mejorar hacia el 95; esta era la medida a nivel de proyecto del cliente, sin que se proporcionara una evaluación separada de precisión, recuerdo, F1 o auditoría independiente.
La IA solo respondió la elegibilidad del producto. Nunca determinó la solvencia, ni estableció límites de crédito, ni validó la identidad, ni definió términos de reembolso, ni realizó verificación del SSN ni aprobó cuentas, esas reglas permanecieron con los sistemas existentes del cliente. Los modos de fallo conocidos (un artículo no arrendable puntuado como alquilable, un artículo alquilable rechazado erróneamente, una línea de recibo abreviada mal asignada, un producto empaquetado o nuevo, una taxonomía del minorista modificada o OCRdefectuosa) señalan el siguiente paso recomendado: decisiones basadas en la confianza que continúan automáticamente cuando hay confianza, aplican reglas de categoría deterministas a confianza media, piden al cliente que recupere a baja confianza, y excluye o enruda para revisar cuando no se resuelve.
08 Estado y resultado
La extensión de Chrome apoyó a 100+ minoristas en aproximadamente cuatro meses, frente a unos seis meses para 15 bajo el modelo original, y finalmente permitió a los clientes usar el producto de financiación en 300+ minoristas online, un aumento de aproximadamente veinte veces respecto al nivel base de 15 minoristas. Un nuevo minorista ya no necesitaba recursos técnicos, acceso sandbox, integración de gateway, QA conjunto, despliegue en el lado del minorista ni lanzamientos coordinados; podía habilitarse mediante la preparación de datos controlada internamente, etiquetado, entrenamiento de modelos, configuración del DOM, pruebas de verificación y activación. El equipo original, de 60 a 70 personas, se mantuvo en general igual, con aproximadamente cuatro o cinco ingenieros de IA/ML añadidos para la preparación de datos, el entrenamiento de modelos y el trabajo de precisión, por lo que la organización evitó el aumento proporcional de personal que el modelo anterior implicaba. Se eliminaron los trabajos de integración de minoristas, desarrollo personalizado, esfuerzo sandbox, pruebas conjuntas y mantenimiento de pagos específicos por plataforma; El cliente informó de un aumento en el volumen de transacciones de pago a medida que más lugares aceptaban el límite aprobado (reportado cualitativamente, sin una cifra exacta). La plataforma se extendió entonces al comercio físico a través de la aplicación móvil, demostrando que el modelo central no se limitaba al checkout web, y los costes ligados a integraciones repetidas, sandboxes, desarrollo de gateway, QA conjunto, coordinación de lanzamientos y crecimiento proporcional del soporte mejoraron, siendo el proveedor de tarjetas virtuales la principal dependencia externa restante.
300+
Comercios online apoyados
20×
Aumento de la cobertura de los minoristas
4 mo
A 100+ minoristas (frente a 6 meses por 15)
85-90%
Precisión reportada del modelo
09 Reflexión / Qué sigue
Lo que funcionó fue resolver el problema de dependencia en lugar del problema de personal: una capacidad de elegibilidad servía a páginas web, carritos de la compra y facturas extraídas OCR, tarjetas virtuales permitían al cliente operar a través de flujos de pago que los minoristas ya soportaban, y cada canal añadía sus propios controles (extracción DOM y autollenado online; OCR, geovallado y caducidad de tarjeta en tienda) en una plataforma compartida consistente. Lo que mejoraría a continuación: formalizar la habilitación de minoristas como un producto de operaciones internas (subida, etiquetado, formación, validación, configuración del DOM y ubicación de tienda, aprobación de lanzamientos, monitorización de la salud); añadir conciliación de recibos para que los totales extraídos, descuentos y conciliación fiscal con la factura final; introducir una política de revisión de baja confianza; reforzar los controles de geovallas con plazos cortos, límites de cantidad y transacciones individuales y cierre inmediato tras la autorización; construir detección automatizada de cambios de DOM mediante pruebas sintéticas programadas; informes separados de OCR y errores de IA en los paneles; mejorar la trazabilidad de gobernanza del modelo (canal, minorista, modelo y versión de datos de entrenamiento, entradas, confianza en OCR y clasificación, versión del acuerdo, resultado de la tarjeta); y expandirse cuidadosamente a Android e iOS dado sus diferentes permisos y comportamientos de ubicación en segundo plano. El resultado duradero fue una plataforma omnicanal donde los datos de productos de los minoristas reemplazaron la integración de pagos personalizados, la IA determinó la elegibilidad, los sistemas existentes gestionaron la identidad y el crédito, las tarjetas virtuales crearon interoperabilidad, y el navegador y el móvil dieron al cliente el control sobre la distribución, desvinculando el crecimiento empresarial del esfuerzo de ingeniería.