Lerne, wie du eine Liefer‑ oder Abhol‑App für Essen baust: Modell wählen, MVP‑Funktionen definieren, Zahlungen und Dispatch planen, Kosten schätzen und mit Zuversicht starten.
Bevor du Bildschirme skizzierst oder Frameworks vergleichst, entscheide, welche Art von Geschäft du bauen willst. Eine Food-Delivery-App und eine Abhol-Bestell-App können viel UI teilen, verhalten sich aber betriebsseitig sehr unterschiedlich — besonders bei Timing, Gebühren und Kundenerwartungen.
Sei explizit über deine Hauptnutzer. Du kannst eine Gruppe zuerst bedienen und andere später hinzufügen, aber du solltest wissen, für wen du am ersten Tag optimierst:
Wähle das Hauptziel für die erste Version: Lieferung, Abholung oder eine klare Mischung.
„Beides“ ist in Ordnung — aber nur, wenn du klar erklären kannst, warum Kunden beide Optionen in deinem ersten Gebiet nutzen würden und wie der Betrieb das unterstützt.
Liste die ersten Städte oder Stadtteile auf, die du bedienen willst. Dein Anfangsgebiet beeinflusst alles: Dichte der Restaurants, Lieferzeiten, Kurierverfügbarkeit und Marketingkosten. Eine enge Zone ist einfacher schnell und konsistent zu machen.
Wähle messbare Ziele, wie Bestellanzahl, Wiederkauf‑Rate, durchschnittliche Lieferzeit und Stornierungsrate. Diese Metriken leiten den Umfang deines Food‑App‑MVP und die Roadmap für Lieferfunktionen.
Entscheide dein Erlösmodell früh: Provision pro Bestellung, Restaurant‑Abos, Liefergebühren, Servicegebühren oder ein Hybrid. Diese Wahl formt Preisgestaltung, Aktionen und wie du dein "Liefer-App bauen"-Angebot Restaurants und Kunden positionierst.
Bevor du Bildschirme gestaltest oder Funktionen wählst, entscheide, welche Art App du baust. Diese Wahl bestimmt Komplexität, Time‑to‑Market und Unit Economics.
Marketplace‑Apps listen viele Restaurants. Du brauchst Onboarding-Tools, Restaurant‑Freigaben, Menüverwaltung über verschiedene Küchen hinweg und Support‑Workflows für viele Problemtypen. Der Vorteil ist größere Auswahl (oft einfachere Kundenakquise) und mehr Bestellvolumenpotenzial — sofern du den Betrieb gut ausführst.
Single‑Brand‑Apps (ein Restaurant oder eine Kette) sind einfacher. Du kontrollierst Menüstruktur, Öffnungszeiten, Zubereitungszeiten und Richtlinien. Meist schneller zu liefern und leichter zu warten; Margen lassen sich besser schützen, weil du keinen beidseitigen Marktplatz mit hohen Rabatten subventionieren musst.
Ein Hybrid kann als Single‑Brand starten und später Partnerrestaurants hinzufügen oder als Marketplace starten und eine „Flaggschiff“-Marke hervorheben. Hybrid kann funktionieren — erhöht aber oft früh den Scope.
Zwei Hauptmodelle:
Eine Abhol‑Bestell‑App kann ein großartiges v1 sein: kein Kurier‑Dispatch, weniger Edge‑Cases, einfachere Rückerstattungen und klarer Status („accepted → preparing → ready for pickup“). Sie reduziert auch die Support‑Last.
Für Version 1 entscheide dich für einen primären Pfad (z. B. Single‑Brand + Abholung oder Marketplace + Restaurant‑geliefert). Du kannst mit Blick auf Erweiterungen designen, aber eine fokussierte Entscheidung hilft, früher zu starten und aus echten Bestellungen zu lernen statt aus Annahmen.
Bevor du über Features sprichst, mappe die Journeys. Eine „Journey“ ist einfach die Abfolge von Schritten, die eine Person unternimmt, um ein Ziel zu erreichen — eine Bestellung aufgeben, sie zubereiten, ausliefern oder das Geschäft verwalten. Wenn du diese Abläufe aufschreibst, zeigen sich Lücken früh (z. B. wann sammelst du eine Telefonnummer, wer kann stornieren, was passiert bei ausverkauften Artikeln?).
Eine nützliche Regel: skizziere zuerst einfache Bildschirme, dann verwandle sie in Anforderungen. Wenn du keinen Screen dafür skizzieren kannst, verstehst du es wahrscheinlich noch nicht.
Kunden wollen Sicherheit und Schnelligkeit. Dein Ablauf sollte beantworten: „Was kann ich bestellen, wann bekomme ich es und was kostet es?“
Halte die Schritte knapp: Restaurants oder Marke entdecken, Menü durchstöbern, Artikel anpassen, Warenkorb prüfen (Gebühren, Steuern, Liefer-/Abholzeit), bezahlen, dann Fortschritt verfolgen.
Support ist Teil der Journey, nicht ein Nachgedanke. Füge einen klaren Pfad für „Wo ist meine Bestellung?“, „Adresse ändern“ oder „Stornieren“ hinzu mit Regeln, die zu deinem Betrieb passen.
Restaurants brauchen eine verlässliche Queue und klare Zeitangaben. Die Kernschleife ist:
Entscheide früh, wie Ersatzartikel funktionieren und wer den Kunden kontaktiert. Vermeide einen Flow, der Personal zwingt, wegen jeder Kleinigkeit anzurufen.
Wenn du On‑Demand‑Lieferung einbeziehst, halte die Kurier‑Schritte minimal: Auftrag annehmen, zur Abholung navigieren, Abholung bestätigen, zur Lieferung navigieren, Lieferung bestätigen.
„Proof“ kann ein Foto, ein PIN‑Code oder eine Unterschrift sein. Wähle das, was zu deinen Auftragsarten passt (Abstellen vs. Übergabe) und keinen unnötigen Reibungspunkt schafft.
Admin ist, wo das Geschäft täglich läuft: Restaurants onboarden, Lieferzonen und Gebühren festlegen, Aktionen verwalten, Rückerstattungen ausstellen und Reports ansehen.
Lege fest, wer was darf. Zum Beispiel: Können Restaurant‑Manager rückerstatten oder nur Admins? Können sie Zubereitungszeiten ändern? Bereinige Berechtigungen jetzt, um späteren Ärger zu vermeiden.
Wenn jede Journey auf eine Seite passt, konvertiere die Schritte in deinen Anfangs‑Scope und weise Verantwortliche zu. Das hält deine Food‑Delivery‑ oder Abhol‑App fokussiert auf reale Nutzung — nicht eine Wunschliste.
Dein MVP (Minimum Viable Product) ist die kleinste Version deiner Food‑Delivery‑ oder Abhol‑App, die echte Bestellungen zuverlässig annehmen kann. Ziel: Nachfrage beweisen, Betrieb validieren und lernen — ohne Monate mit „Nice‑to‑haves“ zu verbringen.
Zum Start sollten Kunden:
Wenn einer dieser Schritte holprig ist, bricht die Conversion schnell ein.
Restaurants brauchen ein einfaches Restaurant‑Bestellsystem, das zum Service passt:
Für On‑Demand‑Lieferung kann die Kurier‑App minimal sein:
Dein Admin‑Dashboard für Restaurants sollte umfassen:
Um v1 fokussiert zu halten, verschiebe Funktionen wie Loyalty, fortgeschrittene Promotions, Abonnements, In‑App‑Chat, komplexes Batching und detaillierte Analytics. Füge sie hinzu, nachdem Kernfunktionen und Unit Economics validiert sind.
Dein Menü und die Bestellregeln sind die Grundlagen. Wenn diese schlampig sind, verbringst du Monate damit, Support‑Tickets, Rückerstattungen und verwirrende Gesamtsummen zu beheben.
Beginne mit einer vorhersehbaren Hierarchie: Kategorien → Artikel → Optionen. Die meisten Restaurants brauchen:
Eine einfache Regel: Wenn eine Option Preis oder Bestand ändert, mache sie zu einem Modifier — nicht zu einer Notiz.
Definiere, wie Summen berechnet und angezeigt werden, in dieser Reihenfolge:
Entscheide außerdem Mindestbestellwert, wie der Lieferradius Gebühren beeinflusst und was bei Teilrückerstattungen passiert.
Setze Regeln für Öffnungszeiten, Zubereitungszeit, Abholfenster und Artikelverfügbarkeit (pro Artikel und Modifikator). Bei geplanten Bestellungen definiere Cutoffs (z. B. „Bestellung mindestens 60 Minuten im Voraus“).
Plane Ersatzartikel, nachträglich ausverkaufte Artikel und „kontaktlose“ Lieferhinweise. Lege fest, wer Änderungen freigibt (Restaurant, Kunde, Support) und wie Preisunterschiede behandelt werden.
Mindestens ein Snapshot von: Artikel‑Namen/Optionen wie bestellt, Preisaufschlüsselung, Steuer-/Gebührenzeilen, Zeitstempel (bestellt/angenommen/bereit/geliefert), Fulfillment‑Typ, Adresse/Geo, Zahlungsstatus, Rückerstattungen und ein klares Ereignisprotokoll für Streitfälle.
Eine Food‑App gewinnt oder verliert durch Geschwindigkeit und Klarheit. Menschen sind oft hungrig, in Eile oder nutzen ein kleines Display mit einer Hand. Ziel: weniger Entscheidungen, weniger Taps, weniger Überraschungen.
Erzwinge keinen langen Account‑Flow bevor Nutzer browsen können. Lass Leute Menüs sofort sehen, und frage erst beim Checkout nach Login.
Für Authentifizierung ist Telefonnummer/OTP oft am schnellsten — kein Passwort, weniger „Passwort vergessen“-Abbruch. Email kann sekundär angeboten werden (für Belege oder Geschäftskunden). Halte es möglichst auf einem Screen.
Address‑UX ist eine Hauptfrustquelle, mache sie fehlertolerant:
Zeige die Lieferzone früh. Wenn eine Adresse außerhalb liegt, sag es klar und schlage Abholung (oder einen nahegelegenen Ort) statt einer generischen Fehlermeldung vor.
Checkout ist Vertrauenssache. Präsentiere eine saubere Zusammenfassung mit:
Füge einen klaren Liefer‑vs‑Abholung‑Toggle nahe oben hinzu — Nutzer sollten ihn nicht nach dem Befüllen des Warenkorbs suchen müssen. Wenn sich etwas am Preis ändert (Mindestbestellwert, Surge, ausverkaufte Artikel), erkläre es in klarer Sprache.
Nutze gut lesbare Schriftgrößen, starken Farbkontrast und große Touch‑Ziele (besonders für Mengen‑Buttons und Adressfelder). Verlasse dich nicht nur auf Farbe, um Fehler zu signalisieren — füge Text wie „Straßenadresse ist erforderlich“ hinzu.
Erleichtere Wiederholungen: Bestellungen erneut aus der Historie, Favoriten für Gerichte und Restaurants, und hilfreiche Fehlermeldungen, die genau sagen, was zu tun ist. Je weniger Sackgassen, desto mehr abgeschlossene Bestellungen.
Checkout ist der Moment, in dem deine App Vertrauen gewinnt — oder Support erzeugt. Halte v1 einfach, mache Regeln jedoch klar, damit Kunden, Restaurants und Kuriere wissen, was bei Änderungen passiert.
Die meisten Apps starten mit Karten plus Apple Pay/Google Pay. Digitale Wallets reduzieren Eingaben, verbessern Conversion und können Betrug mindern.
Wenn es dein Markt verlangt, füge Bargeld vorsichtig hinzu. Bargeld erhöht Reichweite in einigen Regionen, steigert aber Stornorisiko und verkompliziert Kurierabläufe (Wechselgeld, No‑Shows). Begrenze Bargeld ggf. auf verifizierte Nutzer, bestimmte Restaurants oder kleine Bestellwerte.
Zwei Ansätze:
Egal was du wählst, definiere Regeln für häufige Fälle: Restaurant lehnt Bestellung ab, Kurier kann nicht liefern, Kunde storniert, Restaurant ist verspätet, Artikel ausverkauft. Stelle die Richtlinie auf der Bestellbestätigung und auf /help oder in /terms bereit.
Trinkgeld ist UX‑ und Policy‑Frage. Entscheide früh:
Plane auch, wie du Auftragsanpassungen (z. B. Ersatzartikel) handhabst. Wenn sich Summen ändern können, mache den Freigabeablauf explizit: „Neuen Gesamtbetrag bestätigen“ vs. „Automatisch anpassen bis zu €X“.
Rückerstattungen sind unvermeidlich: fehlende Artikel, falsche Lieferung, späte Zustellung oder Kundenbeschwerden.
Support:
Mache Teilrückerstattungen für Support und Betrieb einfach — Artikel und Mengen auswählen sowie Grundcodes. Diese Daten helfen, wiederkehrende Probleme mit bestimmten Restaurants oder Kurieren zu erkennen.
Dein MVP sollte einer strengen Regel folgen: niemals rohe Kartendaten speichern. Nutze einen Zahlungsanbieter mit tokenisierten Zahlungen, sodass deine App nur Tokens und Zahlungsstatus handhabt.
Schütze den Flow mit:
Sende Kunden einen detaillierten Beleg (E‑Mail und/oder In‑App) mit Steuern, Gebühren, Rabatten und Trinkgeld. Restaurants brauchen ebenfalls eine klare Aufschlüsselung: Subtotal, Plattformcommission, Auszahlungen und Rückerstattungsanpassungen.
Wenn du später Geschäftskunden unterstützen willst, designe das Belegformat so, dass es sich zu echten Rechnungen entwickeln lässt, ohne das Checkout‑System komplett neu zu schreiben.
Dispatch und Abholung sind der Punkt, an dem deine App aus einer schönen UI ein verlässliches Werkzeug wird. Ziel: Die richtige Bestellung pünktlich zur richtigen Person mit minimalem Hin‑und‑Her bringen.
Manuelle Zuweisung funktioniert gut in frühen Phasen. Ein Admin (oder Restaurantpersonal) wählt einen Kurier basierend auf Standort, Fahrzeugtyp oder Verfügbarkeit. Langsamer, aber flexibel bei niedrigen Volumen oder schwierigen Gebieten.
Auto‑Zuweisungsregeln lohnen sich bei konsistentem Auftragsfluss. Halte sie regelbasiert und erklärbar:
Eine Live‑Karte schafft Vertrauen, erhöht aber Komplexität (Batterie, GPS‑Genauigkeit, „steckende“ Punkte). Als MVP können status‑only updates ausreichen: „Order accepted“, „Preparing“, „Picked up“, „Arriving“, „Delivered“.
Du kannst dennoch Erwartungen erfüllen mit zeitnahen Push‑Benachrichtigungen und realistischen ETAs, basierend auf einfacher Distanz + Puffer‑Logik.
Wähle die leichteste Option, die zu deinem Risiko passt:
Verzögerungen passieren — dein Produkt sollte die Erholung routiniert machen:
Abholbestellungen brauchen Struktur, um Warteschlangen und kaltes Essen zu vermeiden. Unterstütze:
Gut gemanagte Dispatch‑ und Abholprozesse reduzieren Rückerstattungen, Supportanfragen und Churn — ohne am ersten Tag komplexe Technik zu benötigen.
Dein Tech‑Stack sollte das Geschäft unterstützen, das du betreiben willst — nicht umgekehrt. Für die meisten Food‑Delivery‑ und Abholprodukte reicht eine einfache, bewährte Basis: Mobile Apps + Backend‑API + Admin‑Dashboard.
Wenn du mit Abholung startest, kannst du die Kurier‑App und Dispatch‑Logik oft nach hinten schieben.
Keine Einheitslösung — wähle nach Timeline und Team:
Ein gängiger Weg ist: Web‑Bestellflow + leichtes Admin, dann mobile Apps, wenn das Geschäftsmodell es verlangt.
Wenn dein Ziel ist, Abläufe schnell zu validieren (Menüs, Checkout, Bestellstatus und ein Admin‑View) ohne eine volle Engineering‑Pipeline, kann eine Vibe‑Coding‑Plattform wie Koder.ai helfen. Sie ermöglicht, von Anforderungen zu funktionierenden Screens und Backend‑Logik per Chat zu kommen.
Du kannst z. B. einen Kundenbestellfluss, ein Restaurant‑Dashboard und ein einfaches Admin‑Tool im selben Umfeld prototypen und iterieren. Koder.ai unterstützt Planungsmodus, Snapshots/Rollback und Source‑Code‑Export — nützlich, wenn du schnell starten und später das Codebase intern weiterführen willst.
Viele Apps wirken „smart“ wegen Integrationen, nicht wegen maßgeschriebener Logik:
Halte die erste Version fokussiert: nur das implementieren, was Bestellung, Fulfillment und Customer Support unterstützt.
Auch ein einfaches Restaurant‑Bestellsystem profitiert von einem klaren Kernmodell:
Diese Entitäten früh richtig zu modellieren reduziert schmerzhafte Migrationen später.
Zwei Gewohnheiten verhindern Chaos bei steigendem Bestellvolumen:
Ziel ist keine fancy Architektur, sondern ein Setup, das einfach zu liefern, zu betreiben und schwer zu breaken ist.
Eine Food‑Delivery‑App ist nur so gut wie die täglichen Tools dahinter. Das Admin‑/Ops‑Toolkit verhindert, dass kleine Probleme (falsche Öffnungszeiten, fehlende Modifikatoren, Zahlungsfehler) in Support‑Tickets und Rückerstattungen ausarten.
Onboarding sollte sich wie eine Checkliste anfühlen, nicht wie ein E‑Mail‑Ping‑Pong. Sammle das Nötige upfront:
Zeige Fortschritt („Schritt 2 von 4“) und ermögliche Speichern/Weitermachen. Je schneller ein Restaurant ein sauberes Live‑Menü hat, desto schneller kommen wiederkehrende Bestellungen.
Dein Ops‑Team muss Dinge ändern können, die Kunden sofort sehen:
Füge Guardrails hinzu: Warnung, wenn ein Artikel keinen Preis hat, wenn Modifikatorgruppen zu groß sind oder ein Restaurant „offen“ ist, aber keine aktiven Kuriere in der Nähe hat.
Support ist am einfachsten, wenn jede Aktion an die Bestelltimeline gekoppelt ist. Für Rückerstattungen und Bestellprobleme füge Schnellaktionen hinzu wie:
Halte Kommunikationsvorlagen kurz und konsistent und protokolliere jede Änderung (wer hat was wann gemacht).
Richte eine Ops‑Ansicht ein, die Ausnahmen hervorhebt statt alle Bestellungen aufzulisten:
Einfache Alerts (Email oder In‑App) sparen Stunden: „10+ fehlgeschlagene Zahlungen in 5 Minuten“ oder „Restaurant nimmt Bestellungen an, ist aber als geschlossen markiert.“
Admin‑Tooling schützt auch Margen. Tracke Rückerstattungsrate pro Restaurant, Promo‑Nutzung nach Kohorte und durchschnittliche Lieferzeit pro Zone.
Beim Vergleichen von Tools oder bei der Entscheidung, wie viel in interne Dashboards investiert werden soll, hilft ein Vergleich von Plattformen und Plänen — verweise Leser auf /pricing.
Testing ist der Punkt, an dem eine Food‑Delivery‑App von einer Demo zu einem Business‑Tool wird. Du prüfst nicht nur Bugs — du beweist, dass Kunden bestellen können, Restaurants liefern können und Kuriere ohne Verwirrung ausliefern.
Bevor du dich an Edge‑Cases wagst, stelle sicher, dass die "Money Paths" immer funktionieren:
Führe die Flows realistisch aus: ausverkaufte Artikel, Adressänderungen, Notizen und erneute Bestellungen.
Bestellungen passieren auf älteren Phones, instabilem Wi‑Fi und in überlasteten Netzen. Teste verschiedene Bildschirmgrößen und OS‑Versionen und simuliere:
Restaurants reagieren nicht sanft auf Last — Tickets stapeln sich. Simuliere Bursts (z. B. 20–50 Bestellungen in wenigen Minuten) und prüfe:
Überprüfe Zugriffskontrollen (wer sieht was), Rate‑Limits für Login/OTP‑Endpoints und einfache Fraud‑Flags (zu viele fehlgeschlagene Zahlungen, wiederholte Stornierungen, ungewöhnliche Trinkgeldbeträge).
Starte mit einigen echten Restaurants in einem begrenzten Gebiet. Tracke, wo Nutzer zögern (Checkout‑Abbrüche, Restaurant‑Annahmeverzögerungen) und behebe diese Probleme vor der breiteren Öffnung. Stelle sicher, dass dein Ops‑Dashboard täglich nutzbar ist — nicht nur in Tests.
Der Launch ist nicht das Ziel — es ist der Moment, in dem du von echtem Nutzerverhalten lernst. Plane eine stabile Version 1, die verständlich ist und von einem klaren Betrieb getragen wird.
Vor dem Einreichen in App Stores bereite das Nötigste vor, das Verwirrung am ersten Tag reduziert:
Frühes Wachstum kommt meist lokal, nicht durch breite Ads. Bei Single‑Brand push deine App an bestehende Kunden (In‑Store‑Signage, Belege, E‑Mail‑Liste). Bei einem Marketplace ist Marketing auch Supply: Restaurants rekrutieren und deren Menüs korrekt live haben.
Wenn du öffentlich baust, dokumentiere Entscheidungen, MVP‑Scope und Änderungen nach Beta — das kann frühe Nutzer und Partner anziehen. (Kleiner Hinweis: Koder.ai hat ein Earn‑Credits‑Programm für Creator, die Inhalte über ihre Builds veröffentlichen — nützlich, wenn du MVP‑Kosten niedrig halten willst.)
Beginne mit nützlichen Triggern: Reorder‑Buttons, gespeicherte Adressen und Status‑Updates. Nutze Push‑Benachrichtigungen sparsam — Bestellupdates sind willkommen; tägliche Promo‑Pushes nicht. Halte Aktionen simpel und messbar (Erstbesteller‑Rabatt, Reaktivierung nach 30 Tagen).
Tracke ein paar Metriken konstant:
Nutze die Daten für die Roadmap: Behebe die größten Drop‑Off‑Screens zuerst, dann die Top‑Support‑Probleme. Wenn Warenkörbe am Checkout sterben, siehe /blog/how-to-reduce-cart-abandonment für schnell testbare Ideen.
Beginne mit der Entscheidung für dein Geschäftsmodell und den Hauptnutzer für v1:
Definiere außerdem eine begrenzte erste Lieferzone und 90-Tage-Erfolgskennzahlen (Bestellanzahl, Wiederkaufrate, Liefer-/Abholzeit, Stornierungen).
Abholung ist in der Regel schneller und günstiger zu starten, weil du vermeidest:
Du kannst Nachfrage und Restaurantabläufe mit einem einfacheren Statusfluss validieren: accepted → preparing → ready for pickup.
Ein Marketplace benötigt Werkzeuge für Onboarding und Verwaltung vieler Partner, z. B.:
Eine Single-Brand-App ist einfacher, weil du Menüstruktur, Öffnungszeiten, Zubereitungszeiten und Richtlinien kontrollierst — daher meist schneller zu liefern und leichter zu pflegen.
Mappe die Journeys für jede Rolle und halte jeden Ablauf auf einer Seite:
Wenn du die Schritte niederschreibst, werden Lücken (z. B. Stornierungen, ausverkaufte Artikel oder wer den Kunden kontaktiert) offensichtlich.
Dein MVP sollte zuverlässig eine vollständige Bestellung abwickeln.
Kunden-MVP:
Restaurant-MVP:
Nutze eine klare Struktur: Kategorien → Artikel → Optionen.
Praktische Regeln:
Zeige die Summen in einer vorhersehbaren Reihenfolge:
Lege außerdem Mindestbestellwert, Regeln für Lieferradius und Verhalten bei Teilrückerstattungen fest. Klare Aufschlüsselungen reduzieren Streitfälle und Supportanfragen.
Gängige v1-Optionen sind Karten + Apple Pay/Google Pay für höhere Conversion.
Zur Zahlungsstrategie:
Speichere niemals Rohkartendaten — nutze tokenisierte Zahlungen und sichere Admin-Zugänge (Rollen, 2FA).
Starte mit einem der beiden Ansätze:
Für Tracking reichen Status-Updates (accepted, preparing, picked up, arriving, delivered) oft als MVP. Proof of Delivery wähle nach Risiko: Foto (Abstellen), PIN (hochpreisig), Unterschrift (selten).
Konzentriere dich auf die „Money Paths“ end-to-end:
Starte dann mit einem kleinen Beta in einem begrenzten Gebiet mit wenigen Restaurants. Nutze Ops-Tools, um Ausnahmen zu erkennen (fehlgeschlagene Zahlungen, blockierte Bestellungen, lange Zubereitungs-/Abholzeiten) und priorisiere die wichtigsten Probleme für dein Roadmap-Backlog. Zur Verbesserung von Checkout-Abbrüchen siehe /blog/how-to-reduce-cart-abandonment.
Admin-MVP:
