From e4fa714419cfc87bb91a7ab0ebe373774aaaa89c Mon Sep 17 00:00:00 2001 From: Clemens Creutzburg Date: Mon, 15 Jun 2026 17:52:08 +0200 Subject: [PATCH] Add go-live and go-to-market roadmaps --- README.md | 3 + docs/go-live-checklist-netcup.md | 222 +++++++++++++++++ docs/go-to-market-30-60-90.md | 394 +++++++++++++++++++++++++++++++ docs/next-steps-roadmap.md | 149 ++++++++++++ 4 files changed, 768 insertions(+) create mode 100644 docs/go-live-checklist-netcup.md create mode 100644 docs/go-to-market-30-60-90.md create mode 100644 docs/next-steps-roadmap.md diff --git a/README.md b/README.md index 88ddc94..30bc1e2 100644 --- a/README.md +++ b/README.md @@ -46,6 +46,9 @@ Organisation, waehrend Produktlogik, Betrieb und Vermarktung zentral bleiben. - [database/schema.sql](/config/workspace/kaffeeliste-neustart/database/schema.sql) - [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md) - [RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md) +- [docs/go-live-checklist-netcup.md](/config/workspace/kaffeeliste-neustart/docs/go-live-checklist-netcup.md) +- [docs/go-to-market-30-60-90.md](/config/workspace/kaffeeliste-neustart/docs/go-to-market-30-60-90.md) +- [docs/next-steps-roadmap.md](/config/workspace/kaffeeliste-neustart/docs/next-steps-roadmap.md) - [docs/product-strategy.md](/config/workspace/kaffeeliste-neustart/docs/product-strategy.md) - [docs/marketing-ops.md](/config/workspace/kaffeeliste-neustart/docs/marketing-ops.md) - [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md) diff --git a/docs/go-live-checklist-netcup.md b/docs/go-live-checklist-netcup.md new file mode 100644 index 0000000..cddbac7 --- /dev/null +++ b/docs/go-live-checklist-netcup.md @@ -0,0 +1,222 @@ +# Go-Live-Checkliste fuer Netcup Webspace + +Diese Checkliste ist fuer den ersten echten Betrieb auf Netcup Webspace gedacht. +Sie baut auf [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md), +[RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md) und +[docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md) +auf, ist aber absichtlich strenger und operativer. + +## 1. Go-Live-Scope festziehen + +- [ ] Entscheiden, ob der erste Livegang ein geschlossener Pilot oder ein oeffentliches SaaS-Launch ist. +- [ ] Fuer einen oeffentlichen Launch Registrierung absichern oder vorerst deaktivieren. + Das Repo nennt Mail-Verifikation, Passwort-Reset und Rate-Limits selbst als offene Punkte vor echtem Go-Live. +- [ ] Falls diese Punkte noch fehlen: nur mit eingeladenen Testkunden oder manuell freigeschalteten Mandanten live gehen. +- [ ] Einen Release-Owner und einen Restore-Owner benennen. +- [ ] Ein Wartungsfenster fuer den Erststart und fuer kuenftige Releases definieren. + +## 2. Environment-Modell festlegen + +Empfehlung fuer Netcup Webspace: + +- [ ] `local`: Entwicklung lokal. +- [ ] `staging`: echte Netcup-Subdomain wie `staging.example.tld`, eigene DB, eigene `.env`. +- [ ] `production`: produktive Domain, eigene DB, eigene `.env`. + +Pragmatisches Verzeichnislayout ohne Root-Zwang: + +- [ ] `staging` unter `/apps/kaffeekasse-stage/current` +- [ ] `production` unter `/apps/kaffeekasse/current` +- [ ] Offsite- oder Backup-Artefakte nicht im Webroot ablegen. + +Wichtig fuer dieses Repo: + +- [ ] `public/` bleibt der einzige Webroot. +- [ ] `.env` wird aus dem Projektwurzelverzeichnis geladen. +- [ ] Der Browser-Installer schreibt `.env` in das Projektwurzelverzeichnis und `storage/installed.lock` in `storage/`. +- [ ] `bin/cron.php` schreibt `storage/cron.lock`. +- [ ] Deshalb muessen Projektwurzel und `storage/` mindestens fuer den Deployment-User, besser auch fuer den Webspace-User, sauber beschreibbar sein. + +## 3. Netcup vorbereiten + +- [ ] Domain oder Subdomain im CCP/WCP anlegen. +- [ ] DNS frueh setzen und Aufloesung pruefen. +- [ ] In Plesk/WCP pro Environment eine eigene Site mit eigenem Document Root anlegen. +- [ ] Document Root fuer jedes Environment auf `.../current/public` setzen. +- [ ] Pro Environment eine eigene MySQL-Datenbank und einen eigenen DB-User anlegen. +- [ ] PHP-Version im WCP fest auf 8.3 oder 8.4 pinnen und nicht auf "System Default" lassen. +- [ ] Dieselbe PHP-Hauptversion fuer Web und CLI verwenden. + +## 4. Secrets und Konfiguration vorbereiten + +Pflichtwerte laut App: + +- [ ] `APP_URL` +- [ ] `APP_ENV` +- [ ] `APP_DEBUG=0` +- [ ] `APP_TIMEZONE` +- [ ] `APP_KEY` +- [ ] `DB_HOST` +- [ ] `DB_PORT` +- [ ] `DB_NAME` +- [ ] `DB_USER` +- [ ] `DB_PASS` +- [ ] `RFID_SHARED_SECRET` + +Empfehlung: + +- [ ] `staging` und `production` nie dieselben Secrets oder dieselbe DB teilen. +- [ ] Admin-Zugang fuer die Plattform separat dokumentieren und im Passwortsafe ablegen. +- [ ] Wenn der Browser-Installer verwendet wird: danach `.env` sichern und offsite ablegen. +- [ ] Wenn `.env` manuell gepflegt wird: `.env` vor dem ersten Deploy lokal erzeugen und erst dann hochladen. + +## 5. Erstes Staging-Deployment + +- [ ] Lokal oder in CI `scripts/build-release.sh` ausfuehren. +- [ ] Release-Artefakt sicher ablegen. Es ist Teil des Rollback-Pfads. +- [ ] Artefakt per FTPES oder SFTP nach Netcup hochladen. +- [ ] Paket in den festen Environment-Pfad entpacken. +- [ ] Pruefen, dass `.env`, `storage/uploads`, `storage/logs` und `storage/cache` nicht versehentlich ueberschrieben oder geloescht wurden. + Das Build-Skript schliesst diese Pfade aus dem Release aus. +- [ ] Falls der Browser-Installer genutzt wird: `/install` nur auf `staging` einmal durchlaufen. +- [ ] Falls manuell installiert wird: `.env` hochladen und danach + `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/migrate.php` + oder die zu eurer PHP-Version passende Binary ausfuehren. +- [ ] Pruefen, dass `storage/installed.lock` angelegt wurde. + +## 6. Staging-Smoketest vor Production + +- [ ] Startseite laden. +- [ ] `/admin/login` erfolgreich testen. +- [ ] Einen Test-Mandanten anlegen. +- [ ] Tenant-Login pruefen. +- [ ] Eine Testbuchung und eine Test-Einzahlung anlegen. +- [ ] `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/healthcheck.php` ausfuehren und JSON pruefen. +- [ ] `/usr/local/php83/bin/php /apps/kaffeekasse-stage/current/bin/cron.php` manuell ausfuehren. +- [ ] Pruefen, dass `cron.lock` nach dem Lauf wieder verschwindet. + +## 7. SSL und HTTPS + +- [ ] Erst SSL ausrollen, wenn DNS sauber auf Netcup zeigt. +- [ ] Im WCP fuer jede produktive Domain ein Let's-Encrypt-Zertifikat ausstellen. +- [ ] `www` nur dann mit absichern, wenn `www` auch wirklich genutzt werden soll. +- [ ] Fuer den ersten Go-Live kein Wildcard-Zertifikat verwenden, wenn es nicht zwingend noetig ist. + Bei Netcup werden Wildcard-Zertifikate nicht automatisch erneuert. +- [ ] HTTPS fuer die produktive Domain erzwingen. +- [ ] Nach Aktivierung pruefen, dass alle Logins und Formulare nur noch ueber HTTPS laufen. +- [ ] Session-Cookies unter HTTPS pruefen, weil `secure` in der App vom HTTPS-Kontext abhaengt. + +## 8. Backup-Strategie produktionsreif machen + +Minimum: + +- [ ] Taegliches DB-Backup einrichten. +- [ ] Vor jedem Release ein frisches manuelles DB-Backup ziehen. +- [ ] `.env` offsite sichern. +- [ ] `storage/uploads` offsite sichern. +- [ ] Letztes stabiles Release-Artefakt offsite sichern. + +Netcup-spezifisch: + +- [ ] Falls euer Tarif den Backup Manager anbietet: wiederkehrendes Backup in WCP aktivieren. +- [ ] Backups regelmaessig herunterladen oder an einen zweiten Ort kopieren. +- [ ] Backup Manager nicht als einzigen Disaster-Recovery-Pfad betrachten. + Netcup dokumentiert, dass diese Backups nur auf demselben Hosting wiederhergestellt werden sollen. + +## 9. Cron sauber einrichten + +- [ ] In WCP eine geplante Aufgabe fuer `bin/cron.php` alle 5 Minuten anlegen. +- [ ] Dieselbe PHP-Version verwenden wie fuer die Website. +- [ ] Den Task vor dem Speichern mit "Run Now" testen. +- [ ] Wenn WCP auf eurem Tarif mit chroot oder relativen Pfaden zickt: den final funktionierenden Befehl direkt dokumentieren. +- [ ] Eine zweite geplante Aufgabe fuer `bin/healthcheck.php` einrichten, mindestens stuendlich oder taeglich. +- [ ] Task-Ausgaben in eine Mail oder Logdatei laufen lassen, statt sie still zu verwerfen. + +Wichtige Einschraenkung dieses Repos: + +- [ ] `bin/healthcheck.php` liefert JSON, setzt aber bei DB-Problemen derzeit keinen expliziten Exit-Code ungleich 0. +- [ ] Fuer Alarmierung deshalb nicht nur auf "Errors only" bei Scheduled Tasks vertrauen. +- [ ] Zusaetzlich einen externen HTTPS-Uptime-Check auf Startseite oder Login-Seite einrichten. + +## 10. Monitoring-Minimum fuer den Start + +- [ ] Externes Uptime-Monitoring auf die produktive HTTPS-URL aktivieren. +- [ ] Plesk-/PHP-Error-Logs in die Regelbetriebsroutine aufnehmen. +- [ ] Nach dem Go-Live taeglich Audit-Ereignisse fuer fehlgeschlagene Logins und Access-Denied pruefen. +- [ ] Wachstum der Tabellen `consumption_events`, `ledger_entries` und `audit_events` beobachten. +- [ ] Offene RFID-Ereignisse aus dem Cron-Output beobachten, falls RFID pilotiert wird. +- [ ] Einen klaren Empfaenger fuer Alarmmails hinterlegen. + +## 11. Release-Prozess fuer echte Produktion festlegen + +Empfohlener erster Produktionsprozess auf Netcup Webspace: + +- [ ] Aenderungen auf `staging` komplett durchtesten. +- [ ] Release-Artefakt mit Zeitstempel bauen. +- [ ] Direkt vor dem Produktionsdeploy DB-Backup erstellen. +- [ ] `.env` und persistente `storage/`-Inhalte zusatzlich sichern. +- [ ] Release nach `production` hochladen. +- [ ] `bin/migrate.php` ausfuehren. +- [ ] `bin/healthcheck.php` ausfuehren. +- [ ] Admin-Login, Tenant-Login und Testbuchung sofort pruefen. +- [ ] Den naechsten automatischen Cron-Lauf beobachten. +- [ ] Erst danach das Release als "stabil" markieren. + +Wichtige Einschraenkung dieses Repos: + +- [ ] `bin/migrate.php` spielt nur `database/schema.sql` erneut ein. +- [ ] Das aktuelle `schema.sql` arbeitet mit `CREATE TABLE IF NOT EXISTS` und ist damit fuer Erstinstallation geeignet, aber kein vollwertiges inkrementelles Migrationssystem. +- [ ] Vor dem ersten Release mit DB-Schema-Aenderungen eine klare Migrationskonvention festlegen, zum Beispiel versionierte SQL-Dateien plus Runbook-Schritt. + +## 12. Fallback und Restore vorher ueben + +Rollback fuer einen fehlgeschlagenen Release: + +- [ ] Letztes stabiles Release-Artefakt erneut deployen. +- [ ] Wenn noetig DB-Backup vom Start des Releases einspielen. +- [ ] `.env` und `storage/uploads` wiederherstellen. +- [ ] `bin/healthcheck.php` ausfuehren. +- [ ] Admin-Login, Tenant-Login und Testbuchung pruefen. + +Restore fuer echten Ausfall: + +- [ ] Zielreihenfolge dokumentieren: Code, `.env`, Uploads, DB, Healthcheck, Smoke-Test. +- [ ] Restore nicht nur theoretisch planen, sondern einmal auf `staging` ueben. +- [ ] Ziel-RTO und Ziel-RPO festlegen, auch wenn sie anfangs noch pragmatisch sind. +- [ ] Ansprechpartner und Zugangsdaten fuer Restore ausserhalb des Repos dokumentieren. + +## 13. Finale Go-Live-Freigabe + +Nur live schalten, wenn alles abgehakt ist: + +- [ ] Production-Domain zeigt auf Netcup und loest korrekt auf. +- [ ] SSL ist gueltig und HTTPS wird erzwungen. +- [ ] `public/` ist einziger Webroot. +- [ ] `.env`, Backups, Dumps und `.git` sind nicht oeffentlich erreichbar. +- [ ] DB-Backup von heute existiert. +- [ ] Cron laeuft erfolgreich. +- [ ] Externes Monitoring prueft die Seite. +- [ ] Admin-Login und ein Test-Tenant funktionieren. +- [ ] Restore wurde mindestens einmal auf `staging` geprobt. +- [ ] Es gibt eine bewusste Entscheidung, ob offene Registrierung bereits verantwortbar ist. + +## Quellen + +- Repo-intern: + [DEPLOY.md](/config/workspace/kaffeeliste-neustart/DEPLOY.md), + [RUNBOOK.md](/config/workspace/kaffeeliste-neustart/RUNBOOK.md), + [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md), + [app/bootstrap.php](/config/workspace/kaffeeliste-neustart/app/bootstrap.php), + [config/app.php](/config/workspace/kaffeeliste-neustart/config/app.php), + [app/Services/SetupService.php](/config/workspace/kaffeeliste-neustart/app/Services/SetupService.php), + [bin/migrate.php](/config/workspace/kaffeeliste-neustart/bin/migrate.php), + [bin/cron.php](/config/workspace/kaffeeliste-neustart/bin/cron.php), + [bin/healthcheck.php](/config/workspace/kaffeeliste-neustart/bin/healthcheck.php), + [scripts/build-release.sh](/config/workspace/kaffeeliste-neustart/scripts/build-release.sh) +- Offizielle Doku: + https://www.netcup.com/en/helpcenter/documentation/web-hosting/php-shell + https://www.netcup.com/en/helpcenter/documentation/web-hosting/scheduled-tasks + https://www.netcup.com/en/helpcenter/documentation/web-hosting/enabling-ssl-tls + https://www.netcup.com/en/helpcenter/documentation/web-hosting/backup-manager + https://docs.plesk.com/en-US/obsidian/customer-guide/scheduling-tasks.65207/ + https://www.plesk.com/kb/docs/managing-web-hosting-changing-the-document-root-directory/ diff --git a/docs/go-to-market-30-60-90.md b/docs/go-to-market-30-60-90.md new file mode 100644 index 0000000..1a0e368 --- /dev/null +++ b/docs/go-to-market-30-60-90.md @@ -0,0 +1,394 @@ +# Go-to-Market 30-60-90 Tage + +Stand: 2026-06-15 + +## Kurzfazit + +Die naechsten 90 Tage sollten nicht mit breitem Marketing, sondern mit einem +scharfen Beachhead beginnen: + +- Primaere Zielgruppe: Teams, Vereine und kleine Community-Standorte mit 10-50 + aktiven Nutzern, die heute Papier, Excel oder lose Strichlisten verwenden. +- Sekundaere Zielgruppe: Coworking-Standorte nur als sales-assistierter Pilot, + nicht als Hauptbotschaft auf der allgemeinen Startseite. +- Kernversprechen: `Papier bleibt moeglich. Abrechnung wird sauber. RFID kommt, + wenn es sich wirklich lohnt.` + +Das Ziel bis Tag 90 ist nicht Reichweite, sondern belastbares Marktfeedback: + +- 10+ Discovery-Gespraeche +- 3-5 aktive Pilotkunden +- 2 zahlungsbereite Referenzen oder Verlangerungen +- ein belastbarer Preiskorridor +- ein sauber messbarer Lead-zu-Aktivierungs-Funnel + +## Repo-basierte Diagnose + +Das Produkt ist fuer fruehe Pilotkunden weiter als die Vermarktung. + +- Die Startseite erklaert das System technisch stark, aber den operativen Nutzen + noch zu wenig. In [resources/views/home/index.php](../resources/views/home/index.php) + stehen aktuell `PHP/MySQL`, `Netcup-Webspace` und `RFID-Roadmap` sehr weit + vorne. +- Die CTA-Struktur ist zu hart fuer Erstkontakt. Auf der Startseite gibt es + aktuell primaer `Mandant starten`, aber keinen sichtbaren `Demo ansehen`, + `Pilot anfragen` oder `Kontakt`. +- Die Paketsektion nennt Pakete, aber keine oeffentlich validierte Preislogik, + keine Mitgliedergrenzen und keine Testzusage. +- Tracking ist in [docs/marketing-ops.md](./marketing-ops.md) sauber gedacht, + aber im Produkt noch nicht sichtbar umgesetzt. +- Gleichzeitig ist das Produkt onboardingfaehig: + [app/Services/TenantRegistrationService.php](../app/Services/TenantRegistrationService.php) + legt beim Signup bereits Owner, Standardprodukte, Quellen und Grundeinstellungen + an. Das ist eine gute Basis fuer Demo, Trial und Pilot. + +## Positionierung + +### Empfehlung + +Nicht `Kaffeekasse fuer alle` vermarkten. Stattdessen ein klares Einstiegsproblem +verkaufen: + +- `Wir ersetzen nicht eure Gewohnheit auf einen Schlag.` +- `Wir machen aus Papier, Nachtrag und Selbstbedienung eine saubere Abrechnung.` +- `Wenn ihr spaeter RFID wollt, muesst ihr nicht neu anfangen.` + +### Empfohlene Marktansprache + +- Primaer: Vereinsvorstand, Getraenkewart, Office Manager, Team-Admin, + Community Manager, die heute Fehler, Rueckfragen und fehlende Einzahlungen + manuell klaeren. +- Sekundaer: Coworking-Betreiber mit Community-Kueche oder Honesty Bar. Hier + ist das Produkt eher eine schlanke Beverage-Operations-Loesung als eine + komplette Coworking-Plattform. + +### Messaging-Hierarchie + +- Hauptclaim: `Die Kaffeekasse fuer Teams und Vereine, die noch nicht ganz auf + Papier verzichten wollen.` +- Unterclaim: `Digitale Buchungen, Papier-Nacherfassung und spaeter RFID - alles + in einer nachvollziehbaren Abrechnung.` +- Beweis 1: `Mitglieder, Produkte, Einzahlungen und Salden in einem Ablauf` +- Beweis 2: `Sofort startklar im Browser, Tablet oder Kiosk` +- Beweis 3: `RFID nicht heute noetig, aber morgen anschliessbar` + +### Was nicht in die Hero-Message gehoert + +- `PHP/MySQL` +- `Netcup` +- `mandantenfaehig` +- `Ledger` + +Diese Begriffe sind sinnvoll fuer Betrieb, Doku und Technikvertrauen, aber nicht +fuer den ersten Kaufimpuls. + +## Demo-Setup + +### Warum das jetzt Prioritaet hat + +Aktuelle Wettbewerber kombinieren sehr oft Demo oder Trial mit sehr einfacher +Preislogik. Stand 2026-06-15: + +- Getraenkewart kommuniziert eine sofortige Demo und eine kostenlose kleine + Einstiegsstufe. +- Clubfridge stellt ein Testsystem und 30 Tage Gratis-Test in den Vordergrund. +- Cobot kombiniert `Try it for free` und `Schedule a demo`. + +Die Lehre daraus: Frueher Markt will erst sehen, dann glauben, dann kaufen. + +### Empfohlenes Demo-Setup + +- Ein `Team-Demo` mit 12 Mitgliedern, 4 Produkten, 30 Buchungen und 3 + Einzahlungen +- Ein `Verein-Demo` mit Papierliste als Entwurf plus verbuchter Papierliste +- Ein `Coworking-Demo` mit vorbereiteten RFID-Geraeten, Tags und Events, aber + ohne die RFID-Roadmap als Hauptverkaufspunkt zu missbrauchen + +### Empfohlene Demo-Artefakte + +- Oeffentliche Browser-Demo mit taeglichem oder stuendlichem Reset +- 7-Minuten-Live-Demo-Skript +- 90-Sekunden-Klickpfad fuer die Startseite: + `Mitglied anlegen -> Buchung erfassen -> Einzahlung buchen -> Papierliste + verbuchen` +- Einseitiges Pilot-PDF: + `Was wird in 14 Tagen gemeinsam getestet?` + +### Demo-Story + +- Problem: `Striche fehlen, Spaetzahler fehlen, niemand will am Monatsende + rechnen` +- Heute: `Papier bleibt erlaubt` +- Morgen: `Digitale Selbstbuchung spart Rueckfragen` +- Spaeter: `RFID ist ein Upgrade, kein Neuanfang` + +## Landingpage-Verbesserungen + +### Sofort priorisieren + +- Hero von technischer auf operative Sprache drehen +- Primaere CTA auf `Demo ansehen` oder `Pilot anfragen` +- Sekundaere CTA auf `Kostenlos testen` +- Einen Abschnitt `Fuer wen ist das?` mit drei Kacheln: + `Team`, `Verein`, `Coworking-Kueche` +- Einen Abschnitt `So startet ihr in 1 Nachmittag` +- Einen Abschnitt `Papier heute, digital morgen, RFID spaeter` + +### Danach + +- Preissektion mit realen Stufen statt nur Paketnamen +- FAQ zu `Brauchen wir App-Downloads?`, `Kann Papier bleiben?`, `Was kostet + RFID spaeter?`, `Wie schnell sind wir live?` +- Vertrauenselemente: + `Hosting in DE/EU`, `Datenschutz`, `keine Kreditkarte fuer Pilot`, `persoenliche + Begleitung` +- Spater: Logos, Zitate und Mini-Case-Studies von echten Piloten + +### Konkrete Copy-Richtung fuer die Hero + +- Headline: `Die Kaffeekasse ohne Zettelchaos` +- Subline: `Erfasst Kaffee, Getraenke und Einzahlungen digital, fuehrt + Papierlisten weiter und haltet Salden sauber nachvollziehbar - fuer Teams, + Vereine und Community-Standorte.` +- CTA 1: `Demo ansehen` +- CTA 2: `Pilot starten` + +## Lead-Funnel + +### Zielbild + +Nicht direkt von `Landing Visit` zu `voller Self-Service-Registrierung` +optimieren. Dazwischen braucht es eine niedrigere Huerde. + +Empfohlener Funnel: + +1. Landing Visit +2. CTA Klick auf `Demo ansehen` oder `Pilot anfragen` +3. Lead erfasst +4. Demo angesehen oder Termin gebucht +5. Pilot zugesagt +6. Tenant angelegt +7. Erste Buchung innerhalb von 24 Stunden +8. Erste Einzahlung oder erste Papierliste innerhalb von 7 Tagen +9. Verlaengerung oder Upgrade + +### Minimaler Funnel fuer die ersten 90 Tage + +- Kanal 1: Warmes Netzwerk +- Kanal 2: Direktansprache lokaler Vereine, Coworking-Spaces, Bueros, + Feuerwehren, Gemeinschaftsraeume +- Kanal 3: 2-3 kurze Content-Stuecke mit konkretem Problemfokus: + `Excel vs. Kaffeeliste`, `Papierliste sauber nacherfassen`, `Wann lohnt sich + RFID wirklich?` + +### Tracking, das sofort noetig ist + +Die Eventnamen existieren schon in [docs/marketing-ops.md](./marketing-ops.md). +Fuer die ersten 90 Tage reicht: + +- `landing_view` +- `demo_clicked` +- `pilot_requested` +- `register_started` +- `tenant_registered` +- `first_consumption_recorded` +- `first_payment_recorded` +- `paper_sheet_created` + +### CRM-Minimum + +Noch kein grosses CRM-Projekt starten. Eine einfache Tabelle oder ein sehr +schlankes CRM reicht mit diesen Feldern: + +- Organisation +- Segment +- Ansprechpartner +- Problem heute +- Anzahl Nutzer +- Heute Papier, digital oder gemischt +- Interesse an RFID spaeter: ja/nein +- Status: `neu`, `demo`, `pilot`, `aktiv`, `verloren` +- Grund fuer Verlust + +## Pricing-Validierung + +### Marktbeobachtung am 2026-06-15 + +- Getraenkewart kommuniziert eine einfache Preislogik von `20 Cent pro Mitglied + und Monat`, mit `0 EUR` fuer sehr kleine Teams und `5 EUR / Monat` fuer 25 + Mitglieder. +- selbstbedienBar zeigt eine kostenlose Einstiegsstufe mit bis zu 5 Usern. +- Clubfridge bewirbt 30 Tage Gratis-Test und argumentiert ueber geringe + laufende Kosten und klare Einsparung von Verwaltungsaufwand. +- Cobot liegt als Coworking-Management-Plattform deutlich hoeher und eignet sich + eher als Referenz fuer den sales-assistierten Coworking-Pfad als fuer die + breite Preiserwartung im Vereins- und Teamsegment. + +### Schlussfolgerung + +Der Team-/Vereinsmarkt ist preissensibel. Eine `normale B2B-SaaS-Optik` mit +hohem Einstiegspreis wird dort frueh bremsen. Gleichzeitig ist Coworking als +Segment eher bereit, fuer operative Zuverlaessigkeit und spaetere Integrationen +mehr zu zahlen. + +### Validierungsansatz + +Nicht sofort eine endgueltige Preisarchitektur festschreiben. In den ersten +Piloten zwei Preislogiken testen: + +- Variante A: flache Standortpreise + - Beispiel: `9 EUR`, `19 EUR`, `39 EUR` +- Variante B: faire Mitgliederlogik + - Beispiel: `0,20 EUR pro aktivem Mitglied/Monat` mit Mindestpreis + +### Was oeffentlich sichtbar sein sollte + +- 30 Tage Pilot oder Testphase +- Kein Kreditkarten-Zwang am Anfang +- RFID nicht oeffentlich festpreisen, sondern `auf Anfrage / Pilot` +- Klarer Satz: `Fuer groessere Standorte oder RFID-Szenarien sprechen wir kurz + direkt miteinander` + +### Was in jedem Gespraech abgefragt werden sollte + +- Wie viele aktive Nutzer gibt es wirklich? +- Wie viel Verwaltungszeit spart das pro Monat? +- Ist eher `pro Mitglied` oder `pro Standort` gefuehlt fair? +- Wuerde man ohne RFID schon zahlen? +- Ist Papier-Nacherfassung kaufentscheidend oder nur hilfreich? + +## Erster Pilotkundenprozess + +### Idealer Pilotkunde + +- 10-50 aktive Nutzer +- klares heutiges Problem mit Papier, Excel oder Nachbuchungen +- ein verantwortlicher Owner +- Bereitschaft, 14 Tage aktiv zu testen +- Bereitschaft fuer 2 Feedback-Termine + +### Pilotablauf + +1. 20-Minuten-Qualifizierung +2. 30-Minuten-Demo entlang des echten Prozesses +3. Pilotzusage mit klarem Testziel +4. Tenant anlegen und Owner live einrichten +5. Binnen 24 Stunden erste echte Buchung +6. Tag 7: Check-in zu Aktivierung, Rueckfragen, Widerstaenden +7. Tag 14 oder 21: Review, Preisgespraech, Verlaengerung oder Abschluss + +### Pilot-Erfolgskriterien + +- Owner ist aktiv +- mindestens 5-10 Mitglieder angelegt +- mindestens 20 echte Buchungen +- mindestens 1 Einzahlung oder 1 Papierlisten-Posting +- kein schwerer Vertrauensbruch in Salden oder Nachvollziehbarkeit +- klare Aussage: `Wuerden wir dafuer zahlen?` + +### Pilotangebot + +- `Begleiteter Pilot fuer 14 oder 30 Tage` +- `Einrichtung gemeinsam in 30 Minuten` +- `Keine Datenmigration noetig` +- `Feedback gegen guenstige Early-Adopter-Konditionen` + +## Priorisierte 30-60-90-Tage-Empfehlung + +## Tage 1-30 + +Ziel: Message klaeren, Demo faehig machen, erste Gespraeche starten. + +- Einen Beachhead final auswaehlen: + `Teams/Vereine mit Hybrid-Prozess` sollte aktuell gewinnen. +- Startseite sprachlich neu ausrichten und technische Begriffe aus der Hero nach + unten verschieben. +- Demo-Umgebung mit 2-3 vorbereiteten Tenants aufsetzen. +- CTA-Struktur erweitern: + `Demo ansehen`, `Pilot anfragen`, `Kostenlos testen` +- Minimales Tracking fuer Landing, Demo, Signup und Aktivierung einbauen. +- Outreach-Liste mit 50 passenden Erstkontakten aufbauen, zuerst warm, dann + lokal-kalt. +- 10 Discovery-Gespraeche fuehren. +- 3 Pilotkunden anbahnen. + +Messbar bis Tag 30: + +- 10 Gespraeche +- 3 qualifizierte Pilotkandidaten +- 1 funktionierende Browser-Demo +- 1 Landingpage-Version mit klarer Botschaft + +## Tage 31-60 + +Ziel: Piloten aktivieren, Preissignale einsammeln, erste Beweise erzeugen. + +- 2-3 Piloten live nehmen. +- Zwei Pricing-Frames in Gespraechen testen: + `pro Standort` vs. `pro Mitglied` +- Erste Landingpage-Variante nach Segment pruefen: + `Verein/Team` gegen `Coworking` +- Pilot-Onboarding standardisieren: + Checkliste, Demo-Skript, Follow-up-Mail, Tag-7-Review +- Ein erstes Mini-Case-Study-Format bauen: + Problem, Einfuehrung, erste Ergebnisse, Zitat +- Die haeufigsten Einwaende und Kaufgruende dokumentieren. + +Messbar bis Tag 60: + +- 2-3 aktive Piloten +- 70% der Piloten mit erster Buchung in 24 Stunden +- 2 belastbare Preisreaktionen pro Segment +- 1-2 verwertbare Kundenstimmen + +## Tage 61-90 + +Ziel: Gewinner schaerfen, erste bezahlte Wiederholbarkeit bauen. + +- Gewinner-Positionierung oeffentlich festziehen. +- Eine oeffentliche Preislogik veroeffentlichen, aber RFID weiter als + gesonderten Sales-Pfad lassen. +- Referenzen und Vertrauenselemente auf die Startseite bringen. +- Den Pilotprozess in einen wiederholbaren `Demo -> Pilot -> Paid` Ablauf + ueberfuehren. +- 2 Piloten in bezahlte Kunden oder verlaengerte Nutzung umwandeln. +- Entscheiden, ob Coworking eine eigene Unterseite und eigene Sales-Story + verdient oder vorerst nur Upside bleibt. + +Messbar bis Tag 90: + +- 3-5 aktive Pilotkunden insgesamt +- 2 zahlungsbereite oder zahlende Referenzkunden +- 1 veroeffentlichte Preislogik +- klarer Entscheid zur Rolle von Coworking im GTM + +## Klare Priorisierung + +Wenn nur wenig Kapazitaet da ist, dann in genau dieser Reihenfolge: + +1. Positionierung fuer einen Beachhead +2. Demo und Pilotprozess +3. Landingpage-CTA und Tracking +4. Pricing-Validierung in echten Gespraechen +5. Erst danach breitere Content- oder Paid-Massnahmen + +## Was ich explizit nicht priorisieren wuerde + +- Paid Ads vor dem ersten wiederholbaren Pilotprozess +- eine zu breite Positionierung fuer Teams, Vereine und Coworking gleichzeitig +- oeffentliche RFID-Versprechen, die noch keine echte Kaufhuerde geloest haben +- grosse CRM- oder Marketing-Automation-Projekte vor den ersten 3-5 Piloten + +## Externe Referenzen + +Stand 2026-06-15: + +- Getraenkewart Startseite: https://getraenkewart.com/ +- Getraenkewart Preise: https://getraenkewart.com/preise/ +- Getraenkewart FAQ: https://getraenkewart.com/faq +- Clubfridge Startseite: https://clubfridge.com/ +- Clubfridge Testsystem / Testen: https://clubfridge.com/clubfridge-testen/ +- Clubfridge RFID-Artikel: https://clubfridge.com/rfid-kuehlschrank-im-vereinsheim-einrichten-so-funktioniert-die-digitale-getraenkekasse/ +- selbstbedienBar Preise: https://www.selbstbedienbar.de/preise/ +- Cobot Pricing: https://www.cobot.me/en/pricing +- Cobot Startseite: https://www.cobot.me/en/ diff --git a/docs/next-steps-roadmap.md b/docs/next-steps-roadmap.md new file mode 100644 index 0000000..d48bf59 --- /dev/null +++ b/docs/next-steps-roadmap.md @@ -0,0 +1,149 @@ +# Naechste Schritte Roadmap + +Stand: 2026-06-15 + +Diese Roadmap verdichtet die Empfehlungen mehrerer Fach-Agenten fuer Produkt, +Sicherheit, Betrieb, QA und Go-to-Market in einen konkreten Fahrplan fuer das +hochgeladene Repository. + +## Leitplanke + +Der erste echte Einsatz soll **kein breiter oeffentlicher SaaS-Launch** sein, +sondern ein **kontrollierter Pilot** mit 1-2 Mandanten. + +Vor Day 1 gewinnt nicht die groesste Funktionsbreite, sondern der Hybrid-Kern: + +- Mitglieder +- Produkte und Preise +- digitale Buchungen +- Einzahlungen +- Papierlisten-Nacherfassung +- saubere Salden und Auditierbarkeit + +RFID bleibt fuer den ersten Produktivstart vorbereitet, aber nicht +automatisiert. + +## Phase 1: Vor dem Pilot hart absichern + +Diese Punkte sollten vor einem echten Testkunden produktionsnah erledigt sein. + +### Muss + +- serverseitige Ownership-Pruefung fuer alle `tenant_id`-bezogenen IDs + bei Buchungen, Einzahlungen, Papierlisten und RFID +- Self-Service-Rollenmodell schaerfen: + `member` soll nur fuer sich selbst buchen und nur eigene Daten sehen +- PINs nicht mehr im Klartext speichern oder anzeigen +- Rate-Limits fuer Login und Registrierung +- Passwort-Reset fuer Owner und Mitglieder +- Registrierung entweder als geschlossenen Pilot betreiben oder erst nach + Mail-Verifikation oeffnen +- Korrektur-/Storno-Flow fuer Fehlbuchungen, Einzahlungen und Papierlisten +- Mitglieder-Saldenliste und Buchungshistorie pro Mitglied +- CSV-Exporte fuer Salden und Buchungen +- RFID-Intake fuer Day 1 deaktivieren oder explizit haerten + +### Soll + +- inkrementellen Migrationspfad einfuehren statt reinem `schema.sql`-Replay +- Healthcheck um klaren Monitoring-Pfad erweitern +- Audit-Retention und datensparsame Audit-Metadaten definieren +- Netcup-Hardening technisch erzwingen: + HTTPS, Header, Session-Secure-Handling, Installer-Lockdown + +### Abnahme + +- ein neuer Tenant kann ohne DB-Eingriff eingerichtet werden +- ein verlorenes Passwort ist ohne manuelle SQL-Hilfe loesbar +- eine Fehlbuchung laesst sich im Produkt sauber korrigieren +- Salden in UI, Export und DB stimmen ueberein +- Cross-Tenant-Zugriffe sind negativ getestet + +## Phase 2: Staging, Go-Live-Readiness und Pilot-UAT + +### Betrieb + +- Staging-Umgebung auf Netcup anlegen +- produktionsnahes Deployment durchspielen +- SSL, Cron, Healthcheck und Backup auf Staging pruefen +- Restore einmal wirklich testen +- Release- und Rollback-Ablauf dokumentiert ueben + +### QA + +- Smoke-Tests fuer Installation, Admin-Login, Tenant-Registrierung, + Owner-Login, Mitglieder, Produkte, Buchungen, Einzahlungen und Papierlisten +- DB-Stichproben fuer `consumption_events`, `ledger_entries`, `ledger_lines` +- Rechte- und Mandantentrennung negativ testen +- RFID nur als optionalen Inbox-Test behandeln + +### Pilotkundenprozess + +- 1 kleiner digitaler Pilotmandant +- 1 Hybrid-Pilotmandant mit Papierliste +- 5-7 Tage UAT mit echten oder realistisch simulierten Buchungen +- Freigabe durch Owner und Admin des Piloten + +### Abnahme + +- alle Smoke-Tests bestanden +- keine kritischen Fehler offen +- Backup, Cron und Restore nachweislich geprueft +- mindestens 10 Buchungen, 2 Einzahlungen und 1 Papierlisten-Posting pro Pilot + +## Phase 3: 30-60-90 Tage nach dem Upload + +## 30 Tage + +- Beachhead-Segment festziehen: + Teams und Vereine mit Hybrid-Prozess +- Landingpage verkaufsnaher schaerfen: + Problem, Demo, Pilot statt Technik zuerst +- Demo-Setup bauen: + Team-Demo, Vereins-Demo, 7-Minuten-Skript +- 10+ Discovery-Gespraeche fuehren +- 3 Pilotkunden anbahnen + +## 60 Tage + +- 2-3 Piloten aktiv im System +- Preisvalidierung zwischen Standortpreis und Mitgliederpreis +- Tracking fuer `demo_clicked`, `pilot_requested`, + `tenant_registered`, `first_consumption_recorded`, + `first_payment_recorded`, `paper_sheet_created` +- wiederholbaren `Demo -> Pilot -> Aktiv` Ablauf aufbauen + +## 90 Tage + +- 2 zahlungsbereite Referenzen oder Verlaengerungen +- erste oeffentliche Preislogik festziehen +- Landingpage mit Vertrauenselementen und FAQ erweitern +- Pilot-Feedback in priorisierte Produktarbeit ueberfuehrt + +## Bewusst spaeter + +Diese Punkte sind sinnvoll, aber nicht noetig fuer den ersten kontrollierten +Pilot: + +- MFA fuer Owner/Admin +- Einladungs-Workflow +- RFID-Autobuchung und Event-Regeln +- White-Labeling +- automatisches Billing +- groessere CRM- oder Marketing-Automation + +## Sofort als naechste 5 Arbeitspakete + +1. Ownership-Checks, Rollenmodell und PIN-Hardening umsetzen. +2. Passwort-Reset, Rate-Limits und Pilot-Registrierungsmodus bauen. +3. Korrekturen/Stornos, Saldenansichten und CSV-Exporte ergaenzen. +4. Staging auf Netcup aufsetzen und die Go-Live-Checkliste durchgehen. +5. Demo-Setup plus 1-2 Pilotmandanten vorbereiten. + +## Verwandte Dokumente + +- [docs/go-live-checklist-netcup.md](/config/workspace/kaffeeliste-neustart/docs/go-live-checklist-netcup.md) +- [docs/go-to-market-30-60-90.md](/config/workspace/kaffeeliste-neustart/docs/go-to-market-30-60-90.md) +- [docs/product-strategy.md](/config/workspace/kaffeeliste-neustart/docs/product-strategy.md) +- [docs/marketing-ops.md](/config/workspace/kaffeeliste-neustart/docs/marketing-ops.md) +- [docs/production-blueprint.md](/config/workspace/kaffeeliste-neustart/docs/production-blueprint.md)