Operative Kontextschicht: belegte Antworten und freigegebene Aktionen über Chat, Tickets, Wiki und CRM

Das Problem

Ein B2B-Technologieunternehmen in DACH führt Enterprise-Kundenprojekte über Vertrieb, Delivery und Engineering. Jeder Kunde lebt an sechs Orten gleichzeitig: ein Ticket-Board, ein Wiki-Bereich, ein Chat-Kanal, ein CRM-Deal, mehrere Postfächer und die Meetings, in denen die eigentlichen Entscheidungen fallen. Stakeholder aus Vertrieb, Delivery, Engineering, Betrieb und Management wurden befragt, bevor die erste Zeile Code entstand. Ihre Fragen, verdichtet:

• Welcher der fünf Stände dieses Kunden ist aktuell, und wer hat das entschieden?
• Was hat sich seit meinem letzten Blick bewegt, das ich vermutlich verpasst habe?
• Kann ich einer Antwort trauen, oder muss ich die Quelle ohnehin öffnen?
• Kann das System auf eine Änderung hin handeln, und wer trägt die Verantwortung, wenn es das tut?
• Was darf ein Kollege von meinen Meetings und meinen Deals sehen, und was darf ein Assistent sehen?
• Übersteht das einen Security-Review?

Digests gab es bereits. Die Chat-Suite fasst Nachrichten und Mails pro Person zusammen, die Wiki-Suite fasst Seiten und Tickets pro Person zusammen. Keins von beiden zitiert die Textstelle, die einen Eintrag vor dich gelegt hat, keins trägt die Unterschrift eines Kollegen, keins schreibt in den Datensatz zurück, und keins weiß, zu welchem Kunden eine Seite, ein Thread und ein Ticket gehören. Diese Lücke ist der ganze Auftrag.

Diese Fallstudie richtet sich an CTOs, VPs Engineering und IT-Leitungen in DACH-Unternehmen, die belegte Antworten und freigegebene Aktionen über Chat, Tickets, Wiki und CRM auf dem eigenen EU-Cloud-Tenant brauchen.

Ein Tisch, fünf Vokabulare. Jeder Kreis spricht in eigenen Worten über den Kunden; die Schicht hält darunter einen Datensatz, gelesen als du, zitiert, gezeichnet.

Synthetischer Screenshot 1: das Änderungsradar, mit fiktiven Kunden, Personen und Datensätzen. Jeder Eintrag sagt wann, wer, welches System, warum er auf deinem Radar ist, und zitiert die Erwähnung. Der gezeichnete Fakt trägt seine Kette: erst die zeichnende Person, dann das Meeting, aus dem er stammt, mit wem er geteilt ist, wie viele unabhängige Quellen ihn stützen.

Was die Person sieht

Die Screenshots auf dieser Seite sind synthetisch. Sie zeigen die echten Bildschirme mit fiktiven Kunden, Personen und Datensätzen, damit der Kunde ungenannt bleibt und kein Datensatz den Tenant verlässt.

Fähigkeiten

Wofür die Leute es nutzen, in der Reihenfolge, in der sie es übernommen haben:

1. Das Änderungsradar. Was hat sich seit meinem letzten Blick bewegt, das mich betrifft, gefaltet pro Kunde, mit zitierter Erwähnung oder weggelassenem Eintrag. Mindestens ein Tag, höchstens sieben, damit Abwesenheit nachgeholt und nicht stumm verworfen wird. Eine Quelle, die nicht geantwortet hat, steht namentlich auf der Seite, damit ein ruhiges Radar und ein gescheiterter Lesezugriff zwei verschiedene Dinge sind.
2. Das Morgen-Briefing. Dasselbe Radar als kurzer Text zum Tagesbeginn, der einen Fakt als Neuigkeit zählt, wenn er den Graphen erreicht hat, nicht nur, wenn er wahr wurde.
3. Call Notes zu Entscheidungen. Meeting-Transkripte werden live als die Person gelesen und zusammengefasst: Notizen, Entscheidungen, wer was übernommen hat. Die Entscheidungen landen zeilenweise im Proposals-Tab der Person. Wer die Zusammenfassungen mit einem Kollegen teilt, zeigt ihm die Zusammenfassung, nie das Transkript.

4. Belegte Fragen. Frag nach einem Kunden, einer Seite, einer Entscheidung. Die Antwort zitiert ihre Quellen, ist auf das beschnitten, was die Person sehen darf, und sagt “nicht gefunden” statt zu erfinden.
5. Rückschreiben als du selbst. Am Ticket kommentieren, an die Wiki-Seite anhängen (nie ersetzen, damit Inline-Kommentare verankert bleiben), im Chat-Thread antworten, ein Arbeitselement anlegen. Jedes auf einer Karte freigegeben, jedes mit Beleg.
6. Der Deal neben der Arbeit. CRM-Phase und Abschlussdatum neben der Engineering-Bewegung, die Frage, die kein einzelnes System beantwortet.
7. Die Editor-Tür. Dasselbe Backend über MCP in Claude (Cowork, Desktop, der claude.ai-Connector), Codex und jeder MCP-fähigen Anwendung. Dieselbe Identität, dasselbe Gate, derselbe Audit-Trail.

etwas wird gesagt, oder etwas ändert sich in einem System
  -> eine Person sagt wahr, oder eine Person gibt frei
  -> es landet, zitiert, bei den Menschen, die es betrifft
  -> Aktionen gehen als die Person in die Systeme zurück, mit Beleg

Synthetischer Screenshot 2: das Freigabe-Gate. Ein Vorschlag wird als offen abgelegt und als Karte gepostet. Dieselbe Nachricht kann nie eine zweite Prüfung öffnen; eine Ablehnung ist selbst eine auditierte Entscheidung.

Synthetischer Screenshot 3: der Proposals-Tab, die Aktions-Inbox. Eine Zeile pro Aussage, ein Urteil pro Zeile. Eine Aussage ohne nachvollziehbare Beziehung wird abgewiesen, die Zeile bleibt offen. Ein Assistent darf in diese Liste vorschlagen und darf nicht annehmen.

Kontrollgarantien

Der Unterschied ist nicht das Modell. Es ist das, was die Schicht verweigert:

1. Nur delegierte Berechtigungen. Kein Dienstkonto mit allem. Eine Person sieht, was sie ohnehin sehen würde, ein Assistent sieht, was seine Nutzerin sieht.
2. Nichts wird ohne menschlichen Tipp geschrieben. An jeder Tür, auch über MCP. Ein Assistent kann vorschlagen und kann nicht freigeben.
3. Nie zweimal gefragt. Dieselbe Nachricht öffnet nie eine zweite Prüfung, und dasselbe Signal aus einer zweiten Nachricht auch nicht; eine Ablehnung und eine Dublettenentscheidung sind auditierte Entscheidungen.
4. Eine Prüfung bleibt offen, bis eine Person entscheidet. Eine verlorene Karte oder eine übersehene Nachricht schließt keine, und zwei Personen arbeiten nie dieselbe Zeile.
5. Herkunft auf jedem Datensatz, die Erwähnung zitiert oder der Eintrag weggelassen. Grund, wortgleiche Textstelle, Autor, Link.

6. Ringe bewerten Quellen, nie Menschen. Welchem System eine widersprüchliche Antwort folgen soll, wird gezeigt; keine Note, kein Abzeichen, kein Score sitzt je auf einem Kollegen.
7. Personal- und personenbezogene Daten mehrstufig ausgeschlossen. Kommerzielle Konditionen und alles zur Beschäftigung reisen nie mit, auch bei aktivem Teilen. Meetings mit externen Teilnehmern werden abgelehnt. Transkripte werden nie gespeichert.
8. Nur anhängender Audit-Trail, inklusive abgelehnter und deduplizierter Einträge. Das Zurücknehmen einer bestätigten Aktion ist Kompensation, nie Löschung. Jeder Fakt ist entfernbar.
9. Lückentelemetrie ab Tag 1. Das Unternehmen sieht, welche Fragen die Schicht nicht beantworten konnte, pro Quelle, damit Wert pro System gemessen wird und nie pro Person.
10. Datenresidenz präzise benannt. Compute und Speicher in der EU, auf dem eigenen Cloud-Tenant des Unternehmens. Die Inferenz des Sprachmodells ist nicht auf die EU begrenzt, und die Seite sagt das.

Leitplanke

Die Schicht schreibt das Produktivverhalten nie aus einer Sitzung heraus um. Ein Fakt kommt durch ein Urteil herein, ein Schreibzugriff durch einen Tipp, und der Audit-Trail hält das Abgelehnte und das Deduplizierte neben dem Bestätigten. Wenn zwei Quellen sich widersprechen, sagt der Ring, welchem System zu folgen ist, und die Kette sagt, wo nachzusehen ist. Niemand bekommt standardmäßig ein Dossier, und jeder kann einen Sprung zum Datensatz machen, statt einem Kollegen zu schreiben.

Das Freigabemuster hinter diesem Gate, ein Vorschlag als offen abgelegt und der Tipp einer Person vor jedem Schreibzugriff, ist im Human-in-the-Loop Approval-Flow-Blueprint dokumentiert.

Fünf Fähigkeiten, die das belegt

1. Berechtigungsbewusste Antworten über sechs Systeme ohne Dienstkonto.
2. Ein Freigabe-Gate, das an jeder Tür hält, auch an der, die ein Assistent nutzt.
3. Herkunft, die bis ins Radar, ins Briefing und in die Antwort überlebt.
4. Rückschreiben in die Systeme als die Person, mit Beleg.
5. Ein Wissensgraph, den Menschen über Urteile füllen und der sich auf dem Radar auszahlt.

Von links nach rechts: eine Person sagt wahr. Von rechts nach links: eine Person gibt den Schreibzugriff frei. Alles andere, was die Schicht liest, wird live beantwortet und landet nie im Graphen.

Der jüngste Schritt legt den Graphen selbst auf das Radar, der Teil, den kein Digest hat:

• Der gezeichnete Fakt eines Kollegen erreicht das Radar des Teams innerhalb von Minuten. Wenn eine Person einen Fakt annimmt und mit einem Team teilt, sieht ihn jeder in diesem Team unter dem Kunden, den er nennt: die Aussage als zitierte Textstelle, wer gezeichnet hat, das Team, mit dem er geteilt ist. Die Zugehörigkeit wird als jede Person gelesen, damit der Fakt eines Teams seine Mitglieder erreicht und sonst niemanden, und die eigenen Fakten sind für dich keine Neuigkeit.
• Woher er kommt, in einer Zeile. Unter jedem Eintrag: der Datensatz, aus dem er stammt, wer ihn eingereicht hat, wer wann wahr dazu gesagt hat, wie viele unabhängige Quellen ihn stützen. Erst die zeichnende Person, dann das Meeting oder die Mail, der Link zur Zusammenfassung. Die volle Kette öffnet sich auf Tipp. Sie wird als “wo nachsehen” gezeigt, nie als “wie sehr glauben”.
• Der Test, der zählt. Jemand, der nicht im Meeting war, erfährt, was dort entschieden wurde, ohne jemanden zu fragen, der dabei war. Das ist der Satz, mit dem die Leute den Wert beschreiben.
• Eine Ticket-Zeile sagt, was sich bewegt hat, nicht, wo das Ticket steht. “Status To Do → In Progress”, aus der Änderungshistorie gelesen, ohne Mehrkosten. Eine Massenänderung ist eine Karte, die Zeilen dahinter auf Tipp.
• Unter jedem Kunden, woher seine Änderungen kamen. “Tickets 7 · Wiki 2 · Dein Postfach 1”, die Faltung sichtbar gemacht, und eine Zeile, die kein Digest eines einzelnen Systems drucken kann.
• Ein Weg in den Graphen. Ein Fakt erreicht den Graphen nur über das Urteil einer Person oder die stehende Zustimmung einer Person. Nichts, was die Schicht nur liest, landet je darin.

Was wir gemessen haben

Ehrlicher Stand

Im Pilotbetrieb auf dem eigenen Tenant des Kunden. Nutzung wird pro Tür aus den Audit-Ereignissen gemessen, nie aus Meinungen.