01 Contesto & Problema
Il cliente offriva un prodotto BNPL focalizzato sul leasing: i clienti richiedevano un limite di spesa approvato, poi finanziavano acquisti idonei e rimborsavano in rate invece di pagare per intero. Il prodotto copriva solo oggetti affittabili come mobili, televisori ed elettronica di consumo, non consumabili di basso valore come penne, quaderni e cancelleria. Il cliente è cresciuto integrando direttamente l'opzione di pagamento nel sito web di ogni rivenditore: le vendite si avvicinano al rivenditore, il rivenditore fornisce un sandbox, il team integra il gateway, ingegneria e QA testano il checkout, poi entrambe le parti coordinano una release in produzione.
Quel modello funzionava in cinque o sette rivenditori e si ruppe con la crescita della rete. I rivenditori utilizzavano diverse combinazioni di Shopify, Magento, BigCommerce e piattaforme personalizzate, diversi checkout, diversi processori di pagamento e diverse procedure sandbox e di rilascio, così ogni integrazione diventava una propria implementazione permanente e ciclo di supporto a sé stante. Qualsiasi aggiornamento della piattaforma o modifica del checkout del rivenditore potrebbe costringere il client a ricostruire l'integrazione, rifare i test di regressione e programmare una nuova release congiunta. Dopo circa sei mesi il programma supportava circa 15 rivenditori con 60-70 persone, e il piano prevedeva 200+ rivenditori l'anno successivo: un'estensione lineare implicava centinaia, potenzialmente quasi mille, di persone. Il vero problema non era la capacità di sviluppo. L'architettura rendeva ogni nuovo rivenditore una nuova dipendenza esterna, quindi il cliente aveva bisogno di un modello in cui la crescita dei rivenditori non richiedesse più una crescita proporzionale in ingegneria e supporto.
02 Ruolo e vincoli
Come AI Product Manager ho posseduto la soluzione end-to-end: strategia prodotto, definizione del problema, design del customer journey, definizione di casi d'uso AI, architettura delle soluzioni, strategia di enablement del retailer, requisiti di dati prodotto e etichettatura, coordinamento ingegneristico e AI/ML, requisiti API e backend, integrazione con schede virtuali, esperienze mobile ed estensioni browser, coordinamento sicurezza e conformità, requisiti di analisi e prestazioni del modello, pianificazione del rollout e gestione degli stakeholder. Una delle richieste più importanti è stata determinare dove l'IA dovesse e non dovesse essere utilizzata: il modello rispondeva solo se un prodotto fosse idoneo secondo la politica del prodotto locabile. Non ha determinato l'affidabilità creditizia, fissato limiti di credito, validato l'identità, definito i termini di rimborso, eseguito la verifica del SSN né approvato conti, tutto ciò che è rimasto fedele ai sistemi di approvazione, identità e accordo esistenti del cliente.
I vincoli erano concreti. Eliminare la dipendenza dall'implementazione lato retailer: nessun retailer dovrebbe dover aggiungere un metodo di pagamento, fornire accesso sandbox, cambiare il checkout, esporre API personalizzate, assegnare sviluppatori o gestire un QA congiunto. Supportare l'idoneità a livello di prodotto, poiché un rivenditore poteva vendere sia articoli affittabili che non affittabili, quindi il sistema classificava gli articoli del singolo carrello invece che i rivenditori interi, e gestiva i carrelli misti finanziando solo la parte idonea. Lavorare tra diverse tecnologie dei rivenditori e gestire le modifiche DOM, poiché l'estensione continua a leggere le pagine dei rivenditori e gli aggiornamenti delle pagine potrebbero modificare la struttura HTML, i selezionatori, le schede prodotto, i prezzi e i campi di checkout. Mantenere un'accuratezza di classificazione accettabile, generalmente tra l'85 e il 90 percento con un obiettivo superiore a 90 e miglioramento verso il 95. Proteggere le informazioni dei clienti (nome, indirizzo, numero di cellulare, SSN e OTP) con crittografia, tokenizzazione, controlli di accesso e registrazione di audit. E successivamente, supporta il retail fisico senza integrarli nel sistema di punto vendita di ogni negozio.
03 Approccio al prodotto
Invece di costruire un team di integrazione più efficiente per i rivenditori, abbiamo cambiato la posizione dell'integrazione. Il modello originale inseriva la capacità di finanziamento del cliente all'interno della cassa del rivenditore. Il modello riprogettato collocava l'esperienza di finanziamento all'interno dei canali controllati dal cliente: un'estensione Chrome per l'ecommerce e l'app mobile del cliente per i negozi fisici. Questo ha creato una piattaforma condivisa e indipendente dal commerciante che operava in molti rivenditori senza che alcun rivenditore implementasse il metodo di pagamento del cliente.
Online, l'estensione Chrome ha identificato il rivenditore, ha informato il cliente che il finanziamento era disponibile, ha letto il carrello e il totale, ha inviato i dettagli del prodotto al backend, ha classificato ogni articolo come affittabile o non affittabile, ha escluso gli articoli non idonei, ha controllato l'importo idoneo rispetto al limite del cliente, ha supportato la registrazione e la verifica, ha presentato l'accordo, generato una carta virtuale a uso singolo o a uso limitato, e l'ha compilata automaticamente nella cassa standard del rivenditore. Abilitare un nuovo rivenditore è diventato un processo gestito internamente piuttosto che un'integrazione bilaterale di sei mesi: raccogliere i dati pubblici del catalogo del rivenditore, etichettare i prodotti affittabili o non affittabili secondo la politica del cliente, formare o aggiornare il classificatore su migliaia di record, validare l'accuratezza rispetto alle etichette note, configurare l'estrazione DOM per nome prodotto, prezzo, quantità, categoria e totale carrello, Testa il flusso end-to-end, poi attiva il rivenditore, senza bisogno di sandbox, cambio di checkout o deployment gateway.
In negozio, abbiamo esteso la stessa funzionalità anche all'app mobile. L'app rilevava che il cliente era all'interno della georecinzione di un negozio; al banco fatturazione il cliente fotografava la bolletta dettagliata; OCR estratto nomi di prodotto, quantità e prezzi; Le voci sono state normalizzate e passate allo stesso modello di idoneità; l'app separava gli oggetti idonei dagli inammissibili, così i prodotti non noleggiabili potevano essere pagati separatamente; il totale idoneo veniva confrontato con il limite; il cliente accettò l'accordo; Veniva generata una carta virtuale per l'importo idoneo e utilizzata tramite il normale processo di accettazione della carta del negozio. Se il cliente ha lasciato la geofence prima di usare la carta, questa è scaduta automaticamente. La geofencing non ha elaborato la transazione, ha agito come un trigger per il backend per cambiare lo stato del ciclo di vita della carta.
Il cliente sembrava aver bisogno di un team di integrazione più numeroso. Il vero problema era che la crescita dipendeva da centinaia di sistemi e programmi di rilascio esterni per i rivenditori. Spostare l'esperienza in un'estensione controllata dal client e un'app mobile, con le carte virtuali come livello di interoperabilità, ha cambiato questa dipendenza: i dati prodotto del rivenditore hanno sostituito l'integrazione dei pagamenti personalizzati e ogni articolo veniva deciso indipendentemente.
04 Caratteristiche costruite
Rilevamento supportato da rivenditori
L'estensione riconosce i siti dei rivenditori abilitati e informa il cliente che il finanziamento è disponibile.
Estrazione con carretto basata su DOM
La logica DOM specifica per il rivenditore estrae informazioni su prodotti e carrelli dalla pagina.
Idoneità ai prodotti IA
Ogni articolo del carrello è classificato come locabile o non affittabile dal modello condiviso.
Manipolazione con carrelli misti
Gli oggetti non idonei sono esclusi, quindi solo la parte idonea viene finanziata.
Registrazione in estensione
I nuovi clienti creano un account senza lasciare il percorso di acquisto.
Carta virtuale + autocompilazione del checkout
Viene generata una carta monouso o a uso limitato che viene compilata automaticamente alla cassa del rivenditore.
Viaggio mobile in negozio
L'app client esistente è stata estesa per finanziare acquisti fisici idonei.
Geofencing degli store
L'app rileva quando un cliente si trova all'interno dell'area configurata da un negozio supportato.
Cattura del conto + OCR
Il cliente fotografa la fattura dettagliata; OCR estrae le linee dall'immagine.
Normalizzazione dei ricevimenti
OCR produzione viene convertita in registri strutturati di prodotti, quantità e prezzi.
Divisione idonea / non idonea
L'app mostra cosa può essere finanziato e cosa deve essere fatturato o pagato separatamente.
Scadenza attivata da geofensione
Lasciare il confine del negozio prima di usarlo attiva la scadenza automatica della carta.
È stato inoltre inviato: validazione del limite approvato, verifica mobile OTP, validazione SSN in tempo reale rispetto ai sistemi di identità esistenti del cliente, presentazione e accettazione dell'accordo (in estensione e in app), abilitazione ripetibile da parte dei rivenditori tramite formazione prodotto più configurazione DOM, classificazione condivisa dei prodotti riutilizzata su entrambi i canali e un unico backend omnicanale per l'idoneità, la validazione del cliente, gli accordi, le carte virtuali e le analisi.
05 Architettura
Due canali clienti convergevano su un backend. Il canale online è l'estensione Chrome più il rivenditore estrazione DOM; Il canale in negozio è l'app mobile più fotografia di bollette, OCR e geofencing. Entrambi utilizzano gli stessi servizi di base per la normalizzazione del prodotto, la classificazione dei prodotti locatibili, l'identità del cliente e la validazione del limite di credito, la generazione di accordi, l'emissione di carte virtuali, la gestione del ciclo di vita della carta e l'analisi e la registrazione di audit. Un backend Python espone REST API; un fornitore esterno di schede compatibili PCI DSS emette le schede virtuali monouso o a uso limitato.
L'architettura ha modificato l'unità di espansione. Dove in precedenza ogni rivenditore richiedeva un accordo commerciale, risorse tecniche del rivenditore, accesso sandbox, integrazione dei pagamenti, QA congiunto, un rilascio coordinato e supporto continuo della piattaforma, un nuovo rivenditore online ora richiede principalmente la preparazione dei dati prodotto, l'etichettatura, l'addestramento o la validazione del modello, la configurazione del DOM, il test di checkout e l'attivazione delle estensioni. Un nuovo rivenditore fisico richiede principalmente la configurazione della posizione del negozio, la copertura dei dati prodotto, la validazione del formato delle ricevute, i test OCR , i test di idoneità e la validazione dell'accettazione della carta. La sicurezza comprende crittografia, tokenizzazione, accesso limitato, audit logging, verifica OTP, validazione in tempo reale del SSN, esecuzione controllata di accordi, schede monouso o uso limitato, scadenza attivata dalla posizione e il fornitore conforme PCI DSS. L'affidabilità viene monitorata per superficie: rotture DOM online (prodotti mancanti, selettori non validi, fallimenti di autocompilazione), OCR variabilità in negozio (scarsa illuminazione, sfocatura, pieghe, abbreviazioni, linee fiscali e di sconto), limiti di geofence (permessi negati, accuratezza interna, deriva GPS, eventi di uscita ritardati, limiti di sfondo del sistema operativo) e risultati della scheda virtuale (fallimenti di emissione, timeout del provider, attivazione, scadenza, autorizzazione). I compromessi sono espliciti: l'indipendenza del rivenditore dipende ancora dal DOM del rivenditore; L'indipendenza dal POS dipende dalla qualità dello scontrino; un modello condiviso abbraccia due tipi di input molto diversi; il controllo della posizione è limitato dalla precisione della posizione; e il fornitore esterno di carte riduce il carico infrastrutturale aggiungendo al contempo la dipendenza dal fornitore.
06 Analisi e Osservabilità
La piattaforma ampliata necessitava di misurazioni separate per il pagamento online, OCR prestazioni, accuratezza del modello, comportamento di localizzazione e risultati di pagamento, perché un singolo guasto poteva originare in uno di essi. OCR accuratezza e accuratezza della classificazione venivano misurate separatamente: un errore di classificazione poteva derivare da testo OCR errato, analisi delle ricevute errate, contesto insufficiente del prodotto o un errore genuino del modello. Sia un funnel di ecommerce (il rivenditore rileva → proroga aperta → carrello estratto → classificato → importo idoneo → verificato → accordo → carta → autocompilazione → acquisto) sia un imbuto in negozio (il negozio rileva → geofence inserito → fattura fotografata → OCR → →linee classificate → non affittabili, separati → idonei approvato → accordo →→ pagamento o scadenza della carta) sono stati strumentati una volta all'altra. Anche il profilo di supporto si è spostato: da integrazioni con rivenditori, sandbox e difetti di gateway, verso fatturazione, accordi, rimborsi, lettura di OCR o fatture, modifiche al DOM, domande sui permessi di localizzazione e autorizzazioni della carta.
Metriche dei rivenditori online
Rilevamento del rivenditore, estrazione del carrello, errori DOM, autocompilazione e successo del pagamento, conversione da approvazione a acquisto.
Metriche di classificazione
Accuratezza per rivenditore, categoria e canale, tariffe false affittabili e non locabili, e distribuzione della fiducia.
OCR metriche
Successo di cattura e elaborazione, estrazione di linea e di prezzo, riconciliazione totale, riconquista e tassi di correzione manuale.
Metriche della georezione
Rilevamento dell'ingresso, negazione del permesso, eventi di uscita, carte scadute dopo l'uscita e tempo dalla generazione al pagamento.
Metriche a carta virtuale
Successo della richiesta, latenza di generazione, errori del provider, attivazione, risultati di autorizzazione e tasso di carta non utilizzata.
07 Livello decisionale AI
Il modello ha risposto a una domanda definita in modo ristretto, coerente su entrambi i canali: questo prodotto è idoneo secondo la politica del cliente sul prodotto locabile? Gli input online combinavano nome del prodotto, immagine, categoria, contesto del rivenditore, descrizione dove disponibile, prezzo e quantità, oltre all'etichetta di formazione noleggiabile/non affittabile. Gli input in negozio erano descrizioni OCR-estratte, testo della voce delle ricevute, quantità, prezzo, contesto del negozio e dati sui prodotti precedenti dei rivenditori, che spesso erano molto meno descrittivi rispetto a una pagina ecommerce, quindi la normalizzazione del prodotto era la più importante nel flusso in negozio. La pipeline raccoglieva informazioni sui prodotti dal DOM o dalla ricevuta, normalizzava il testo specifico del rivenditore, mappava le categorie conosciute, valutava la locabilità, restituiva il risultato, calcolava il totale idoneo e registrava il risultato e la versione del modello per il monitoraggio. La formazione utilizzava dati strutturati a forma di foglio di calcolo (nome, immagine, categoria, rivenditore, etichetta) con migliaia di esempi per ogni rivenditore o gruppo di rivenditori, un modello supervisionato di classificazione dei prodotti. La precisione riportata era circa dell'85-90 percento con l'obiettivo di superare il 90 e migliorare verso il 95; questa era la misura a livello di progetto del cliente, senza alcuna precisione separata, richiamo, valutazione F1 o revisione indipendente.
L'IA ha risposto solo all'idoneità del prodotto. Non ha mai determinato l'affidabilità creditizia, fissato limiti di credito, convalidato l'identità, definito termini di rimborso, eseguito verifiche SSN o approvato conti, questi sono rimasti con i sistemi esistenti del cliente. Le modalità di guasto note (un articolo non noleggiabile valutato come affittabile, un articolo noleggiabile erroneamente rifiutato, una linea di ricevuta abbreviata mappata male, un prodotto bundle o nuovo, una tassonomia del rivenditore modificata o OCRcattivi) indicano il passo successivo raccomandato: decisioni basate sulla fiducia che continuano automaticamente quando sono fiduciose, applicano regole di categoria deterministiche a media fiducia, chiedono al cliente di riconquistare a bassa fiducia, e esclude o instradamenti da esaminare quando non risolto.
08 Stato e Esito
L'estensione Chrome supportava 100+ rivenditori in circa quattro mesi, contro circa sei mesi per 15 nel modello originale, e alla fine permise ai clienti di utilizzare il prodotto di finanziamento in 300+ rivenditori online, un aumento di circa venti volte rispetto al valore base dei 15 rivenditori. Un nuovo rivenditore non aveva più bisogno di risorse tecniche, accesso sandbox, integrazione gateway, QA congiunto, implementazione lato rivenditore o rilasci coordinati; poteva essere abilitato tramite la preparazione dei dati controllati internamente, l'etichettatura, l'addestramento del modello, la configurazione del DOM, il check-test e l'attivazione. Il team originale di 60-70 persone è rimasto sostanzialmente lo stesso, con circa quattro o cinque ingegneri AI/ML aggiunti per la preparazione dei dati, l'addestramento dei modelli e il lavoro di accuratezza, così l'organizzazione ha evitato l'aumento proporzionale del personale che il vecchio modello implicava. Il lavoro di integrazione con i rivenditori, lo sviluppo personalizzato, lo sforzo sandbox, i test congiunti e la manutenzione dei pagamenti specifica per piattaforma sono stati rimossi; Il cliente ha riportato un aumento del volume di transazioni di pagamento man mano che più posti accettavano il limite approvato (riportato qualitativamente, senza una cifra esatta fornita). La piattaforma si è poi estesa al retail fisico tramite l'app mobile, dimostrando che il modello principale non era limitato al web checkout, e i costi legati a integrazioni ripetute, sandbox, sviluppo gateway, QA congiunto, coordinamento delle release e crescita proporzionale del supporto sono migliorati, con il fornitore di carte virtuali come principale dipendenza esterna rimasta.
300+
Rivenditori online supportati
20×
Aumento della copertura dei rivenditori
4 mo
A 100+ rivenditori (contro 6 mesi per 15)
85-90%
Accuratezza del modello riportata
09 Riflessione / Cosa succede
Ciò che ha funzionato è stato risolvere il problema della dipendenza invece che quello del personale: una capacità di idoneità serviva pagine web, carrelli della spesa e bollette estratte OCR, le carte virtuali permettevano al cliente di operare tramite flussi di pagamento già supportati dai rivenditori, e ogni canale aggiungeva i propri controlli (estrazione DOM e compilazione automatica online; OCR, geofencing e scadenza della carta in negozio) su una piattaforma condivisa e coerente. Cosa migliorerei dopo: formalizzare l'abilitazione del rivenditore come prodotto operativo interno (caricamento, etichettatura, formazione, validazione, configurazione DOM e sede del negozio, approvazione del rilascio, monitoraggio della salute); aggiungere la riconciliazione delle ricevute in modo che i totali estratti, gli sconti e la riconciliazione fiscale con la fattura finale; introdurre una politica di revisione a bassa fiducia; rafforzare i controlli geofensi con scadenze brevi, limiti di importo e singola transazione e chiusura immediata dopo l'autorizzazione; costruire il rilevamento automatizzato delle modifiche DOM tramite test sintetici programmati; segnalazione separata di OCR e errori AI sulle dashboard; migliorare la tracciabilità della governance del modello (canale, rivenditore, modello e versione dei dati di addestramento, input, OCR e confidenza nella classificazione, versione dell'accordo, esito della carta); e espandere attentamente su Android e iOS, dato che i loro diversi permessi e comportamenti di posizione in background. Il risultato duraturo è stata una piattaforma omnicanale in cui i dati dei prodotti dei rivenditori hanno sostituito l'integrazione dei pagamenti personalizzati, l'IA ha determinato l'idoneità, i sistemi esistenti hanno gestito identità e credito, le carte virtuali hanno creato l'interoperabilità, e browser e mobile hanno dato al cliente il controllo sulla distribuzione, separando la crescita aziendale dallo sforzo ingegneristico.