01 Kontext & Problem
Der Kunde bot ein leasingorientiertes BNPL Produkt an: Die Kunden beantragten ein genehmigtes Ausgabenlimit, finanzierten dann berechtigte Käufe und zahlten in Ratenzahlungen zurück, anstatt vollständig zu zahlen. Das Produkt umfasste nur vermietbare Artikel wie Möbel, Fernseher und Unterhaltungselektronik, nicht weniger wertvolle Verbrauchsgüter wie Stifte, Notizbücher und Schreibwaren. Der Kunde wuchs, indem er seine Zahlungsoption direkt in die Website jedes Einzelhändlers integrierte: Der Vertrieb spricht den Händler an, der Händler stellt eine Sandbox zur Verfügung, das Team integriert das Gateway, Engineering und QA-Tests beim Checkout, dann koordinieren beide Seiten eine Produktionsversion.
Dieses Modell funktionierte bei fünf bis sieben Einzelhändlern und brach mit dem Wachstum des Netzwerks zusammen. Einzelhändler betrieben verschiedene Kombinationen aus Shopify, Magento, BigCommerce und kundenspezifischen Plattformen, verschiedene Kassen, unterschiedliche Zahlungsabwicklungen sowie unterschiedliche Sandbox- und Release-Verfahren, sodass jede Integration zu einem eigenen, permanenten Implementierungs- und Supportzyklus wurde. Jedes Upgrade der Händlerplattform oder jede Änderung des Checkouts könnte den Kunden dazu zwingen, die Integration neu aufzubauen, Regressionstests zu erneuern und eine neue gemeinsame Version zu planen. Nach etwa sechs Monaten unterstützte das Programm etwa 15 Einzelhändler mit 60 bis 70 Personen, und der Plan sah im folgenden Jahr 200+ Einzelhändler vor: Eine lineare Erweiterung implizierte Hunderte, potenziell fast tausend Menschen. Das eigentliche Problem war nicht die Entwicklungskapazität. Die Architektur machte jeden neuen Händler zu einer neuen externen Abhängigkeit, sodass der Kunde ein Modell brauchte, bei dem das Wachstum des Einzelhändlers kein verhältnismäßiges Wachstum in Technik und Support mehr erforderte.
02 Rolle & Einschränkungen
Als AI Product Manager besaß ich die End-to-End-Lösung: Produktstrategie, Problemdefinition, Kundenreise-Design, KI-Anwendungsfall-Definition, Lösungsarchitektur, Retailer-Enablement-Strategie, Produktdaten- und Labeling-Anforderungen, Engineering und KI/ML-Koordination, API- und Backend-Anforderungen, virtuelle Kartenintegration, die mobilen und Browser-Erweiterungs-Erlebnisse, Sicherheits- und Compliance-Koordination, Analytik- und Modellleistungsanforderungen, Rollout-Planung und Stakeholder-Management. Eine der wichtigsten Forderungen war die Abgrenzung, wo KI eingesetzt werden sollte und wo nicht: Das Modell beantwortete nur, ob ein Produkt unter die Vermietbarkeitsrichtlinie berechtigt sei. Es hat keine Kreditwürdigkeit festgestellt, keine Kreditlimits festgelegt, keine Identität validiert, keine Rückzahlungsbedingungen festgelegt, keine SSN-Verifizierung durchgeführt oder Konten genehmigt, was alle im bestehenden Genehmigungs-, Identitäts- und Vertragssystem des Kunden blieb.
Die Einschränkungen waren konkret. Beseitigen Sie die Abhängigkeit von der Implementierung auf der Händlerseite: Kein Händler sollte eine Zahlungsmethode hinzufügen, Sandbox-Zugriff bereitstellen, den Checkout ändern, benutzerdefinierte APIs bereitstellen, Entwickler zuweisen oder gemeinsame Qualitätssicherung durchführen müssen. Die Produktanspruchsberechtigung zu unterstützen, da ein Einzelhändler sowohl vermietbare als auch nicht vermietbare Artikel verkaufen konnte, weshalb das System einzelne Warenwarenartikel statt ganze Einzelhändler klassifizierte und gemischte Warenwagen nur durch die Finanzierung des berechtigten Teils behandelte. Arbeiten Sie über verschiedene Händlertechnologien hinweg und verwalten Sie DOM-Änderungen, denn die Erweiterung liest weiterhin Händlerseiten und Versionsupdates können die HTML-Struktur, Selektoren, Produktkarten, Preise und Checkout-Felder verschieben. Halten Sie eine akzeptable Klassifikationsgenauigkeit aufrecht, in der Regel 85 bis 90 Prozent, mit einem Ziel über 90 und Verbesserung bis zu 95. Schützen Sie Kundeninformationen (Name, Adresse, Mobilnummer, SSN und OTP) mit Verschlüsselung, Tokenisierung, Zugriffskontrollen und Audit-Protokollierung. Und später den physischen Einzelhandel zu unterstützen, ohne in das Kassensystem jedes Geschäfts integriert zu werden.
03 Produktansatz
Anstatt ein effizienteres Einzelhändler-Integrationsteam aufzubauen, haben wir den Standort der Integration geändert. Das ursprüngliche Modell platzierte die Finanzierungsfähigkeit des Kunden direkt an der Kasse des Händlers. Das neu gestaltete Modell platzierte das Finanzierungserlebnis in Kanälen, die der Kunde kontrollierte: eine Chrome Erweiterung für E-Commerce und die mobile App des Kunden für physische Geschäfte. Dadurch entstand eine gemeinsame, händlerunabhängige Plattform, die bei vielen Einzelhändlern funktionierte, ohne dass ein Einzelhändler die Zahlungsmethode des Kunden implementierte.
Online identifizierte die Chrome -Erweiterung den Händler, teilte dem Kunden mit, dass die Finanzierung verfügbar sei, las den Warenkorb und die Gesamtsumme, schickte Produktdetails an das Backend, klassifizierte jeden Artikel als vermietbar oder nicht vermietbar, schloss nicht berechtigte Artikel aus, verglich den berechtigten Betrag mit dem Kundenlimit, unterstützte die Registrierung und Verifikation, legte die Vereinbarung vor, erstellte eine Einmal- oder Limit-Nutz-Virtual-Karte, und es automatisch an der Standardkasse des Händlers ausgefüllt. Die Ermöglichung eines neuen Händlers wurde zu einem intern verwalteten Prozess statt einer sechsmonatigen bilateralen Integration: Sammeln der öffentlichen Katalogdaten des Händlers, Produkte gemäß der Richtlinie des Kunden vermarktbar oder nicht vermarktbar, den Klassifikator auf Tausenden von Datensätzen trainieren oder aktualisieren, die Genauigkeit gegen bekannte Etiketten validieren, DOM-Extraktion für Produktname, Preis, Stückzahl, Kategorie und Warenkorb konfigurieren, Teste den End-to-End-Ablauf und aktiviere dann den Händler – kein Sandbox, Checkout-Änderung oder Gateway-Deployment erforderlich.
Im Geschäft haben wir dieselbe Funktion in die mobile App erweitert. Die App erkannte, dass sich der Kunde innerhalb des Geofences eines Geschäfts befand; Am Abrechnungsschalter fotografierte der Kunde die aufgeschlüsselte Rechnung; OCR extrahierte Produktnamen, Mengen und Preise; Die Linienposten wurden normalisiert und an dasselbe Anspruchsmodell weitergegeben; Die App trennt sich zwischen berechtigten und nicht zulässigen Artikeln, sodass nicht vermietbare Produkte separat bezahlt werden können; Die berechtigte Gesamtsumme wurde mit dem Limit geprüft; der Kunde akzeptierte die Vereinbarung; Eine virtuelle Karte wurde für den berechtigten Betrag generiert und über den normalen Kartenakzeptanzprozess des Geschäfts verwendet. Wenn der Kunde den Geofence vor der Nutzung der Karte verlassen hat, lief er automatisch ab. Geofencing verarbeitete die Transaktion nicht, sondern fungierte als Auslöser für das Backend, um den Lebenszyklusstatus der Karte zu ändern.
Der Kunde schien ein größeres Integrationsteam zu benötigen. Das eigentliche Problem war, dass das Wachstum von Hunderten externer Händlersysteme und Veröffentlichungsplänen abhing. Die Verlagerung des Erlebnisses in eine kundengesteuerte Erweiterung und mobile App, mit virtuellen Karten als Interoperabilitätsschicht, änderte diese Abhängigkeit: Die Produktdaten des Einzelhändlers ersetzten die Integration benutzerdefinierter Zahlungen, und jeder Artikel wurde unabhängig entschieden.
04 Gebaute Merkmale
Erkennung von unterstützten Einzelhändlern
Die Erweiterung erkennt aktivierte Händlerstandorte an und teilt dem Kunden mit, dass die Finanzierung verfügbar ist.
DOM-basierte Wagenextraktion
Händlerspezifische DOM-Logik zieht Produkt- und Warenkorbinformationen von der Seite ab.
Berechtigung für KI-Produkte
Jeder Warenkorbteil wird nach dem Shared-Modell als vermietbar oder nicht vermietbar eingestuft.
Umgang mit gemischten Wagen
Nicht berechtigte Gegenstände sind ausgeschlossen, sodass nur der berechtigte Teil finanziert wird.
Registrierung in der Erweiterung
Neue Kunden erstellen ein Konto, ohne die Einkaufsreise zu verlassen.
Virtuelle Karte + automatische Auszahlung
Eine Einweg- oder Limit-Use-Karte wird generiert und automatisch an der Kasse des Händlers ausgefüllt.
Mobile Reise im Geschäft
Die bestehende Kunden-App wurde erweitert, um berechtigte Käufe in physischen Geschäften zu finanzieren.
Store-Geofencing
Die App erkennt, wenn sich ein Kunde im konfigurierten Bereich eines unterstützten Geschäfts befindet.
Bill-Eroberung + OCR
Der Kunde fotografiert die aufgeschlüsselte Rechnung; OCR extrahiert Zeilenelemente aus dem Bild.
Quittungsnormalisierung
OCR Output wird in strukturierte Produkt-, Mengen- und Preisaufzeichnungen umgewandelt.
Teilung der Berechtigung / Nicht-Berechtigung
Die App zeigt, was finanziert werden kann und was separat abgerechnet oder bezahlt werden muss.
Geofence-ausgelöster Ablauf
Das Verlassen der Ladengrenze vor der Nutzung löst automatisch das Ablaufdatum der Karte aus.
Ebenfalls ausgeliefert: Validierung mit genehmigtem Limit, Verifizierung mobiler OTP, Echtzeit-SSN-Validierung gegenüber den bestehenden Identitätssystemen des Kunden, Vereinbarungspräsentation und -akzeptanz (In-Extension und In-App), wiederholbare Einzelhändler-Aktivierung durch Produkttraining plus DOM-Konfiguration, gemeinsame Produktklassifizierung, die über beide Kanäle hinweg wiederverwendet wird, sowie ein einziges Omnichannel-Backend für Berechtigung, Kundenvalidierung, Vereinbarungen, virtuelle Karten und Analysen.
05 Architektur
Zwei Kundenkanäle konvergierten auf einem Backend. Der Online-Kanal ist die Chrome Erweiterung plus Händler-DOM-Extraktion; Der In-Store-Kanal ist die mobile App plus Bill Photography, OCR und Geofencing. Beide nutzen dieselben Kerndienste für Produktnormalisierung, Klassifizierung vermietbarer Produkte, Kundenidentitäts- und Kreditlimitvalidierung, Vertragserstellung, Ausgabe virtueller Karten, Verwaltung des Kartenlebenszyklus sowie Analysen und Audit-Protokollierung. Ein Python Backend stellt REST APIs bereit; ein externer, PCI-DSS-konformer Kartenanbieter stellt die Einweg- oder Limited-Use-Virtual-Karten heraus.
Die Architektur veränderte die Expansionseinheit. Während zuvor jeder Händler eine kommerzielle Vereinbarung, technische Ressourcen, Sandbox-Zugang, Zahlungsintegration, gemeinsame Qualitätssicherung, eine koordinierte Veröffentlichung und fortlaufende Plattformunterstützung benötigte, benötigt ein neuer Online-Händler nun in erster Linie Produktdatenvorbereitung, Beschriftung, Modelltraining oder -validierung, DOM-Konfiguration, Checkout-Tests und Erweiterungsaktivierung. Ein neuer physischer Händler benötigt in erster Linie die Konfiguration des Geschäftsstandorts, die Abdeckung von Produktdaten, die Validierung des Belegformats, OCR Tests, Eignungstests und Kartenakzeptanz. Die Sicherheit umfasst Verschlüsselung, Tokenisierung, eingeschränkten Zugriff, Audit-Protokollierung, OTP-Verifikation, Echtzeit-SSN-Validierung, kontrollierte Vertragsausführung, Einmal- oder begrenzte Nutzungskarten, standortbedingten Ablauf und den PCI-DSS-konformen Anbieter. Die Zuverlässigkeit wird pro Oberfläche überwacht: DOM-Defekt online (fehlende Produkte, ungültige Selektoren, Autofill-Ausfälle), OCR Variabilität im Shop (schlechte Beleuchtung, Unschärfe, Faltungen, Abkürzungen, Steuer- und Rabattlinien), Geofence-Limits (verweigerte Genehmigungen, Genauigkeit im Innenraum, GPS-Drift, verzögerte Austrittsereignisse, Betriebssystem-Hintergrundbeschränkungen) und virtuelle Karten-Ergebnisse (Ausgabefehler, Anbieter-Timeouts, Aktivierung, Ablauf, Autorisierung). Die Kompromisse sind explizit: Die Unabhängigkeit des Einzelhändlers hängt weiterhin vom DOM des Einzelhändlers ab; Die Unabhängigkeit von POS hängt von der Qualität des Belegs ab; Ein gemeinsames Modell umfasst zwei sehr unterschiedliche Eingabetypen; Die Standortkontrolle ist durch die Genauigkeit des Standorts begrenzt; und der externe Kartenanbieter senkt die Infrastrukturbelastung und erhöht gleichzeitig die Abhängigkeit von den Anbietern.
06 Analytics & Observability
Die erweiterte Plattform benötigte separate Messungen für Online-Checkout, OCR Leistung, Modellgenauigkeit, Standortverhalten und Zahlungsergebnisse, da ein einzelner Fehler in jedem dieser Fälle entstehen konnte. OCR Genauigkeit und Klassifikationsgenauigkeit wurden getrennt gemessen: Ein Klassifikationsfehler konnte durch falsche OCR Text, falsches Empfangsanalyse, unzureichenden Produktkontext oder einen echten Modellfehler entstehen. Sowohl ein E-Commerce-Funnel (Händler erkannt → geöffnete Verlängerung, → Warenkorb extrahiert → → berechtigten Betrag klassifiziert → → Vereinbarung → Karte → Autofill → Kauf) als auch ein Trichter im Geschäft (der Laden-Funnel erkannt → Geofence → Rechnung eingegeben → OCR → Linien → klassifiziert → nicht vermietbar, getrennt → berechtigt genehmigt → Vereinbarung → Karte → Zahlung oder Ablauf) wurden End-to-End-instrumentiert. Auch das Supportprofil verschob sich: weg von Händlerintegrationen, Sandboxen und Gateway-Defekten hin zu Abrechnungen, Vereinbarungen, Rückzahlung, OCR oder Rechnungslesen, DOM-Änderungen, Fragen zur Standortberechtigung und Kartenautorisierung.
Online-Händler-Metriken
Händlererkennung, Warenkorb-Extraktion, DOM-Fehler, Autofill und Checkout-Erfolg, Genehmigungs-zu-Kauf-Conversion.
Klassifikationsmetriken
Genauigkeit nach Einzelhändler, Kategorie und Kanal, falsch vermietbare und nicht vermietbare Tarife sowie Konfidenzverteilung.
OCR Kennzahlen
Erfolgs- und Erfassungserfolg, Linien- und Preisextraktion, vollständige Abstimmung, Rückgewinnung und manuelle Korrekturraten.
Geofence-Metriken
Einreiseerkennung, Genehmigungsverweigerung, Austrittsereignisse, Karten, die nach dem Austritt abgelaufen sind, und Zeit von der Entstehung bis zur Zahlung.
Virtuelle Kartenmetriken
Erfolgsantrag, Generierungslatenz, Anbieterfehler, Aktivierung, Autorisierungsergebnisse und Rate der ungenutzten Karten.
07 KI-Entscheidungsschicht
Das Modell beantwortete eine eng definierte Frage, die über beide Kanäle hinweg konsistent ist: Ist dieses Produkt gemäß der Vermietbarkeitsrichtlinie des Kunden berechtigt? Online-Eingaben kombinierten Produktname, Bild, Kategorie, Händlerkontext, Beschreibung, wo verfügbar, Preis und Menge sowie das vermietbare/nicht-vermietbare Schulungsetikett. In-Store-Eingaben wurden OCRextrahierte Beschreibungen, Quittungszeilentexte, Menge, Preis, Ladenkontext und frühere Produktdaten des Einzelhändlers, die oft deutlich weniger beschreibend waren als eine E-Commerce-Seite, sodass die Produktnormalisierung im Ladenablauf am wichtigsten war. Die Pipeline erfasste Produktinformationen aus dem DOM oder Kassenbon, normalisierte einzelhändlerspezifischen Text, mappte sie auf bekannte Kategorien, bewertete die Leasingfähigkeit, gab das Ergebnis zurück, berechnete die zulässige Gesamtsumme und erfasste das Modellergebnis sowie die Version zur Überwachung. Das Training verwendete strukturierte, tabellenartige Daten (Name, Bild, Kategorie, Händler, Etikett) mit Tausenden von Beispielen pro Händler oder Einzelhändlergruppe, ein überwachtes Produktklassifikationsmodell. Die gemeldete Genauigkeit lag bei etwa 85 bis 90 Prozent mit dem Ziel, über 90 zu überschreiten und sich auf 95 Prozent zu verbessern; dies war die Projektmaßnahme des Kunden, ohne separate Präzisions-, Rückruf-, F1- oder unabhängig geprüfte Bewertung.
Die KI beantwortete nur die Produktberechtigung. Es wurde nie die Kreditwürdigkeit festgestellt, keine Kreditlimits festgelegt, die Identität validiert, Rückzahlungsbedingungen festgelegt, keine SSN-Verifizierung durchgeführt oder Konten genehmigt, all diese Systeme blieben im bestehenden System des Kunden. Bekannte Fehlerarten (ein nicht vermietbarer Artikel, der als vermietbar bewertet wurde, ein vermietbarer Artikel, der fälschlicherweise abgelehnt wurde, eine verkürzte Quittungszeile falsch zugeteilt, ein gebündeltes oder brandneues Produkt, eine geänderte Einzelhändlertaxonomie oder schlechte OCR)) deuten auf den empfohlenen nächsten Schritt: eine vertrauensbasierte Entscheidungsfindung, die automatisch fortgesetzt wird, wenn sie sicher ist, deterministische Kategorienregeln mit mittlerem Vertrauen anwendet, und den Kunden auffordert, bei niedriger Sicherheit wieder einzuholen, und schließt oder Routen zur Überprüfung aus, wenn sie nicht gelöst sind.
08 Status & Ergebnis
Die Chrome -Erweiterung unterstützte innerhalb von etwa vier Monaten 100+ Einzelhändler, im Vergleich zu etwa sechs Monaten für 15 unter dem ursprünglichen Modell, und ermöglichte es den Kunden schließlich, das Finanzierungsprodukt bei 300+ Online-Händlern zu nutzen, was einer etwa zwanzigfachen Steigerung gegenüber der Basis von 15 Einzelhändlern entspricht. Ein neuer Händler benötigte keine technischen Ressourcen, Sandbox-Zugang, Gateway-Integration, gemeinsame Qualitätssicherung, Händler-seitige Bereitstellung oder koordinierte Releases mehr; sie konnte durch intern gesteuerte Datenvorbereitung, Beschriftung, Modelltraining, DOM-Konfiguration, Checkout-Tests und Aktivierung aktiviert werden. Das ursprüngliche Team von 60 bis 70 Personen blieb im Wesentlichen unverändert, mit etwa vier bis fünf KI/ML-Ingenieuren für Datenvorbereitung, Modelltraining und Genauigkeitsarbeit, sodass die Organisation die proportionale Personalerhöhung vermied, die das alte Modell vorsah. Retailer-Integrationsarbeit, individuelle Entwicklung, Sandbox-Arbeit, gemeinsames Testen und plattformspezifische Zahlungswartung wurden entfernt; Der Kunde berichtete von einem Anstieg der Checkout-Transaktionen, da mehr Unternehmen das genehmigte Limit akzeptierten (qualitativ angegeben, keine genaue Zahl angegeben). Die Plattform wurde dann über die mobile App auf den physischen Einzelhandel ausgeweitet, was bewies, dass das Kernmodell nicht auf den Web-Checkout beschränkt war, und die Kosten für wiederholte Integrationen, Sandboxen, Gateway-Entwicklung, gemeinsame Qualitätssicherung, Versionskoordination und das Wachstum des proportionalen Supports verbesserten, wobei der virtuelle Kartenanbieter die wichtigste verbliebene externe Abhängigkeit war.
300+
Unterstützte Online-Händler
20×
Erhöhung der Händlerabdeckung
4 mo
Zu 100+ Händlern (im Vergleich zu 6 Monaten für 15)
85-90%
Berichtete Modellgenauigkeit
09 Reflexion / Was als Nächstes kommt
Was funktionierte, war die Lösung des Abhängigkeitsproblems statt des Personalproblems: Eine Berechtigungsfunktion bediente Webseiten, Einkaufswagen und OCRextrahierte Rechnungen, virtuelle Karten ermöglichten es dem Kunden, über bereits unterstützte Zahlungsströme von Einzelhändlern zu arbeiten, und jeder Kanal fügte eigene Kontrollen hinzu (DOM-Extraktion und Autofill online; OCR, Geofencing und Kartenablauf im Geschäft) auf einer konsistenten, geteilten Plattform. Was ich als Nächstes verbessern würde: Händler-Enablement als internes Betriebsprodukt formalisieren (Upload, Labeling, Schulung, Validierung, DOM- und Filialstandort-Einrichtung, Release-Genehmigung, Gesundheitsüberwachung); Fügen Sie die Quittungsabstimmung hinzu, sodass extrahierte Gesamtsummen, Rabatte und Steuerabstimmung mit der Endrechnung abgestimmt werden; Einführung einer Low-Confidence Review Policy; Verschärfung der Geofence-Kontrollen mit kurzen Ablaufzeiten, Betrags- und Einzeltransaktionsgrenzen sowie sofortiger Schließung nach Genehmigung; automatisierte DOM-Änderungserkennung durch geplante synthetische Tests zu entwickeln; getrennte Fehlermeldung von OCR und KI auf Dashboards; Verbesserung der Rückverfolgbarkeit der Modell-Governance (Kanal-, Händler-, Modell- und Trainingsdatenversion, Eingaben, OCR - und Klassifikationsvertrauen, Vereinbarungsversion, Kartenergebnis); und sich vorsichtig auf Android und iOS ausweiten, da deren unterschiedliche Berechtigungen und Hintergrundstandortverhalten unterschiedlich sind. Das dauerhafte Ergebnis war eine Omnichannel-Plattform, bei der Produktdaten der Einzelhändler die Integration benutzerdefinierter Zahlungen ersetzten, KI die Berechtigung bestimmte, bestehende Systeme Identität und Kredit verwalteten, virtuelle Karten Interoperabilität schufen und Browser sowie Mobilgeräte dem Kunden die Kontrolle über die Distribution gaben, wodurch das Geschäftswachstum von der technischen Arbeit entkoppelt wurde.