Snowflakes SnowWork macht Ihr Data Warehouse zur Sales Ops-Aktionsebene. Das 5-Fragen-Audit, bevor Sie die Tür öffnen

Ihr Data Warehouse war ein Speicher. Snowflake hat es soeben in eine Laufzeitumgebung verwandelt. Und Sales Operations (Sales Ops) ist nun für eine Oberfläche verantwortlich, die niemand offiziell übergeben hat.

Was Snowflake tatsächlich ausgeliefert hat

Laut Snowflakes Ankündigung wurde Project SnowWork am 18. März 2026 in der Research-Preview als agentenbasierte KI-Plattform gestartet, die es Geschäftsanwendern ermöglicht, mehrstufige Workflows direkt auf governed Snowflake-Daten auszuführen. Kein Code erforderlich. Kein Ticket ans Data-Team.

Die Plattform kommt mit rollenspezifischen Profilen für Finance, Sales, Marketing und Operations. Jedes Profil versteht die für diese Funktion typische Terminologie und KPIs. Ein Vertriebsmitarbeitender im Sales-Profil kann SnowWork bitten, Territory-Zuweisungen neu zu priorisieren, einen quellenübergreifenden Pipeline-Bericht zu erstellen oder eine board-fertige Präsentation zu erstellen. Der Agent plant die Aufgabe und führt sie direkt gegen Ihre governed Data aus.

Snowflake hat Sales Ops explizit als primären Nutznießer genannt. Das Unternehmen sagte, Teams könnten nun „wiederkehrende Berichterstellung automatisieren, quellenübergreifend ohne Coding arbeiten und präsentationsfertige Ergebnisse in Minuten statt Tagen generieren". Das ist eine echte Fähigkeit. Aber sie bringt eine echte Frage mit sich, die Sales Ops beantworten muss, bevor sich der erste Nutzer einloggt.

Und es gibt eine zweite Ebene. Am 27. Mai kündigte Snowflake seine Absicht an, Natoma zu akquirieren, ein MCP (Model Context Protocol)-Governance-Startup. Natoma fügt eine Server-Registry, eine Identitätsebene und eine Zugriffsrichtlinienebene hinzu, die es SnowWork-Agenten ermöglicht, CRM-Plattformen wie Salesforce und HubSpot, virtuelle private Clouds (VPCs) und On-Premise-Systeme mit verifizierter Governance zu erreichen. Wie CIO.com berichtete, wurde die Natoma-Ebene speziell entwickelt, um Richtliniendurchsetzung in agentenbasierten Systemen einzuführen, die bisher keine hatten.

Der kombinierte SnowWork- und Natoma-Stack verändert die Rolle des Data Warehouse vom passiven Speicher zur aktiven Laufzeitumgebung. Diese Verschiebung ist nicht theoretisch. Sie befindet sich bereits in der Preview.

Key Facts

• Snowflake hat SnowWork im März 2026 in der Research-Preview gestartet und richtet sich mit rollenspezifischen agentenbasierten Profilen an Finance-, Sales-, Marketing- und Operations-Nutzer.
• Die Snowflake-Aktie stieg am 28.-29. Mai 2026 um 36 % (der stärkste Tag seit dem IPO), angetrieben durch Q1-Ergebnisse, eine erweiterte AWS-Partnerschaft und die Ankündigung der Natoma-Akquisition, laut CNBC.
• Die ausstehende Natoma-Akquisition fügt MCP-Governance hinzu, damit SnowWork-Agenten über Salesforce, HubSpot, VPCs und On-Premise-Systeme handeln können, nicht nur innerhalb von Snowflake.

Warum das auf Sales Ops landet, nicht auf IT

IT verwaltet den Infrastrukturzugang. Aber Sales Ops besitzt die Definitionen, die in dieser Infrastruktur leben. Ihre Segment-Logik. Ihre Territory-Regeln. Ihre Quota-Zuweisungen. Ihre Deal-Stage-Kriterien.

Wenn ein Geschäftsanwender SnowWork bittet, „Accounts im Mountain-West-Territory neu zuzuweisen", schreibt der Agent gegen die Segment-Logik, die derzeit in Ihrem Data Warehouse liegt. Wenn diese Logik veraltet ist, teilweise aus einer Tabellenkalkulation migriert wurde oder in einem Feld subtil falsch ist, führt der Agent gegen die falsche Definition aus. In großem Maßstab. Autonom.

Das ist es, was es bedeutet, wenn das Data Warehouse zu einer Aktionsebene wird: Der Abstand zwischen einer schlechten Datendefinition und einer schlechten Geschäftsentscheidung fällt weg. In einem traditionellen Warehouse produziert eine falsche Definition einen falschen Bericht. Jemand bemerkt es bei der Überprüfung. In einem agentenbasierten Warehouse produziert eine falsche Definition eine falsche Aktion. Und diese Aktionen können verkettet werden.

Sales Ops hat schon immer die Bedeutung dieser Definitionen verantwortet. Aber wenn die Definitionen in einem Bericht lebten, waren die Kosten der Ungenauigkeit eine verwirrende Zahl. Jetzt sind die Kosten ein ausgeführter Workflow. Die Governance-Oberfläche hat sich soeben erweitert, und zu verstehen, was es bedeutet, als KI-Sales-Operator zu handeln, ist keine optionale Ergänzung mehr.

Die gute Nachricht: Sales Ops ist hier tatsächlich gut positioniert. Sie verstehen Kontext, den IT nicht hat. Sie wissen, welche Territory-Aufteilung in Q3 stattfand und sich noch nicht vollständig in die Datenschicht propagiert hat. Sie wissen, welche Quota-Spalte ein Legacy-Feld ist, das niemand löscht, aber alle ignorieren. Dieses institutionelle Wissen ist genau das, was ein Pre-Deployment-Audit braucht.

Das 5-Fragen-Sales-Ops-Audit

Führen Sie diese durch, bevor ein Geschäftsanwender eine SnowWork-Oberfläche berührt.

1. Wer verantwortet jede Metrik-Definition, gegen die ein Agent schreiben könnte?

Beginnen Sie mit Ihren 10 wichtigsten KPIs: Abgeschlossener Umsatz, Pipeline nach Stage, Quota-Erfüllung, Territory-Zuweisung, Segment-Zugehörigkeit. Identifizieren Sie für jeden, wer zuletzt die Definition aktualisiert hat, wo die Definition liegt (Warehouse, CRM, Tabellenkalkulation oder alle drei) und ob diese Person noch im Unternehmen ist. Wenn Sie diese drei Fragen für eine Metrik nicht beantworten können, ist die Metrik noch nicht bereit für den Agentenzugriff. KI-gestützte CRM-Datenhygiene ist eine Voraussetzung, kein Zusatz.

2. Welche Territories, Segmente und Quotas leben noch in Tabellenkalkulationen (nicht in Snowflake)?

SnowWork operiert auf dem, was im Warehouse liegt. Wenn Ihre Q2-Territory-Neusegmentierung noch in einem Google Sheet auf ein Data-Team-Ticket wartet, weiß SnowWork nichts davon. Ein Agent, der gebeten wird, „die Territory-Abdeckung zu optimieren", wird gegen Q1-Daten optimieren. Auditieren Sie vor der Aktivierung von SnowWork für Sales-Nutzer die Lücke zwischen Ihrem offiziellen Datenmodell und dem Ort, wo die tatsächlichen Arbeitsdaten leben. Automatisierte Lead-Routing-Logik und Echtzeit-Account-Tier-Neuzuweisung sind nur so gut wie die Daten, auf denen sie laufen.

3. Was ist der Rollback-Pfad, wenn ein Agent fälschlicherweise ein Territory neu zuweist oder einen Deal-Stage verschiebt?

Definieren Sie das, bevor Sie es brauchen. Wer wird benachrichtigt? Wie ist der Rücksetzprozess in Salesforce? Erstellt der CRM-Write-back aus der Natoma-MCP-Ebene ein Audit-Ereignis, oder sieht er identisch aus wie eine manuelle Rep-Aktion? Ein nützlicher Test: Wählen Sie einen historischen Territory-Zuweisungsfehler aus den letzten 12 Monaten und gehen Sie durch, wie Sie ihn heute rückgängig machen würden. Prüfen Sie dann, ob dieser Prozess noch funktioniert, wenn der Fehler von einem Agenten statt von einem Menschen stammt.

4. Wie stufen Sie den Zugang zwischen „kann lesen" und „kann handeln" ab, und wo liegt diese Richtlinie?

Lesezugang und Handlungszugang sind unterschiedliche Risikoflächen. Ein Vertriebsmitarbeitender, der einen Pipeline-Bericht liest, ist Standard. Ein Vertriebsmitarbeitender, der SnowWork zur Präsentationserstellung nutzt, ist ein kleiner Schritt. Ein Vertriebsmitarbeitender, der SnowWork zur Neuzuweisung von Accounts oder zum Verschieben von Deal-Stages nutzt, ist ein wesentlich größerer Schritt. Die Natoma-Governance-Ebene fügt Richtliniendurchsetzung hinzu, aber jemand muss die Richtlinie schreiben. Das ist Sales Ops, nicht IT. Datenklassifizierung für KI-Zugang gibt einen Framework für die Abstufung. Ordnen Sie Ihre Snowflake-Objekte Zugangsstufen zu, bevor der erste Pilot beginnt.

5. Was ist der Audit-Trail, wenn ein Deal Stage wechselt, weil ein Agent es vorgeschlagen hat?

Diese Frage ist aus zwei Gründen wichtig. Erstens: Forecast-Genauigkeit. Wenn eine Agentenbewegung eine Stage-Anzahl aufbläst oder deflationiert, müssen Sie das wissen. Zweitens: Coaching. Wenn ein Deal die Stage wechselt, weil ein Agent es vorgeschlagen hat und ein Rep auf „Annehmen" geklickt hat, ist das ein anderes Coaching-Gespräch als bei einem Rep, der die Entscheidung eigenständig getroffen hat. Audit-Trails für von KI ausgeführte Aktionen sind keine optionale Infrastruktur. Sie sind der Weg, Verantwortlichkeit in einem System aufrechtzuerhalten, in dem Menschen und Agenten einen Workflow teilen.

FAQ

Was ist Snowflake Project SnowWork?

SnowWork ist Snowflakes agentenbasierte KI-Plattform, die im März 2026 in der Research-Preview gestartet wurde. Es ermöglicht Geschäftsanwendern, mehrstufige, autonome Workflows direkt auf governed Snowflake-Daten auszuführen, ohne Code zu schreiben oder ein Data-Team einzubeziehen. Nutzer interagieren mit einer rollenspezifischen Oberfläche, die die typische Terminologie und KPIs ihrer Funktion versteht. Für Sales Ops bedeutet das, dass Aufgaben wie Territory-Analyse, Pipeline-Reporting und Präsentationserstellung von einem Geschäftsanwender statt einem Data-Engineer ausgelöst werden können.

Wie unterscheidet sich SnowWork von einem regulären Business-Intelligence-Tool oder einem CRM-Bericht?

Ein Business-Intelligence-Tool (BI) liest Daten und gibt eine Visualisierung zurück. Ein CRM-Bericht zieht einen gefilterten Snapshot. SnowWork plant und führt Workflows aus. Es kann mehrere Schritte verketten, über die Natoma-MCP-Ebene (Model Context Protocol) in Systeme zurückschreiben und Ergebnisse wie Präsentationen oder Neuzuweisungsaktionen produzieren, nicht nur Diagramme. Der Unterschied ist wichtig, weil sich der Fehlermodus ändert: Ein falsches BI-Diagramm ist ein falsches Diagramm. Ein falscher SnowWork-Workflow ist eine falsche Aktion, die gegen Live-Systeme ausgeführt wird.

Sollte Sales Ops Geschäftsanwendern erlauben, SnowWork direkt zu nutzen?

Ja, aber noch nicht, und nicht ohne das Audit. Die fünf Fragen oben sind keine Checkliste, um die Einführung zu verzögern. Sie sind die Mindest-Sorgfaltspflicht, bevor Sie einem Agenten erlauben, auf Daten zu handeln, die Ihr Team besitzt. Die Nutzer, die am meisten von SnowWork profitieren werden: Vertriebsmitarbeitende, Sales Manager und Ops-Analysten, werden echte Zeitersparnisse finden. Das Risiko ist nicht das Tool. Es ist, eine Tür zu öffnen, bevor Sie wissen, was dahinter ist.

Was Sie diese Woche tun sollten

• Einen einwöchigen Pilot mit einem Team, einem Workflow und einem Rollback-Test aufsetzen. Der ideale Pilot-Workflow ist einer, der einen Mitarbeitenden derzeit 30-60 Minuten kostet und ein einzelnes Ergebnis produziert (ein Territory-Bericht, ein Forecast-Deck, eine Account-Liste). Führen Sie die Agentenversion parallel zur manuellen Version aus und vergleichen Sie die Ergebnisse.
• Ihre Metrik-Definitions-Verantwortlichkeit für die 10 wichtigsten KPIs auditieren, über die Sales Ops berichtet. Für jede Metrik: Wer besitzt die Definition, wo liegt sie und ob sie vollständig in Snowflake geladen ist oder noch in einer Tabellenkalkulation steckt.
• Einen Rollback-Test festlegen, bevor Ihr Pilot beginnt. Wählen Sie die riskanteste Aktion, die Ihr Pilot-Workflow ausführen könnte (die mit den schwerwiegendsten Konsequenzen bei einem Fehler), und bestätigen Sie, dass der Rücksetzpfad funktioniert. Dann dokumentieren Sie ihn.
• Das Gespräch über Zugangsstufen jetzt mit Ihrem Data-Team eröffnen. Die Natoma-Governance-Ebene gibt Snowflake die Infrastruktur zur Richtliniendurchsetzung. Sales Ops muss definieren, wie die Richtlinie tatsächlich aussieht. Dieses Gespräch dauert länger als einen Sprint. Beginnen Sie es, bevor Sie unter Druck stehen.

Weiterführende Informationen

• Was ist ein KI-Sales-Operator
• KI Sales Ops vs. Traditionelle Sales Ops
• Warum Sales Ops den höchsten ROI bei KI-Anwendungsfällen hat
• Vom Anruf zum automatischen CRM-Update
• Unternehmen verfehlen Umsatzziele bei KI-Ausgaben und Daten
• OpenAI Workspace-Agenten in Salesforce und Slack