318 lines
11 KiB
Markdown
318 lines
11 KiB
Markdown
Konzept-Update: "Local for Local" Marktplatz
|
||
1. Strategische Neuausrichtung: Die Domains
|
||
Die Trennung wird schärfer.
|
||
|
||
B2In (Backend/B2B): Bleibt das "Maschinenraum"-Portal für Händler, Hersteller und Makler. Hier wird verwaltet.
|
||
|
||
Local for Local (Customer Frontend): Das wird das Gesicht zum Kunden. Der Kunde fühlt sich nicht auf einer abstrakten "B2In"-Seite, sondern in seinem regionalen Hub (z.B. "Local for Local OWL").
|
||
|
||
To-Do: Wir benötigen ggf. die Domain localforlocal.de (o.ä.) und routen diese auf die Endkunden-Ansicht.
|
||
|
||
Onboarding: Findet hier statt ("Werde Teil des lokalen Kreislaufs").
|
||
|
||
2. Das neue Produkt-Konzept (2 Kategorien)
|
||
Wir unterscheiden im Backend bei der Produktanlage künftig zwei Typen:
|
||
|
||
Typ A: Das "Teaser-Produkt" (Ticket-System)
|
||
|
||
Ziel: Frequenzbringer für den stationären Handel (Online-to-Offline).
|
||
|
||
Funktion: Der Kunde kauft nicht direkt online. Er sieht ein Möbelstück (z.B. "Sofa Bielefeld"), verliebt sich, sieht aber: "Beratung und Stoffauswahl nötig".
|
||
|
||
Der "Ticket-Workflow" (Neu):
|
||
|
||
Button: "Ticket & Rabatt sichern".
|
||
|
||
System generiert einen QR-Code/Voucher für einen spezifischen Händler im Hub des Kunden.
|
||
|
||
Call-to-Action: "Gehen Sie zu Möbelhaus Müller, zeigen Sie diesen Code und erhalten Sie 5% Rabatt + Fachberatung".
|
||
|
||
Vorteil: Nimmt den Preisdruck, fördert Beratung, messbarer Erfolg für den Händler (er scannt das Ticket).
|
||
|
||
Typ B: Die "Konfigurations-Anlage"
|
||
|
||
Ziel: Darstellung komplexer Wohnwände/Systeme.
|
||
|
||
Funktion: Zeigt die Machbarkeit und Tiefe des Sortiments ("Alles ist möglich"). Dient als "Showcase" für die Kompetenz der Hersteller.
|
||
|
||
3. Vertrauen durch erweiterte Profile ("Faces")
|
||
Der Marktplatz wird menschlicher. Wir erweitern die Partner-Datenbank (partners Tabelle) massiv um Marketing-Elemente.
|
||
|
||
Händler/Hersteller/Makler-Profilseite:
|
||
|
||
Team-Vorstellung: "Ihr Beraterteam vor Ort" (Fotos von echten Menschen).
|
||
|
||
Galerie: Bilder vom Showroom/Ladenlokal.
|
||
|
||
Story: "Seit 1950 in Herford..."
|
||
|
||
Zweck: Wenn der Kunde das "Ticket" zieht, weiß er schon, zu wem er geht. Das senkt die Hemmschwelle enorm.
|
||
|
||
4. Die User Journey (Kauf-Philosophie)
|
||
Das Dashboard des Kunden ("Mein Zuhause") wird zum emotionalen Feed.
|
||
|
||
Login/Start: Kunde sieht Möbel aus seinem Hub ("Local for Local").
|
||
|
||
Detailseite:
|
||
|
||
Großes Bild.
|
||
|
||
Philosophie-Text (Storytelling zum Möbel).
|
||
|
||
Preisanzeige: "Ab 2.500 € – Ihr Endpreis hängt von Ihrer Konfiguration ab." (Nimmt die Angst vor Fixpreisen).
|
||
|
||
Action: "Ticket ziehen" -> Terminvereinbarung mit Herrn [Name des Verkäufers] im lokalen Möbelhaus vorschlagen.
|
||
|
||
Auswirkungen auf die Entwicklung (Roadmap Anpassung)
|
||
Das passt sehr gut in unseren aktuellen Plan für Januar/Februar (Produkte & Marktplatz). Wir müssen nur den Fokus leicht verschieben:
|
||
|
||
Produkt-Datenbank (Phase 1 Abschluss):
|
||
|
||
Wir fügen ein Feld product_type hinzu (teaser vs. config).
|
||
|
||
Wir fügen Logik für "Preise ab" oder "Preis auf Anfrage" hinzu.
|
||
|
||
Partner-Profile (Erweiterung):
|
||
|
||
Im Backend (das du gerade baust) brauchen wir Upload-Felder für Team-Fotos und "Über uns"-Texte. Das ist schnell gemacht.
|
||
|
||
Das Ticket-System (Teil von Phase 2 Marktplatz):
|
||
|
||
Anstatt eines klassischen "Warenkorbs" bauen wir für Typ A Produkte einen "Ticket-Generator".
|
||
|
||
Das ist technisch einfacher als ein Checkout mit Payment-Provider! Wir generieren ein PDF/QR-Code und senden eine Mail.
|
||
|
||
|
||
Konzeptpapier: B2In / Local for Local Marktplatz-Ökosystem
|
||
Status: Final | Version: 1.1 (Update: Marken-Hierarchie)
|
||
|
||
1. Executive Summary
|
||
Das B2In-Ökosystem ist ein hybrider Marktplatz, der den Immobilienkauf ("Moment of Need") mit der Einrichtung verbindet. Es agiert als "Closed Shop" (Zugang nur über Makler). B2In ist die zentrale B2B-Plattform und Technologie. Local for Local ist das verbindende Prinzip innerhalb des Marktplatzes, das die Endkunden-Marken (style2own, stileigentum) mit den regionalen Händlern verknüpft.
|
||
|
||
Der USP liegt in der Transparenz lokaler Verfügbarkeit (Säule A: Local Express) und exklusiven Insider-Konditionen (Säule B: Smart Club), abgesichert durch ein Cashback-System.
|
||
|
||
2. Marken-Architektur & Entry-Points
|
||
Wir unterscheiden strikt zwischen dem B2B-Zugang (Partner) und den B2C-Einstiegen (Endkunden).
|
||
|
||
A. Der B2B-Kanal (Die Dachmarke)
|
||
Marke: B2In
|
||
|
||
Zielgruppe: Immobilienmakler, Händler, Hersteller.
|
||
|
||
Funktion: Akquise, Partner-Login, Verwaltung ("Maschinenraum").
|
||
|
||
Positionierung: "Das Netzwerk für Immobilien & Einrichtung." Hier findet das Business statt.
|
||
|
||
B. Die B2C-Kanäle (Die Zielgruppen-Türen)
|
||
Der Makler entscheidet anhand der Käuferstruktur, über welche "Tür" der Kunde das System betritt. Beide Landingpages führen in denselben Marktplatz:
|
||
|
||
1. Marke: Style2Own
|
||
|
||
Zielgruppe: Young Professionals, Erstbezug, Urban, Trend-orientiert.
|
||
|
||
Tonalität: Modern, "Du"-Ansprache, Lifestyle-Fokus.
|
||
|
||
Story: "Dein Style. Deine Stadt."
|
||
|
||
2. Marke: StilEigentum
|
||
|
||
Zielgruppe: Gehobenes Segment, Best Ager, Villen, Qualitäts-orientiert.
|
||
|
||
Tonalität: Exklusiv, "Sie"-Ansprache, Werte-Fokus.
|
||
|
||
Story: "Exzellenz und Tradition."
|
||
|
||
C. Das verbindende Element (Inside the Portal)
|
||
Prinzip: Local for Local
|
||
|
||
Funktion: Sobald der Kunde (egal ob über style2own oder stileigentum) eingeloggt ist, greift die "Local for Local"-Logik.
|
||
|
||
Erlebnis: Das Portal passt sich dem Hub des Kunden an und zeigt die lokalen Händler als "Local Heroes". Es ist die Klammer, die den Marktplatz definiert.
|
||
|
||
3. Marktplatz & Produktstrategie (Das 2-Säulen-Modell)
|
||
Im Portal angekommen, wird das Angebot nach Bedürfnis (Zeit vs. Planung) getrennt.
|
||
|
||
Säule A: "Local Express" (Phase 1 Focus)
|
||
Narrativ: "David gegen Goliath" (Support your Locals).
|
||
|
||
Angebot: Sofort verfügbare Ausstellungsstücke, Lagerware und kuratierte "Hidden Gems" der lokalen Fachhändler.
|
||
|
||
Kunden-Vorteil:
|
||
|
||
Verfügbarkeit: "Was ist heute in meiner Nähe abholbereit?" (Schlägt Google Maps).
|
||
|
||
Preis/Leistung: Markenware oft günstiger als im Großmarkt.
|
||
|
||
Händler-Vorteil: Abverkauf von Ausstellungsware (Liquidität), Frequenz im Laden.
|
||
|
||
Säule B: "Smart Club" (Phase 2 Focus)
|
||
Narrativ: "Insider Access".
|
||
|
||
Angebot: Frei konfigurierbare Neuware (Bestellung).
|
||
|
||
Kunden-Vorteil: Zugriff auf "Closed Shop"-Konditionen (Objekt-Preise), die öffentlich nicht verfügbar sind.
|
||
|
||
Strategie: Hersteller können hier Rabatte geben, ohne ihre öffentlichen Marktpreise zu zerstören.
|
||
|
||
4. Monetarisierung & Tracking (Das Cashback-Clearing)
|
||
Das System löst das Problem der fehlenden Transparenz bei Offline-Käufen durch Inzentivierung des Kunden.
|
||
|
||
Der Prozess:
|
||
|
||
Ticket: Kunde zieht im Portal einen QR-Code für Händler X.
|
||
|
||
Kauf: Kunde kauft vor Ort, verhandelt Preise individuell.
|
||
|
||
Upload (Der Trigger): Kunde lädt Kaufbeleg im B2In-Portal hoch, um sein Cashback anzufordern.
|
||
|
||
Clearing: Händler bestätigt Umsatz im Backend -> Händler zahlt Gesamt-Provision an B2In.
|
||
|
||
Ausschüttung: Sobald Geld eingeht, verteilt das System automatisch:
|
||
|
||
Provision an Makler (Lead-Vergütung).
|
||
|
||
Cashback an Kunden (Motivation & Datentreue).
|
||
|
||
Marge an B2In.
|
||
|
||
|
||
|
||
1. Core-Modul: Hub & User Logic
|
||
Das Fundament. Hier wird entschieden, wer was sehen darf.
|
||
|
||
Hub-Logik (Hub Model):
|
||
|
||
Jeder User (Kunde, Makler, Händler) wird einer hub_id zugeordnet (z.B. Hub OWL, Hub Hamburg).
|
||
|
||
Logik: Ein Kunde aus OWL sieht nur Händler und Produkte mit hub_id = OWL. Das ist der Kern von "Local for Local".
|
||
|
||
User-Origin (origin Feld):
|
||
|
||
In der users Tabelle speichern wir, woher der Kunde kam: style2own oder stileigentum.
|
||
|
||
Zweck: Steuert das Theme im Dashboard (Modern vs. Klassisch), die Datenbank bleibt aber dieselbe.
|
||
|
||
Rollen-System (Erweiterung):
|
||
|
||
role: broker (Sieht Provisionen, generiert Invites).
|
||
|
||
role: merchant (Sieht Produkt-Upload, Clearing).
|
||
|
||
role: customer (Sieht Shop, Wallet, Upload).
|
||
|
||
role: admin (Sieht alles + Approval Queue).
|
||
|
||
2. Produkt-Modul: "The 2 Pillars"
|
||
Die Verwaltung der Waren. Hier unterscheiden wir die Strategie.
|
||
|
||
Produkte Tabelle (products):
|
||
|
||
Erweiterung um product_type:
|
||
|
||
'local_stock' (= Säule A, Ausstellungsstück, Händler-gebunden).
|
||
|
||
'smart_order' (= Säule B, Neuware, Hersteller-gebunden).
|
||
|
||
is_curated (Boolean): Für die Qualitätssicherung. Erst wenn Admin "OK" gibt, ist das Produkt öffentlich sichtbar.
|
||
|
||
Händler-Upload (Simple UI):
|
||
|
||
Extrem vereinfachtes Formular für Händler (Handy-optimiert): Foto, Titel, Preis, Statt-Preis, Status (Verfügbar/Verkauft).
|
||
|
||
Kein komplexes Warenwirtschafts-Monster!
|
||
|
||
3. Transaction-Engine: Ticket & Cashback (Das Herzstück)
|
||
Hier fließt das Geld. Das ist der komplexeste Teil der Business-Logik.
|
||
|
||
A. Das Ticket-System (Ticket Model)
|
||
Funktion: Kunde klickt "Ticket ziehen".
|
||
|
||
Daten: user_id, merchant_id, code (Unique String/Hash), created_at.
|
||
|
||
QR-Generierung: On-the-fly Generierung des Codes für das Frontend.
|
||
|
||
B. Das Clearing-System (Transaction / Receipt Model)
|
||
Upload: Kunde lädt Foto hoch + gibt Betrag ein.
|
||
|
||
Status-Maschine (State Machine):
|
||
|
||
pending_merchant: Händler muss bestätigen ("Ja, Kunde war da und hat für 3.000€ gekauft").
|
||
|
||
confirmed: Händler hat bestätigt -> Rechnung an Händler wird generiert.
|
||
|
||
paid: Händler hat Provision an B2In überwiesen.
|
||
|
||
distributed: Provision wurde an Makler/Kunde ausgeschüttet.
|
||
|
||
C. Die Wallet-Logik (Wallet / Commission Model)
|
||
Sobald Status auf paid springt, feuert ein Event (TransactionPaid):
|
||
|
||
Berechnet Split: x% an Makler-Wallet, y% an Kunden-Wallet (Cashback).
|
||
|
||
Erstellt Einträge in der ledger (Kassenbuch) Tabelle.
|
||
|
||
4. Partner-Modul: Makler & Händler Dashboards
|
||
Die B2B-Ansichten.
|
||
|
||
Makler-Invite System:
|
||
|
||
Makler generiert "Invite-Links" oder Codes für style2own/stileigentum.
|
||
|
||
Wenn sich ein Kunde damit registriert, wird broker_id fest beim Kunden hinterlegt (Attribution).
|
||
|
||
Händler Setup-Buchung:
|
||
|
||
Ein kleiner "Service-Store" im Händler-Backend.
|
||
|
||
Button: "Setup-Paket buchen (399€)". Löst eine interne Notification an das B2In-Team aus (Ticket für Fotografen).
|
||
|
||
5. Frontend-Modul: Die Weichenstellung
|
||
Wie die Landingpages mit dem System reden.
|
||
|
||
Multi-Domain-Routing:
|
||
|
||
Wenn Request von style2own.de kommt -> Lade CSS-Variablen-Set "Modern" + Wording "Du".
|
||
|
||
Wenn Request von stileigentum.de kommt -> Lade CSS-Variablen-Set "Classic" + Wording "Sie".
|
||
|
||
Der "Local Feed" (Marktplatz-View):
|
||
|
||
Query: SELECT * FROM products WHERE hub_id = [User-Hub] AND status = 'active'.
|
||
|
||
Sortierung: Lagerware (Säule A) gemischt mit Highlights.
|
||
|
||
Zusammenfassung: Der Entwicklungs-Fahrplan
|
||
Das ist die logische Reihenfolge für die Programmierung:
|
||
|
||
Phase 1: DB & Auth (Basis)
|
||
|
||
User Table mit hub_id, origin, broker_id.
|
||
|
||
Hub Table.
|
||
|
||
Registrierung über Invite-Code (Verknüpfung Makler-Kunde).
|
||
|
||
Phase 2: Händler & Produkte (Content)
|
||
|
||
Händler-Profil (Öffnungszeiten, Bilder).
|
||
|
||
Produkt-CRUD (Create, Read, Update, Delete) für Händler (Säule A).
|
||
|
||
Frontend-Feed ("Zeige Produkte in meinem Hub").
|
||
|
||
Phase 3: Der "Geld-Kreislauf" (Logik)
|
||
|
||
Ticket-Generierung (QR).
|
||
|
||
WICHTIG: Beleg-Upload Formular für Kunden.
|
||
|
||
Händler-Backend: Ansicht "Offene Umsatz-Bestätigungen".
|
||
|
||
Phase 4: Frontend Polish
|
||
|
||
Style2Own vs. StilEigentum Styling.
|
||
|
||
Dashboards hübsch machen.
|
||
|
||
Wie die Module zusammenhängen (Flow)
|
||
Landingpage (Origin) -> Registrierung (Auth + Broker-Link) -> User landet im Hub (Hub-Logik) -> Sieht Produkte (Catalog) -> Zieht Ticket -> Lädt Beleg hoch (Transaction) -> Händler bestätigt -> Cashback fließt (Wallet).
|