These: Wer Microsofts 30 CRM-Skills für Copilot ungeprüft übernimmt, übernimmt fremde Bewertungsregeln

Vergessen Sie die 180 Tools. Die sind egal. Laut Microsoft sind seit dem Blogeintrag vom Donnerstag, 8. Oktober 2026, 30 vorgefertigte CRM-Skills für Copilot Cowork allgemein verfügbar. Sie arbeiten mit mehr als 180 allgemein verfügbaren Tools aus Dynamics 365 Sales, Customer Service und Customer Insights. Autopilot bleibt laut Microsoft in der Private Preview, Code läuft über das Frontier-Programm. Spannend ist etwas anderes: die Frage, wer in Ihrem Unternehmen festlegt, was ein Skill als Beleg gelten lässt.

Das ist meine These, und ich formuliere sie bewusst spitz: Das Tool ist Commodity, der Skill ist Vertriebsstrategie. Wer fertige Skills ungeprüft übernimmt, übernimmt eine Vorstellung davon, welche Evidenz für einen gefährdeten Deal zählt. Ob das schlimm ist, hängt von Ihrer Governance ab, nicht von Microsoft.

Was Microsoft am 8. Oktober angekündigt hat

Die Quelle ist ein Beitrag im Dynamics-365-Blog, verfasst von Deva Rajamohan, Corporate Vice President Dynamics 365 Customer Experience. Der Kern, sinngemäß übersetzt: 30 neue vorgefertigte CRM-Skills für Copilot Cowork sind allgemein verfügbar, Autopilot ist in der Private Preview, Code gibt es über das Frontier-Programm. „Across supported experiences“ – also je nach unterstützter Umgebung – arbeiten die Skills mit mehr als 180 allgemein verfügbaren Tools. Diese Tools stellt Microsoft als Server-Tools über das Model Context Protocol (MCP) bereit.

Den Status sollten Sie genau lesen. GA gilt für Cowork. Autopilot ist laut Microsoft Private Preview, und wiederkehrende Automatisierung sowie Hintergrundbenachrichtigungen unterliegen dort Einschränkungen. Nicht alles gilt überall. Der Blog stellt ausdrücklich klar, dass die genannten Beispiele keine identische Funktion in jeder Umgebung bedeuten.

Preise nennt Microsoft nicht. Der Blog verweist nur darauf, dass Verfügbarkeit und Nutzung unter anderem von der Admin-Konfiguration, Zustimmung der Nutzenden oder des Tenants, Lizenzierung und Unternehmensrichtlinien abhängen. Microsoft Learn nennt für die Service-Skills als Voraussetzung den Zugang zu Copilot Cowork gemäß den geltenden Lizenz- und Ausgaberichtlinien der Organisation sowie passende Lizenzen für Dynamics 365 Customer Service, ebenfalls ohne Preise. Mehr weiß ich dazu nicht, und mehr behaupte ich nicht.

Tool oder Skill: Microsofts eigene Trennung in Dynamics 365

Jetzt wird es interessant. Microsoft zieht selbst eine Linie, die mein ganzes Argument trägt. Ein Tool ist laut Blog standardisierter Zugriff auf CRM-Kontext und freigegebene Aktionen. Den Datensatz einer Opportunity abzurufen, ist laut Microsoft eine Tool-Aktion. Ein Skill dagegen ist aufgabenspezifische Anleitung. Im Blog heißt es (übersetzt): Skills ergänzen die MCP-Tools um Hinweise, welche Evidenz zu berücksichtigen ist, wie mit Unsicherheit umzugehen ist und was ein brauchbares Ergebnis enthalten sollte. Zu beurteilen, warum ein Deal stockt, verlange einen Skill, der den verfügbaren Kontext interpretiert und eine begründete Empfehlung strukturiert.

Lesen Sie das noch einmal. „Welche Evidenz zu berücksichtigen ist.“ Das ist keine Technik. Das ist ein Urteil.

Ein Tool holt Daten. Ein Skill hat eine Meinung. Die Frage ist, wessen.

Wir bei digital-magazin.de haben im Juli über Microsofts autonome Copilot Agents für Dynamics 365 geschrieben, damals ging es um Sales, Service und Finance in der Public Preview. Hier geht es um etwas anderes, nämlich um die Schicht darunter: Wem gehört die Logik, nach der solche Agenten und Assistenten urteilen?

Mythos: Fertige Skills sparen nur Zeit

Der Mythos geht so: Ein Skill ist Bequemlichkeit, eine Vorlage, ein Textbaustein mit Datenanschluss. Wer will schon jede Prozedur von null entwerfen? Microsoft selbst argumentiert so, sinngemäß: Organisationen könnten das Fundament für Vertrieb und Service wiederverwenden, statt jedes Verfahren neu zu entwerfen. Für IT-Teams heißt es, der Aufwand sinke, jeden Vertriebs-, Service- und Marketing-Workflow von Grund auf zu bauen.

Das klingt vernünftig. Es stimmt auch. Nur ist es die halbe Wahrheit.

Die Realität: Fertige Skills bringen Bewertungsregeln mit. Sobald ein Skill beurteilt, ob eine Opportunity Aufmerksamkeit verdient, steckt in seiner Anleitung eine Antwort auf Fragen wie diese: Zählt ein langes Schweigen der Gegenseite mehr als ein fehlender Termin? Wiegt ein neuer Wettbewerber schwerer als ein schrumpfendes Budget? Was gilt als „stockend“? Diese Antworten stehen nicht auf einem Zettel, den ein Vertriebsteam je abgenickt hätte. Sie wirken im Hintergrund.

Seien wir ehrlich: Die wenigsten Vertriebsorganisationen haben ihre Kriterien für einen gefährdeten Deal je sauber aufgeschrieben. Es steckt im Kopf der Führungskraft, in Gesprächen im Flur, in Forecast-Calls. Genau deshalb ist ein fertiger Skill so verführerisch. Er füllt eine Lücke, die niemand benannt hatte.

Welche CRM-Skills Microsoft nennt

Microsoft nennt im Blog nur einen Teil der 30 Skills mit Namen, rund 15. Ich liste sie bewusst nicht vollständig auf und ergänze auch nichts. Beispiele laut Microsoft, jeweils kurz erklärt:

• Der Pipeline prioritizer markiert Opportunities, die Aufmerksamkeit verdienen.
• Deal rescue hilft Verkaufenden, eine stockende oder gefährdete Opportunity zu untersuchen.
• Customer engagement strategy empfiehlt einen 30-Tage-Account-Plan. Der Plan ist die Ausgabe des Skills, kein eigener Skill-Name.
• Case triage bringt dringende Fälle nach oben, Answer research sucht Lösungen in verifiziertem Wissen und ähnlichen Fällen.
• Draft customer reply bereitet eine Antwort vor, die auf Kundendaten beruht.
• Competitive strategy, Business case composer und Deal desk (bereitet Produkt- und Preiskonfigurationen vor) nennt Microsoft als Cowork-Beispiele.
• Reconcile my opportunity und Stage advance readiness tauchen bei der Trennung von Analyse und Änderung auf, dazu gleich mehr.

Schauen Sie sich diese Liste mit der Brille der Vertriebsstrategie an. Pipeline priorisieren, Deals retten, Wettbewerb bewerten, Business Case schreiben, Stufen freigeben. Das ist kein Werkzeugkasten. Das ist der Kern dessen, was gute Vertriebsorganisationen von mittelmäßigen unterscheidet.

Cowork, Code, Autopilot: dieselbe Logik in drei Umgebungen

Laut Blog bestimmen Cowork, Code und Autopilot, wie Teams die Skills einsetzen. Für Cowork beschreibt Microsoft einen Wettbewerbs-Deal: Verkaufende kombinieren Competitive strategy für Anforderungen und Einwände, Business case composer für das Investitionsargument und Deal desk für Produkt- und Preiskonfigurationen. Im Service sollen Answer research und Draft customer reply helfen, passende Hinweise zu prüfen und eine auf Kundendaten gestützte Antwort zur Prüfung vorzubereiten.

Für Code nennt Microsoft interaktive Anwendungen, die sich an den Fragen und Belegen des Geschäfts ausrichten. Der Sales Research Agent skill kann laut Blog die Analyse von Pipeline und Forecast leiten. Case triage und Case preparation brief können einen Service-Workspace informieren, der zeigt, welche Fälle Aufmerksamkeit brauchen und warum.

Autopilot ist laut Microsoft Private Preview. Als Aufgaben nennt der Blog das Prüfen von Deal-Änderungen, das Bewerten dokumentierter Fallinteraktionen und das Identifizieren wiederverwendbarer Hinweise aus verifizierten Lösungen. Wiederkehrende Automatisierung und Hintergrundbenachrichtigungen unterliegen dort weiterhin Einschränkungen.

Jetzt meine Einschätzung, nicht Microsofts Aussage: Eine Bewertungslogik, die in einem Skill steckt, reist mit. Wer in Cowork festlegt, was einen Deal als gefährdet gelten lässt, trifft dieselbe Festlegung in jeder Umgebung, in der der Skill läuft. In Code wird aus dieser Logik sogar ein Baustein einer Anwendung, den Ihr Team vielleicht nie wieder anschaut. Das heißt nicht, dass Skills von selbst irgendetwas tun. Der Blog betont das Gegenteil. Es heißt: Ein einmal übernommenes Urteil verteilt sich leise.

Service und Marketing hängen mit drin

Der Vertrieb ist die auffälligste Baustelle, aber Microsoft spricht laut Blog drei Gruppen an: Vertrieb, Service und Marketing. Servicemitarbeitende können kontospezifische Fallhistorie prüfen, Korrespondenz in strukturierte Fallvorschläge verwandeln, passende Antworten recherchieren und Kundenantworten vorbereiten. Marketingteams können laut Blog Ansprache unter Berücksichtigung von Einwilligungen (consent-aware outreach) und markenkonforme Inhalte direkt im Arbeitsfluss vorbereiten.

Auch dort steckt Urteilskraft, die man leicht übersieht. Meine Einordnung: Schon „dringend“ in der Case triage ist eine Gewichtung. Zählt die Dauer eines offenen Falls mehr als die Bedeutung des Kontos? Zählt ein verärgerter Ton mehr als ein technischer Stillstand? Jemand hat das entschieden, auch wenn es im Ergebnis nur wie eine sortierte Liste aussieht.

Dasselbe gilt für die Tonlage einer vorbereiteten Antwort. Ist sie förmlich, verbindlich, entgegenkommend? Wie viel Kulanz klingt darin an? Das sind Markenfragen, und sie landen in einem Entwurf, den vielleicht jemand nur noch überfliegt.

Fair gesagt: Für viele Service-Standardfälle kann Standardlogik völlig reichen. Wer Passwort-Rücksetzungen oder Statusanfragen sortiert, braucht keine hauseigene Philosophie. Die Frage ist nur, ob Sie bewusst entschieden haben, wo das gilt und wo nicht.

Was Microsoft richtig macht

Fairness muss sein, und die Konstruktion ist an mehreren Stellen sauber. Erstens trennt Microsoft laut Blog zwischen Analyse, Empfehlung, vorgeschlagener Änderung und abgeschlossener Aktion. Reconcile my opportunity kann Abweichungen zwischen Kundeninteraktionen und Opportunity-Datensatz erkennen und Feldänderungen vorschlagen. Draft customer reply bereitet eine Antwort zur Prüfung vor. Stage advance readiness bewertet Evidenz gegen die Kriterien der Organisation, und eine solche Bewertung ist laut Microsoft selbst keine Änderung der Verkaufsphase.

Zweitens: „People remain in control of business actions“, heißt es im Blog (übersetzt: Menschen behalten die Kontrolle über Geschäftsaktionen). Die Beispiele implizierten keine automatische Übergabe zwischen Erfahrungen, keine identische Funktion überall und keine Erlaubnis, ohne passende Autorisierung Nachrichten zu senden oder CRM-Datensätze zu ändern. Teams sollten klar unterscheiden können, was die KI empfiehlt, was Nutzende freigeben und was tatsächlich geändert wird.

Drittens: Die Plugins respektieren laut Microsoft die bestehenden Berechtigungen in Dynamics 365 und Microsoft 365.

Das ist gut gebaut. Ich sage das ohne Ironie. Und trotzdem greift es an meiner Kernfrage vorbei, denn all diese Mechanismen regeln das Was passiert nach dem Urteil. Sie sagen nichts darüber, wie das Urteil zustande kommt.

Eigene Skills, eigene Kriterien: Microsofts Gegenargument

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of hands on a laptop keyboard in a meeting room, on the screen abstract colored cards and connector lines like a workflow graph, a coffee cup beside, soft daylight, no logos, no brand marks, no readable text, no letters, no numbers, no watermarks, 16:9

Das stärkste Gegenargument liefert Microsoft selbst. Laut Blog können Organisationen die Skills in eigene Agenten und „AI harnesses“ erweitern, also in die Arbeitsumgebungen, die ihre Teams ohnehin nutzen. Und in Microsoft Learn steht für Customer Service, man könne Cowork um eigene Skills ergänzen, zugeschnitten auf Workflows, Wissensquellen und Triage-Regeln des Teams. Solche eigenen Skills lassen sich anlegen und installieren; sie liegen laut Learn in OneDrive.

Dazu kommen Checkpoints. Laut Learn lassen sie Servicemitarbeitende vorgeschlagene Feldänderungen und Aktionen prüfen und freigeben, bevor irgendetwas in Dynamics 365 gespeichert wird. Servicebezogene Tool-Aufrufe können laut Learn eine Freigabe durch Nutzende erfordern, bevor Cowork sie anwendet.

Also alles halb so wild? Nicht ganz. Ein Checkpoint prüft eine vorgeschlagene Änderung. Er prüft nicht, ob der Vorschlag auf einer Logik beruht, die Sie je bewusst gewählt haben. Wer jeden Vorschlag freigibt, weil er plausibel klingt, hat die Logik trotzdem übernommen, nur mit Unterschrift.

Eine offene Frage bleibt: Ob sich Microsofts Standard-Skills selbst verändern lassen oder nur ergänzen und erweitern, sagt die Quelle nicht. Das sollten Admins und Führungskräfte vor einem Rollout klären, bevor jemand eine Annahme trifft.

Wessen Meinung steckt im Skill?

Nehmen wir Deal rescue. Ein Skill soll untersuchen, warum eine Opportunity stockt. Wie viele Wege gibt es, das zu tun? Unzählige. Man kann auf Aktivitäten schauen, auf Gesprächsinhalte, auf Entscheidungswege, auf Wettbewerb, auf Preisfragen, auf interne Blockaden. Welche Evidenz in welcher Reihenfolge zählt, ist eine Entscheidung. Ich unterstelle Microsoft hier nichts Böses. Im Gegenteil: Der Konzern muss für sehr viele Organisationen eine brauchbare Mitte treffen.

Genau das ist das Problem. Eine Mitte ist für alle gleich.

Stellen Sie sich zwei Unternehmen vor, die denselben Markt bedienen. Beide fahren denselben Deal rescue mit denselben Standardregeln. Beide bekommen bei einem stockenden Angebot dieselbe Art von Rückfrage-Empfehlung. Beide bewerten dieselben Signale als Warnzeichen. Wo bleibt da der Unterschied, der Ihnen einen Vorsprung verschaffen könnte? Meiner Einschätzung nach genau dort: Die Kriterien, nach denen gewonnen oder verloren wird, sind kein Wettbewerbsvorteil mehr, wenn alle sie aus derselben Bibliothek ziehen.

Die harte Wahrheit: Ein Skill von der Stange ist eine Beratung, die Ihre Konkurrenz auch bucht.

Das ist meine Einordnung, Max’ Einordnung, keine Microsoft-Aussage. Ob die Skills im Alltag tatsächlich so einheitlich wirken, kann ich nicht belegen. Es gibt keine Zahlen, keine Kundenbeispiele, keine Messung. Die Quelle liefert Ankündigung und Dokumentation, mehr nicht.

Gatekeeper hier, Skill-Schicht dort

Zum Vergleich: Wir bei digital-magazin.de haben am Freitag, 9. Oktober, über Googles Gemini agent und das Prompt-Fenster als Gatekeeper geschrieben. Bei Google sitzt die Steuerung in unserer Lesart im Eingabefenster. Bei Microsoft sitzt sie, so lese ich den Blog, in einer Schicht darunter, nämlich in den Anleitungen, die bestimmen, wie die Tools benutzt werden. Zwei Wege zum selben Ziel: Wer die Schicht kontrolliert, in der Anweisungen und Urteile entstehen, kontrolliert die Arbeit. Mehr will ich dazu hier nicht sagen, das ist ein anderes Stück.

Und die Salesforce-Seite? Am 19. September ging es bei uns um Skill-Audits und den Entzug von Skill-Rechten bei Salesforce. Dort lautete die Frage: Wer darf was, und wie kontrolliere ich das nachträglich? Hier lautet sie anders: Wer definiert die Logik im Skill, bevor überhaupt jemand etwas darf? Das eine ist Rechteverwaltung. Das andere ist Strategie.

Microsofts Prüftest für IT-Teams

Ein Satz im Blog gefällt mir besonders, weil er ehrlich ist. Microsoft formuliert (übersetzt): Ein vorgeschlagenes Update sollte nicht wie eine gespeicherte Änderung erscheinen, und ein Entwurf sollte nicht wie eine gesendete Nachricht erscheinen. Wohlgemerkt: „sollte“. Das ist ein Prüfkriterium für IT-Teams, keine technische Garantie. Ob Ihre Umgebung das einhält, müssen Sie selbst testen.

Ich würde diesen Test in jeden Pilot schreiben. Lassen Sie Draft customer reply laufen und prüfen Sie, ob die Servicemitarbeitenden den Unterschied zwischen Entwurf und Versand wirklich erkennen. Lassen Sie Reconcile my opportunity Feldänderungen vorschlagen und beobachten Sie, wie oft jemand ungelesen bestätigt. Das ist unbequem. Es ist aber der einzige Weg, zu erfahren, ob die Checkpoints Kontrolle bedeuten oder nur ein weiteres Fenster, das man wegklickt.

Kennen Sie das? Ein Dialog erscheint zum zwanzigsten Mal, und der Daumen drückt schon, bevor der Kopf liest. Genau da entsteht das Risiko, nicht in der Technik.

Vier Fragen für die Governance Ihrer CRM-Skills

Aus alldem folgt für mich keine Abwehrhaltung, sondern ein Arbeitsauftrag. Vier Fragen, die ich vor einem Rollout beantwortet haben wollte:

1. Welche Skills nutzen wir unverändert, und haben wir ausdrücklich entschieden, dass uns Microsofts Standardlogik dafür reicht?
2. Wo hinterlegen wir unsere eigenen Kriterien, zum Beispiel für „stockend“, „gefährdet“ oder „reif für die nächste Phase“, damit Skills wie Stage advance readiness gegen unsere Regeln prüfen und nicht gegen leere Felder?
3. Wer im Unternehmen verantwortet einen eigenen Skill so wie Code, mit Zuständigkeit, Änderungsprotokoll und Review?
4. Wie prüfen wir regelmäßig Microsofts eigenen Test, dass ein Entwurf nicht als gesendete Nachricht und ein Vorschlag nicht als gespeicherte Änderung erscheint?

Die zweite Frage ist die unbequemste. Wer sie ehrlich beantwortet, merkt oft, dass die Kriterien gar nicht existieren. Dann hilft auch der beste Skill nichts, denn der Default füllt die Lücke ohnehin.

Übrigens ist das keine neue Erkenntnis. Wir bei digital-magazin.de haben im September schon über den ERP-Agent-Gateway und die Frage, wer die Workflows besitzt, geschrieben. Dieselbe Spur, anderes System.

Wer in Ihrem Team die Kriterien aufschreibt

Mein Rat, ohne Umschweife: Schreiben Sie auf, bevor Sie einschalten. Nehmen Sie eine Stunde, setzen Sie Vertrieb, Service und IT an einen Tisch und formulieren Sie in einfachen Sätzen, woran Sie einen gefährdeten Deal erkennen. Nicht perfekt. Nur schriftlich. Dann vergleichen Sie, was der Skill daraus macht.

Falsch wäre auch das Gegenteil. Alles selbst bauen zu wollen, ist Zeitverschwendung, wo die Standardlogik reicht. Für Case triage oder Customer brief mag Microsofts Mitte völlig in Ordnung sein. Wo es dagegen um Ihre Differenzierung geht, um Preisverhandlung, Wettbewerbspositionierung, Phasenfreigabe, sollten Sie das Urteil selbst in der Hand halten.

Und die Konkurrenz? Sie wird dieselbe Bibliothek sehen. Ob sie dieselben Fragen stellt, ist offen.

Das Tool kann jeder, den Skill müssen Sie wollen

Microsoft beschreibt im eigenen Blog ein Fundament, das ich für solide halte: 30 Skills für Cowork, allgemein verfügbar, dazu mehr als 180 Tools über MCP, klare Trennung von Vorschlag und Ausführung, Checkpoints, Erweiterbarkeit. Autopilot bleibt Private Preview, Code geht über Frontier, Preise und Lizenzdetails fehlen. Das ist der belegte Teil.

Der unbelegte Teil ist meine These, und ich halte sie aufrecht: Die Datenanbindung wird in Zukunft kaum noch jemanden unterscheiden. Was Unternehmen unterscheidet, ist die Logik, mit der sie ihre Daten bewerten. Ein Tool ruft den Datensatz ab, das kann jeder. Der Skill entscheidet, was daraus folgt.

Auch im Service gilt das. Wer eine Antwort an die Kundschaft vorbereiten lässt, übernimmt Tonlage und Gewichtung gleich mit. Die Frage ist dann weniger, ob die Automatisierung funktioniert. Sie lautet: Wissen Sie, wonach sie urteilt?

Der Punkt ist: Niemand zwingt Sie, die Standardlogik abzulehnen. Aber sie sollte Ihre bewusste Wahl sein. Wer sie ungeprüft übernimmt, übernimmt mit ihr eine fremde Meinung darüber, wie Ihr Geschäft zu lesen ist.

Wessen Meinung soll in Ihrem CRM stehen?