01 Kontextur & Problem
Kunden erbjöd en leasingfokuserad BNPL produkt: kunderna ansökte om en godkänd utgiftsgräns, finansierade sedan berättigade köp och betalade tillbaka på avbetalning istället för att betala fullt ut. Produkten täckte endast uthyrningsbara varor som möbler, TV-apparater och konsumentelektronik, inte lågvärdiga förbrukningsvaror som pennor, anteckningsböcker och kontorsmaterial. Kunden växte genom att integrera sitt betalningsalternativ direkt på varje återförsäljares webbplats: försäljningen kontaktar återförsäljaren, återförsäljaren tillhandahåller en sandlåda, teamet integrerar gatewayen, ingenjörs- och kvalitetskontrolltester kassan, sedan koordinerar båda sidor en produktionsrelease.
Den modellen fungerade hos fem till sju återförsäljare och gick sönder när nätverket växte. Återförsäljare körde olika kombinationer av Shopify, Magento, BigCommerce och anpassade plattformar, olika kassar, olika betalningsprocessorer samt olika sandbox- och releaseprocedurer, så varje integration blev sin egen permanenta implementerings- och supportlivscykel. Varje uppgradering eller byte av återförsäljarens plattform kan tvinga kunden att bygga om integrationen, göra om regressionstester och schemalägga en ny gemensam release. Efter ungefär sex månader stödde programmet cirka 15 återförsäljare med 60 till 70 personer, och planen var 200+ återförsäljare året därpå: en linjär utvidgning innebar hundratals, potentiellt nära tusen, personer. Det verkliga problemet var inte utvecklingskapaciteten. Arkitekturen gjorde varje ny återförsäljare till en ny extern beroende, så kunden behövde en modell där återförsäljartillväxt inte längre krävde proportionell tillväxt i teknik och support.
02 Roll och begränsningar
Som AI Product Manager ägde jag helhetslösningen: produktstrategi, problemdefinition, kundresa-design, AI-användningsfallsdefinition, lösningsarkitektur, återförsäljar-enablement-strategi, produktdata- och märkningskrav, ingenjörs- och AI/ML-samordning, API- och backend-krav, virtuell kortintegration, mobil- och webbläsartilläggsupplevelser, säkerhets- och efterlevnadskoordinering, analys- och modellprestandakrav, utrullningsplanering och intressenthantering. Ett av de viktigaste samtalen var att avgränsa var AI skulle och inte skulle användas: modellen svarade endast på om en produkt var berättigad enligt policyn för uthyrningsbara produkter. Den fastställde inte kreditvärdighet, satte inte kreditgränser, validerade identitet, definierade återbetalningsvillkor, utförde SSN-verifiering eller godkände konton, allt detta förblev inom kundens befintliga godkännande-, identitets- och avtalssystem.
Begränsningarna var konkreta. Eliminera beroendet från återförsäljarens sida: ingen återförsäljare ska behöva lägga till en betalningsmetod, tillhandahålla sandbox-åtkomst, ändra sin kassa, exponera anpassade API:er, tilldela utvecklare eller köra gemensam QA. Stödja produktnivåbehörighet, eftersom en återförsäljare kunde sälja både leasingbara och icke-leasable varor, så systemet klassificerade individuella kundvagnsartiklar istället för hela återförsäljare, och hanterade blandade kundvagnar genom att finansiera endast den berättigade delen. Arbeta över olika återförsäljarteknologier och hantera DOM-ändringar, eftersom tillägget fortfarande läser återförsäljarens sidor och siduppdateringar kan förändra HTML-struktur, väljare, produktkort, priser och kassafält. Behåll acceptabel klassificeringsnoggrannhet, generellt 85 till 90 procent med mål över 90 och förbättras mot 95. Skydda kundinformation (namn, adress, mobilnummer, personnummer och OTP) med kryptering, tokenisering, åtkomstkontroller och revisionsloggning. Och senare, stöd fysisk detaljhandel utan att integrera i varje butiks kassasystem.
03 Produktmetod
Istället för att bygga ett mer effektivt team för återförsäljarintegrationen ändrade vi platsen för integrationen. Den ursprungliga modellen placerade kundens finansieringsförmåga i butikens kassa. Den omdesignade modellen placerade finansieringsupplevelsen i kanaler som kunden kontrollerade: en Chrome tillägg för e-handel och kundens mobilapp för fysiska butiker. Det skapade en delad, handlaroberoende plattform som fungerade hos många återförsäljare utan att någon återförsäljare implementerade kundens betalningsmetod.
Online identifierade den Chrome tillägget återförsäljaren, meddelade kunden att finansiering var tillgänglig, läste kundvagnen och totalen, skickade produktdetaljer till backend, klassificerade varje vara som uthyrningsbar eller icke-uthyrningsbar, exkluderade icke-berättigade varor, kontrollerade det berättigade beloppet mot kundens gräns, stödde registrering och verifiering, presenterade avtalet, genererade ett virtuellt kort för engångs- eller begränsad användning, och fyllde i den automatiskt i återförsäljarens standardkassa. Att möjliggöra en ny återförsäljare blev en internt hanterad process snarare än en sex månader lång bilateral integration: samla in återförsäljarens publika katalogdata, märka produkter som möjliga att släppa ut eller inte släppa enligt kundens policy, träna eller uppdatera klassificeraren på tusentals poster, validera noggrannhet mot kända etiketter, konfigurera DOM-extraktion för produktnamn, pris, kvantitet, kategori och kundvagnstotal, Testa end-to-end-flödet, aktivera sedan återförsäljaren, ingen sandbox, checkout-ändring eller gateway-implementering krävs.
I butiken utökade vi samma funktion till mobilappen. Appen upptäckte att kunden befann sig innanför en butiks geofence; Vid faktureringsdisken fotograferade kunden den specificerade räkningen; OCR extraherade produktnamn, kvantiteter och priser; Linjeposterna normaliserades och skickades till samma behörighetsmodell; Appen delade upp berättigade från icke-berättigade varor så att icke-uthyrningsbara produkter kunde betalas separat; Den berättigade totalen kontrollerades mot gränsen; kunden accepterade avtalet; Ett virtuellt kort genererades för det berättigade beloppet och användes genom butikens normala kortaccepteringsprocess. Om kunden lämnade geofence innan kortet användes, gick det ut automatiskt. Geofencing behandlade inte transaktionen, utan fungerade som en trigger för backend att ändra kortets livscykelstatus.
Kunden verkade behöva ett större integrationsteam. Det verkliga problemet var att tillväxten berodde på hundratals externa återförsäljarsystem och lanseringsscheman. Att flytta upplevelsen till en klientstyrd tillägg och mobilapp, med virtuella kort som interoperabilitetslager, förändrade det beroendet: återförsäljarens produktdata ersatte anpassad betalningsintegration och varje punkt bestämdes oberoende.
04 Byggda funktioner
Upptäckt av stödda återförsäljare
Tillägget känner igen aktiverade återförsäljares webbplatser och meddelar kunden att finansiering är tillgänglig.
DOM-baserad vagnutvinning
Återförsäljarspecifik DOM-logik hämtar produkt- och kundvagnsinformation från sidan.
AI-produktbehörighet
Varje kundvagnsartikel klassificeras som uthyrningsbar eller icke-uthyrningsbar enligt den delade modellen.
Hantering av blandade vagnar
Obehöriga poster är uteslutna, så endast den berättigade delen finansieras.
In-extension-registrering
Nya kunder skapar ett konto utan att lämna shoppingresan.
Virtuellt kort + autofyllning av utlåning
Ett engångs- eller begränsat användningskort genereras och fylls i autofyllda i återförsäljarens kassa.
Mobil resa i butiken
Den befintliga klientappen utökades för att finansiera berättigade fysiska butiksköp.
Butiksgeofencing
Appen känner av när en kund befinner sig i en supporterad butiks konfigurerade område.
Bill capture + OCR
Kunden fotograferar den specificerade notan; OCR extraherar radposter från bilden.
Kvittonormalisering
OCR produktion omvandlas till strukturerade produkt-, kvantitets- och prisregister.
Uppdelning mellan berättigad och ej berättigad
Appen visar vad som kan finansieras och vad som måste faktureras eller betalas separat.
Geofence-utlöst utgångspunkt
Att lämna butiksgränsen innan användning utlöser automatiskt kortets utgångsdatum.
Levererades också: validering av godkända gränser, verifiering av mobila OTP:er, realtidsvalidering av personnummer mot kundens befintliga identitetssystem, presentation och godkännande av avtal (både i extension och i appen), upprepbar återförsäljaraktivering via produktutbildning plus DOM-konfiguration, delad produktklassificering återanvänd över båda kanalerna och en enda omnichannel-backend för behörighet, kundvalidering, avtal, virtuella kort och analys.
05 Arkitektur
Två kundkanaler konvergerade på en backend. Onlinekanalen är Chrome extension plus återförsäljarens DOM-extraktion; Kanalen i butiken är mobilappen plus Bill Photography, OCR och GeoFencing. Båda använder samma kärntjänster för produktnormalisering, klassificering av uthyrningsbara produkter, validering av kundidentitet och kreditgränser, avtalsgenerering, utfärdande av virtuella kort, kortlivscykelhantering samt analys- och revisionsloggning. En Python backend exponerar REST API:er; en extern PCI DSS-kompatibel kortleverantör utfärdar engångs- eller begränsade virtuella kort.
Arkitekturen förändrade expansionsenheten. Där varje återförsäljare tidigare krävde ett kommersiellt avtal, tekniska resurser, sandlådeåtkomst, betalningsintegration, gemensam kvalitetskontroll, en koordinerad lansering och löpande plattformsstöd, kräver en ny onlineåterförsäljare nu främst produktdataförberedelse, märkning, modellträning eller validering, DOM-konfiguration, utcheckningstestning och aktivering av tillägg. En ny fysisk återförsäljare kräver främst butikskonfiguration, produktdata, validering av kvittoformat, OCR testning, behörighetstestning och validering av kortacceptans. Säkerheten omfattar kryptering, tokenisering, begränsad åtkomst, revisionsloggning, OTP-verifiering, realtidsvalidering av SSN, kontrollerad avtalsexekvering, engångs- eller begränsade kort, platsutlöst utgångsdatum och PCI DSS-kompatibel leverantör. Tillförlitligheten övervakas per yta: DOM-brott online (saknade produkter, ogiltiga väljare, autofyllningsfel), OCR variation i butik (dålig belysning, oskärpa, vikningar, förkortningar, skatte- och rabattlinjer), geofence-gränser (nekade behörigheter, inomhusnoggrannhet, GPS-drift, fördröjda exit-händelser, OS-bakgrundsgränser) och utfall på virtuella kort (utfärdande fel, leverantörstidsavslutningar, aktivering, utgång, auktorisation). Avvägningarna är tydliga: återförsäljarens oberoende beror fortfarande på återförsäljarens DOM; POS-oberoende beror på kvittots kvalitet; En delad modell omfattar två mycket olika indatatyper; platskontrollen begränsas av platsnoggrannhet; och leverantören av externa kort minskar infrastrukturbelastningen samtidigt som den ökar leverantörsberoendet.
06 Analys och observerbarhet
Den utökade plattformen behövde separat mätning av online-kassan, OCR prestanda, modellnoggrannhet, platsbeteende och betalningsresultat, eftersom ett enda fel kunde uppstå i någon av dem. OCR noggrannhet och klassificeringsnoggrannhet mättes separat: ett klassificeringsfel kunde bero på felaktig OCR text, felaktig kvittotolkning, otillräcklig produktkontext eller ett verkligt modellfel. Både en e-handelstratt (återförsäljaren upptäckte → förlängning öppnad → kundvagn extraherad → klassificerad → berättigad summa → verifierad → överenskommelse → kort → autofyllning → köp) och en butiks-tratten (butik upptäckt → geofence inmatad → faktura, fotograferad → OCR → poster → klassificerade → icke-uthyrningsbara separerade → berättigade godkända → avtal → kort → betalning eller utgång) var instrumenterade från början till slut. Supportprofilen förändrades också: bort från återförsäljarintegrationer, sandlådor och gateway-defekter, mot fakturering, avtal, återbetalning, OCR eller fakturaläsning, DOM-ändringar, platsbehörighet och kortauktorisationsfrågor.
Mätvärden för nätbutiker
Återförsäljardetektion, kundutvinning, DOM-fel, autofyllning och kassaframgång, godkännande-till-köp-konvertering.
Klassificeringsmått
Noggrannhet per återförsäljare, kategori och kanal, falska uthyrningsbara och icke-utlåningsbara satser samt konfidensfördelning.
OCR mätvärden
Framgång med fångst och bearbetning, linje- och prisutvinning, total avstämning, återvinning och manuell korrigering.
Geofence-metrik
Inresedetektion, tillståndsnekt, utgångshändelser, kort som gick ut efter utgång och tid från generering till betalning.
Virtuella kortmetriker
Begäran lyckas, genereringslatens, leverantörsfel, aktivering, auktorisationsresultat och oanvända kortfrekvens.
07 AI-beslutslager
Modellen besvarade en snävt definierad fråga, konsekvent över båda kanalerna: är denna produkt berättigad enligt kundens policy för uthyrningsbara produkter? Onlineinmatningar kombinerade produktnamn, bild, kategori, återförsäljarkontext, beskrivning där det var tillgängligt, pris och kvantitet samt utbildningsetiketten för uthyrningsbar/icke-uthyrningsbar. Inmatningar i butik bestod OCR– extraherade beskrivningar, kvittots radtext, kvantitet, pris, butikskontext och tidigare detaljhandelsproduktdata, som ofta var mycket mindre beskrivande än en e-handelssida, så produktnormalisering var viktigast i butikens flöde. Pipelinen fångade produktinformation från DOM eller kvittot, normaliserade återförsäljarspecifik text, mappade till kända kategorier, utvärderade lättillgänglighet, returnerade resultatet, beräknade det berättigade totalvärdet och registrerade modellresultatet och versionen för övervakning. Utbildningen använde strukturerade, kalkylbladsformade data (namn, bild, kategori, återförsäljare, etikett) med tusentals exempel per återförsäljare eller återförsäljargrupp, en övervakad produktklassificeringsmodell. Den rapporterade noggrannheten var ungefär 85 till 90 procent med målet att överstiga 90 och förbättra mot 95; detta var kundens projektnivåmått, utan separat precision, återkallelse, F1 eller oberoende granskad utvärdering.
AI:n svarade endast på produktbehörighet. Den fastställde aldrig kreditvärdighet, satte aldrig kreditgränser, validerade identitet, definierade återbetalningsvillkor, utförde personnummerverifiering eller godkände konton, dessa stannade kvar i kundens befintliga system. Kända felformer (en icke-leasbar vara bedömd som säljbar, en leasingbar vara felaktigt avvisad, en förkortad kvittorad felmappad, en paketerad eller helt ny produkt, en ändrad detaljhandlartaxonomi eller dålig OCR) pekar på det rekommenderade nästa steget: förtroendebaserat beslut som fortsätter automatiskt när man är säker, applicerar deterministiska kategoriregler med medelkonfidens, ber kunden att återta vid låg konfidens, och exkluderar eller leder till granskning när de inte är lösta.
08 Status och resultat
Chrome-tillägget stödde 100+ återförsäljare inom cirka fyra månader, jämfört med ungefär sex månader för 15 enligt den ursprungliga modellen, och lät så småningom kunder använda finansieringsprodukten hos 300+ onlineåterförsäljare, en ungefär tjugofaldig ökning jämfört med baslinjen på 15 återförsäljare. En ny återförsäljare behövde inte längre tekniska resurser, sandlådeåtkomst, gateway-integration, gemensam kvalitetskontroll, återförsäljarbaserad distribution eller koordinerade releaser; den kunde aktiveras genom internt styrd dataförberedelse, märkning, modellträning, DOM-konfiguration, utlåningstestning och aktivering. Det ursprungliga teamet på 60 till 70 personer förblev i stort sett detsamma, med ungefär fyra till fem AI/ML-ingenjörer tillkomna för dataförberedelse, modellträning och noggrannhetsarbete, så organisationen undvek den proportionella personalökning som den gamla modellen innebar. Detaljhandelsintegrationsarbete, anpassad utveckling, sandlådeinsats, gemensam testning och plattformsspecifik betalningsunderhåll togs bort; Kunden rapporterade ökad volym av utcheckningstransaktioner eftersom fler ställen accepterade den godkända gränsen (kvalitativt rapporterat, ingen exakt siffra angavs). Plattformen utökades sedan till fysisk detaljhandel via mobilappen, vilket visade att kärnmodellen inte var begränsad till webbutcheckning, och kostnader kopplade till upprepade integrationer, sandlådor, gatewayutveckling, gemensam kvalitetskontroll, versionskoordinering och proportionell supporttillväxt förbättrades, med den virtuella kortleverantören som den huvudsakliga kvarvarande externa beroendet.
300+
Stödd onlineåterförsäljare
20×
Ökning av återförsäljartäckning
4 mo
Till 100+ återförsäljare (jämfört med 6 månader för 15)
85-90%
Rapporterad modellnoggrannhet
09 Reflektion / Vad händer härnäst
Det som fungerade var att lösa beroendeproblemet istället för bemanningsproblemet: en behörighetsfunktion betjänade webbsidor, kundvagnar och OCRextraherade räkningar, virtuella kort lät kunden arbeta via betalningsflöden som redan stöddes av återförsäljare, och varje kanal lade till egna kontroller (DOM-utvinning och autofyllning online; OCR, geofencing och kortets utgång i butik) på en konsekvent delad plattform. Vad jag skulle förbättra härnäst: formalisera återförsäljaraktivering som en intern driftsprodukt (uppladdning, märkning, utbildning, validering, DOM och butiksplacering, godkännande av release, hälsoövervakning); lägga till kvittoavstämning så att extraherade totaler, rabatter och skatteavstämning stämmer av med slutfakturan; införa en policy för låg förtroendegranskning; stärka geofence-kontroller med korta utgångstider, gränser för belopp och enskilda transaktioner samt omedelbar avslutning efter auktorisation; bygga automatiserad DOM-ändringsdetektion via schemalagda syntetiska tester; separat OCR - och AI-felrapportering på instrumentpaneler; förbättra spårbarheten i modellstyrning (kanal-, återförsäljar-, modell- och träningsdataversion, indata, OCR - och klassificeringsförtroende, överenskommelseversion, kortresultat); och expandera försiktigt över Android och iOS med tanke på deras olika tillstånd och bakgrundsplaceringsbeteenden. Det bestående resultatet blev en omnikanalplattform där återförsäljarens produktdata ersatte anpassad betalningsintegration, AI fastställde behörighet, befintliga system hanterade identitet och kredit, virtuella kort skapade interoperabilitet och webbläsare samt mobil gav kunden kontroll över distributionen, vilket frikopplade affärstillväxt från ingenjörsarbetet.