Freie Stunden einstellen, buchen, einlösen, abrechnen.
Ein Kreislauf, ein System.
rezuki-flow trägt den Beratungskreislauf von ReZuKi: Partnerinnen pflegen ihre Verfügbarkeiten, Mitarbeitende der Kundenunternehmen buchen daraus mit einem Einmalcode, jede durchgeführte Stunde wird zur Abrechnungsgrundlage. Eigenständige Anwendung mit eigener Datenbank, neben der ReZuKi-Plattform, ohne Durchgriff auf sie.
Verfügbarkeiten statt Kalender-Sync
Persönliches Konto, Profil und Leistungen. Freie Stunden werden konkret eingetragen; nicht eingetragene Zeit ist nicht buchbar. Jede Buchung kommt als ICS-Kopie in den eigenen Kalender.
Buchen mit Code, ohne Namen
Zugang über das Passwort des Unternehmens, Auswahl nach Sprache, Schwerpunkt und Format, Buchung eines freien Termins mit einem Einmalcode aus dem Kontingent. Kein Klartext zum Anlass, nirgends.
Kontingente, Rechnungen, Überblick
Partnerinnen freischalten, Leistungskatalog pflegen, Kontingente führen. Monatsrechnung an Kunden als Entwurf, Rechnungsvorlage für Partnerinnen, Abgleich eingegangener Rechnungen. Freigabe immer durch einen Menschen.
Das Vertraulichkeitsmodell
Die Aufteilung des Wissens ist die zentrale Zusage an die Mitarbeitenden. Sie ist Architekturvorgabe: keine Ansicht, kein Export, keine Auswertung darf sie unterlaufen.
Kundenunternehmen / HR
Kauft das Kontingent, verteilt die Codes.
kennt Code und Person
kennt nicht, ob und bei wem ein Code eingelöst wurde
ReZuKi
Betreibt die Plattform, führt Kontingent und Abrechnung.
kennt Code und Partnerin
kennt nicht, welche Person hinter einem Code steht
Partnerin
Führt die Beratung durch, unterliegt der Schweigepflicht.
kennt Code und Person
die einzige Stelle, an der beides zusammenkommt
Zwei Stufen, ein Datenbestand
Die Partnerseite ist der kritische Pfad. Die Nutzerseite folgt zum Marktstart, die Abrechnung darf zu Beginn manuell laufen.
Partnerseite
- P1 Login, Passwort-Zurücksetzung per E-Mail
- P2 Profil mit Freigabe durch ReZuKi
- P3 Leistungen: Sprache, Schwerpunkt, Format
- P4 Verfügbarkeiten eintragen, ändern, zurückziehen
- P5 Terminübersicht mit Status
- P6 Absage mit Rückbuchung des Codes
- P7 Honorarsatz einsehbar
- P8 Verwaltungssicht für ReZuKi
Nutzerseite und Abrechnung
- N1 Anmeldung mit kundenweitem Passwort
- N2 Gefilterte Partnerauswahl
- N3 Buchung mit Einmalcode, Doppelbuchung ausgeschlossen
- N4 Bestätigung an beide Seiten mit ICS und Videolink
- N5 Wiederabruf mit Code und PIN
- N6 Absage bis zur Frist
- N7 Durchführung bestätigen, Auslöser der Abrechnung
- N8 bis N12 Kontingentprüfung, Dashboard, Rechnungen, Abgleich
Kalender, Video, Schutz
- K1 bis K3 ICS mit stabiler UID, neutraler Inhalt, gleiche Regel für E-Mails
- V1 Videolink je Termin, anbieterunabhängig
- V2 bis V4 Kopplung mit OpenTalk als Ausbau, keine Klarnamen im Raum, Metadaten bleiben bei ReZuKi
- Ü1 bis Ü4 Freigabe statt Sperrung, Vorlauffrist 48 Stunden, wöchentlicher Anstoß, Absageweg
- B1 bis B7 Standort EU, getrennte Anwendung, tägliche Sicherung, Protokolle ohne Inhalte, Löschfristen, Aggregationsgrenze, Betrieb
Zeitplan
Rückwärts geplant von den drei gesetzten Terminen aus dem Lastenheft.
Phase 0 · Entscheiden
Prototyp durchsehen, neun Entscheidungen treffen, Repository und Stack anlegen. Testfenster rezuki-flow.tanagra.cloud steht.
Phase 1 · Partnerseite bauen
P1 bis P8, Datenbank, Protokoll, Mailversand. Wochenweise Stand auf der Testumgebung.
Phase 2 · Prüfen und härten
Testlauf mit Katrin und zwei Partnerinnen, Sicherung und Wiederherstellung, Löschläufe, Überbuchungsschutz.
Statusprüfung
Liegt keine testbare Partnerseite vor (P1 bis P5), stellt ReZuKi auf ein eingekauftes Terminwerkzeug um. Der Umstieg braucht drei Wochen.
Phase 3 · Produktivstellung
Domain scharf, Zugänge für Kohorte 1 (5 bis 8 Partnerinnen), Anleitung, Störungsbereitschaft.
Partnerseite produktiv
Am Tag des digitalen Onboarding-Abschlusses tragen die Partnerinnen ihre freien Zeiten ein.
Phase 4 · Nutzerseite
N1 bis N7, ICS, Videolink. Beginnt, sobald die Partnerseite stabil läuft.
Marktstart
Buchung durch Mitarbeitende der Kundenunternehmen, Bestätigungen, Kontingentführung.
Phase 5 · Abrechnung
N8 bis N12: Kontingentprüfung, Dashboard, Rechnungsentwürfe, Rechnungsabgleich über eine lesende Schnittstelle. Erster automatischer Monatsabschluss Ende Februar.
Phase 6 · Ausbau
OpenTalk-Kopplung, Anbindung des Rechnungswerkzeugs, weitere Kohorten.
Neun Entscheidungen vor dem Bau
01 bis 06 aus Abschnitt 10 des Lastenhefts, 07 bis 09 von unserer Seite. Zu jeder steht im Plan ein Vorschlag.
| Nr. | Frage | Vorschlag in Kurzform | Entscheidet |
|---|---|---|---|
| 01 | Technologie und Architektur | Eigener Stack: Node/Express plus PostgreSQL, statische Seiten aus dem Workspace | Robert, Nils bestätigt |
| 02 | Betrieb ab Januar 2027 | Tanagra betreibt, ReZuKi schaltet selbst frei | Nils, Robert |
| 03 | Rechnungswerkzeug | lexoffice, sevDesk oder easybill prüfen; zum Start PDF-Entwurf aus rezuki-flow | Nils |
| 04 | Wiederabruf absichern | PIN bei erster Einlösung, Wiederabruf mit Code plus PIN | Nils |
| 05 | Videokanal | V1 Linkfeld zum Start, OpenTalk betreut mit AVV als Ausbau | Nils |
| 06 | Rechnungsabgleich N12 | Lesender Endpunkt mit Token, nur Vorgangscode, Partnerin, Zeit, Satzart | Nils, Robert |
| 07 | Standort des Stacks | Eigener Server für Coaching-Daten gemäß Zwei-Server-Beschluss im Vault | Nils, Robert |
| 08 | Domain und Absender | flow.rezuki.de, Mail von termine@rezuki.de über Brevo | Nils |
| 09 | Erinnerungsmail an buchende Person | Freiwillig, nach dem Termin gelöscht, oder ganz verzichten | Nils, Katrin |
So geht es weiter
Prototyp durchklicken
Partnerseite, Nutzerseite und Verwaltung als klickbare Attrappe ohne Backend. Was fehlt oder anders heißen soll, kommt in FEEDBACK.md im Workspace _ReZuKi/rezuki-flow.
Entscheidungen markieren
Die neun Punkte oben im Plan mit übernehmen, ändern oder vertagen versehen. Danach beginnt der Bau der Partnerseite.
Zum PlanKatrin einbeziehen
Vor allem Verfügbarkeiten und Terminübersicht aus Sicht der Partnerpraxis prüfen. Diese Seite und ihre Texte pflegen die Agenten der Box direkt im Workspace.