Zwei Ansätze zur Lead-Qualifikation im E-Commerce
Der Vergleich betrifft zwei Ansätze zur Automatisierung der Lead-Qualifikation und Dokumenten-Extraktion im E-Commerce: kommerzielle LLM-APIs (OpenAI GPT-4o, Anthropic Claude 3.5 Sonnet) und Open-Weight-Modelle auf eigener Hardware (Llama 3 70B, Mistral Large). Beide werden in einen bestehenden Workflow integriert, der eingehende Angebotsanfragen aus E-Mails und PDFs liest, strukturierte Daten extrahiert und Leads im CRM bewertet. Der Fokus liegt auf der Reduktion der First-Response-Time und der Kosten pro Support-Ticket in einem Schweizer Unternehmen mit 201 bis 500 Mitarbeitenden. Die Integration erfolgt über Google Workspace und das bestehende CRM, ohne dass die Infrastruktur ersetzt wird. Der Betrieb läuft als Managed AI Operation über einen Zeitraum von sechs Monaten.
Kriterien für die Bewertung
Die Bewertung stützt sich auf acht Kriterien, die für den operativen Einsatz in der Schweiz relevant sind:
- Kosten pro Inferenz: Abrechnung pro Token versus fixe Hardware-Kosten.
- Latenz: Antwortzeit für die Extraktion und Klassifikation.
- Datenhoheit: Wo die Daten physisch verarbeitet werden.
- Qualität der Extraktion: Genauigkeit bei strukturierten und unstrukturierten Dokumenten.
- Skalierbarkeit: Verhalten bei Lastspitzen (z. B. Black Friday).
- Wartungsaufwand: Aufwand für Updates, Monitoring und Fehlerbehebung.
- Integrationstiefe: Verfügbarkeit stabiler APIs für Google Workspace und CRM.
- Compliance: Einhaltung lokaler Datenschutzanforderungen, auch wenn keine explizite Regulierung vorliegt.
Vergleichstabelle: APIs versus On-Premise
| Kriterium | Kommerzielle APIs (GPT-4o, Claude 3.5) | Open-Weight On-Premise (Llama 3 70B) |
|---|---|---|
| Kosten pro 1 000 Tokens | 0,01–0,03 USD (Input), 0,03–0,12 USD (Output) | 0,002–0,005 USD (amortisierte GPU-Kosten) |
| Latenz (p95) | 800–1 200 ms | 1 500–2 500 ms (je nach GPU) |
| Datenhoheit | Daten verlassen das Gebäude | Daten bleiben lokal |
| Extraktionsgenauigkeit | 96–98 % bei strukturierten PDFs | 90–94 % bei strukturierten PDFs |
| Skalierbarkeit | Automatisch, keine Limits | Begrenzt durch GPU-Anzahl |
| Wartungsaufwand | Gering (API-Updates) | Mittel (Modell-Updates, GPU-Pflege) |
| Integration | Stabile REST-APIs, Webhooks | Eigenes Inference-Backend, REST-API |
| Compliance | Abhängig von Anbieter-Datenrichtlinie | Vollständige Kontrolle über Datenfluss |
Szenario-spezifische Bewertung
Szenario 1: Hohe Dokumenten-Vielfalt. Wenn die eingehenden Anfragen stark variieren (handschriftliche Notizen, gescannte Formulare, E-Mail-Threads), gewinnen kommerzielle APIs. Die höhere Qualität der Sprachverarbeitung kompensiert die höheren Kosten. Bei 500 Dokumenten pro Monat liegt der Kostenvorteil der APIs bei ca. 15 %, da die Fehlerquote niedriger ist und weniger manuelle Nacharbeit nötig ist.
Szenario 2: Hohe Volumina, standardisierte Formate. Bei 2 000+ Anfragen pro Monat mit einheitlichen PDF-Formaten (z. B. Angebotsanfragen über ein Webformular) gewinnen Open-Weight-Modelle. Die Kosten pro Ticket sinken um 60–70 %, und die Latenz ist für den internen Betrieb akzeptabel. Die Datenhoheit ist ein zusätzlicher Vorteil, auch ohne explizite Compliance-Pflicht.
Szenario 3: Lastspitzen. Vor dem Black Friday verdreifacht sich das Anfragevolumen. Kommerzielle APIs skalieren automatisch, ohne dass zusätzliche Hardware beschafft werden muss. On-Premise-Systeme erfordern eine vorab geplante Kapazitätsreserve, was die Investitionskosten erhöht.
Szenario 4: Integration in Google Workspace. Beide Ansätze integrieren sich über REST-APIs. Kommerzielle APIs bieten oft fertige Connectors, während On-Premise-Systeme ein eigenes Inference-Backend erfordern, das mit Gmail und Drive kommuniziert. Der zusätzliche Aufwand liegt bei 2–3 Wochen Entwicklung.
Empfehlung für das beschriebene Szenario
Für ein Schweizer E-Commerce-Unternehmen mit 201 bis 500 Mitarbeitenden, das die First-Response-Time senken und die Kosten pro Support-Ticket reduzieren will, ist Open-Weight On-Premise die empfohlene Option. Die Gründe: Erstens sinken die laufenden Kosten pro Ticket um 60 % gegenüber rein manueller Verarbeitung und um 40 % gegenüber kommerziellen APIs bei hohen Volumina. Zweitens bleibt die Datenhoheit vollständig beim Unternehmen, was im Schweizer Markt ein Vertrauensvorteil ist. Drittens ist die Latenz von 1,5–2,5 Sekunden für die interne Lead-Qualifikation akzeptabel, da keine Echtzeit-Kommunikation mit dem Kunden stattfindet. Der Managed AI Operations-Service übernimmt die Wartung, sodass das interne Team keine GPU-Infrastruktur pflegen muss. Die 6-Monats-Zeitraum reicht aus, um den Pilot zu starten, die Extraktionsgenauigkeit auf über 90 % zu bringen und den Rollout abzuschließen.
Leave a Reply