Zum Inhalt springen
DESIGN OPERATING SYSTEM
V2.7 · READY

12KUNDEN & VOR-ORT-VERKAUF

Ein Profil.Überall passend weiter.

Konto, gespeicherte Reifengröße, Bestellung, Rechnung, Vor-Ort-Kauf und Versand bilden einen Kundenweg. Das System merkt sich nur, was wirklich hilft – und trennt Service, Vertrag und Werbung sichtbar voneinander.

12.1KUNDENKONTO

Wiederkommen.
Nichts zusammensuchen.

Das Konto ist optional. Gastkauf bleibt möglich. Wer ein Konto nutzt, sieht nur die eigenen verifizierten Daten, Aufträge und Belege – nie eine zweite Admin-Oberfläche.

GUEST

Konto bleibt freiwillig

Bestellen ohne Konto bleibt der schnelle Standard. Nachträgliche Konto-Einladung braucht eine eigene bestätigende Handlung.

OWN

Verifizierter Besitz

Historische Bestellungen erscheinen erst nach bestätigter E-Mail. Gleiche Schreibweise allein beweist keine Identität.

UNIQUE

Kein Wiederbestellen

Ein gebrauchter Reifen ist ein Einzelstück. Statt „noch einmal kaufen“ führt der Auftrag zur gespeicherten Größe und zum aktuellen Bestand.

Seitenstart · Implementierung 10.09.2026 · Owner Storefront: Die Datenschutz-Auswahl ist für Erstbesucher bereits im ersten HTML enthalten. Eine gültige gespeicherte Entscheidung blendet sie vor dem ersten Bildaufbau aus. Freiwillige Dienste bleiben bis zur validierten Einwilligung gesperrt. Prüfkriterium: keine verspätete Einblendung, kein Aufblitzen bei Wiederkehr, gleiche Tastaturbedienung und Auswahlmöglichkeiten.

12.2MEINE GARAGE

Die Größe fährt mit.
Das Auto bleibt verständlich.

Fahrzeugname und Größe sind eine persönliche Suchhilfe, keine ungeprüfte Hersteller-Freigabe. Eine Passgarantie entsteht erst mit belastbaren Fahrzeugdaten beziehungsweise fachlicher Prüfung.

01 / PROFILFamilienauto

205 / 55 R16

STANDARD
02 / SAISON
Optional ergänzen

Die Dimension bleibt erhalten.

03 / BESTAND8 passende Angebote

URL, Zurück-Navigation und Filter bleiben nachvollziehbar.

205-55-R16 · WINTER
DATUMZWECKNICHT BEHAUPTEN
ProfilnameSchnellwahl: z. B. Familienautokeine amtliche Fahrzeugidentität
Hersteller / Modellfreiwillige Orientierungkeine automatische Kompatibilität
205 / 55 R16deterministischer Shopfilterkeine Montagefreigabe
SaisonpräferenzStartfilter und erlaubte Segmentierungkein Newsletter ohne DOI

Schnellfilter · Implementierung 10.09.2026 · Owner Storefront: Die Vorschau lädt ausschließlich eigene Fahrzeugprofile. Gäste erhalten eine leere Vorschau ohne Anmeldefehler. Prüfkriterium: abgelaufene, widerrufene und unverifizierte Sitzungen liefern keine Fahrzeuge; personenbezogene Antworten bleiben ungecacht.

12.4SCANNER · KAUF VOR ORT

Ware wählen.
Kunde entscheidet.

Die Scanner-App bleibt eine schnelle Arbeitsoberfläche. Kundensuche erscheint erst im Verkauf; Mitarbeitende sehen nur die für Rechnung, Übergabe und freiwillige Einladung nötigen Daten.

01WARE

Reifen oder vollständigen Satz scannen

02KUNDE

Vorhanden suchen oder Gastdaten erfassen

03ZAHLART

Bar vor Ort oder Mollie auf Kundentelefon

04BELEG

Fortlaufende Rechnung im zentralen Admin

05ÜBERGABE

Erst nach bestätigter Zahlung ausgeben

BESTANDSKUNDESuchen → auswählen → Daten prüfen.

Adresse und E-Mail werden nicht blind überschrieben. Der Auftrag wird mit dem Konto verknüpft und erscheint danach dort.

NEUKUNDE / GASTRechnungsdaten zuerst. Konto nur auf Wunsch.

Die freiwillige Shop-Einladung ist kein Newsletter. Marketing kann der Kunde später selbst und separat im Shop bestätigen.

ONLINE VOR ORTKurzlebiger Mollie-Checkout statt Kartenterminal-Klon.

Link mailen oder teilen, bezahlen, Webhook abwarten, danach Übergabe. Redirect allein gilt nie als Zahlung.

NEUER KAMERAVERTRAGEine normierte Quelle pro Reifen.
01FRONTAUFNAHMEVollständig und mit Abstand.

Hochkant, Kamera auf Reifenmitte, rundherum Luft; das Original bleibt Beweis.

+DETAILSNur wenn hilfreich.

Profil, DOT, Zustand oder Schaden bleiben eigene optionale Aufnahmen.

SETGRUPPENFOTOBewusst ohne Kontur.

Die Frontschablone gilt ausschließlich dem einzelnen physischen Reifen.

Schadenfoto nur bei dokumentiertem Befund · keine generative Form-, Profil- oder Zustandsänderung

12.5MOLLIE & HERMES

Zwei Provider.
Keine geratene Wahrheit.

Mollie bestätigt Geld, Hermes bestätigt Versand. Der eigene Server hält Reservierung, Auftrag, Rechnung und Paketzuordnung; externe Antworten werden idempotent verarbeitet und sichtbar abgeglichen.

MOLLIE · PAYMENT
  1. Bestand 15 Minuten reservieren
  2. Hosted Checkout erzeugen
  3. Kunde auf eigenem Telefon zahlt
  4. Webhook liest Providerstatus
  5. Bezahlt → Rechnung → Abholung
PAYMENTS API · SOFORTIGER KAUFMOMENT
SHIPPINGLABEL.APP · HERMES
  1. Admin wählt reale Kartonanzahl
  2. Ein A4-Bogen je physischem Paket
  3. Oben Provider-PDF, unten Auftrags-QR
  4. Tracking und alle Paket-Units bleiben gekoppelt
  5. Scanner bestätigt jeden Reifen
MANUELLE PAKETWAHL IMPLEMENTIERT · PRODUCTION-PILOT EXTERN OFFEN
PAY

Redirect ist kein Geldeingang

Nur der anschließend gelesene Mollie-Status darf den Auftrag auf bezahlt setzen. Doppelte Webhooks bleiben wirkungsgleich.

SHIP

Label ist noch kein Versand

Das Label bereitet vor. Erst die physische Übergabe im Scanner bucht Ware aus und setzt den Versandzustand.

FAIL

Providerfehler bleibt sichtbar

Keine Phantomzahlung und kein Phantomversand. Retry, letzter Fehler und nächste Aktion bleiben im Admin nachvollziehbar.

12.6ROLL-OUT-REGISTER

Was entsteht.
Und wann es wirklich fertig ist.

Der Stand ist datiert. Implementierter Code, externe Freischaltung und offener Arbeitsschritt tragen unterschiedliche Status – eine Visualisierung ersetzt keinen Betriebsnachweis.

ARBEITSSTAND3 implementiert · 4 externe Abnahmen · 1 offen

Das Kundenkonto ist unter /konto produktiv. Shippinglabel-Production und -Sandbox besitzen getrennte verschlüsselte Profile; Sandbox bleibt vom echten Auftragsworkflow isoliert. Paketanzahl, Unit-Zuordnung, Packscan und A4-Stapel unterstützen mehrere Reifen in einem Karton; eine automatische kostenpflichtige Neuanlage ist ausgeschlossen. Rechtstext, Mollie und genau ein bezahlter Hermes-Production-Pilot brauchen externe Abnahme; der Kampagnenversand bleibt ein eigener Schritt.

  1. 01
    Konto, Garage und AuftragsarchivIMPLEMENTIERT

    Verifiziertes Kundenkonto, neutraler Passwort-Reset, editierbares Profil, mehrere Fahrzeuge beziehungsweise Reifengrößen, Standardprofil sowie eigene Aufträge und Rechnungsdownloads in einer ruhigen Kontoansicht.

    FERTIG, WENN: Registrierung, Anmeldung, Passwort-Reset, Größenfilter, Auftrag und Rechnung funktionieren mobil und am Desktop.
    OWNER
    System
  2. 02
    Saison-Vorlauf mit Double-Opt-inEXTERN OFFEN

    Fail-closed-Code, versionierter Nachweis, Double-Opt-in und Widerruf sind implementiert. Der konkrete Einwilligungswortlaut bleibt bis zur fachlichen Freigabe gesperrt.

    FERTIG, WENN: Freigegebener Wortlaut, DOI, Abmeldung und Testzustellung sind nachgewiesen.
    OWNER
    System + Fachprüfung
  3. 03
    Scanner-Kundensuche und Shop-EinladungIMPLEMENTIERT

    Vor Ort entweder vorhandenen Kunden wählen oder Gastdaten erfassen. Konto-Einladung und Newsletter sind zwei eigene, nicht vorausgewählte Entscheidungen.

    FERTIG, WENN: Suche, Datenübernahme, Gastkauf und freiwillige Einladung sind mit Rollenprüfung getestet.
    OWNER
    System
  4. 04
    Frontale HauptansichtIMPLEMENTIERT

    Jeder physische Reifen erhält genau eine kanonische, hochauflösende Frontaufnahme: stehend, vollständig, mit Rand und ohne Nahwinkel. Weitere Einzel- und Gruppenbilder bleiben getrennte Slots.

    FERTIG, WENN: Die Scanner-Livekamera erzwingt Hochkantkomposition, geschlossene Frontkontur, mehr Abstand und Kamerahöhe auf Reifenmitte; Originalarchiv und automatische Bildaufbereitung nutzen diese Quelle.
    OWNER
    System + Betrieb
  5. 05
    Vor-Ort online über Mollie bezahlenEXTERN OFFEN

    Scanner, 15-Minuten-Reservierung, Storefront-Checkout und Webhook-Gate sind implementiert. Ein produktiver Mollie-Kauf samt Rechnung und Übergabe muss noch abgenommen werden.

    FERTIG, WENN: Link, Ablauf, Webhook, Rechnung und Abholstatus wurden Ende-zu-Ende geprüft.
    OWNER
    System
  6. 06
    Shippinglabel.app/Hermes abnehmenEXTERN OFFEN

    Production- und Sandbox-Appzugänge sind getrennt verschlüsselt; Sandbox kann keine realen Auftragslabels auslösen. Nach jeder Bestellung wählt der Admin die tatsächliche Kartonanzahl und bestätigt den kostenpflichtigen Providerwrite. Ein Label darf mehrere eindeutig zugeordnete Reifen enthalten. Das lokale A4-Testblatt und der reale PDF-Kombinierer erzeugen je Paket oben 210 × 148,5 mm Hermes-Fläche und unten Auftrags-QR, Units und Lagerlaufweg. Offen bleibt der bezahlte Production-Pilot.

    FERTIG, WENN: 50-mm-Kontrolllinie und Trennung stimmen bei 100 %, echter Hermes-Barcode und Auftrags-QR scannen, ein Zwei-Reifen-/Ein-Karton-Auftrag besitzt genau ein PDF/Tracking und beide Reifen werden vor Versand einzeln bestätigt.
    OWNER
    Betreiber + System
  7. 07
    Saisonkampagne mit 24-h-VorlaufNÄCHSTER SCHRITT

    Bestätigte Kontakte werden nach eigener Größe segmentiert. Der Vorlauf ist eine Kampagnenregel, keine künstliche Countdown-Uhr; ausverkaufte Einzelstücke werden niemals weiter beworben.

    FERTIG, WENN: Zielgruppe, Bestandsprüfung, Versand, Abmeldung und öffentliche Freigabe sind in einem Testlauf nachvollziehbar.
    OWNER
    System + Marketing
  8. 08
    Google-Kundenlogin freischaltenEXTERN OFFEN

    Sign in with Google, browsergebundener Einmal-Nonce, serverseitige ID-Token-Prüfung und sichere Kontoverknüpfung sind implementiert. Es werden weder Gmail-/Drive-Rechte noch Refresh-Tokens angefordert oder gespeichert.

    FERTIG, WENN: Web-Client-ID ist gesetzt, shop.geb-reifen.de als autorisierte JavaScript-Origin hinterlegt und ein echter Neu- sowie Bestandskundenlogin sind grün.
    OWNER
    Betreiber + Google

Providerstand 02.09.2026: Shippinglabel dokumentiert Sandbox und Production als getrennte Anwendungen mit eigenen API-Zugängen und liefert erzeugte Labels als PDF. Der lokale A4-Test ist deshalb vollständig providerfrei; das echte Oberteil wird ausschließlich aus dem bereits bezahlten, gespeicherten Production-PDF übernommen. Die interne Kartonanzahl und Unit-Zuordnung bleiben die eigene Systemwahrheit. Hermes weist zugleich darauf hin, dass der aktuelle HSI-Labelaufbau vom früheren Aufbau abweicht. Mollie Payments ist für den unmittelbaren Checkout gedacht; der vorhandene Webhook bleibt Zahlungsarbiter.