MCP-Workflow für Agenturen: Kundenmeetings vorbereiten

MCP lohnt sich für Agenturen erst, wenn möglichst viele Systeme verbunden sind und die KI daraus selbstständig handelt. Diese Annahme führt zu einem unnötig großen ersten Projekt. Der bessere Einstieg ist ein eng begrenzter Lese-Workflow: Vor einem Kundenmeeting stellt die Anwendung die relevanten Informationen aus vorhandenen Quellen zusammen, kennzeichnet Lücken und verlinkt die Belege.

MCP steht für Model Context Protocol. Über diese Schnittstelle kann eine KI-Anwendung auf klar definierte Datenquellen und Funktionen zugreifen. Für die Meetingvorbereitung bedeutet das: Die KI muss nicht mit kopierten Ticketlisten, alten Protokollen und halb erinnerten Zusagen gefüttert werden. Sie kann die freigegebenen Informationen bei Bedarf abrufen.

Das Briefing ist wichtiger als die Anzahl der angebundenen Systeme

Die typische Vorbereitung beginnt kurz vor dem Termin. Du öffnest das Projektboard, suchst nach den letzten Besprechungsnotizen, prüfst neue Supportfälle und versuchst herauszufinden, welche Rückmeldung noch aussteht. Das kostet nicht nur Zeit. Es erhöht auch das Risiko, dass eine relevante Information in einem anderen System liegen bleibt.

Ein MCP-Workflow kann diese Sucharbeit bündeln. Sein Ergebnis sollte allerdings keine glatte Zusammenfassung sein, die kompetent klingt und ihre Herkunft verschweigt. Nützlicher ist ein Arbeitsbriefing: knapp genug für das Meeting, aber mit Quellen, Statusangaben und sichtbaren Unsicherheiten.

Die Leitfrage lautet deshalb nicht: „Welche Systeme können wir per MCP verbinden?“ Sie lautet: „Welche Informationen muss die verantwortliche Person vor diesem Kundentermin zuverlässig prüfen können?“ Erst aus dieser Frage ergeben sich die benötigten Quellen und Werkzeuge.

Begrenze den Workflow auf einen konkreten Termin

Ein brauchbarer Einstieg beginnt mit einem eindeutigen Auslöser. Die Anwendung erhält beispielsweise eine Kundennummer, ein Projekt und das Datum des geplanten Meetings. Daraus erstellt sie ein Briefing für genau diesen Termin. Sie soll weder den gesamten Kundenverlauf analysieren noch ungefragt eine neue Projektstrategie entwerfen.

Lege außerdem einen überschaubaren Zeitraum fest. Für laufende Aufgaben kann der aktuelle Status genügen, während bei Entscheidungen nur Einträge seit dem letzten Meeting relevant sind. Ein unbegrenzter Abruf produziert mehr Text, aber selten mehr Klarheit. Alte, längst erledigte Vorgänge tauchen wieder auf und konkurrieren mit den Punkten, über die tatsächlich gesprochen werden muss.

Damit bleibt der Anwendungsfall überprüfbar: Eine verantwortliche Person kann das erzeugte Briefing mit den Originalquellen vergleichen und erkennen, ob der Workflow relevante Informationen ausgelassen oder falsch eingeordnet hat.

Definiere den Aufbau des Briefings vor den MCP-Werkzeugen

Wenn du zuerst Schnittstellen baust, entsteht leicht eine Sammlung technisch erreichbarer Daten. Das ist noch kein Arbeitsablauf. Lege daher fest, welche Abschnitte das Briefing enthalten soll und welchen Zweck jeder Abschnitt erfüllt.

Für ein regelmäßiges Kundenmeeting kann folgende Struktur ausreichen:

• Ziel des Termins: Anlass, erwartete Entscheidung und bekannte Teilnehmer.
• Stand seit dem letzten Gespräch: abgeschlossene Aufgaben und wesentliche Änderungen.
• Offene Zusagen: vereinbarte Lieferungen oder Rückmeldungen mit Verantwortlichen und Termin.
• Blockaden: Aufgaben, die auf Informationen, Freigaben oder technische Voraussetzungen warten.
• Relevante Supportfälle: offene oder wiederkehrende Anliegen mit ihrem aktuellen Status.
• Entscheidungspunkte: Fragen, die im Termin verbindlich geklärt werden sollten.
• Unklare Angaben: Widersprüche, fehlende Zuständigkeiten oder nicht auffindbare Belege.
• Quellen: direkte Links zu Aufgaben, Tickets und dokumentierten Entscheidungen.

Jeder Eintrag sollte nach Möglichkeit einen Status, eine verantwortliche Person, einen relevanten Zeitpunkt und eine Quelle besitzen. Fehlt eine dieser Angaben, darf der Workflow die Lücke benennen. Er sollte sie nicht durch eine plausible Vermutung schließen. Ein ehrliches „Verantwortung nicht dokumentiert“ ist für die Vorbereitung wertvoller als ein erfundener Projektzustand in tadellosem Agenturdeutsch.

Gib jeder Datenquelle genau eine Aufgabe

Mehrere Systeme enthalten häufig ähnliche Informationen. Eine Zusage kann im Meetingprotokoll stehen, als Aufgabe im Projektboard auftauchen und zusätzlich in einem Supportticket erwähnt werden. Ohne klare Zuständigkeit entstehen widersprüchliche Briefings.

Lege deshalb pro Informationsart eine führende Quelle fest:

• CRM: Kundenstammdaten, zuständige Kontakte und vereinbarte Rahmeninformationen.
• Projektverwaltung: Aufgabenstatus, Zuständigkeiten, Meilensteine und Blockaden.
• Supportsystem: offene Anfragen, Rückfragen und dokumentierte Problembeschreibungen.
• Besprechungsdokumentation: Entscheidungen, Zusagen und Kontext aus früheren Terminen.
• Kalender: Termin, Teilnehmer und hinterlegte Agenda.

Du musst nicht alle diese Quellen anbinden. Wenn Projektstatus und Entscheidungen bereits sauber in einem System gepflegt werden, kann ein einzelner Lesezugriff genügen. MCP schafft seinen größten Nutzen hier nicht durch Menge, sondern durch einen einheitlichen Zugriff auf genau die Informationen, die sonst manuell zusammengesucht werden.

Besonders wichtig ist eine gemeinsame Kennung. Ein Firmenname allein ist oft zu ungenau, weil Schreibweisen, Marken oder mehrere parallele Projekte auseinanderlaufen können. Verwende nach Möglichkeit eine feste Kunden- oder Projekt-ID. Kann die Anwendung eine Bezeichnung nicht eindeutig zuordnen, muss sie nachfragen, statt den wahrscheinlichsten Treffer zu wählen.

So läuft die Meetingvorbereitung ab

MCP stellt die Datenquellen und Abfragen bereit. Die eigentliche Reihenfolge des Ablaufs definierst du in der Anwendung oder im dazugehörigen Workflow. Für die Meetingvorbereitung bietet sich folgender Prozess an:

1. Termin auswählen: Du übergibst den konkreten Kalendereintrag oder wählst Kunde, Projekt und Termin aus.
2. Zuordnung prüfen: Der Workflow ermittelt die eindeutigen IDs für Kunde und Projekt. Mehrdeutige Treffer werden dir zur Auswahl vorgelegt.
3. Informationen abrufen: Die Anwendung liest offene Aufgaben, aktuelle Supportfälle, dokumentierte Entscheidungen und relevante Termindaten.
4. Einträge zusammenführen: Verweise auf denselben Vorgang werden gebündelt. Unterschiedliche Statusangaben bleiben als Widerspruch sichtbar.
5. Briefing erzeugen: Die Informationen werden in die vorher definierte Struktur eingeordnet. Jeder wesentliche Punkt erhält einen Quellenverweis.
6. Menschlich prüfen: Die verantwortliche Person bestätigt das Briefing, ergänzt Gesprächskontext und entscheidet, welche Punkte auf die Agenda gehören.

Der letzte Schritt ist kein dekorativer Freigabeklick. Ein System kann dokumentierte Informationen zusammenstellen, kennt aber nicht automatisch jede informelle Absprache oder politische Empfindlichkeit im Kundenverhältnis. Die fachliche Verantwortung für die Gesprächsführung bleibt bei der Person, die den Termin vorbereitet.

Regeln für Widersprüche und fehlende Daten

Der Workflow wird erst dann belastbar, wenn du das Verhalten für unordentliche Fälle definierst. Gerade diese Fälle machen in realen Arbeitsabläufen einen beträchtlichen Teil der Sucharbeit aus.

Widersprüche nicht automatisch auflösen

Steht eine Aufgabe im Projektboard auf „erledigt“, während ein aktuelles Supportticket dasselbe Problem weiterhin beschreibt, sollte das Briefing beide Angaben zeigen. Eine mögliche Formulierung lautet: „Projektaufgabe als erledigt markiert; Supportticket weiterhin offen.“ Die verantwortliche Person kann anschließend prüfen, ob es sich um einen neuen Fall, eine unvollständige Lösung oder einen veralteten Status handelt.

Fehlende Informationen ausdrücklich markieren

Zu einer dokumentierten Zusage gehört kein Termin? Dann erscheint sie unter den offenen Punkten mit dem Hinweis „Termin fehlt“. Gibt es keinen Beleg für eine behauptete Entscheidung, gehört auch das in die Ausgabe. Der Workflow soll Vorbereitungslücken sichtbar machen, nicht sprachlich überdecken.

Aktualität an der Quelle zeigen

Ein Briefing sollte erkennen lassen, wann ein Status zuletzt geändert wurde. Das bedeutet nicht, dass ältere Informationen wertlos sind. Du kannst aber unterscheiden, ob eine Blockade gestern bestätigt wurde oder seit längerer Zeit ungeprüft im System steht.

Ausfälle einzelner Quellen offenlegen

Ist das Supportsystem beim Abruf nicht erreichbar, darf trotzdem ein Briefing entstehen. Es muss dann klar darauf hinweisen, dass die Supportfälle nicht geprüft werden konnten. Eine unvollständige Ausgabe mit Warnhinweis ist kontrollierbar. Eine scheinbar vollständige Ausgabe ist es nicht.

Starte mit Lesezugriffen und einem klaren Datenumfang

Für diesen Anwendungsfall benötigt der MCP-Workflow zunächst keine Schreibrechte. Er muss keine Aufgaben verändern, Notizen anlegen oder E-Mails versenden. Das hält den ersten Einsatz überschaubar und verhindert, dass eine fehlerhafte Zuordnung direkt bestehende Projektdaten verändert.

Auch bei reinen Lesezugriffen solltest du nur die Informationen bereitstellen, die das Briefing benötigt. Vertragsunterlagen, Rechnungsdaten oder vollständige Postfächer gehören nicht automatisch dazu. Die bestehenden Berechtigungen der jeweiligen Systeme müssen weiterhin gelten: Wer ein vertrauliches Projekt nicht einsehen darf, sollte dessen Daten auch nicht über den MCP-Zugriff erhalten.

Falls du später aus dem Briefing heraus Aufgaben anlegen oder Statuswerte ändern möchtest, wird daraus ein eigener Schreib-Workflow. Dann brauchst du eine technische Freigabe vor der Aktion. Wie sich das trennen lässt, beschreibt der Artikel MCP-Tool mit Freigabe: Schreibzugriffe sicher bauen.

Prüfe den Workflow an echten Vorbereitungssituationen

Ein Test mit künstlich aufgeräumten Beispieldaten sagt wenig darüber aus, ob das Briefing im Alltag hilft. Nimm mehrere bevorstehende Termine mit unterschiedlichen Voraussetzungen: ein laufendes Projekt, einen Kunden mit offenen Supportfällen und einen Termin, bei dem vor allem eine Entscheidung ansteht.

Vergleiche für jeden Termin das MCP-Briefing mit der bisherigen manuellen Vorbereitung. Entscheidend sind keine hübschen Formulierungen, sondern konkrete Prüffragen:

• Wurden alle offenen Zusagen mit ihrer Quelle gefunden?
• Sind erledigte und offene Vorgänge korrekt getrennt?
• Werden widersprüchliche Statusangaben sichtbar?
• Kannst du jeden wichtigen Punkt im Ursprungssystem nachprüfen?
• Enthält das Briefing irrelevante Vorgänge, die den Termin nicht betreffen?
• Ist klar, welche Quelle nicht erreichbar oder nicht aktuell war?

Notiere Fehler nach Ursache. Fehlt ein Punkt, weil die Abfrage ungeeignet ist, musst du den Workflow ändern. Fehlt er bereits im Ursprungssystem, liegt ein Pflegeproblem vor. Diese Unterscheidung verhindert, dass du eine KI-Anweisung überarbeitest, obwohl die benötigte Information nirgendwo verlässlich dokumentiert ist.

Wenn du vor der technischen Umsetzung noch klären musst, ob der zugrunde liegende Ablauf stabil genug ist, hilft die Checkliste zur Vorbereitung einer Prozessautomatisierung.

Wann dieser MCP-Workflow wenig bringt

Eine MCP-Integration ist keine Pflichtübung. Liegen alle relevanten Informationen bereits in einer gut gepflegten Projektansicht, kann eine gespeicherte Abfrage oder Vorlage denselben Zweck einfacher erfüllen. Die zusätzliche Schnittstelle wäre dann hauptsächlich ein weiterer Ort, an dem etwas kaputtgehen kann.

Auch stark informelle Prozesse sind schlechte Kandidaten. Wenn Zusagen überwiegend in persönlichen Nachrichten, Telefonaten oder im Gedächtnis einzelner Personen verbleiben, kann der Workflow sie nicht zuverlässig finden. In diesem Fall solltest du zuerst festlegen, wo Entscheidungen und Verpflichtungen dokumentiert werden.

Für rechtlich oder finanziell verbindliche Aussagen genügt ein automatisch erstelltes Briefing ebenfalls nicht als alleinige Grundlage. Vertragsstände, Preise und Freigaben müssen aus den dafür vorgesehenen Originalunterlagen geprüft werden. Das Briefing kann auf diese Dokumente verweisen, sollte ihren Inhalt aber nicht zur vermeintlich verbindlichen Kurzfassung erklären.

Ein guter erster MCP-Workflow reduziert Sucharbeit

Die Vorbereitung von Kundenmeetings eignet sich als erster MCP-Workflow, weil das Ziel klar und die Wirkung überprüfbar ist. Die Anwendung sammelt definierte Informationen, ordnet sie einem Termin zu und legt Quellen sowie Lücken offen. Sie trifft keine Kundenentscheidung und verändert keine Projektdaten.

Beginne daher mit einem festen Briefingformat, wenigen führenden Quellen und reinen Lesezugriffen. Wenn dieses Ergebnis im Arbeitsalltag verlässlich ist, kannst du den Umfang gezielt erweitern. Ein zusätzlicher Datenzugriff ist erst dann sinnvoll, wenn er eine konkrete Frage des Briefings besser beantwortet. Alles andere ist Systemtourismus mit Schnittstelle.

Häufige Fragen

Kurz beantwortet, damit du schneller einschätzen kannst, was für dein Projekt wichtig ist.

Braucht ein MCP-Workflow für Kundenmeetings mehrere Datenquellen?

Nein. Beginne mit den Quellen, die offene Aufgaben, Entscheidungen und Blockaden verlässlich abbilden. Wenn eine einzige Projektverwaltung alle benötigten Informationen enthält, kann ein einzelner Zugriff ausreichen.

Sollte das MCP-Briefing automatisch an den Kunden gesendet werden?

Für den Einstieg nicht. Das Briefing dient der internen Vorbereitung und sollte vor jeder Weitergabe fachlich geprüft werden. Informelle Absprachen, sensible Details und unklare Statusangaben benötigen menschliche Einordnung.

Kann der Workflow nach dem Meeting Aufgaben und Notizen anlegen?

Technisch lässt sich der Ablauf später um Schreibzugriffe erweitern. Behandle das jedoch als eigenen Workflow mit eindeutiger Vorschau, technischer Freigabe, Berechtigungsprüfung und nachvollziehbarem Ergebnis.

Was passiert, wenn sich Projektboard und Supportticket widersprechen?

Der Workflow sollte beide Statusangaben samt Quellen anzeigen und den Widerspruch markieren. Er darf nicht ohne belastbare Regel entscheiden, welche Angabe korrekt ist.