OpenAI Presence is worth considering when a large, repeatable customer workflow needs a managed voice or chat agent with governed access to business systems. It is not a self service tool that a team can switch on in an afternoon. OpenAI currently offers it in limited general availability for eligible enterprise customers (OpenAI's official Presence launch).
That makes the buying question operational, not merely technical. A capable agent can reason, follow procedures, use approved tools, and escalate. Your company must still decide where a conversation begins, how identity is established, which actions are allowed, who owns exceptions, what evidence proves success, and how the system recovers when something changes.
This guide turns those decisions into a fit test and a bounded pilot.
What OpenAI Presence includes
OpenAI describes Presence as a managed enterprise product for voice and chat agents in customer support, outbound sales, and high risk internal workflows. The launch material describes agents that can connect to company systems, permissions, and policies, follow standard procedures, complete approved actions, reach people when needed, and improve through evaluations and controlled changes (the official launch).
The word managed matters. OpenAI says deployments are led by its Forward Deployed Engineers and select systems integrators. Presence is therefore closer to an enterprise program with implementation support than a general software subscription. Buyers should not assume a specific channel, model, connector, capacity, retention rule, price, or service level until it is written into their deployment scope.
That boundary is useful. It keeps a new product announcement from becoming an imaginary feature list. It also gives procurement a direct first question: can the organization support a managed implementation and the operating work that follows?
Who should consider it now
Presence is a serious candidate when the workflow has all of these traits:
- enough volume or business value to justify a managed enterprise deployment;
- a repeatable procedure that experts can explain and test;
- systems that expose approved actions through controlled tools;
- clear human owners for ambiguity, sensitive cases, and failed dependencies;
- measurable outcomes beyond message speed;
- an operating team that can review evidence and approve changes.
A team may be too early when its policies live only in employee memory, customer identity is unreliable, no one owns exceptions, or the underlying systems cannot expose safe actions. An agent does not remove those gaps. It can make them occur faster and at greater scale.
Choose the workflow before choosing the technology. A narrow order status journey with reliable identity and a clear escalation path is easier to govern than a broad promise to automate customer service. High risk requests involving payments, legal commitments, account access, safety, or vulnerable customers need stricter authority boundaries and earlier human ownership.
Map six operating boundaries before you buy
Write a one page boundary map for the candidate journey. Use six boxes.
- Channel entry. State where the customer enters and what happens if they change channel. Do not assume every Presence deployment supports every channel.
- Identity and context. Define the evidence required to recognize a customer, the records the agent may read, and how uncertain matches are handled.
- Authority and actions. List what the agent may explain, recommend, create, update, cancel, refund, or never do. Tie each consequential action to permission and validation.
- Human handoff and ownership. Name the queue or role that accepts an escalation, the context that travels with it, the response clock, and what happens if nobody accepts.
- Evidence and measurement. Define success in customer terms. A reply is not proof that a refund settled, a technician arrived, or a booking changed.
- Change control and recovery. Record who may change instructions, tools, or thresholds, how a new version is evaluated, and how the team pauses or rolls back unsafe behavior.
The map should identify a system of record for every important field. It should also separate a temporary dependency failure from an agent reasoning failure. Those problems need different owners and different remedies.
Test one customer journey before you scale
Run a representative journey through five planned conditions: the normal path, an ambiguous request, a restricted action, a failed dependency, and a customer who asks for a person. Use safe test accounts where real customers should not carry the risk.
For every condition, set acceptance criteria in five columns:
- Customer outcome — The requested result and confirmation rule
- Policy behavior — The instruction or limit that governed the response
- Tool action — The requested action, validation, result, and error
- Human ownership — The named queue, acceptance time, and transferred context
- Recovery — The retry, pause, fallback, or rollback that restored control
Review the full trace with frontline operators, system owners, security, and risk. Measure completion, correction, unowned time, escalation acceptance, and recovery. Do not let a high automation rate hide the difficult cases that create cost or harm.
Expand only after the same journey passes again following a controlled change. That second pass proves the team can operate the system, not just demonstrate it once.
Decide what stays in your conversation stack
Presence can be the managed agent layer for an approved workflow. It does not automatically replace the customer conversation stack around that layer. Most organizations still need channel entry, customer identity, queue ownership, agent workspaces, private collaboration, case state, reporting, consent records, and a durable handoff path.
Draw the stack as responsibilities, not vendor logos. Mark where messages arrive, where identity is resolved, where the agent reasons, where tools execute, where a person accepts work, and where outcomes are recorded. For each boundary, define the event, owner, timeout, evidence, and recovery path.
This prevents two common mistakes. The first is sending an automated answer while a person already owns the case. The second is treating an agent trace as the customer record even when another approved system owns orders, reservations, payments, or account state.
Ask these questions during procurement
Ask for deployment specific answers rather than assumptions:
- Which voice and chat channels are included in our scope?
- Which models, regions, capacity limits, data controls, retention terms, and service levels apply?
- Who builds and maintains each tool connection?
- How are permissions checked before consequential actions?
- What context reaches a human and how is acceptance recorded?
- Which evaluation set blocks a release?
- How are tool errors, policy changes, and instruction changes detected?
- Who can pause the workflow and how quickly can the last safe version return?
- What evidence can operations, security, and auditors inspect?
- What is included in implementation, ongoing improvement, and commercial terms?
Record unanswered questions as launch blockers or explicit risks. A polished demo is useful, but it is not a deployment contract.
How DripTell fits the operating model
DripTell can support the conversation operation around an AI workflow. Its current AI capabilities cover intent understanding, approved knowledge, human handoff, and lead scoring. The team inbox provides assignments, private notes, statuses, customer context, and controls that return work to people. Automation provides triggers, conditions, assignments, waits, approved webhooks, and human handoff actions.
These are relevant when a business needs channel conversations to become owned work before, during, or after an agent interaction. They are not a claim that DripTell integrates with OpenAI Presence. Any connection, channel, data flow, and permission model must be confirmed for the actual deployment. AI Calls is also an early access DripTell capability, not a generally available substitute for Presence.
A useful architecture conversation starts with the six boundary map. It then assigns each responsibility to a verified product capability, an authoritative business system, or a named human team.
Final decision
OpenAI Presence fits when the managed enterprise approach matches the value and risk of a repeatable workflow, and when the company is ready to own the operating boundaries around the agent. It is a poor fit when the business is looking for instant self service automation, cannot define allowed actions, or lacks owners for exceptions and recovery.
Make the decision on one journey and its evidence. If you want to map how customer conversations, ownership, and human handoff should work around that journey, talk with DripTell. Bring the policy, systems, exception owners, and recovery plan rather than a generic automation target.
Frequently asked questions
Is OpenAI Presence self service
No. OpenAI currently describes Presence as a managed enterprise product in limited general availability, led by its deployment teams and select systems integrators. Eligibility and the deployment scope must be confirmed with OpenAI.
Does OpenAI Presence replace a customer service platform
Not automatically. Presence can provide the managed agent layer for a defined workflow. A business may still need channels, identity, queues, human workspaces, case state, reporting, consent, and authoritative systems. Map responsibilities before deciding what it replaces.
Which workflow should a team pilot first
Choose one repeatable journey with a valuable outcome, reliable identity, controlled tools, measurable completion, and a reachable human owner. Include ambiguity, a restricted action, a failed dependency, and a request for a person in the test.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy