Gastronomie
Eine scheinbar einfache Frage zu einem eigenen Online-Bestell- und Lieferkanal wuchs sich zu einem Product-Discovery-Projekt aus. Bevor etwas gebaut oder ausgewählt wurde, untersuchte Simply Dom die gewünschte Kundenerfahrung, bestehende Lösungen, mögliche Architekturen und die operativen Folgen — einschließlich der Gründe, warum mehrere naheliegende Optionen ausschieden.
Die Ausgangssituation
Die Frage kam direkt aus der Praxis. Ein Unternehmer aus der Gastronomie wollte mehr Kontrolle über seinen eigenen Online-Bestell- und Lieferkanal, mit eigenen Fahrern, ohne dabei auf eine Kundenerfahrung zu verzichten, die große Plattformen inzwischen zum Standard gemacht haben.
Ein Element war dabei besonders konkret: Der Kunde sollte seine Bestellung während der Lieferung wirklich verfolgen können. Nicht ein Status „unterwegs“, nicht nur eine geschätzte Lieferzeit, sondern zu sehen, wo sich die Lieferung gerade befindet.
Auf den ersten Blick eine Softwarefrage: Welche Lösung bietet das? Die erste Recherche machte schnell deutlich, dass diese Formulierung zu einfach war.
Die geschäftliche Fragestellung
Es gibt viele Systeme für Online-Bestellungen und ebenso viele für Dispatch, Routen und Fahrer. Auffällig viele Anbieter verwenden dabei Begriffe wie „Live Tracking“ oder „Real-Time Delivery“. Nur bedeuten diese Begriffe nicht überall dasselbe.
Mal kann der Betreiber seine Fahrer live verfolgen, der Kunde aber nicht. Mal erhält der Kunde Status-Updates ohne Karte. Mal existiert die gewünschte Erfahrung nur, wenn ein externer Kurierpartner die Lieferung übernimmt. Und mal bietet eine Plattform fast alles Nötige — außer genau dem Teil, wegen dem die Recherche begonnen hatte.
Die Schwierigkeit lag also nicht darin, Anbieter zu finden; davon gab es genug. Die Schwierigkeit bestand darin nachzuweisen, welche Kombination die gewünschte Erfahrung tatsächlich liefern konnte — mit eigenen Fahrern, einem funktionierenden Tagesbetrieb und ausreichender Kontrolle über den Kundenkanal.
Die Entscheidungen
Der erste Schritt bestand darin, die gewünschte Erfahrung präzise zu definieren. „Live Tracking“ wurde nicht als bloßes Feature-Label akzeptiert; die Frage wurde konkreter: Muss der Endkunde auf einer Karte eine sich bewegende Position des Fahrers sehen können, während die Bestellung unterwegs ist? Das wurde zum Prüfstein.
Danach wurden die Ebenen des Problems auseinandergenommen. Einerseits der kommerzielle Kundenkanal: Sortiment, Bestellung, Zahlung, Kundendaten und Kommunikation. Andererseits die Ausführung: Aufträge zuweisen, Fahrer steuern, Routen, Status und Standort.
Diese Aufteilung machte verschiedene Architekturen sichtbar: eine einzige Plattform, die alles erledigt, eine Bestellplattform gekoppelt an spezialisierte Last-Mile-Software, eine bestehende Lösung mit einem externen Lieferpartner, oder mehr Individualentwicklung rund um Systeme, die jeweils für sich bereits bewährte Bausteine bieten.
Nicht jede Option erhielt gleich viel Zeit. Wenn eine Kernanforderung nicht nachweisbar unterstützt wurde, schied sie aus. Das war wichtiger, als eine lange Shortlist zu erstellen.
Meine Rolle
Meine Rolle war Product Discovery und Opportunity Validation: die ursprüngliche Frage zerlegen, die gewünschte Kundenerfahrung ausformulieren, bestehende Bestellplattformen und Last-Mile-Lösungen getrennt untersuchen und prüfen, was Anbieter tatsächlich meinen, wenn sie „Live Tracking“ schreiben.
Dabei wurde ausdrücklich festgehalten, was bewiesen war, was nur eine Marketingaussage war und wo noch eine offene Frage bestand.
Auch die operative und kommerzielle Seite wurde einbezogen. Was sieht der Endkunde, was sieht der Fahrer, was muss der Betreiber tun können? Wie gelangt eine Bestellung von einem System ins andere, und wo entsteht ein zusätzlicher manueller Schritt? Wer besitzt die Kundenbeziehung? Und wie viel Abhängigkeit verschiebt sich wirklich, wenn man einen einzigen Marktplatz durch mehrere Softwareanbieter ersetzt?
Die Frage, ob der Vorteil groß genug ist, um diese zusätzliche Komplexität zu rechtfertigen, blieb dabei bewusst offen: Sie lässt sich erst ernsthaft beantworten, sobald feststeht, welche Architektur überhaupt leisten kann, was verlangt wird.
Die Recherche wurde anschließend erneut hinterfragt — nicht um möglichst viele Lösungen zu behalten, sondern um sich schneller von Lösungen zu trennen, die bei näherer Prüfung nicht das taten, was sie auf den ersten Blick zu tun schienen.
Die Umsetzung
Das Ergebnis dieser ersten Discovery-Phase war keine Software, und das war auch nicht die Absicht. Stattdessen lag ein deutlich schärferes Problembild vor: ein ausformulierter Kundenflow, ein separater Flow für Fahrer und operative Steuerung, ein Vergleich möglicher Plattformkategorien und eine Übersicht der Lösungen, die an wesentlichen Punkten ausschieden — mit der jeweiligen Begründung.
Daneben lag ein erstes Architekturbild vor, welche Systeme zusammenarbeiten könnten, und vor allem eine Liste von Fragen, die in einer nächsten Rechercherunde noch bewiesen werden mussten.
Dadurch wurde auch klar, wo weitere Recherche wirklich sinnvoll war: nicht zwanzig Anbieter erneut anschreiben, sondern eine begrenzte Gruppe von Optionen gezielt gegen die wirklich entscheidenden Bedingungen testen. Erst danach lassen sich technische Machbarkeit, operative Umsetzbarkeit und Wirtschaftlichkeit gemeinsam beurteilen.
Stand der Dinge — August 2026
Die zweite Rechercherunde hat vor allem das Spielfeld verkleinert.
Plattformen für Online-Bestellung, Dispatch und Fahrerunterstützung gibt es genug. Nur erweist sich „Live-Tracking“ nicht als eindeutiger Begriff. Bei manchen Lösungen kann der Betreiber seine Fahrer verfolgen, der Kunde jedoch nicht. Anderswo erhält der Kunde Statusupdates, ohne eine Karte zu sehen. Und in manchen Modellen besteht dieses Erlebnis nur, wenn ein externer Lieferpartner die Fahrt übernimmt. Diese Optionen sind weggefallen.
Gleichzeitig wurde die operative Frage schärfer. Mehrere Gastronomiemarken müssen über einen eigenen direkten Kanal arbeiten können, mit einem gemeinsamen Team eigener Fahrer. Bestellungen müssen korrekt ankommen, Fahrer müssen gesteuert werden können, und der Kunde muss während der Lieferung dieselbe Klarheit erhalten, die er von großen Plattformen gewohnt ist.
Aus dem Vergleich bleibt eine konkrete Option übrig: eine Direktbestellplattform gekoppelt an Dispatch- und Fahrerfunktionalität. Auf dem Papier kommt diese Kombination dem Gesuchten am nächsten. Doch das Element, mit dem der Auftrag begann, steht noch nicht fest: Kann der Endkunde bei einer Lieferung mit eigenen Fahrern tatsächlich sehen, wie sich die Position seines Fahrers auf einer Karte bewegt?
Außerdem muss sich noch zeigen, wie mehrere Marken innerhalb desselben Betriebs behandelt werden, wie der tägliche Ablauf in der Praxis aussieht, welche Lizenzen nötig sind und was das Ganze insgesamt kostet.
Der nächste Schritt bleibt deshalb bewusst klein: eine Demo des echten Systems, die Bestätigung dieses kritischen Ablaufs und ein konkretes Angebot. Keine Implementierung, keine Individualentwicklung, kein Business Case auf Basis von Marketingaussagen. Erst wenn diese Elemente vorliegen, lässt sich beurteilen, ob dies technisch und operativ funktioniert und ob es sich finanziell trägt.
Der Fall ist noch nicht abgeschlossen. Aber was noch bewiesen werden muss, ist inzwischen genau benannt.
Bewusst nicht gemacht
Kein „ja, das geht“, nur weil irgendwo auf einer Website „Live Tracking“ stand. Keine Plattform empfohlen, ohne zu prüfen, wer dieses Tracking wirklich sehen konnte. Keine Individuallösung vorgeschlagen, nur weil bestehende Lösungen nicht sofort perfekt passten. Kein Software-Stack gewählt, bevor klar war, wie er täglich genutzt werden müsste. Und kein Business Case rund um Funktionen gebaut, die noch nicht nachgewiesen waren.
Zu diesem Zeitpunkt musste noch nichts verkauft werden.
Der erste Gewinn lag schon dort: weniger Unsicherheit.
Manche Optionen schieden dadurch aus, andere wurden interessanter, und die ursprüngliche Frage wurde deutlich schärfer, als sie zu Beginn war.
Genau das soll Product Discovery leisten.