01 Context & Probleem
De klant bood een leasegericht BNPL product aan: klanten vroegen een goedgekeurde uitgavenlimiet aan, financierden vervolgens in aanmerking komende aankopen en betaalden het terug op termijnen in plaats van volledig te betalen. Het product omvatte alleen verhuurbare artikelen zoals meubels, televisies en consumentenelektronica, niet laagbetaalbare verbruiksartikelen zoals pennen, notitieboekjes en kantoorartikelen. De klant groeide door zijn betaaloptie direct te integreren in de website van elke retailer: sales benadert de retailer, retailer biedt een sandbox, het team integreert de gateway, engineering en QA testen de kassa, waarna beide partijen een productierelease coördineren.
Dat model werkte bij vijf tot zeven retailers en viel uit naarmate het netwerk groeide. Retailers draaiden verschillende combinaties van Shopify, Magento, BigCommerce en aangepaste platforms, verschillende kassa's, verschillende betalingsverwerkers en verschillende sandbox- en releaseprocedures, zodat elke integratie een eigen permanente implementatie- en ondersteuningscyclus werd. Elke upgrade of wijziging van het retailplatform kan de klant dwingen de integratie opnieuw op te bouwen, regressietests opnieuw uit te voeren en een nieuwe gezamenlijke release in te plannen. Na ongeveer zes maanden ondersteunde het programma ongeveer 15 retailers met 60 tot 70 mensen, en het plan was 200+ retailers het jaar daarop: een lineaire uitbreiding impliceerde honderden, mogelijk bijna duizend, mensen. Het echte probleem was niet de ontwikkelingscapaciteit. De architectuur maakte van elke nieuwe retailer een nieuwe externe afhankelijkheid, dus de klant had een model nodig waarbij retailgroei geen proportionele groei in engineering en ondersteuning meer vereiste.
02 Rol & Beperkingen
Als AI Product Manager was ik eigenaar van de end-to-end oplossing: productstrategie, probleemdefinitie, klantreisontwerp, AI use-case definitie, oplossingsarchitectuur, retailer-enablementstrategie, productdata- en labelvereisten, engineering en AI/ML-coördinatie, API- en backend-eisen, virtuele kaartintegratie, de mobiele en browserextensie-ervaringen, coördinatie van beveiliging en compliance, analytics- en modelprestatie-eisen, uitrolplanning en stakeholdermanagement. Een van de belangrijkste oproepen was het bepalen waar AI wel en niet gebruikt moest worden: het model gaf alleen antwoord op of een product in aanmerking kwam onder het verhuurbaarheidsbeleid. Het bepaalde de kredietwaardigheid niet, stelde geen kredietlimieten vast, valideerde de identiteit, bepaalde terugbetalingsvoorwaarden, voerde geen SSN-verificatie uit of keurde rekeningen goed, die allemaal bleven bij de bestaande goedkeurings-, identiteits- en overeenkomstsystemen van de klant.
De beperkingen waren concreet. Elimineer afhankelijkheid van implementatie aan retailerzijde: geen enkele retailer zou een betaalmethode moeten toevoegen, sandbox-toegang moeten bieden, de afrekenfunctie moeten wijzigen, aangepaste API's moeten blootstellen, ontwikkelaars moeten toewijzen of gezamenlijke QA moeten uitvoeren. Ondersteuning van productniveau-geschiktheid, aangezien een retailer zowel verhuurbare als niet-verhuurbare artikelen kon verkopen, dus het systeem classificeerde individuele winkelwagenitems in plaats van hele retailers, en behandelde gemengde winkelwagens door alleen het in aanmerking komende deel te financieren. Werk over verschillende retailtechnologieën heen en beheer DOM-wijzigingen, want de extensie leest nog steeds retailpagina's en pagina-updates kunnen de HTML-structuur, selectoren, productkaarten, prijzen en kassavelden verschuiven. Behoud een acceptabele classificatienauwkeurigheid, meestal 85 tot 90 procent met een doel boven de 90 en verbeter richting 95. Bescherm klantinformatie (naam, adres, mobiel nummer, BSN en OTP) met encryptie, tokenisatie, toegangscontroles en auditregistratie. En later fysieke detailhandel ondersteunen zonder te integreren in het point-of-sale systeem van elke winkel.
03 Productbenadering
In plaats van een efficiënter retail-integratieteam op te bouwen, hebben we de locatie van de integratie veranderd. Het oorspronkelijke model plaatste de financieringscapaciteit van de klant binnen de kassa van de winkel. Het herontworpen model plaatste de financieringservaring binnen kanalen die de klant controleerde: een Chrome uitbreiding voor e-commerce en de mobiele app van de klant voor fysieke winkels. Dat creëerde een gedeeld, handelaaronafhankelijk platform dat bij veel retailers werkte zonder dat een retailer de betaalmethode van de klant implementeerde.
Online identificeerde de Chrome uitbreiding de retailer, vertelde de klant dat financiering beschikbaar was, las het winkelmandje en het totaal, stuurde productgegevens naar de backend, classificeerde elk artikel als verhuurbaar of niet-verhuurbaar, sloot niet-in aanmerking komende artikelen uit, controleerde het in aanmerking komende bedrag tegen de limiet van de klant, ondersteunde registratie en verificatie, presenteerde de overeenkomst, genereerde een eenmalige of beperkte virtuele kaart, en het automatisch ingevuld bij de standaard kassa van de winkel. Het mogelijk maken van een nieuwe retailer werd een intern beheerd proces in plaats van een bilaterale integratie van zes maanden: verzamel de publieke catalogusgegevens van de retailer, labelen producten als verhuurbaar of niet-verhuurbaar volgens het beleid van de klant, trainen of updaten de classifier op duizenden records, valideren de nauwkeurigheid tegen bekende labels, configureren DOM-extractie voor productnaam, prijs, hoeveelheid, categorie en het totale aantal wagens, Test de end-to-end flow, activeer daarna de retailer, zonder sandbox, checkout-wijziging of gateway-implementatie nodig.
In de winkel hebben we dezelfde functionaliteit uitgebreid naar de mobiele app. De app detecteerde dat de klant zich binnen de geofence van een winkel bevond; Bij de facturatiebalie fotografeerde de klant de gespecificeerde rekening; OCR haalde productnamen, hoeveelheden en prijzen op; De posten werden genormaliseerd en doorgegeven aan hetzelfde geschiktheidsmodel; de app splitste in aanmerking komende en niet-in aanmerking komende items, zodat niet-verhuurbare producten apart betaald konden worden; het in aanmerking komende totaal werd gecontroleerd tegen de limiet; de klant accepteerde de overeenkomst; Er werd een virtuele kaart gegenereerd voor het in aanmerking komende bedrag en gebruikt via het normale kaartacceptatieproces van de winkel. Als de klant de geofence verliet voordat hij de kaart gebruikte, verliep deze automatisch. Geofencing verwerkte de transactie niet, het fungeerde als trigger voor de backend om de levenscyclusstatus van de kaart te wijzigen.
De klant leek een groter integratieteam nodig te hebben. Het echte probleem was dat groei afhing van honderden externe retailersystemen en releaseschema's. Door de ervaring te verplaatsen naar een door de klant bestuurde extensie en mobiele app, met virtuele kaarten als interoperabiliteitslaag, veranderde die afhankelijkheid: retailerproductgegevens vervingen de aangepaste betalingsintegratie en elk item werd onafhankelijk bepaald.
04 Gebouwde Kenmerken
Detectie van ondersteunde retailers
De extensie herkent ingeschakelde retailsites en geeft aan dat de klant financiering beschikbaar is.
DOM-gebaseerde kar-extractie
De retailer-specifieke DOM-logica haalt product- en winkelwageninformatie van de pagina.
Geschiktheid voor AI-producten
Elk karretje wordt door het gedeelde model als verhuurbaar of niet-verhuurbaar geclassificeerd.
Gemengde karretje
Niet-in aanmerking komende items zijn uitgesloten, dus alleen het in aanmerking komende deel wordt gefinancierd.
In-extension registratie
Nieuwe klanten maken een account aan zonder de winkelreis te verlaten.
Virtuele kaart + automatische invul van het afrekenen
Een eenmalige of beperkte kaart wordt gegenereerd en automatisch ingevuld bij de kassa van de winkel.
Mobiele reis in de winkel
De bestaande client-app werd uitgebreid om in aanmerking komende fysieke winkelaankopen te financieren.
Store geofencing
De app detecteert wanneer een klant zich in het geconfigureerde gebied van een ondersteunde winkel bevindt.
Bill capture + OCR
De klant fotografeert de gespecificeerde rekening; OCR haalt regelitems uit de afbeelding.
Ontvangstnormalisatie
OCR output wordt omgezet in gestructureerde product-, hoeveelheids- en prijsregistraties.
Verdeeldheid tussen in aanmerking komende en niet-geschikte
De app toont wat gefinancierd kan worden en wat apart gefactureerd of betaald moet worden.
Door geofence getriggerde vervaldatum
Het verlaten van de winkelgrens vóór gebruik activeert automatisch de verloop van de kaart.
Ook geleverd: goedgekeurde limietvalidatie, mobiele OTP-verificatie, realtime SSN-validatie tegen de bestaande identiteitssystemen van de klant, presentatie en acceptatie van overeenkomsten (inextension en in-app), herhaalbare retailer-enablement via producttraining plus DOM-configuratie, gedeelde productclassificatie die over beide kanalen wordt hergebruikt, en een enkele omnichannel backend voor geschiktheid, klantvalidatie, overeenkomsten, virtuele kaarten en analytics.
05 Architectuur
Twee klantkanalen kwamen samen op één backend. Het online kanaal is de Chrome extensie plus retailer DOM-extractie; Het in-store kanaal is de mobiele app plus billfotografie, OCR en geofencing. Beide gebruiken dezelfde kerndiensten voor productnormalisatie, classificatie van verhuurbare producten, validatie van klantidentiteit en kredietlimiet, overeenkomstgeneratie, uitgifte van virtuele kaarten, kaartlevenscyclusbeheer en analyse en auditregistratie. Een Python backend maakt REST API's beschikbaar; een externe PCI DSS-conforme kaartleverancier geeft de eenmalige of beperkte virtuele kaarten uit.
De architectuur veranderde de uitbreidingseenheid. Waar elke retailer voorheen een commerciële overeenkomst, technische middelen van de retailer, toegang tot sandbox, betalingsintegratie, gezamenlijke QA, een gecoördineerde release en doorlopende platformondersteuning vereiste, heeft een nieuwe online retailer nu voornamelijk productgegevensvoorbereiding, etikettering, modeltraining of validatie, DOM-configuratie, checkout-testen en extensieactivatie nodig. Een nieuwe fysieke winkel vereist voornamelijk winkellocatieconfiguratie, productgegevens, validatie van het bonnetjesformaat, OCR testen, geschiktheidstests en kaartacceptatievalidatie. De beveiliging omvat encryptie, tokenisatie, beperkte toegang, auditlogging, OTP-verificatie, realtime SSN-validatie, gecontroleerde overeenkomst uitvoeren, eenmalige of beperkte kaarten, locatie-getriggerde vervaldatum en de PCI DSS-conforme provider. De betrouwbaarheid wordt per oppervlak gemonitord: DOM-breuk online (ontbrekende producten, ongeldige selectoren, autofill-fouten), OCR variabiliteit in de winkel (slechte verlichting, waasheid, vouwen, afkortingen, belasting- en kortingslijnen), geofence-limieten (geweigerde toestemmingen, binnennauwkeurigheid, GPS-drift, vertraagde exit-gebeurtenissen, OS-achtergrondlimieten) en uitkomsten van virtuele kaarten (uitgiftefouten, time-outs van aanbieders, activatie, vervaldatum, autorisatie). De afwegingen zijn expliciet: de onafhankelijkheid van de detailhandelaar hangt nog steeds af van de DOM van de winkelier; De onafhankelijkheid van POS hangt af van de kwaliteit van de ontvangstbon; Eén gedeeld model omvat twee zeer verschillende invoertypen; locatiecontrole wordt begrensd door locatienauwkeurigheid; en de externe kaartleverancier verlaagt de infrastructuurlast terwijl hij afhankelijk wordt van leveranciers.
06 Analytics & Observability
Het uitgebreide platform had aparte metingen nodig voor online afrekenen, OCR prestaties, modelnauwkeurigheid, locatiegedrag en betalingsresultaten, omdat een enkele fout in elk van deze situaties kon ontstaan. OCR nauwkeurigheid en classificatienauwkeurigheid werden afzonderlijk gemeten: een classificatiefout kon ontstaan door onjuiste OCR tekst, onjuiste ontvangstbewijsparsing, onvoldoende productcontext of een echte modelfout. Zowel een e-commerce funnel (retailer detecteerde → verlenging geopend → winkelwagen, → geclassificeerd → in aanmerking komende bedrag → geverifieerd → overeenkomst → kaart → automatische invul → aankoop) als een trechter in de winkel (winkel die → geofence → factuur werd ingevoerd, gefotografeerd → OCR → lijnposten → geclassificeerd → niet-verhuurbaar gescheiden → in aanmerking komende goedgekeurde → overeenkomst → kaart → betaling of vervaldatum) werden end-to-end geïnstrumenteerd. Het ondersteuningsprofiel verschoof ook: weg van retailer-integraties, sandboxes en gateway-defecten, naar facturering, overeenkomsten, terugbetaling, OCR of factuurlezing, DOM-wijzigingen, locatie-toestemming en kaartautorisatie-vragen.
Online retailer-metrics
Winkelierdetectie, winkelwagenextractie, DOM-fouten, autofill en kassa-succes, goedkeuring-naar-aankoopconversie.
Classificatiemetrieken
Nauwkeurigheid per retailer, categorie en kanaal, valse verhuurbare en niet-verhuurbare tarieven, en betrouwbaarheidsverdeling.
OCR metrieken
Succes van het vastleggen en verwerken, lijn- en prijsextractie, totale afstemming, herwinning en handmatige correctie.
Geofence-metrieken
Toegangsdetectie, toestemmingsweigering, uitstapgebeurtenissen, kaarten die na het vertrek verlopen, en tijd van generatie tot betaling.
Virtuele-kaartmetrieken
Aanvraagsucces, generatielatentie, fouten van de aanbieder, activatie, autorisatieresultaten en ongebruikte kaartpercentage.
07 AI-beslissingslaag
Het model beantwoordde één nauw gedefinieerde vraag, consistent over beide kanalen: is dit product geschikt onder het lease-productbeleid van de klant? Online invoer combineerde productnaam, afbeelding, categorie, retailercontext, beschrijving waar beschikbaar, prijs en hoeveelheid, plus het verhuurbare/niet-verhuurbare trainingslabel. In-store inputs werden OCR- extraherde beschrijvingen, ontvangstregeltekst, hoeveelheid, prijs, winkelcontext en eerdere retailerproductgegevens, die vaak veel minder beschrijvend waren dan een e-commercepagina, dus productnormalisatie was het belangrijkst in de in-winkel flow. De pijplijn legde productinformatie vast van de DOM of ontvangstbon, normaliseerde retailer-specifieke tekst, koppelde aan bekende categorieën, evalueerde de draagbaarheid, retourneerde het resultaat, berekende het in aanmerking komende totaal en registreerde het modelresultaat en versie voor monitoring. De training gebruikte gestructureerde, spreadsheetvormige gegevens (naam, afbeelding, categorie, retailer, label) met duizenden voorbeelden per retailer of retailergroep, een begeleid productclassificatiemodel. De gerapporteerde nauwkeurigheid lag ongeveer tussen de 85 en 90 procent, met als doel meer dan 90 en te verbeteren richting 95; dit was de projectmaatstaf van de klant, zonder aparte precisie-, terugroep-, F1- of onafhankelijk gecontroleerde evaluatie.
De AI beantwoordde alleen de productgeschiktheid. Het heeft nooit de kredietwaardigheid vastgesteld, kredietlimieten vastgesteld, identiteit gevalideerd, terugbetalingsvoorwaarden vastgesteld, BSN-verificatie uitgevoerd of rekeningen goedgekeurd, deze zijn niet binnen de bestaande systemen van de klant gebleven. Bekende faalmodi (een niet-verhuurbaar artikel beoordeeld als verhuurbaar, een verhuurbaar artikel dat ten onrechte is afgewezen, een verkorte ontvangstregel verkeerd toegewezen, een gebundeld of gloednieuw product, een gewijzigde retailtaxonomie of slechte OCR) wijzen op de aanbevolen volgende stap: vertrouwensgebaseerde beslissingen die automatisch doorgaan wanneer ze zeker zijn, deterministische categorieregels toepast bij gemiddelde betrouwbaarheid, en de klant vraagt om bij laag vertrouwen te herwinnen, en sluit of routes naar herziening uit wanneer deze niet is opgelost.
08 Status & Uitkomst
De Chrome -uitbreiding ondersteunde binnen ongeveer vier maanden 100+ retailers, tegenover ongeveer zes maanden voor 15 onder het oorspronkelijke model, en stelde uiteindelijk klanten in staat het financieringsproduct te gebruiken bij 300+ online retailers, een ongeveer twintigvoudige stijging ten opzichte van de basislijn van 15 retailers. Een nieuwe retailer had geen technische middelen, sandbox-toegang, gateway-integratie, gezamenlijke QA, retailer-side deployment of gecoördineerde releases meer nodig; dit kon worden mogelijk gemaakt door intern gestuurde gegevensvoorbereiding, labeling, modeltraining, DOM-configuratie, uitchecktesten en activatie. Het oorspronkelijke team van 60 tot 70 personen bleef grotendeels hetzelfde, met ongeveer vier tot vijf AI/ML-ingenieurs toegevoegd voor datavoorbereiding, modeltraining en nauwkeurigheidswerk, waardoor de organisatie de proportionele personeelsuitbreiding die het oude model impliceerde, vermeden. Retailerintegratiewerk, maatwerkontwikkeling, sandbox-inspanning, gezamenlijke tests en platform-specifieke betalingsonderhoud werden verwijderd; De klant meldde een toename van het aantal transacties bij de checkouts doordat meer plaatsen de goedgekeurde limiet accepteerden (kwalitatief gerapporteerd, geen exact cijfer vermeld). Het platform breidde zich vervolgens uit naar fysieke retail via de mobiele app, waarmee werd aangetoond dat het kernmodel niet beperkt was tot webafrekenen, en de kosten die gekoppeld waren aan herhaalde integraties, sandboxes, gateway-ontwikkeling, gezamenlijke QA, releasecoördinatie en proportionele groei van ondersteuning verbeterden, waarbij de virtuele kaartprovider de belangrijkste overgebleven externe afhankelijkheid was.
300+
Online retailers worden ondersteund
20×
Uitbreiding van de dekking van de retailer
4 mo
Naar 100+ retailers (tegenover 6 maanden voor 15)
85-90%
Gerapporteerde modelnauwkeurigheid
09 Reflectie / Wat is de volgende stap
Wat werkte was het oplossen van het afhankelijkheidsprobleem in plaats van het personeelsprobleem: één geschiktheidsfunctie bediende webpagina's, winkelwagentjes en OCR-extraherde rekeningen, virtuele kaarten lieten de klant werken via betalingsstromen die retailers al ondersteunden, en elk kanaal voegde zijn eigen controles toe (DOM-extractie en automatische invul online; OCR, geofencing en kaartvervaldatum in de winkel) op een consistent gedeeld platform. Wat ik nu zou verbeteren: retailer enablement formaliseren als een intern operationeel product (upload, labeling, training, validatie, DOM en winkellocatie-instelling, release-goedkeuring, gezondheidsmonitoring); Ontvangstafstemming toevoegen zodat de extraherde totalen, kortingen en belastingafstemming met de eindrekening worden toegevoegd; een beleid van lage betrouwbaarheid invoeren; het versterken van geofence-controles met korte vervaldatums, limieten voor bedrag en enkele transacties en onmiddellijke sluiting na autorisatie; het bouwen van geautomatiseerde DOM-veranderingsdetectie via geplande synthetische tests; aparte OCR - en AI-foutrapportage op dashboards; het traceerbaarheid van modelgovernance verbeteren (kanaal-, retailer-, model- en trainingsdataversie, invoer, OCR - en classificatievertrouwen, overeenkomstversie, kaartuitkomst); en voorzichtig uitbreiden over Android en iOS gezien hun verschillende toestemmingen en achtergrondlocatiegedrag. Het blijvende resultaat was een omnichannelplatform waarbij retailerproductgegevens de integratie van aangepaste betalingen vervingen, AI de geschiktheid bepaalde, bestaande systemen identiteit en krediet beheerden, virtuele kaarten interoperabiliteit creëerden en browser en mobiel de klant controle gaven over distributie, waardoor bedrijfsgroei werd losgekoppeld van technische inspanningen.