ooligo

OpenAI Presence

ai-customer-experience ai-support-agent · voice-ai · conversational-ai
AI-NATIVE
RevOpsCustomer Success
6.8 /10

Was es ist

OpenAI Presence ist die gemanagte Plattform von OpenAI, um Voice- und Chat-Agents in Produktion zu bringen, gestartet am 22. Juli 2026. Es ist kein Modell und kein Self-Serve-Builder. Es ist ein deploytes Produkt: Forward Deployed Engineers (FDEs) von OpenAI oder ausgewählte globale Systemintegratoren definieren mit Ihnen einen konkreten Job – ein Abrechnungsproblem lösen, einen Versicherungsschaden begleiten, ein IT-Ticket eines Mitarbeiters schließen –, binden die Systeme an, die dieser Job braucht, kodieren Ihre Richtlinien und Eskalationsregeln, testen den Agent und bringen ihn live. Der Launch-Post von OpenAI nennt Kundensupport, Outbound-Vertrieb und interne Workflows mit hohem Risiko als unterstützte Einsatzformen.

Die Plattform bündelt Bausteine, die Sie sonst selbst zusammensetzen würden: Standard Operating Procedures und Richtlinien, Guardrails, eng berechtigte „genehmigte Aktionen” gegen Ihre APIs, Simulationen und Grader, die vor dem Release laufen, sowie einen Verbesserungszyklus nach dem Launch, in dem Codex über ein Presence-Plugin Produktionssessions und Eskalationen auswertet und Änderungen vorschlägt, die Ihr Team gegen die Live-Version testet, bevor ein kontrollierter Rollout folgt.

Es ist ein eigenes Produkt, getrennt von den Agents, die Sie in ChatGPT bauen. Das OpenAI-Help-Center zieht die Linie klar: ChatGPT Workspace Agents werden in ChatGPT- und Slack-Workspaces erstellt und geteilt; Presence-Agents werden mit OpenAI oder einem Partner definiert und deployt und nie über diese Oberfläche gebaut.

Die bisherige Evidenz

Die englischsprachige Telefon-Support-Hotline von OpenAI selbst läuft auf Presence. OpenAI berichtet, dass sie 75 % der eingehenden Anliegen ohne Menschen löst und dass der Codex-Verbesserungszyklus die Übergaben an Menschen in 10 Tagen um 15 Prozentpunkte gesenkt hat. Beide Zahlen sind selbst berichtet, und OpenAI hat nicht veröffentlicht, wie es „gelöst” definiert.

Die genannten Kunden sind früh dran: BBVA ist Design-Partner und erkundet Voice-Support für alltägliche Bankgeschäfte in Mexiko, SoftBank testet japanischsprachige Kundengespräche, und IAG erkundet Support bei Lastspitzen wie Unwetterereignissen. Keiner wurde zum Launch als vollständiges Produktiv-Deployment beschrieben.

Preisrealität

Es gibt keinen öffentlichen Preis, keine veröffentlichte Abrechnungseinheit und kein genanntes Minimum. Laut OpenAI-Help-Center werden Preis, Modelle, Kanäle, Kapazität und Datenverarbeitung pro Deployment festgelegt, und der Zugang hängt von „Workflow-Fit, Implementierungsbereitschaft und verfügbarer Delivery-Kapazität” ab. Nehmen Sie das wörtlich: Im Limited GA bewerben Sie sich um FDE-Zeit, Sie kaufen keine Lizenz.

Unsere Planungsschätzung, keine angebotene Zahl: Budgetieren Sie wie bei Sierra, dem nächsten ergebnisbasierten Wettbewerber, dessen Verträge im Bereich von $150K–$350K+ pro Jahr liegen, plus die internen Kosten für Security-, Datenschutz- und Rechtsprüfung und die Systemintegrationsarbeit, die Ihr eigenes Team trägt. Wenn Ihr Volumen kein sechsstelliges Jahresbudget trägt, passt Presence heute nicht.

Am besten geeignet für

Enterprise-Support- und CX-Verantwortliche mit volumenstarken, richtlinienlastigen Voice- oder Chat-Journeys – Abrechnung, Schadensfälle, Kontoservice –, die bereits eine Enterprise-Beziehung zu OpenAI haben und wollen, dass OpenAIs eigene Engineers den Build verantworten. Es passt auch zu RevOps-Teams, die einen Outbound- oder Qualifizierungs-Voice-Agent pilotieren, bei dem die von OpenAI geführte Umsetzung den Ausschlag gibt.

Lassen Sie es, wenn Sie noch dieses Quartal ohne Sales-Zyklus starten müssen, wenn Sie Ihr CCaaS ersetzen wollen (Presence beschreibt weder Routing noch Workforce Management noch Qualitätsmanagement) oder wenn Ihr Team den Agent-Code selbst besitzen will – dann bauen Sie direkt auf der OpenAI API, die OpenAI nach eigener Aussage für Voice-Kunden weiter unterstützt.

Im Vergleich zu den Alternativen

Die beiden etablierten Optionen sind Sierra, der ergebnisbasiert bepreiste Pure Player mit Voice-Deployments im großen Maßstab, und Salesforce Agentforce, der Standard, wenn Ihr Service Desk bereits in Salesforce lebt. Der am schnellsten wachsende Neueinsteiger ist Decagon. Wählen Sie Sierra oder Decagon, wenn Sie einen Anbieter mit vielen namentlich bekannten Produktiv-Deployments und einen Vertrag wollen, der definiert, was eine Lösung ist; wählen Sie Agentforce, wenn CRM-Konsolidierung schwerer wiegt als die Modellwahl. Für telefonzentrierte Contact Center bieten Parloa und PolyAI eine Telefonie-Tiefe, die Presence nicht dokumentiert hat. Wählen Sie Presence, wenn Sie OpenAI-Modelle mit OpenAI-FDEs in der Ergebnisverantwortung wollen und auf Delivery-Kapazität warten können.

Worauf Sie achten sollten

  • Der Beleg ist OpenAIs eigene Hotline. Ein Anbieter, der seinen eigenen Support automatisiert, kämpft mit keinen Altsystemen und kontrolliert das Modell vollständig. Absicherung: Legen Sie im Pilotvertrag eine Baseline für Containment und Genauigkeit aus Ihren aktuellen Tools fest, definieren Sie „gelöst” anhand Ihrer Wiedereröffnungs- und Wiederholungskontaktraten und machen Sie die Ausweitung davon abhängig, dass die Baseline über ein volles Quartal übertroffen wird.
  • Jede Bedingung gilt pro Deployment, also ist nichts Standard. Datenaufbewahrung, Speicherregion, Modellkonfiguration und Preis können vom Kunden nebenan abweichen. Absicherung: Lassen Sie Aufbewahrung, Maskierung, Region und Ankündigungsfrist für Modellwechsel in der Deployment-Dokumentation festschreiben, bevor die Security-Freigabe erfolgt, und verlangen Sie vor jedem Modellwechsel eine Ankündigung und einen erneuten Lauf Ihrer Evaluation-Suite.
  • Delivery-Kapazität ist der Engpass, und Lock-in folgt ihr. Agents, die OpenAI-FDEs in Presence bauen, sind kein portabler Code in Ihrem Besitz. Absicherung: Halten Sie SOPs, Richtlinienregeln, Testszenarien und Grader-Kriterien vom ersten Tag an in Ihrem eigenen Repository, damit ein Wechsel zu Sierra, Decagon oder einem eigenen API-Build sie wiederverwendet, statt bei null anzufangen.