Development
Kein zweiter Messenger — Kommunikation am Change Request
Rückfragen und Klärungen dort, wo Scope und Bestätigung ohnehin liegen. Warum MEMNO keinen Slack-Ersatz baut — und trotzdem Kommunikation braucht.
„Können wir statt drei nur zwei Logo-Varianten?“ — solche Fragen landen heute in WhatsApp oder E-Mail. Später suchst du den Thread, in dem der Kunde zugestimmt hat. MEMNO soll das am Nachtrag lösen, nicht in einem generellen Chat.
Scope
Thread pro Change Request. Owner ↔ Client. E-Mail-Digest bei neuen Nachrichten. System-Events („Kunde hat bestätigt“, „Zahlung eingegangen“) im Thread. Kein Slack, kein WhatsApp-Import.
Was rein kommt — und was nicht
- Ja: Nachrichten am konkreten Nachtrag, beide Seiten antworten, Lesen per Magic-Link
- Ja: E-Mail „Neue Nachricht in MEMNO“ mit Link zurück
- Nein: Genereller Projekt-Chat, Gruppenchats, @mentions, Video/Voice
- Nein: WhatsApp-Integration — bewusst ausgeschlossen
Warum das Sinn macht
Rückfrage vor Bestätigung reduziert „das hab ich nicht so verstanden“. Bei Streit liegt Thread + PDF + Bestätigung an einem Ort. Für Easy Pay: erst klären → bestätigen → bezahlen im selben Flow.
Passt zur MEMNO-Story
„Schau in MEMNO, Projekt X, Nachtrag vom 12.6.“ — nicht „such in WhatsApp nach der Nachricht von letzter Woche“.
Technik (Konzept)
Tabelle `requestMessages` mit `authorRole: owner | client | system`. Realtime über Convex Subscription auf `changeRequestId`. Rate-Limit: max. eine E-Mail pro Thread pro Stunde — kein Spam.
Voraussetzung: Phase A–C der zweiseitigen Plattform, damit beide Seiten optional auf der Plattform sind. Phase D (E-Mail-Benachrichtigungen) kann ohne D+ live gehen.