Die Aufgabe passte in einen Satz: Welche Kollegen sollen zehn Sekunden nach Ihrem Meeting-Ende wie informiert werden — und in welchen Tools wird die Interaktion wie dokumentiert?
Zwei Ebenen, mehr nicht. Klingt nach einem Nachmittag. Wurde ein Tag, und der hat mehr über unsere Prozesse verraten als das halbe Quartal davor.
Der interessante Teil war die Besetzung. Angetreten sind Sales, Marketing, Projektmanagement und Customer Success. Das Development-Team haben wir bewusst nicht als eigene Gruppe aufgestellt, sondern als Springer — sie durften helfen, wenn irgendwo etwas klemmte. Nebeneffekt, den wir dankbar mitgenommen haben: Entwickler haben ohnehin kaum Meetings. Sie wären beim Thema „Was passiert nach dem Meeting?“ die schlechtesten Zeugen gewesen.
Warum haben wir die Entwickler bewusst herausgehalten?
Weil die Frage keine technische mehr ist, wenn man die passende Software im Einsatz hat.
Ob ein Agent eine Slack-Nachricht schreiben kann, ist seit Jahren geklärt. Ob er sie an die richtige Person schreibt, in der richtigen Länge, mit dem richtigen Objekt verknüpft — das weiß nur, wer diese Nachricht sonst selbst getippt hätte.
Unsere Erwartung war, dass die Fachbereiche eine grobe Wunschliste abliefern und wir daraus ein Konzept bauen. Eingetreten ist das Gegenteil. Die Ansätze waren spezifischer, als sie aus dem Development gekommen wären, weil die Leute ihre eigenen Schmerzpunkte modelliert haben statt vermuteter fremder. Wer selbst dreimal die Woche vergisst, den Kollegen über eine Zusage zu informieren, baut einen anderen Filter als jemand, der das Problem nur aus dem Ticket kennt.
Das ist der eigentliche Ertrag des Formats: Ein Hackathon mit Nicht-Entwicklern ist keine Team-Veranstaltung mit Pizza. Er ist eine Discovery-Methode.
Was haben Sales und Customer Success herausgefunden?
Die beiden Gruppen haben sich, ohne Absprache, gegenseitig proaktiv informiert. Das war der erste Hinweis darauf, dass hier ein echter Schmerz liegt und nicht ein konstruierter.
Ihre Lösung lief auf zwei Orte hinaus: Slack (alternativ Teams) für die Information und HubSpot als CRM für die Dokumentation. Dazu die Entscheidung, die den Rest des Tages geprägt hat — das Meeting muss als echtes Objekt existieren, verknüpft mit den richtigen Kontakten. Nicht als Textblock, der irgendwo klebt.
Drei Learnings aus dieser Gruppe:
Erstens: Kurz, kürzer, am besten. Maximal ein bis zwei Sätze in Slack. Mehr nicht. Die Meeting-Dokumentation sieht dagegen anders aus: zwei Sätze plus Bullet Points. Daraus folgt eine Regel, die härter ist, als sie klingt — jeder Prompt für jeden Output muss anders aussehen, je nachdem ob Sie informieren oder dokumentieren. Ein Agent mit einem einzigen Textbaustein produziert für beide Fälle Mittelmaß.
Zweitens: Gleiches System, andere Objekte. Sales dokumentiert an Deals, Customer Success an Support-Tickets. Verschiedene Objekte, gleicher Unterbau. Deshalb müssen Sie die Objektbeziehungen verstehen und sauber in Kontakte und Unternehmen einspeisen — auf die bauen beide auf. Wer diesen Common Ground nicht sauber modelliert, baut zwei Silos mit KI-Anstrich.
Drittens: Filter einbauen. Wann muss wer überhaupt Bescheid wissen? Nicht jede Interaktion ist eine Nachricht wert.
Warum waren Marketing und Projektmanagement der schwierigere Fall?
Weil dort andere Systeme relevant sind: Task Management, Google Drive mit der Projektdokumentation in Sheets und Docs, und dahinterliegende Workflows und Datenbanken, in denen Themen wie Zielgruppen für Kampagnen oder Kundenprofile liegen.
Deutlich mehr Kanäle als bei Sales und Customer Success. Gleichzeitig deutlich mehr Stakeholder, die informiert werden müssen.
Komplexer — und am Ende hilfreicher. Jede Erwähnung, jedes Versprechen, jede Absprache wird sofort weitergegeben. Genau das, was in Projekten sonst zwischen zwei Kalenderwochen verschwindet.
Der Preis dafür wurde in derselben Sitzung sichtbar: Es muss deutlich besser gefiltert werden, an wen wie viel geht. Ein Gesamt-Channel, in den alles läuft, würde etwa alle vier Minuten pingen. Den liest niemand mehr. Schlimmer: Den nimmt niemand mehr ernst — auch dann nicht, wenn ausnahmsweise etwas Wichtiges drinsteht.
Wie können Sie KI-Agenten im Unternehmen einsetzen, ohne Lärm zu produzieren?
Wir haben die Ansätze zu einem Ablauf verdichtet, den wir über Motion automatisch starten. Motion ist eine KI-gestützte Work-Management-Plattform, die aus einem Prompt oder einer hinterlegten SOP ein Projekt mit Tasks erzeugt, diese nach Rolle und Kapazität zuweist und selbst terminiert. Der eingebaute Meeting-Notetaker liefert den Auslöser, die Integrationen zu HubSpot, Salesforce, Google Meet und Outlook liefern die Anbindung.
Der Ablauf in fünf Stufen:
- Trigger — das Meeting endet.
- Pass-through — der Workflow findet alle relevanten Objekte: CRM, Task Management, Dokumentation, Kommunikationskanal, was auch immer. Je nach Use Case ist das massiv unterschiedlich und jeweils ein komplett eigener Workflow. Das ist kein Schönheitsfehler, sondern die Erkenntnis: Einen generischen Post-Meeting-Agenten gibt es nicht.
- Bewertung nach Rolle und Situation — anhand von sechs Fragen:
- Was ist passiert?
- Wo stehen wir?
- Was soll passieren?
- Was ist der Output?
- Was sind die Learnings?
- Wer muss über was informiert werden?
- Routing — in den richtigen Kanal und die richtige Ansprache.
- Proaktive Information — die Person bekommt die Nachricht, ohne zu fragen.
Getrennt davon läuft die Dokumentation. Im CRM oder Task Management brauchen Sie fast immer etwas anderes als den gestrafften Textblock für Slack. Mindestens zwei Modi, oft drei: informieren, dokumentieren, anderer Blickwinkel.
Wie viele automatische Nachrichten verträgt ein Team pro Tag?
Das war die Grenze, die uns am meisten überrascht hat — weil sie nichts mit Technik zu tun hat.
Unsere Daumenregel aus dem Hackathon: Zwischen fünf und acht automatischen Nachrichten pro Tag und Empfänger wird es kritisch. Darüber kippt die Aufmerksamkeit, und der Kanal ist verbrannt. Ab da müssen Sie splitten — nach Empfängergruppe, nach Dringlichkeit, nach Objekt.
Das ist ein Erfahrungswert aus einem Tag, keine Messreihe. Aber er deckt sich mit dem, was wir seither im Betrieb sehen: Die Kapazitätsgrenze eines KI-Workflows ist nicht der Rechner. Es ist der Mensch am anderen Ende.
Wer KI-Agenten im Unternehmen einsetzen will, sollte diese Zahl vor der ersten Automatisierung festlegen, nicht danach. Sonst optimieren Sie ein System, das längst niemand mehr liest.
Was ist mit dem Prototyp passiert?
Er wurde weggeworfen. Zumindest als Code.
Die Fachbereiche haben an einem Tag eine theoretisch funktionierende Version abgeliefert. Genau das war die Aufgabe. Aber ein Hackathon-Ergebnis ist ein Prototyp — und Prototyp ist nicht Produkt. Im nächsten Sprint hat unser Development-Team den Workflow komplett nachgebaut, optimiert und in die bestehende Infrastruktur integriert.
Was überlebt hat, ist das Wertvollere: die Anforderungen. Die Filterlogik, das Objektmodell, die Lautstärkegrenze, die Trennung von Informieren und Dokumentieren. Diese Entscheidungen hätte kein Development-Team so getroffen, weil ihm dafür der Alltag fehlt.
Wie führen Sie so einen Hackathon selbst durch?
Sechs Dinge, die bei uns den Unterschied gemacht haben:
- Stellen Sie eine Frage, keine Aufgabe. „Wer soll zehn Sekunden nach Ihrem Meeting was wissen?“ ist beantwortbar. „Optimiert unsere Kommunikation“ ist es nicht.
- Zwei Ebenen, nicht zehn. Informieren und Dokumentieren haben gereicht, um einen ganzen Tag zu füllen.
- Entwickler als Springer, nicht als Team. Sonst lösen sie die Aufgabe, statt sie stellen zu lassen.
- Nach Abteilung trennen. Die Unterschiede zwischen Sales und Marketing sind der eigentliche Erkenntnisgewinn. In gemischten Gruppen mitteln sie sich weg.
- Verlangen Sie etwas Lauffähiges. Ein Foliensatz erzeugt keine Erkenntnis. Erst der Versuch, es wirklich zu bauen, deckt auf, was fehlt.
- Planen Sie den Nachbau ein. Wenn nach dem Hackathon kein Sprint folgt, war es ein netter Tag — mehr nicht.
Es hat Spaß gemacht. Alle haben etwas gelernt. Viele mussten ihren klassischen Arbeitsbereich verlassen. Und trotzdem — oder genau deshalb — kam Tieferes heraus, als ein reines Entwicklerprojekt geliefert hätte. Weil Erwartungshaltung und Lösungsansätze von denen formuliert wurden, die das Ergebnis später nutzen.
Nächster Schritt
Sie wollen Meetings nicht dokumentieren, sondern nutzen? Wir bauen genau solche Abläufe — von der Anforderung bis zur produktiven Integration.
→ AI Operations bei ReachOut Software — wie wir KI-Workflows in bestehende Systeme bringen.
→ Wie wir sicher iterieren, ohne den Betrieb zu gefährden, lesen Sie in Zwei Systeme, ein Deploy.
