GastroFlow

Eine Plattform für den Betrieb — Module danach

Zuerst die Abläufe, die den Abend tragen: Speisekarte, QR-Bestellung, Küche, Reservierung, Gäste, Kennzahlen und Anbindungen. Darunter die Website-Module und Werkzeuge, mit denen Fenix Web die Installation baut.

GastroFlow

Was der Betrieb morgen Abend nutzt

Sieben Abläufe, dieselben Daten. Website-Module und Werkzeuge folgen darunter — für die Installation, nicht für den ersten Verkaufssatz.

Speisekarte
Gerichte, Preise, Allergene und Bilder zentral. Tageskarte und Korrektur sind live, sobald Sie speichern.
QR-Bestellung
Gast scannt den Tischcode und bestellt im Browser. Kein Download, kein Account. Das Ticket landet am Desk.
Küche
Bon und Station statt Zuruf. Status: Neu → Küche → Fertig → Serviert.
Reservierung
Kapazität und Bestätigung auch nach Mitternacht — wenn das Telefon niemand mehr abnimmt.
Gäste
Hinweise für den Service in der eigenen Instanz, nicht in einem fremden Portal.
Analytics
Tagesübersicht, Auslastung, Topseller, Export — Zahlen für den Betrieb, keine Chart-Galerie.
Integrationen
Anbindungen an Hardware, Partner und die eigene Website. Technik steht in der Dokumentation.

Website-Module und Werkzeuge

Technik für die Installation

fenix-theme bis Menu-Importer — für Teams, die die Website selbst bauen oder erweitern. Nicht der Einstieg für den Restaurantbetrieb.

Core · Webdesign

fenix-theme

Das Basis-Webdesign des Ökosystems. Blockbasiert, auf Gastronomie zugeschnitten, angebunden an die Website-API.

Für wen

Häuser, die Website und Betrieb in einer Installation halten — nicht auf einer Extra-Plattform.

Problem

Standard-Webdesigns kennen weder Allergene noch Reservierungsblöcke. Inhalte und Betrieb fallen auseinander.

So arbeitet es

Theme-Struktur, Reservierungs-Integration, Flächen nach WCAG als Maßstab — kein Audit-Siegel. Änderungen an Speisekarte und Seiten gehen über dieselben Blöcke live.

Restaurantinnenraum, für den GastroFlow den Betrieb abbildet

Erweiterung · Datenmodell

fenix-companion

Individuelle Erweiterung für alles, was Seiten allein nicht tragen: Custom Post Types, Rollen und die Daten, die nachts weiterlaufen.

Für wen

Installationen mit Speisekarte, Schicht und Rechten — nicht nur mit statischen Seiten.

Problem

Gerichte in Beiträgen, Rollen per Hand, Importe ohne Zielmodell. Der Betrieb hat keine feste Struktur.

So arbeitet es

Speisekarten-CPT, Rollen und Rechte, Datenmigration, Cron-Jobs. Webdesign und Erweiterungen lesen dasselbe Modell.

GastroFlow · Flow Order

QR am Tisch, Bon in der Küche

Flow Order ist das Bestellmodul: QR-Tischcodes, Kitchen Display, Bon-Druck, Offline-Puffer. Die volle Plattform steht auf der GastroFlow-Seite.

Für wen

Service und Küche im laufenden Abend, wenn Wege teuer sind und der Bon nicht warten darf.

Problem

Bestellungen über fremde Apps, Status nirgends, Küche erfährt zu spät, was am Tisch steht.

So arbeitet es

Gast scannt den Tischcode, die Bestellung landet im Desk und als Bon an der Station. Offline-Puffer hält den Abend, wenn das Netz wackelt.

GastroFlow im Backend: Speisekarte mit Gerichten, Preisen und Status
Live-Desk: Tische und Bestellungen in einer Ansicht.
QR-Code am Tisch für Flow-Order-Bestellungen
QR-Code pro Tisch.
Küchenmonitore mit Bestelllisten über der Pass
Küchenbon nach Station.

Erweiterung · Formulare

fenix-forms

Formular-Engine für Reservierungen, Kontakt und Event-Anfragen. Speicherung in der eigenen Website-Instanz, DSGVO-tauglich.

Für wen

Betriebe, die Tische, Rückfragen und Feiern annehmen — ohne eine zweite Formular-Erweiterung.

Problem

Reservierungen in Mail-Postfächern, Spam ohne Filter, keine Weitergabe an Küche oder Kalender.

Reservierungslogik

Kapazität, Zeiten und Bestätigung sitzen in der Engine — nicht in einer Tabelle, die niemand pflegt.

Spam-Schutz

Anfragen werden gefiltert, bevor sie im Postfach oder im Desk landen.

Webhook-Ausgabe

Ereignisse gehen an angebundene Systeme: Kalender, CRM, internes Routing.

E-Mail-Trigger

Bestätigung an den Gast, Hinweis an den Betrieb — aus demselben Datensatz.

Security · Lizenz

fenix-license-control

Lizenzprüfung mit Ed25519-Signaturen. Jede Installation wird an die Domain gebunden; Module werden remote aktiviert und periodisch geprüft.

Für wen

Betreiber und Partner, die Webdesign, Orders und Forms legal und offline-fähig halten müssen.

Problem

Module ohne Nachweis, Kopien ohne Domain, Ausfall wenn die Prüfung das Haus zumacht.
Stack und Integration
Websiteeigene Installation
PHP8.0 oder höher
REST-APIneoweb/v1
SignierungEd25519
BindungDomain, Laufzeit, Modulumfang
OfflineGrace-Period, Betrieb läuft weiter

Ed25519-Validierung

Lizenz wird im Generator signiert, das Modul prüft den öffentlichen Schlüssel beim Start.

Seed-Management

Schlüsselpaare aus einem verwahrten Seed, Rotation und Wiederherstellung protokolliert.

Domain-Bindung

Lizenz gilt für die genannte Domain — nicht für beliebige Kopien.

Design · Tokens

fenix-style-guide

Design-Token-System und Komponenten-Bibliothek. Ein Erscheinungsbild über Webdesign, Desk und Formulare — mit Varianten und Live-Vorschau.

Für wen

Teams, die Webdesign-Varianten ausliefern, ohne jede Seite neu zu gestalten.

Problem

Farben und Abstände divergieren zwischen Website, Bestellschirm und Küchendisplay.

So arbeitet es

Tokens, Komponenten-Beispiele, Webdesign-Varianten, Live-Vorschau. Module lesen dieselben Werte.

Tool · Provisionierung

Demo-Installer

Ein Klick setzt eine volle Demo-Umgebung auf: Beispieldaten, Sandbox, Zurücksetzen. Zum Prüfen, nicht zum Produktivbetrieb.

Für wen

Häuser und Webagenturen, die GastroFlow und die Module sehen wollen, bevor sie Daten einspielen.

Problem

Leere Website-Instanz, keine Speisekarte, kein Tisch — die Demo bleibt Theorie.

So arbeitet es

One-Click-Setup, Beispieldaten, Sandbox-Modus, Zurücksetzen auf den Ausgangszustand.