/workspace/calls.html.
Calls sind KEINE eigene Terminart neben dem Kalender, sondern dieselben
Termine mit art = 'call' oder 'review'. Ein zweiter Terminspeicher waere
die sichere Art, irgendwann zwei widerspruechliche Uhrzeiten zu haben.
Diese Seite fuegt nur hinzu, was ein Gespraech vom blossen Termin
unterscheidet: das Protokoll danach. Die Sichtbarkeitsregel ist Wort fuer
Wort dieselbe wie im Kalender -- ein Termin darf nicht in der einen
Ansicht auftauchen und in der anderen fehlen.
Der tragende Satz von Seite 13, woertlich genommen:
"Jeder Call endet mit klaren To-dos, die direkt ins Board uebernommen
werden."
To-dos werden deshalb NICHT als Text im Protokoll abgelegt, sondern
sofort zu echten Aufgaben -- mit dem Gespraech als Herkunft in der
Beschreibung, zugeordnet an das Gegenueber des Calls. Sonst steht die
Verabredung in einem Dokument, das niemand mehr oeffnet. Geprueft:
Protokoll geschrieben -> Aufgaben stehen im Brett.
Weitere Punkte:
- Reihenfolge der Gruppen ist Dringlichkeit, nicht Chronologie: Ganz oben
stehen vergangene Gespraeche OHNE Protokoll. Das ist der einzige
Zustand, der etwas von einem verlangt. Nur diese Gruppe ist optisch
hervorgehoben; wenn alles schreit, sieht man nichts mehr.
- Ein festgehaltenes Protokoll ist danach nur noch lesbar. Ein Gespraech
nachtraeglich umschreiben zu koennen waere genau das, was ein Protokoll
wertlos macht.
- "Naechster Termin" legt den Folgetermin direkt in den Kalender -- mit
demselben Gegenueber und demselben Meeting-Link.
- Alles in EINER Transaktion. Geprueft mit einem absichtlich kaputten
To-do: kein Protokoll, keine halben Aufgaben, kein Folgetermin.
- Enter im To-do-Feld legt die naechste Zeile an, damit man eine Liste
tippen kann, ohne zur Maus zu greifen.
- Meeting-Link nur bei anstehenden Gespraechen und nur, wenn es wirklich
eine http(s)-Adresse ist. "bei mir zu Hause" bleibt schlichter Text.
Zur Videotechnik selbst bewusst KEINE Entscheidung getroffen: Ein eigener
WebRTC-Raum braucht einen TURN-Server, damit Verbindungen hinter
Mobilfunk-NAT zustande kommen. Das ist eine Infrastrukturfrage mit
laufenden Kosten und gehoert besprochen, nicht nebenbei entschieden.
Bis dahin traegt der Termin einfach den Link des Dienstes, der ohnehin
benutzt wird.
Nebenbei: .knopf-still lag in scouting.css und fehlte dadurch auf
calls.html -- dort standen prompt nackte Systemknoepfe. Der Baustein
gehoert ins gemeinsame start.css, dort liegt er jetzt.
/workspace/scouting.html. Erster Baustein aus Phase 3 und der Bereich,
in dem Scouts bisher praktisch nichts hatten.
Der Merksatz von Seite 15 ist hier die Sicherheitsregel, nicht nur eine
Beschreibung: "Scouts sehen ihre Pipeline -- die Admin-Rolle die
Gesamtuebersicht -- Creator keine Scout-internen Daten."
- Creator bekommen 404, nicht 403, und zwar auf Schnittstelle UND Seite.
Sie sollen nicht einmal erfahren, dass es den Bereich gibt.
- Ein Scout sieht ausschliesslich die eigene Pipeline. Geprueft: Patrick
bekommt auf Sams Lead 404 beim Lesen, Aendern und Loeschen.
- Das Management sieht alles, kann nach Scout filtern und Leads einem
Scout zuordnen.
Pipeline als gruppierte Liste, nicht als Board: Sechs Spalten waeren auf
dem Handy unbedienbar, und Scouts arbeiten unterwegs. Jede Stufe traegt
eine eigene Farbe an der linken Kante, die von kuehl (neu entdeckt) nach
gruen (uebergeben) laeuft -- die Richtung der Pipeline wird sichtbar,
ohne Ampel-Geblinke.
Jede Karte hat genau EINEN naheliegenden Schritt ("Weiter zu ..."), der
Rest steckt im aufklappbaren Teil. Der Weiter-Knopf traegt bewusst nur
die Farbe seiner Stufe statt des vollen Farbverlaufs, sonst waere die
Seite ein Streifenmuster aus identischen Leuchtbalken.
Faellige Follow-ups stehen als eigene Leiste ganz oben. Das ist der
Teil, der ohne System am ehesten untergeht -- nicht der Kontakt selbst,
sondern das Nachfassen.
Uebergabe ("Creator-Onboarding starten", Seite 15): Aus einem
uebergebenen Lead legt das Management mit einem Klick eine echte Person
mit Zugangscode an. Der Code wird genau einmal angezeigt, wie in der
Personenverwaltung. Die Qualifizierung des Scouts (Plattform, Handle,
Potenzial, LIVE-Aktivitaet) wandert dabei automatisch ins Creator-Profil
-- sonst muesste das Management abtippen, was laengst dasteht. Geprueft:
Lead -> Person -> Profil, alle drei verbunden, zweiter Versuch wird
abgelehnt.
Ein uebergebener Lead ist Teil der Betreuungsgeschichte -- den loescht
nur das Management, nicht der Scout (403).
Nebenbei: .knopf-still gab es im Baukasten noch gar nicht, die Zweit-
knoepfe waren nackte Systemknoepfe. Jetzt sauber definiert.
DogFatherGit