Can a Dot make commitments to a customer on its own?

No. Commitments should pass through human approval. In OpenAI's scenario the Dot updates the proposal, builds a proof of concept and suggests a solutions engineer, but pricing, contractual terms and promises stay with your team. See Dots security and privacy .

What does the Dot actually do with a customer's requirements?

It checks the requirements and account history against your product documentation, finds what needs testing, builds a proof of concept, and keeps the proposal and test plan in step as things change.

Does this replace a solutions engineer?

No. The scenario has the Dot suggest a solutions engineer, which points to human expertise for the evaluation that matters. The Dot handles the preparation and the paperwork around it.

How should a sales team start?

Begin with one active opportunity and a single deliverable such as a test plan. Our free Agent Readiness Scorecard can help you pick a workflow that is ready for an always-on agent.

OpenAI Dots for Sales Teams: Proposals That Keep Up With Requirements

Enterprise sales is a long conversation between a customer's requirements and a product that keeps changing. Documents multiply: discovery notes, account history, product documentation, a proposal, a test plan, the proof of concept that has to be built and re-run. The work is not one hard task but a moving set of small ones, and it all has to stay consistent. OpenAI's sales scenario for Dots is aimed squarely at that maintenance burden.

For the product background, see what Dots are. This page focuses on the sales workflow and, in particular, on the approvals that keep it safe.

The scenario

A sales lead's Dot checks a customer's requirements and account history against product documentation. It finds what needs testing, builds a proof of concept, suggests a solutions engineer, and updates the proposal and test plan as things change. The pattern is a familiar one: keep the artifacts synchronised with the latest reality so the human can focus on the conversation.

What the Dot does end-to-end

Reads the requirement. It compares what the customer asked for against your product documentation and the account's history.
Finds the gaps. It identifies what needs testing rather than assuming an answer.
Builds a proof of concept. Using its own cloud computer and browser, and the ability to write and test code, it can assemble a working demonstration.
Brings in expertise. It suggests a solutions engineer where a person should take over.
Keeps documents current. It updates the proposal and test plan as requirements and scope change.

Because a Dot works 24/7 and can handle several projects at once, this upkeep continues between calls. Context carries across channels too: reach the Dot in ChatGPT, in Slack and Teams, or let it message you when a proposal needs a decision. Texting via iMessage/RCS is coming on a limited Pro waitlist.

Approvals are the point

Sales is where an error becomes a commitment, so approvals are not a formality. OpenAI's safeguards support an approval-first design:

Auto-review checks actions against your instructions, Custom Rules and safety requirements before consequential steps.
Custom Rules let you encode what the Dot must never send, promise or price without a person.
Proactive research is read-only. It cannot send messages, change app content, or control your browser or computer.
Sensitive tasks always stay with you, and OpenAI can pause or stop a Dot if monitoring finds a concern.
The activity view shows what the Dot did, including background work.

Two boundaries are worth stating plainly. First, the Dot should prepare, not commit: pricing, contractual terms and delivery promises go out under a human's name. Second, Dots can make mistakes, so every customer-facing artifact needs review before it ships. The security and privacy guide covers the full control set.

How to split the work

Step	Dot	Your team
Discovery	Match requirements to product docs and history	Confirm what the customer really needs
Fit analysis	Flag what needs testing	Decide whether to pursue
Proof of concept	Build and test a demonstration	Review results, bring the solutions engineer
Proposal	Draft and update the proposal and test plan	Approve pricing and commitments
Change control	Rerun the comparison as scope moves	Sign off on the new version

Risks and guardrails

Over-claiming. A Dot can bridge from documentation to a promise it should not make; Custom Rules should mark commitments as human-only.
Stale evidence. Proof of concept results age quickly; tie each to a date and a re-test trigger.
Data boundaries. Keep customer data within the systems you have approved and review what the Dot can reach.
Overlap with humans. Make the hand-off to a solutions engineer explicit so ownership is never ambiguous.

Longer term, some of this work may move to specialist Dots — organizational agents with their own identity, credentials and access to systems of record, which OpenAI is testing in areas including commercial contracting. For now, the same principles apply: the agent prepares and evidences, a person approves and signs.

A practical rollout checklist

Choose one live opportunity and one deliverable, such as a test plan.
Connect the CRM, document store and product docs the Dot needs.
Describe the outcome and name the human approver for every artifact.
Write Custom Rules that make pricing and commitments human-only.
Require a review step before anything reaches the customer.
Track proposal cycle time and how often the Dot spots a real gap.
Expand only once the approval loop holds. The Agent Readiness Scorecard helps you choose the next workflow.

Source: OpenAI, Introducing dots and the Dots help center.