dots for teams: Pro, Business Premium or Enterprise

Business Premium is the plan an organisation needs: it includes dots across every region where ChatGPT is available, without the geographic exclusion affecting the Pro plan. Enterprise, Edu and Healthcare get access through a beta that ships off by default until an admin enables it.

The three paths compared

	Pro	Business Premium	Enterprise / Edu / Healthcare
Dots included	1	1	Beta, enabled by an admin
Geographic coverage	Excludes the EEA, Switzerland, the UK	All supported regions	All supported regions
Default state	On	On	Off
Billing	Personal	Per seat	Per seat / agreement
Who enables it	The user	The user	A workspace admin

The row that matters most for a corporate decision is the second: if your organisation operates in Europe, Pro is not an option and Business Premium is.

What is already documented for teams

Its own Slack identity

A dot can have a separate Slack account, with its own identity and access in those services. That is a meaningful difference from agents that always act with the employee’s credentials: the dot shows up as a distinct actor with its own history.

It simplifies auditing and limits the blast radius if something goes wrong: access is revoked in one place, not everywhere.

Shared and centralised permissions

Plugin connections are shared across dots, ChatGPT, ChatGPT Work and Codex, and managed from ChatGPT’s Plugins tab. Two consequences:

• Good: there is already a single place where an admin reviews which apps are connected.
• Bad: the dot inherits the permissions you already gave ChatGPT. If the workspace had broad access, the dot starts with it.

Rules and pre-action review

The controls apply the same in a corporate context: per-action custom rules, Auto-review before sensitive actions, and an activity view to follow the work. An admin cannot disable core safety requirements, rules included.

Data in workspaces

• In Business, Enterprise and Edu, content is not used to improve models by default.
• But limited human review may occur, including in safety-related cases, even with model improvement off. That nuance is worth reading before delegating sensitive information.

What is still unverified

We will be explicit, because this is the part others omit:

• SSO and SCIM for dots: we have not verified whether dedicated provisioning controls exist.
• Exportable audit log: the activity view is visible in the app; we have not verified an export for compliance.
• Certifications (SOC 2, ISO 27001) scoped to dots usage: we have not verified coverage.
• Data residency for dots’ cloud computers.
• Admin-configurable geographic restrictions.

If those points are decisive for your evaluation, the right route is to ask OpenAI directly. We would rather mark them unverified than fill them in.

A sensible adoption sequence

1. Pilot with a small team and scoped tasks. No consequences if something fails.
2. Review inherited plugin permissions before connecting anything new.
3. Set baseline rules for the whole organisation: reads open, outbound writes with approval, payments and credentials out of scope.
4. Name an owner for the activity view. An agent with no owner for its audit is a risk, not a productivity gain.
5. Separate use cases by risk. Anything that writes outward needs more control than anything that only reads.

When a specialized dot is the better fit

If what you want is not an assistant per employee but an automated role with defined responsibilities, that is a different product category: specialized dots, with their own identity and credentials, in a pilot programme with OpenAI’s engineering team.

The difference is framing: a dot per employee is a tool; a specialized dot is a position.