01 Kontekst og problem
Kunden tilbød et leasingfokusert BNPL -produkt: kundene søkte om en godkjent utgiftsgrense, finansierte deretter kvalifiserte kjøp og betalte tilbake på avdrag i stedet for å betale fullt ut. Produktet dekket kun utleiebare varer som møbler, TV-er og forbrukerelektronikk, ikke lavverdige forbruksvarer som penner, notatbøker og skrivesaker. Kunden vokste ved å integrere betalingsalternativet direkte i hver forhandlers nettside: salg henvender seg til forhandleren, forhandleren tilbyr en sandkasse, teamet integrerer gatewayen, ingeniørarbeid og QA-tester kassen, deretter koordinerer begge parter en produksjonsutgivelse.
Den modellen fungerte hos fem til syv forhandlere og brøt sammen etter hvert som nettverket vokste. Forhandlere kjørte ulike kombinasjoner av Shopify, Magento, BigCommerce og tilpassede plattformer, ulike utsjekkinger, ulike betalingsprosessorer, og ulike sandkasse- og utgivelsesprosedyrer, slik at hver integrasjon ble sin egen permanente implementerings- og støttelivssyklus. Enhver oppgradering av forhandlerplattformens oppgradering eller endring i kassen kan tvinge kunden til å bygge integrasjonen på nytt, gjøre regresjonstesting på nytt og planlegge en ny felles lansering. Etter omtrent seks måneder støttet programmet rundt 15 forhandlere med 60 til 70 personer, og planen var 200+ forhandlere året etter: en lineær utvidelse innebar hundrevis, potensielt nær tusen, mennesker. Det virkelige problemet var ikke utviklingskapasiteten. Arkitekturen gjorde hver ny forhandler til en ny ekstern avhengighet, så kunden trengte en modell der vekst for forhandlere ikke lenger krevde proporsjonal vekst i ingeniørarbeid og støtte.
02 Rolle og begrensninger
Som AI Product Manager eide jeg helhetlig løsning: produktstrategi, problemdefinisjon, kundereisedesign, AI-brukstilfelledefinisjon, løsningsarkitektur, detaljist-enablement-strategi, produktdata- og merkingskrav, ingeniør- og AI/ML-koordinering, API- og backend-krav, integrasjon av virtuelle kort, mobil- og nettleserutvidelsesopplevelser, sikkerhets- og compliance-koordinering, analyse- og modellytelseskrav, utrullingsplanlegging og interessenthåndtering. En av de viktigste avgjørelsene var hvor KI skulle og ikke skulle brukes: modellen svarte kun på om et produkt var kvalifisert under policyen for utleieprodukter. Den vurderte ikke kredittverdighet, satte ikke kredittgrenser, validerte identitet, definerte tilbakebetalingsvilkår, utførte SSN-verifisering eller godkjente kontoer, noe som alle forble i kundens eksisterende godkjennings-, identitets- og avtalesystemer.
Begrensningene var konkrete. Eliminer avhengighet av implementering på forhandlersiden: ingen forhandler skal måtte legge til en betalingsmetode, gi sandkassetilgang, endre utsjekking, eksponere tilpassede API-er, tildele utviklere eller kjøre felles QA. Støtte produktnivå-berettigelse, siden en forhandler kunne selge både utleibare og ikke-utleibare varer, så systemet klassifiserte individuelle handlekurvvarer i stedet for hele forhandlere, og håndterte blandede handlekurver ved kun å finansiere den kvalifiserte delen. Arbeid på tvers av ulike forhandlerteknologier og administrer DOM-endringer, fordi utvidelsen fortsatt leser forhandlernes sider, og sideoppdateringer kan endre HTML-struktur, velgere, produktkort, priser og kassefelt. Oppretthold akseptabel klassifiseringsnøyaktighet, vanligvis 85 til 90 prosent med mål over 90 og forbedring mot 95. Beskytt kundeinformasjon (navn, adresse, mobilnummer, personnummer og OTP) med kryptering, tokenisering, tilgangskontroller og revisjonslogging. Og senere, støtte fysisk detaljhandel uten å integrere i hver butikks kassesystem.
03 Produkttilnærming
I stedet for å bygge et mer effektivt team for forhandlerintegrasjon, endret vi plasseringen av integrasjonen. Den opprinnelige modellen plasserte kundens finansieringsmulighet i butikkens kasse. Den redesignede modellen plasserte finansieringsopplevelsen i kanaler kunden kontrollerte: en Chrome utvidelse for netthandel og kundens mobilapp for fysiske butikker. Det skapte en delt, forhandleruavhengig plattform som opererte på tvers av mange forhandlere uten at noen forhandler implementerte kundens betalingsmetode.
På nett identifiserte Chrome -utvidelsen forhandleren, informerte kunden om finansiering som mulig, leste handlekurven og totalen, sendte produktdetaljer til backend, klassifiserte hver vare som utleibar eller ikke-utleibar, ekskluderte ikke-kvalifiserte varer, sjekket det kvalifiserte beløpet mot kundens grense, støttet registrering og verifisering, presenterte avtalen, genererte et engangs- eller begrenset-bruk virtuelt kort, og fylte den automatisk ut i forhandlerens vanlige kasse. Å aktivere en ny forhandler ble en internt administrert prosess i stedet for en seks måneders bilateral integrasjon: samle inn forhandlerens offentlige katalogdata, merke produkter som kan leies ut eller ikke utleies i henhold til kundens policy, trene eller oppdatere klassifiseren på tusenvis av poster, validere nøyaktighet mot kjente etiketter, konfigurere DOM-ekstraksjon for produktnavn, pris, mengde, kategori og total handlekurv, Test ende-til-ende-flyten, og aktiver deretter forhandleren, ingen sandkasse, utsjekkingsendring eller gateway-utrulling kreves.
I butikken utvidet vi samme funksjonalitet til mobilappen. Appen oppdaget at kunden befant seg innenfor en butikks geofence; Ved faktureringsdisken fotograferte kunden den spesifiserte regningen; OCR hentet ut produktnavn, mengder og priser; linjepostene ble normalisert og sendt til samme kvalifiseringsmodell; Appen delte kvalifiserte fra ikke-kvalifiserte varer slik at ikke-utleibare produkter kunne betales separat; Den kvalifiserte totalen ble sjekket mot grensen; kunden aksepterte avtalen; Et virtuelt kort ble generert for det kvalifiserte beløpet og brukt gjennom butikkens vanlige kortakseptprosess. Hvis kunden forlot geofence før kortet, utløp det automatisk. Geofencing behandlet ikke transaksjonen, det fungerte som en trigger for at backend skulle endre kortets livssyklusstatus.
Kunden så ut til å trenge et større integrasjonsteam. Det virkelige problemet var at veksten var avhengig av hundrevis av eksterne forhandlersystemer og utgivelsesplaner. Å flytte opplevelsen inn i en kundestyrt utvidelse og mobilapp, med virtuelle kort som interoperabilitetslag, endret denne avhengigheten: detaljhandelens produktdata erstattet tilpasset betalingsintegrasjon, og hvert punkt ble bestemt uavhengig.
04 Bygningsfunksjoner
Deteksjon av støttet forhandler
Utvidelsen gjenkjenner aktiverte forhandlere og forteller kunden at finansiering er tilgjengelig.
DOM-basert vognutvinning
Forhandlerspesifikk DOM-logikk henter produkt- og handlekurvinformasjon fra siden.
Kvalifisering for AI-produkter
Hver vognvare klassifiseres som utleibar eller ikke-utleibar etter den delte modellen.
Håndtering av blandet vogn
Ikke-kvalifiserte gjenstander er unntatt, så kun den kvalifiserte delen finansieres.
In-extension registrering
Nye kunder oppretter en konto uten å forlate handlereisen.
Virtuelt kort + autofyll for utsjekk
Et kort for engangsbruk eller begrenset bruk genereres og fylles automatisk ut i butikkens kasse.
Mobil reise i butikken
Den eksisterende klientappen ble utvidet for å finansiere kvalifiserte fysiske butikkkjøp.
Store geofencing
Appen oppdager når en kunde befinner seg inne i det konfigurerte området til en støttet butikk.
Bill capture + OCR
Kunden fotograferer den spesifiserte regningen; OCR trekker ut linjeposter fra bildet.
Kvitteringsnormalisering
OCR produksjonen konverteres til strukturerte produkt-, mengde- og prisopptegnelser.
Kvalifisert / ikke-kvalifisert splittelse
Appen viser hva som kan finansieres og hva som må faktureres eller betales separat.
Geofence-utløst utløp
Å forlate butikkgrensen før bruk utløser automatisk utløp av kortet.
Også sendt: validering av godkjent grense, mobil OTP-verifikasjon, sanntids SSN-validering mot kundens eksisterende identitetssystemer, presentasjon og aksept av avtaler (både i utvidelse og i appen), repeterbar forhandleraktivering via produkttrening pluss DOM-konfigurasjon, delt produktklassifisering gjenbrukt på tvers av begge kanaler, og en enkelt omnikanal-backend for kvalifisering, kundevalidering, avtaler, virtuelle kort og analyse.
05 Arkitektur
To kundekanaler konvergerte på én backend. Den nettbaserte kanalen er Chrome -utvidelsen pluss forhandlerens DOM-ekstraksjon; Kanalen i butikken er mobilappen pluss Bill Photography, OCR og Geofencing. Begge bruker de samme kjernetjenestene for produktnormalisering, klassifisering av leasingprodukter, validering av kundeidentitet og kredittgrense, avtalegenerering, utstedelse av virtuelle kort, kortlivssyklusstyring, samt analyse og revisjonslogging. En Python backend eksponerer REST API-er; en ekstern PCI DSS-kompatibel kortleverandør utsteder engangs- eller begrensede virtuelle kort.
Arkitekturen endret utvidelsesenheten. Der hver forhandler tidligere krevde en kommersiell avtale, tekniske ressurser, sandkassetilgang, betalingsintegrasjon, felles kvalitetskontroll, en koordinert lansering og løpende plattformstøtte, krever en ny nettforhandler nå primært produktdataforberedelse, merking, modelltrening eller validering, DOM-konfigurasjon, sjekktesting og utvidelsesaktivering. En ny fysisk forhandler krever primært konfigurasjon av butikk, dekning av produktdata, validering av kvitteringsformat, OCR testing, kvalifiseringstesting og godkjenning av kort. Sikkerheten omfatter kryptering, tokenisering, begrenset tilgang, revisjonslogging, OTP-verifisering, sanntids SSN-validering, kontrollert avtaleutførelse, engangs- eller begrenset brukskort, lokasjonsutløst utløp og PCI DSS-kompatibel leverandør. Pålitelighet overvåkes per overflate: DOM-brudd på nett (manglende produkter, ugyldige velgere, autofyllingsfeil), OCR variasjon i butikken (dårlig belysning, uskarphet, brettinger, forkortelser, avgifts- og rabattlinjer), geofence-grenser (nektet tillatelser, innendørs nøyaktighet, GPS-drift, forsinkede utgangshendelser, OS-bakgrunnsgrenser), og resultater for virtuelle kort (utstedelsesfeil, leverandørens tidsavbrudd, aktivering, utløp, autorisasjon). Avveiningene er eksplisitte: forhandlerens uavhengighet avhenger fortsatt av forhandlerens DOM; POS-uavhengighet avhenger av kvaliteten på kvitteringen; En delt modell omfatter to svært forskjellige inngangstyper; Posisjonskontroll er begrenset av lokasjonsnøyaktighet; og leverandøren av eksterne kort reduserer infrastrukturbelastningen samtidig som den legger til leverandøravhengighet.
06 Analyse og observabilitet
Den utvidede plattformen trengte separate målinger for nettbasert betaling, OCR ytelse, modellnøyaktighet, lokasjonsatferd og betalingsutfall, fordi en enkelt feil kunne oppstå i hvilken som helst av disse. OCR nøyaktighet og klassifiseringsnøyaktighet ble målt separat: en klassifiseringsfeil kunne skyldes feil OCR tekst, feil kvittering, utilstrekkelig produktkontekst eller en reell modellfeil. Både en e-handelstrakt (forhandler oppdaget → utvidelse åpnet → handlekurv hentet ut → klassifisert → kvalifisert beløp → verifisert → avtale → kort → autofyll → kjøp) og en trakt i butikk (butikken oppdaget → geofence registrert → regning, fotografert → OCR → linjeposter → klassifisert → ikke-utleibart, separert → kvalifisert godkjent → avtale → kort → betaling eller utløp) ble instrumentert ende-til-ende. Supportprofilen endret seg også: bort fra forhandlerintegrasjoner, sandkasser og gateway-feil, til fakturering, avtaler, tilbakebetaling, OCR eller fakturalesing, DOM-endringer, lokasjonstillatelser og kortautorisasjonsspørsmål.
Nettforhandlermålinger
Forhandlerdeteksjon, handlekurv-ekstraksjon, DOM-feil, autofyll og sjekk-suksess, godkjenning-til-kjøp-konvertering.
Klassifiseringsmetrikker
Nøyaktighet etter forhandler, kategori og kanal, falsk utleiebare og ikke-utleibare satser, samt konfidensfordeling.
OCR målinger
Fangst og prosessering av suksess, linje- og prisutvinning, total avstemming, gjenvinning og manuell korrigering.
Geofence-metrikker
Innreisedeteksjon, tillatelsesavslag, utgangshendelser, kort utløpt etter utgang, og tid fra generering til betaling.
Virtuelle kortmetrikker
Forespørselssuksess, genereringsforsinkelse, leverandørfeil, aktivering, autorisasjonsresultater og rate for ubrukt kort.
07 AI-beslutningslag
Modellen svarte på ett snevert definert spørsmål, som var konsistent på tvers av begge kanaler: er dette produktet kvalifisert under kundens policy for utleieprodukter? Nettbaserte input kombinerte produktnavn, bilde, kategori, forhandlerkontekst, beskrivelse der det var tilgjengelig, pris og mengde, samt opplæringsetiketten for utleie/ikke-utleiebar. Inndata i butikken ble OCRhentet ut beskrivelser, kvitteringslinjetekst, mengde, pris, butikkkontekst og tidligere detaljhandelsproduktdata, som ofte var langt mindre beskrivende enn en nettbutikkside, så produktnormalisering var viktigst i butikkens flyt. Pipelinen fanget produktinformasjon fra DOM eller kvittering, normaliserte forhandlerspesifikk tekst, kartla til kjente kategorier, evaluerte utleibarhet, returnerte resultatet, beregnet det kvalifiserte totalet, og registrerte modellresultatet og versjonen for overvåking. Opplæringen brukte strukturerte, regnearkformede data (navn, bilde, kategori, forhandler, etikett) med tusenvis av eksempler per forhandler eller forhandlergruppe, en overvåket produktklassifiseringsmodell. Rapportert nøyaktighet var omtrent 85 til 90 prosent med mål om å overstige 90 og forbedre seg mot 95; dette var kundens prosjektmåling, uten separat vurdering av presisjon, tilbakekalling, F1 eller uavhengig revidert evaluering.
AI-en svarte kun på produktberettigelse. Den fastsatte aldri kredittverdighet, satte kredittgrenser, validerte identitet, definerte tilbakebetalingsvilkår, utførte personnummerverifisering eller godkjente kontoer, disse ble værende i kundens eksisterende systemer. Kjente feilmoduser (en ikke-utleibar vare scoret som utleiebar, en utleibar vare feilaktig avvist, en forkortet kvitteringslinje feilkartlagt, et pakket eller helt nytt produkt, en endret detaljisttaksonomi eller dårlig OCR) peker mot anbefalt neste steg: tillitsbasert beslutningstaking som fortsetter automatisk når man er sikker, anvender deterministiske kategoriregler med middels konfidens, og ber kunden om å gjenvinne ved lav konfidens, og ekskluderer eller ruter til gjennomgang når det ikke er løst.
08 Status og utfall
Den Chrome utvidelsen støttet 100+ forhandlere innen omtrent fire måneder, mot omtrent seks måneder for 15 under den opprinnelige modellen, og lot etter hvert kundene bruke finansieringsproduktet hos 300+ nettforhandlere, en omtrent tjue ganger økning sammenlignet med basislinjen på 15 forhandlere. En ny forhandler trengte ikke lenger tekniske ressurser, sandkassetilgang, gateway-integrasjon, felles kvalitetskontroll, distribusjon på forhandlersiden eller koordinerte utgivelser; den kunne aktiveres gjennom internt kontrollert dataforberedelse, merking, modelltrening, DOM-konfigurasjon, utsjekkingstesting og aktivering. Det opprinnelige teamet på 60 til 70 personer forble stort sett det samme, med omtrent fire til fem AI/ML-ingeniører lagt til for dataforberedelse, modelltrening og nøyaktighetsarbeid, slik at organisasjonen unngikk den proporsjonale bemanningsøkningen som den gamle modellen innebar. Arbeid med integrasjon av forhandlere, skreddersydd utvikling, sandkassearbeid, felles testing og plattformspesifikk betalingsvedlikehold ble fjernet; Kunden rapporterte økt transaksjonsvolum etter hvert som flere steder aksepterte den godkjente grensen (oppgitt kvalitativt, uten eksakt tall). Plattformen ble deretter utvidet til fysisk detaljhandel via mobilappen, noe som beviste at kjernemodellen ikke var begrenset til nettbasert utsjekking, og kostnadene knyttet til gjentatte integrasjoner, sandkasser, gateway-utvikling, felles kvalitetskontroll, koordinering av utgivelser og proporsjonal støtte økte, med den virtuelle kortleverandøren som den viktigste gjenværende eksterne avhengigheten.
300+
Nettbutikker støttes
20×
Økning i forhandlerdekning
4 mo
Til 100+ forhandlere (mot 6 måneder for 15)
85-90%
Rapportert modellnøyaktighet
09 Refleksjon / Hva skjer videre
Det som fungerte, var å løse avhengighetsproblemet i stedet for bemanningsproblemet: én kvalifikasjonsfunksjon betjente nettsider, handlekurver og OCR-ekstraherte regninger, virtuelle kort lot klienten operere gjennom betalingsstrømmer som allerede støttet forhandlere, og hver kanal la til sine egne kontroller (DOM-uttak og autofyll online; OCR, geofencing og kortutløp i butikk) på en konsekvent delt plattform. Hva jeg ville forbedret neste: formalisere forhandleraktivering som et internt driftsprodukt (opplasting, merking, opplæring, validering, oppsett av DOM og butikkplassering, godkjenning av utgivelser, helseovervåking); Legg til kvitteringsavstemming slik at uttrukne totaler, rabatter og skatteavstemming stemmer med sluttregningen; innføre en lav-tillits-gjennomgangspolitikk; styrke geofence-kontroller med korte utløpsdatoer, grenser for antall og enkelttransaksjoner og umiddelbar stenging etter godkjenning; bygge automatisert DOM-endringsdeteksjon via planlagte syntetiske tester; separate OCR - og AI-feilrapportering på dashbord; forbedre modellstyringssporbarhet (kanal-, forhandler-, modell- og treningsdataversjon, input, OCR - og klassifiseringskonfidens, avtaleversjon, kortresultat); og utvide forsiktig på tvers av Android og iOS, gitt deres ulike tillatelser og bakgrunnslokasjonsatferder. Det varige resultatet var en omnikanalplattform der detaljhandelsproduktdata erstattet tilpasset betalingsintegrasjon, AI fastslo kvalifikasjon, eksisterende systemer administrerte identitet og kreditt, virtuelle kort skapte interoperabilitet, og nettleser og mobil ga kunden kontroll over distribusjonen, noe som skilte forretningsvekst fra ingeniørarbeidet.