Build a Voice-to-Work Workflow in ChatGPT: Email, Calendar, Slack, Browser Tasks, On-Screen Approvals, and Text Handoff

What a Voice-to-Work Workflow Is—and What It Is Not

A Voice-to-Work workflow is a governed sequence for using spoken instructions to start useful work in ChatGPT, retrieve information from authorized apps, create drafts or artifacts, review proposed actions, approve only the intended external steps, capture evidence of what happened, and hand off unfinished work into text without losing the approval trail. It is not a permission slip for ChatGPT to roam through email, calendars, Slack, cloud documents, browsers, or business systems without supervision.

The distinction matters because OpenAI’s September 23, 2026 release notes say Live now supports plugins on web, iOS, and Android, and Voice is available in Work on web and mobile. OpenAI also says users can use the plugins and connected apps available to their account during a Voice conversation, follow written responses in the chat, ask Voice in Work to create documents, presentations, and spreadsheets, use connected apps, or work in a browser. Those capabilities make voice a practical front door for work, but they do not remove account authorization, workspace controls, app permissions, approval prompts, usage limits, or human responsibility for consequential operations.

In this tutorial, “Voice-to-Work” means you speak a structured request such as “look up the current project email thread, draft a reply, check my calendar for three available times, prepare a Slack update, and stop before sending anything.” ChatGPT may retrieve information from connected apps that are available to the selected experience and may prepare drafts or artifacts. Before any email is sent, Slack message is posted, calendar invite is created, browser action is submitted, document is shared, account setting is changed, booking is made, or purchase is attempted, an authorized human must inspect the output and use the required on-screen approval path where approval is required.

OpenAI’s Work and Codex help page states that Voice uses the tools and permissions available to the selected experience. That single sentence should shape the entire operating model. A voice request in Chat is not the same as a voice request in Work, and a Work task on web or mobile is not the same as a desktop Work or Codex session. The available tools, permissions, account context, workspace policy, role, and app connections can differ by plan, account, workspace, app, surface, region, rollout, and administrator setting.

The safest mental model is “speech starts and steers a governed workflow; screens approve consequences.” OpenAI says that on web and mobile, actions requiring approval must be approved or declined through on-screen controls and that spoken approval is not supported. Therefore a user saying “yes, send it” should not be treated as sufficient for an approval-gated action on those surfaces. The workflow should pause, display the proposed action, require the user to verify the recipient, content, account, and consequences, and then use the product’s available on-screen control to approve or decline.

Because OpenAI’s accuracy guidance says ChatGPT can produce incorrect or misleading outputs, fabricated references, and confident but wrong claims, the workflow must treat generated work as a draft until verified. Voice transcripts may also not exactly match what was said, according to OpenAI’s Voice documentation. That means names, dates, addresses, amounts, recipients, file names, contractual commitments, meeting times, and instructions with similar-sounding words need a deliberate verification step before any external action.

A good Voice-to-Work workflow therefore separates six stages: retrieval, interpretation, drafting, human review, approved action, and evidence capture. If you collapse these stages into a single spoken command—“read my email, decide what matters, reply to the client, move the meeting, update Slack, and finish the purchase”—you remove the checkpoints that prevent account mix-ups, wrong-recipient messages, accidental disclosure, duplicate calendar holds, unreviewed browser submissions, and unauthorized commitments.

The Operating Pattern: Speak, Retrieve, Draft, Review, Approve, Capture, Handoff

The practical pattern is simple enough to teach across a team but strict enough for enterprise administrators, founders, executive assistants, developers, legal-technology professionals, educators, and advanced ChatGPT users to audit. Each task should begin with a spoken instruction that defines the account, apps, data class, permitted actions, stop conditions, and reviewer. ChatGPT should then retrieve only the necessary information, create a written summary and draft artifact, ask for clarification when the instruction is ambiguous, and stop before any external or destructive step.

A recommended spoken opening is: “Use my work account only. Read the latest approved sources from Gmail, Calendar, and Slack for the Phoenix launch. Summarize what you found with source names. Draft, but do not send, an email to the partner and a Slack update to the internal channel. Stop before posting, sending, booking, deleting, purchasing, or changing permissions. I will review everything on screen.” This instruction tells ChatGPT what to do, what not to do, which account context matters, and which actions require a hard stop.

For a browser task, the same structure should be even more explicit because browser sessions can involve signed-in accounts, forms, uploads, shopping carts, ticketing systems, portals, or administrative settings. A safer spoken request is: “Open the browser task only for research and draft preparation. Do not submit forms, accept terms, purchase anything, change settings, upload confidential files, delete records, or send messages. If a page asks for credentials, payment, identity information, protected health information, legal commitments, or account changes, stop and summarize what is needed.”

This prompt pack covers safe delegation of browser tasks with scope limits, stop conditions, credential handoffs, approval gates, and evidence capture. The 25 ChatGPT-5.5 Prompts for Delegating Browser Tasks Safely: Scope, Stop Conditions, Credential Handoffs, Approval Gates, and Evidence article is a focused companion for Cloud Browser Signed In Tasks because it directly matches signed-in browser task delegation and adds practical safety boundaries for the current workflow’s browser steps.

When the retrieval stage begins, you should expect source attribution at the level of “which connected app and account produced this fact,” not just a generic summary. If ChatGPT says a client requested a deadline change, the reviewer needs to know whether that came from an email thread, a Slack message, a calendar description, a document, or a browser page. Source and account attribution are especially important for users who maintain multiple Google, Microsoft, Slack, GitHub, CRM, or project-management identities.

During the draft stage, the output should remain internal. Draft emails, event descriptions, Slack updates, documents, presentations, spreadsheets, and browser form text can save time, but they can also encode incorrect assumptions. The workflow should ask ChatGPT to label assumptions, unresolved questions, and facts requiring verification. That requirement is consistent with OpenAI’s own accuracy guidance that important facts, dates, quotes, data, and external references should be verified through reliable sources.

During the review stage, the authorized human should compare the draft against the retrieved sources and the intended business outcome. The review should cover recipients, channel, tone, attachments, dates, time zones, obligations, confidentiality, account identity, file-sharing scope, and whether the content would create a promise, legal commitment, HR action, financial instruction, medical statement, educational record disclosure, or compliance representation. If any of those categories apply, route the output through the organization’s normal approval process before sending or submitting.

During the approved-action stage, use the visible on-screen approval controls required by the surface and app policy. Do not rely on spoken approval where OpenAI says it is unsupported. Do not ask ChatGPT to bypass confirmations, reduce friction by changing permission modes, or continue after a stop condition. If the screen shows a proposed action that differs from the spoken intent, decline it, capture the discrepancy, and restart from a narrower instruction.

During the evidence-capture stage, record what was requested, which connected apps or sources were used, what drafts were created, which actions were approved, who reviewed them, and what remains unfinished. The evidence does not need to include secrets, passwords, OTPs, bank credentials, private keys, identity documents, protected health information, or unnecessary personal data. In many organizations, a short task note with source labels, timestamps, reviewer initials, and links to approved artifacts is more useful and safer than copying raw sensitive content into a separate log.

During handoff, if the Voice call ends while a Work task is unfinished, OpenAI says it can continue in text. That is a convenience feature, not a reversal mechanism and not a bypass of approval gates. The text continuation should restate the current task state, pending decisions, stop conditions, and next reviewer before continuing. If an action was already approved and performed, the text handoff should not imply it can be silently undone; if a message was sent to the wrong recipient or a calendar invite went out with incorrect information, follow your incident, correction, or recall process rather than relying on continuation alone.

Preflight Checklist Before You Speak

The preflight is the most important part of a reliable Voice-to-Work workflow because it prevents the two most common failure modes: starting in the wrong environment and granting broader operational authority than the task requires. Complete this checklist before speaking a work request, especially when the task involves email, calendars, Slack, browser sessions, shared documents, customer records, legal material, student information, personnel matters, finance, healthcare, security operations, or administrative settings.

Preflight item	Decision rule	Operational warning
Plan and availability	Confirm that Voice, plugins, connected apps, Work, or Codex are available to the account, plan, surface, and region you are using.	OpenAI states that availability varies by plan, workspace, region, app version, and parental controls; do not assume another user’s setup matches yours.
Surface	Choose the correct surface: Chat, Work on web or mobile, or Work/Codex in the desktop app when appropriate and available.	Voice uses the tools and permissions of the selected experience, so the same spoken request can have different tool access in different places.
Work access	Use Work only when the user has both Voice and Work access and the task belongs in that workspace.	OpenAI says Voice in Work requires both Voice and Work access; do not treat ordinary Chat access as Work access.
Workspace role	Verify that the user’s workspace role is appropriate for the requested retrieval, drafting, and approval steps.	A user may be able to draft a message but not approve publication, external sharing, account changes, or administrative actions.
Connected accounts	Confirm the exact email, calendar, Slack, document, browser, or provider account before retrieving or acting.	Multi-account users should assume account mix-ups are possible until the source account is visibly confirmed.
App permissions	Use the least permission mode that allows the task, and keep approval prompts for actions that matter.	OpenAI says changing an app permission changes when ChatGPT asks before using already-authorized access; it does not grant the app new service access.
Data class	Classify the task as public, internal, confidential, regulated, privileged, youth-related, financial, health-related, legal, security-sensitive, or personal.	Never speak, paste, upload, or store passwords, OTPs, private keys, bank credentials, identity documents, protected health information, or unapproved confidential data.
Task outcome	Define whether the task may only summarize, may draft, may prepare an approval request, or may complete an approved action.	“Help with this” is too broad for connected apps; specify what may happen and what must not happen.
Stop conditions	State the exact events that require ChatGPT to pause: ambiguity, missing source, external send, booking, purchase, deletion, permission change, upload, credential prompt, or legal commitment.	Stop conditions should be part of the spoken instruction, not only an internal team policy document.
Reviewer	Name the authorized reviewer or role responsible for approval before external action.	The person speaking may not be the correct approver for finance, legal, HR, education, healthcare, security, or customer-impacting work.

A concise preflight script for an individual knowledge worker is: “I am in the correct work account and workspace. Use only the connected apps already available here. Treat this as confidential internal business information. Retrieve and draft only. Stop before sending, posting, booking, deleting, purchasing, sharing, changing permissions, or submitting forms. I will review on screen.” This takes less than a minute to say and creates a much clearer operating boundary than a casual command.

A stricter preflight script for an enterprise user is: “Before starting, confirm the selected experience, the connected account names you will use, the data sources you plan to read, the permission level for each app if visible, the output artifacts you will create, the approval gates you will require, and the stop conditions. If you cannot confirm an item, ask me before proceeding.” This script is useful when the workflow touches several systems and when administrators need users to preserve a repeatable pattern.

For security teams and administrators, the preflight should also include whether the app calls and approvals are logged in the organization’s supported compliance tooling. OpenAI’s connected-app documentation says app calls are logged in the Compliance Logs platform for supported enterprise use. That does not mean every organization, plan, app, or event has the same logging posture, so administrators should validate their own environment and communicate what evidence users should preserve outside the product.

This enterprise playbook explains how workspace admins can import plugin marketplaces from GitHub and govern internal ChatGPT plugin distribution. The How to Import and Govern ChatGPT Plugin Marketplaces from GitHub: Enterprise Workspace Playbook article is a focused companion for Multi Account Plugin Governance because it is the strongest match for plugin governance across managed workspaces and accounts, unlike the broader multi-agent governance posts.

Choose Chat, Work, or Desktop Codex Deliberately

Choose Chat when the task is conversational, low-risk, and limited to plan-supported plugins or connected apps available in Chat. OpenAI’s release notes say Free and Go users can use Voice in Chat with the plugins supported by their plan. That statement should not be expanded into a claim that every plugin, app, or account action is available to every user, or that Chat is the right surface for enterprise work involving workspace documents, browser tasks, or administrative workflows.

Choose Work when the task involves work artifacts, connected apps, documents, presentations, spreadsheets, or browser work available through the Work experience and the user has both Voice and Work access. OpenAI says Voice is available in Work on web and mobile, and the Work/Codex documentation says Voice is also available in Work or Codex in the desktop app. Because availability and behavior can vary, the preflight should verify the selected experience instead of assuming that a mobile, web, and desktop session expose the same tools.

Choose desktop Codex only when the task belongs in a coding or development context and the user has appropriate access to the desktop experience. The Work/Codex help page indicates that Voice is available in Work or Codex in the desktop app, while Voice in Work on web and mobile is distinct. Developers should not use voice to instruct code-related tools to modify repositories, execute commands, change infrastructure, rotate credentials, update production settings, or merge code without the organization’s normal review and approval gates.

A practical decision rule is: if the outcome is a message, meeting, document, spreadsheet, presentation, or browser-based administrative preparation, start in Work when available and authorized; if the outcome is code analysis or development assistance, consider the appropriate Codex-enabled desktop path; if the outcome is a general question or lightweight draft, Chat may be sufficient. In every case, consequential external actions still require human review and appropriate approval.

The wrong-surface risk is not theoretical. A founder with personal and company calendars may speak “move the investor call to next week” while using a personal account; an educator may ask for a student-family email from the wrong workspace; a developer may ask for a release note while connected to a repository context that should not be used; a legal-technology professional may ask for a client update while in a non-client workspace. The workflow should stop when source identity, account identity, or authorization is unclear.

Set Least-Privilege App Connections Before You Need Them

OpenAI’s connected-app documentation states that installing a plugin does not replace provider authorization, workspace approval, or account authorization. These controls are separate. A user may install or see an app option, but the provider may still require authorization; the workspace may still need approval; the user’s role may still limit access; and the app’s own permissions may still require approval before specific actions.

Permission modes may include Always ask, Allow read actions, Allow low-risk actions, and, for eligible accounts or apps, Allow all actions. Treat these as action-gating settings, not as proof that ChatGPT has new access to the underlying service. OpenAI says changing an app’s permission changes when ChatGPT asks before using already-authorized access; it does not grant the app new access. That means administrators should manage both sides: the provider-side authorization and the ChatGPT-side action approval behavior.

For most voice workflows, “Always ask” or a similarly conservative setting is operationally safer than broad action permission because voice is prone to ambiguity and transcripts may not exactly match what was said. “Allow all actions,” where available, carries elevated risk and should not be treated as an account-wide default. It may be inappropriate for accounts that can send external messages, change calendars, share files, submit forms, administer users, modify repositories, spend money, access regulated data, or alter security settings.

A least-privilege setup should group app use into three tiers. Tier 1 is read-only retrieval for low-risk sources such as public or approved internal reference material. Tier 2 is draft creation for email, calendar descriptions, Slack messages, documents, spreadsheets, presentations, and browser form text, with no external submission. Tier 3 is approved action, where the user reviews the proposed operation on screen and authorizes it through the required control. Teams should document which apps and data classes are allowed in each tier.

Administrators should also establish a disconnect and cleanup procedure before broad adoption. If a user connects the wrong account, leaves an app authorized after a project ends, changes roles, departs the organization, or no longer needs a plugin, the team should know how to revoke or adjust access through the relevant provider, workspace administration, and ChatGPT app settings. The exact screens and labels can change, so the policy should describe responsibilities and verification evidence rather than depend only on screenshots.

A Safe Opening Prompt You Can Speak

The opening spoken prompt should be structured enough that ChatGPT can follow it and conservative enough that a reviewer can audit it. The prompt below is a recommendation, not an official OpenAI template. Adapt it to your organization’s app names, data classifications, approval rules, and incident procedures, and do not include secrets or unnecessary personal data.

Recommended spoken workflow prompt:

Use my authorized work context only. Before you take action, confirm the selected experience, the connected account names you will use, and the apps or sources you plan to read.

Task: [describe the business outcome].

Data boundary: Treat this as [public / internal / confidential / regulated / privileged / youth-related / financial / health-related / legal / security-sensitive]. Do not ask for or expose passwords, OTPs, private keys, bank credentials, identity documents, protected health information, or unapproved confidential data.

Allowed steps:
1. Retrieve only the minimum necessary information from the authorized connected apps.
2. Summarize the findings with source and account attribution.
3. Draft the requested email, calendar item, Slack message, document, spreadsheet, presentation, or browser text.
4. List assumptions, uncertainties, and facts that require verification.

Stop conditions:
Stop before sending, posting, booking, purchasing, deleting, changing permissions, submitting forms, uploading files, sharing documents, making legal or financial commitments, or changing account settings.
Stop if the account, recipient, source, date, amount, address, or instruction is ambiguous.
Stop if a page requests credentials, payment details, identity documents, health information, private keys, or confidential material not approved for this workflow.

Approval:
Show me the proposed action on screen. I will review it. Use only the required on-screen approval controls where approval is needed; do not treat spoken approval as sufficient.

Handoff:
If the Voice call ends before completion, continue in text with a summary of completed steps, pending approvals, stop conditions, and next reviewer.

This prompt works because it gives ChatGPT a task, a data boundary, permitted steps, stop conditions, and an approval rule. It also anticipates the text handoff that OpenAI says can continue unfinished Work tasks after a Voice call ends. The handoff line is important because users often end a call while multitasking and then return later; the next text message should not proceed as if the approval context were obvious.

For an email-calendar-Slack scenario, replace the task line with: “Find the latest partner request about the launch schedule, draft a concise email response with three available meeting times from my calendar, and draft an internal Slack update for the project channel. Do not send, post, or create calendar events until I approve on screen.” This phrasing allows retrieval and draft preparation while preserving the human decision at the point of external communication.

For a browser research scenario, replace the task line with: “Use the browser only to collect publicly available pricing and documentation for the vendor renewal review, summarize the source pages, and draft comparison notes. Do not log into new accounts, submit forms, contact vendors, accept terms, upload documents, or make purchases.” This phrasing prevents a research task from becoming a procurement action.

Operational rule: A voice instruction may initiate retrieval and drafting, but external messages, submissions, payments, purchases, bookings, destructive actions, permission changes, publication, legal commitments, campaign launches, and other consequential operations require authorized human review and the required on-screen approval path.

What Must Never Be Spoken, Pasted, or Stored in the Workflow

Do not speak, paste, upload, or store passwords, one-time passcodes, private keys, API keys, recovery codes, bank credentials, payment card details, government identity documents, protected health information, student records not approved for the workflow, privileged legal material outside the approved matter, confidential security findings, or another person’s private messages unless the organization has explicitly authorized that data use and the selected environment is appropriate. Even then, minimize the content and prefer references, redactions, or approved source systems over copying raw sensitive data into a prompt.

Voice can feel informal, which increases the risk that users will disclose more than they would type. A salesperson might dictate a customer’s private phone number into a follow-up task, a parent might describe a child’s medical detail while drafting a school email, a developer might read an access token aloud from a terminal, or a finance employee might include bank details in a vendor message. The workflow should instruct ChatGPT to stop and ask for a safer alternative when such information appears unnecessary or unapproved.

OpenAI’s Voice documentation says Live and Advanced audio clips are retained with the transcript for 30 days, and deleting a chat also deletes associated audio or video clips within 30 days, subject to stated security, safety, legal, and previously disassociated training-data exceptions. OpenAI also states that archiving does not delete clips. These boundaries make data minimization a practical necessity, not just a privacy slogan.

The Privacy Center described by OpenAI explains settings related to memory, ads, location, temporary chat, apps/plugins, multi-factor authentication, model improvement, and data export/deletion. Opening the Privacy Center does not itself modify settings or override organization policy, and OpenAI notes that availability and controls vary by plan, region, account, and workspace. Users should therefore treat privacy review as an administrative task with verification, not as a one-click assurance that every Voice-to-Work risk is solved.

If sensitive content is unavoidable, the workflow should move from voice to a controlled written process with redaction, approved systems, and the right reviewer. For example, a legal team should refer to “the executed agreement in the approved matter workspace” rather than reading privileged clauses aloud unless the workspace, authorization, and retention implications have been reviewed. A healthcare or education team should use approved records systems and policy-specific procedures rather than improvising through a voice conversation.

Why the Opening Discipline Determines the Rest of the Workflow

The rest of this tutorial will build the workflow in operational detail: app connection governance, email and calendar drafting, Slack updates, browser-task boundaries, on-screen approvals, artifact review, safe cancellation, text continuation, audit notes, and cleanup. The opening discipline you establish here determines whether those later steps are reliable. If the workflow starts in the wrong account, with the wrong surface, the wrong permission mode, or no stop conditions, the later review process becomes damage control instead of governance.

For teams adopting Voice-to-Work at scale, the best rollout is not “tell everyone they can use voice now.” A safer rollout is to publish approved task patterns, define prohibited data, set least-privilege app permissions, train users to speak structured requests, require source and account attribution, preserve on-screen approvals, and collect feedback on near misses. That approach aligns with OpenAI’s broader prompt-engineering guidance to use explicit instructions, structured roles, representative examples, versioned prompt code, tests, and evaluation before production rollout.

The key habit is to make ChatGPT repeat the operational frame before doing the work: selected experience, accounts, sources, allowed steps, stop conditions, reviewer, and handoff plan. If that summary is wrong, correct it before retrieval. If the summary is right, proceed to retrieval and drafting. If the proposed action later differs from the summary, decline the approval and restart with a narrower instruction.

Voice-to-Work is valuable because it can reduce the friction of gathering context, producing first drafts, and carrying unfinished work from speech into text. It is safe only when users preserve the boundaries OpenAI documents: tools and permissions depend on the selected experience, existing app connections and usage limits continue to apply, app authorization and workspace approval remain separate, approval-gated actions on web and mobile require on-screen controls, and generated or transcribed content still needs verification before consequential use.

Run the Read Stage: Verify the Account, Name the Sources, and Summarize Only Authorized Content

The read stage is the part of the workflow where you ask ChatGPT to retrieve or inspect information that you are already authorized to access, then report what it found without sending, posting, booking, buying, deleting, or changing anything. OpenAI’s documentation for Voice in Work says Voice uses the tools and permissions available to the selected experience, and the connected-app documentation makes clear that provider authorization, workspace approval, app permissions, and role access remain separate controls. Treat that separation as an operating rule: before any summary appears, confirm the selected account, the connected source, and the scope of what ChatGPT is allowed to inspect.

A safe read request is narrow enough to be auditable. Instead of saying, “Catch me up on everything,” say, “Read only the last five unread messages in my work Gmail inbox from the vendor domain I name, and summarize dates, requested decisions, and attachments without opening unrelated threads.” The second request gives ChatGPT a source, a limit, a purpose, and a non-action boundary. It also reduces the chance that the model will summarize irrelevant or unauthorized material from a different connected account, workspace, or mailbox.

Use this spoken sequence when a task touches email, calendar, Slack, or a browser session. First, identify the workspace or account in plain language. Second, state the source to inspect. Third, state the maximum lookback window or item count. Fourth, state what fields should be extracted. Fifth, state that no external action is permitted. This structure is not a magic phrase; it is an operational guardrail that gives you a repeatable way to separate retrieval from drafting and action.

Sample spoken read request:
"Use Work, not personal Chat. Confirm the connected account before reading.
Read only my authorized work Gmail inbox for the latest thread from Jordan about the Q4 launch review.
Do not send, archive, label, forward, download attachments, or update anything.
Summarize the sender, recipients, date, requested decision, deadline, and any stated source documents.
If you are uncertain about the account or thread, stop and ask me to choose."

That prompt includes two stop conditions: uncertainty about the account and uncertainty about the thread. Stop conditions matter because Voice transcripts may not exactly match what was said, according to OpenAI’s Voice documentation. A misheard recipient name, project code, date, or workspace can become a real operational error if the assistant proceeds into drafting or action. Make the assistant repeat the critical identifiers before it reads sensitive material.

When using Slack or similar team communication tools, specify whether the assistant may inspect channels, direct messages, mentions, threads, or search results. Direct messages and private channels often contain context that is not appropriate for broad summarization, even if technically accessible to the signed-in user. A conservative workflow asks for the minimum channel and thread needed for the stated task, then requires source attribution in the output so you can see exactly where each summarized claim came from.

Sample spoken Slack read request:
"Check only the authorized #release-ops channel in my work Slack.
Look for messages from the last 24 hours that mention the staging freeze.
Do not inspect DMs or private channels unless I explicitly name them.
Return a bullet summary with message author, timestamp, channel, and the exact decision or blocker mentioned.
Do not post, react, create reminders, invite anyone, or change channel settings."

Calendar reading has a different risk profile because a calendar item can imply attendance, availability, location, confidential meeting topics, or customer identity. Ask for metadata only unless you need the body of an event. For example, “List today’s meetings that conflict with the launch review, showing title, organizer, start time, end time, and whether I am required or optional” is safer than “summarize my calendar.” If the event description contains call-in details, access codes, private addresses, or confidential notes, the assistant should avoid reproducing them unless there is a clear, authorized need.

Sample spoken calendar read request:
"Inspect only my work calendar for next Tuesday.
Find conflicts with the 2:00 p.m. product review.
Show event title, organizer, start and end time, and whether I am accepted, tentative, or declined.
Do not reveal video links, dial-in codes, private addresses, or attendee personal details.
Do not create, move, cancel, or RSVP to any event."

Browser reading should be handled as a separate source category because a browser task may expose signed-in pages, internal dashboards, customer records, admin panels, purchasing screens, or account settings. If you use Work to operate in a browser, keep the read stage limited to inspection and extraction. Do not ask for form submission, publishing, checkout, credential changes, permission changes, or account modifications during the same spoken instruction that asks the assistant to read a page.

This prompt collection shows how ChatGPT Work webhooks can turn Gmail, Slack, and GitHub events into reviewable automation workflows. The 25 ChatGPT Work Webhook Prompts for Gmail, Slack, and GitHub Automation article is a focused companion for Gmail and Slack Workflow Design because it specifically covers Gmail and Slack automation design in ChatGPT Work, aligning with the article’s email and messaging workflow sections.

Use a Source Attribution Contract for Every Read Output

A source attribution contract is a short rule that tells ChatGPT how to report evidence. It should require each factual claim to be tied to a visible source label such as Gmail thread, calendar event, Slack channel, document title, spreadsheet tab, or browser page. This does not guarantee truth, but it gives you a practical audit trail and makes hallucination checks easier. OpenAI’s accuracy guidance warns that ChatGPT can produce incorrect or misleading outputs, including confident claims and fabricated references, so important facts still need human verification.

Source attribution contract:
"For every factual statement, include the source type and item:
- Email: sender, subject, date, and thread position if visible
- Calendar: event title, organizer, date, and time
- Slack: channel, author, timestamp, and thread if applicable
- Browser: page title or system area visible to you, without exposing secrets
If a claim is inferred rather than directly stated, label it as inference.
If you cannot identify the source, put it in an 'Unverified or unclear' section."

This contract prevents a common failure mode: a smooth summary that blends facts from multiple places without telling you where each item came from. In a voice workflow, blended summaries are especially risky because the user may be walking, multitasking, or making decisions from audio alone. Ask for a written response in the chat and review it visually before you authorize a draft or any external action.

Read target	Minimum safe scope	Attribution to require	Do not allow during read stage
Email	Named mailbox, thread, sender, search term, or recent item count	Sender, recipients if necessary, subject, date, and thread position	Send, forward, archive, label, delete, download unnecessary attachments, or change filters
Calendar	Named calendar, date range, event title, or conflict window	Event title, organizer, date, time, attendee role, and source calendar	Create, move, cancel, RSVP, invite attendees, expose access codes, or change availability
Slack	Named workspace, channel, thread, mention search, or time window	Workspace, channel, author, timestamp, thread, and quoted decision if needed	Post, react, invite, remove, pin, create reminders, or change channel settings
Browser	Named signed-in site or visible page area needed for the task	Page title, visible record name, section label, and timestamp if relevant	Submit forms, purchase, book, publish, delete, change permissions, or alter account settings
Documents and files	Named document, folder, or file supplied or selected by the user	Document title, section heading, page or slide if visible, and last modified metadata if available	Share externally, overwrite, delete, change access, or quote confidential sections beyond the need

The table is a recommended operating pattern, not a statement that every connector exposes every field or supports every restriction. OpenAI’s connected-app documentation says access and permissions depend on the app, the provider, workspace settings, and the user’s authorization. If a source cannot provide the attribution you need, downgrade the task to a manual review: ask ChatGPT to explain what it can see, then inspect the source yourself before relying on the summary.

Confirm Recipients, Dates, Amounts, and Commitments Before Drafting

The read stage should end with a confirmation checkpoint. Ask ChatGPT to list all people, organizations, dates, times, time zones, monetary amounts, locations, deliverables, and commitments it believes are relevant. Then correct the list verbally or in text before asking for any draft. This is especially important because voice recognition can confuse names and because many workplace mistakes come from one-character differences in email addresses, calendar dates, or channel names.

Confirmation checkpoint:
"Before drafting, read back the critical fields:
1. Account or workspace used
2. Source items inspected
3. Intended recipient or audience
4. Relevant dates, times, and time zones
5. Requested decision or deliverable
6. Any amounts, quantities, or contractual language
7. Items you inferred rather than directly observed
Do not draft until I confirm or correct these fields."

For calendar workflows, force explicit time-zone confirmation. “Next Friday at 10” is ambiguous across distributed teams, travel calendars, and daylight-saving transitions. A safer spoken instruction is, “Use the time zone shown on my work calendar for the organizer, and display it before drafting the event.” If the source does not make the time zone clear, stop and ask instead of guessing.

For email and Slack replies, confirm the recipient class before drafting. A reply to a customer, outside counsel, regulator, journalist, employee, contractor, vendor, or executive carries different tone, disclosure, and approval requirements. The model can help produce a draft, but an authorized human must decide what can be disclosed and whether the message creates a legal, financial, employment, security, or contractual commitment.

For spreadsheets, confirm whether the assistant is reading raw data, a summary table, or a derived report. Ask it to label any calculations, assumptions, and missing fields. Do not let a voice workflow turn an uncertain spreadsheet interpretation into an external forecast, invoice, payment instruction, personnel decision, or compliance representation without independent review by the responsible team.

Build the Draft Stage: Create Artifacts Without External Side Effects

The draft stage begins only after the read stage has produced attributed evidence and you have confirmed critical fields. A draft can be an email reply, calendar event proposal, Slack response, document outline, spreadsheet plan, presentation structure, browser action plan, or checklist. It should not be sent, posted, booked, purchased, submitted, published, shared, or committed during the draft stage. This separation is the central safety pattern for Voice-to-Work because it prevents a single spoken instruction from becoming an irreversible action.

OpenAI’s Work and connected-app documentation states that actions requiring approval on web and mobile must be approved or declined through on-screen controls; spoken approval is not supported. Design your draft stage so there is nothing to approve yet except the content of the draft. The later action stage, covered separately in the overall workflow, is where on-screen controls and explicit human review become mandatory for consequential operations.

A strong draft request names the artifact type, audience, source basis, constraints, and review format. It also asks ChatGPT to preserve uncertainties instead of smoothing them away. For example, “Draft a customer email that cites only the confirmed delivery date from the email thread and marks the unresolved pricing question as pending” is better than “Write a reassuring reply.” The first version limits the draft to verified evidence; the second invites the model to fill gaps with plausible language.

Sample spoken draft request for email:
"Using only the confirmed facts from the attributed summary, draft a reply to Jordan.
Do not send it. Keep it under 180 words.
Acknowledge the Q4 launch review, confirm that I can attend if the time is 3:00 p.m. Eastern, and ask them to resend the budget attachment because the source summary did not verify it.
Do not make commitments about budget approval, legal approval, delivery dates, or staffing.
Put any uncertain facts in brackets for me to review."

This draft request forbids common overreach: budget approval, legal approval, delivery commitments, and staffing commitments. Your own forbidden list should match your role and organization. A sales leader might forbid price concessions, nonstandard terms, and delivery guarantees. A school administrator might forbid disclosure of student records or disciplinary details. A legal-technology team might forbid privileged conclusions, legal advice to a client, or settlement language without attorney approval.

Sample spoken draft request for Slack:
"Draft a Slack message for the #release-ops channel based only on the staging-freeze thread you summarized.
Do not post it.
Make it a neutral status update with three bullets: confirmed freeze window, unresolved blocker, and owner to confirm.
If the owner was inferred, label it as 'needs confirmation' rather than assigning responsibility."

A Slack draft should be reviewed for audience size and permanence. A channel message can reach more people than an email thread, trigger notifications, or become part of an audit trail. Ask ChatGPT to identify whether the draft includes confidential customer names, unreleased product details, incident information, security vulnerabilities, personal data, employment matters, or legal conclusions. If it does, do not post until the appropriate owner reviews it.

Draft Calendar Items as Proposals, Not Appointments

Calendar drafting is a place where wording matters. Ask for a proposed event title, agenda, attendee list, duration, and scheduling rationale, but do not create or move the event until you review it on screen. The draft should display the organizer account, source calendar, proposed attendees, time zone, and whether any conflicts were found. If the assistant is unsure whether a person should be invited or merely informed, it should place that person in a “confirm before inviting” section.

Sample spoken draft request for a meeting:
"Draft a calendar event proposal only; do not create the event.
Title: Q4 Launch Review Prep.
Use the confirmed participants from the email thread, but place optional names in a 'confirm before inviting' list.
Suggest two 30-minute windows next week that do not conflict with my work calendar.
Show time zones, source calendar, agenda, and unresolved questions.
Do not include video links, private addresses, access codes, or confidential notes in the draft."

This instruction protects against both accidental disclosure and accidental scheduling. It also forces the assistant to show why a time was selected. If a calendar connector or workspace policy does not allow the assistant to inspect conflicts, ask it to prepare a manual scheduling checklist instead of guessing. The correct fallback is not “try anyway”; it is “draft the decision support and let the user perform the action.”

Draft Documents, Spreadsheets, and Presentations With Evidence Labels

Voice in Work can be used to create documents, presentations, and spreadsheets when the selected experience and account support those tools, according to OpenAI’s Work documentation. Treat those artifacts as drafts that require human review. A document outline should include evidence labels for claims. A spreadsheet should separate imported values, formulas, assumptions, and manually entered placeholders. A presentation should distinguish sourced facts from narrative interpretation.

Sample spoken draft request for a document:
"Create a draft document outline, not a final document for sharing.
Use only the authorized email thread and calendar summary we confirmed.
Sections: objective, decisions needed, timeline, open questions, and next-step options.
For each factual bullet, add the source label in parentheses.
Put any unsupported recommendation in an 'analysis, not source fact' section.
Do not share the document or change permissions."

A spreadsheet draft should be designed for reviewability before usefulness. Ask for separate tabs or sections for source data, calculations, assumptions, and review notes if the tool supports that structure. If the spreadsheet will later inform payments, hiring, inventory, grades, compliance filings, medical decisions, or customer eligibility, the draft is not enough. The responsible human or specialist must verify the formulas, source records, and governing rules before any decision is made.

Sample spoken draft request for a spreadsheet:
"Prepare a spreadsheet draft plan only.
Columns: source item, date, owner, requested action, due date, status, evidence link or label, and reviewer notes.
Do not import private data beyond the fields already summarized.
Do not email, share, publish, or connect the sheet to automation.
Mark any missing due date as 'unknown' instead of estimating it."

Presentation drafts need a specific anti-hallucination rule because slide decks often compress evidence into confident headlines. Ask ChatGPT to keep unsupported claims out of slide titles. A safe instruction is, “Use descriptive slide titles unless the source evidence directly supports a conclusion.” For example, “Open blockers before launch review” is safer than “Launch is at risk” unless the source material explicitly says the launch is at risk.

Sample spoken draft request for a presentation:
"Draft a five-slide presentation outline for internal review only.
Do not create external-facing claims.
Each slide must list the evidence sources used and a reviewer checkpoint.
Use cautious titles unless the source explicitly supports a stronger conclusion.
Include a final slide called 'Open questions and required approvals.'
Do not share, export, publish, or invite collaborators."

Draft Browser Plans Before Browser Actions

Browser tasks should have their own intermediate artifact: a browser plan. A browser plan lists the page or system area to inspect, the exact fields to review, the proposed steps, the stop conditions, and the actions that require on-screen approval. This is safer than saying, “Go update the record,” because signed-in browser sessions can expose administrative controls, customer information, billing screens, publishing flows, or irreversible settings.

Sample spoken draft request for a browser plan:
"Draft a browser plan only; do not operate the page yet.
Goal: review whether the vendor onboarding record has a missing tax form.
Steps should include the page area to inspect, fields to compare, and what evidence to capture.
Stop before editing, submitting, downloading, changing permissions, sending messages, or uploading files.
If a form contains bank details, tax identifiers, identity documents, or personal data, summarize only the presence or absence of the required field and stop for human review."

A browser plan should also name the signed-in account or role visible on the page, if available. If ChatGPT cannot confirm whether it is operating in the intended account, stop. Do not rely on a browser profile nickname, remembered session, or visual assumption when the task could affect customers, employees, payments, legal records, production systems, or public content.

Use an Evidence Table Before You Move From Draft to Action

An evidence table is the bridge between a draft and a later approval. It forces the assistant to list what it used, what it inferred, what remains unknown, and what a human must inspect. This is particularly useful after a voice session because the written transcript may not exactly match the spoken conversation and because Work tasks can continue in text if unfinished when the Voice call ends. Text continuation is useful, but it does not undo earlier actions and must preserve the same approval gates and stop conditions.

Draft element	Evidence source	Directly stated or inferred?	Human verification required	Action blocked until verified?
Recipient name and address	Email thread header or directory entry	Directly stated if visible in the source	Verify exact spelling, domain, role, and whether the recipient is authorized	Yes, before sending or inviting
Meeting time	Calendar availability and source email request	May be inferred from conflicts and preferences	Verify date, time zone, attendee availability, and organizer account	Yes, before creating or moving an event
Project status	Slack channel thread, email update, or document section	Often inferred from multiple signals	Verify with the named owner before posting a firm status	Yes, if external, executive, or compliance-facing
Spreadsheet due date	Email request, calendar milestone, or project document	Direct if explicitly stated; otherwise unknown	Verify against the source record and responsible owner	Yes, before workflow automation or reminders
Browser update plan	Visible signed-in page and internal process document	Plan is assistant-generated	Verify account, record, fields, permissions, and consequences	Yes, before submitting or saving changes
Legal, financial, HR, health, or security implication	Usually multiple sources plus policy or specialist review	Assistant analysis is not authoritative	Escalate to qualified authorized reviewer	Yes, always

Use the evidence table as a required artifact for any workflow that crosses from personal productivity into organizational consequence. A simple internal reminder may not need the full table. A customer response, contract-related email, incident update, policy interpretation, payment-related spreadsheet, employee communication, student record, healthcare workflow, or public-facing post should have one. The extra minute spent on evidence usually costs less than repairing a mistaken send, calendar invite, or browser change.

Evidence table request:
"Before we consider any action, create an evidence table.
Rows should cover each draft claim, proposed recipient, date, time, attachment, link, number, and commitment.
Columns: draft element, source, direct quote or summary, inferred or stated, uncertainty, and human verification required.
Do not proceed to sending, posting, scheduling, submitting, sharing, or editing until I review the table on screen."

This request is deliberately conservative. It treats the assistant as a drafting and analysis tool, not as an autonomous operator for consequential work. OpenAI’s prompt engineering guidance recommends explicit instructions, structured roles, tests, and evaluation for production use; the same idea applies at the individual workflow level. You are creating a small testable protocol: retrieve narrowly, attribute sources, draft with uncertainty, review evidence, then decide whether a separate action stage is appropriate.

Hallucination Checks to Run on Every Draft

A hallucination check is not a vague request to “make sure this is right.” It is a targeted review for unsupported names, dates, facts, citations, commitments, and invented context. Ask ChatGPT to mark every sentence in the draft as supported, inferred, stylistic, or unsupported. Then require unsupported content to be removed or bracketed for human completion. This aligns with OpenAI’s accuracy guidance that important facts and external references should be verified through reliable sources.

Draft hallucination check:
"Audit the draft sentence by sentence.
Label each sentence as:
- Supported by source
- Reasonable inference
- Style or transition only
- Unsupported and should be removed or bracketed
List any names, dates, amounts, links, attachments, policies, or commitments that were not directly verified.
Do not improve the draft until after the audit."

Run a second check for authority. A draft can be factually accurate but still unauthorized. For example, an email may correctly state a discount, but you may not have authority to offer it. A Slack post may accurately report a security issue, but disclosure may need incident-response approval. A calendar invite may reflect a real meeting need, but inviting an external recipient may disclose a confidential project. Ask the assistant to separate “true if sourced” from “permitted to say or do.”

Authority check:
"Now check authority, not accuracy.
Identify any sentence or proposed action that could create a legal, financial, HR, security, privacy, customer, educational, medical, contractual, or public commitment.
For each item, say which authorized human role should review it.
Do not remove the item silently; mark it for approval or rewrite it as a non-committal question."

Run a third check for privacy and unnecessary disclosure. The safest draft often says less. If a message does not need a customer identifier, private address, access code, student detail, health detail, bank detail, internal vulnerability, or confidential attachment name, remove it. Never speak, paste, or store passwords, one-time passwords, private keys, bank credentials, identity documents, protected health information, or unapproved confidential data in the workflow.

Artifact Review: What to Inspect on Screen

On-screen review is not limited to the final approval button. Review the artifact itself: the account shown, the recipients, the subject line, the channel, the document title, the sharing state, the file location, the browser page, and any hidden fields or metadata you can inspect. For email, expand recipient chips and check domains. For calendar events, inspect guests, conferencing, location, description, reminders, visibility, and time zone. For documents, inspect sharing permissions and whether the artifact is stored in the intended workspace.

• Email draft: Confirm sender account, to/cc/bcc fields, exact domains, subject, attachments, quoted history, confidentiality labels, and whether reply-all is appropriate.
• Calendar proposal: Confirm organizer calendar, attendees, optional versus required status, time zone, recurrence, conferencing, location, event visibility, and description content.
• Slack draft: Confirm workspace, channel or DM, audience size, thread target, mentions, links, emojis or reactions, and whether the draft reveals restricted information.
• Document draft: Confirm file owner, workspace location, title, sharing permissions, comments, tracked changes, evidence labels, and whether confidential source text is over-quoted.
• Spreadsheet draft: Confirm source-data boundaries, formulas, hidden sheets, filters, permissions, imported data, assumptions, and whether any downstream automation is connected.
• Presentation draft: Confirm audience, slide claims, speaker notes, embedded images, charts, source labels, and whether titles overstate the evidence.
• Browser plan: Confirm signed-in account, record identity, environment, page URL or system area, proposed fields, save buttons, destructive controls, and permission implications.

If the interface presents an approval prompt, use the on-screen controls rather than trying to approve by voice. OpenAI’s Work/Codex documentation states that, on web and mobile, actions requiring approval must be approved or declined through on-screen controls and spoken approval is not supported. If you cannot see the approval clearly, decline or stop. A voice workflow should never rely on guessed approval state.

Stage-Specific Spoken Templates You Can Reuse

The following templates are examples, not required product commands. Adapt them to the tools, policies, and account controls available in your workspace. Each template preserves the same core pattern: verify the selected account, read narrowly, attribute evidence, draft without side effects, and require on-screen review before action.

Email Reply Template

"Confirm the connected work email account before reading.
Read only the latest thread with [person or subject] from [date range].
Summarize the source, requested decision, deadline, and any attachments without downloading unnecessary files.
Then draft a reply only; do not send.
Use only sourced facts, bracket uncertainties, and avoid commitments about price, legal approval, delivery, staffing, or refunds.
Before any send action, show an evidence table and wait for on-screen review."

Use this template when the risk is mistaken disclosure or accidental commitment. It is appropriate for routine internal coordination, vendor follow-up, or customer-service preparation, provided the content is authorized and no protected or confidential information is exposed unnecessarily. For legal, employment, healthcare, financial, security, or regulatory messages, treat the output as a preliminary draft for qualified review.

Calendar Proposal Template

"Use my work calendar only and confirm the calendar name.
Inspect [date range] for availability related to [meeting purpose].
Do not create, move, cancel, or RSVP.
Draft a meeting proposal with title, agenda, proposed times, time zones, required attendees, optional attendees, and conflicts.
Do not include private addresses, access codes, or confidential notes.
Mark any uncertain attendee or time as 'confirm before inviting.'"

Use this template when scheduling requires coordination but not immediate booking. It keeps the assistant in planning mode and makes ambiguous attendees visible before invitations go out. If a meeting has legal, HR, student, patient, board, security, or customer-sensitive content, review the title and description carefully because calendar metadata can itself disclose sensitive information.

Slack Status Template

"Use the authorized work Slack workspace only.
Read only [channel or thread] from [time window].
Do not inspect DMs, post, react, invite users, create reminders, or change settings.
Summarize decisions and blockers with author, timestamp, and channel.
Draft a short status update for review only.
Label inferred owners and unresolved decisions clearly."

Use this template for internal coordination where attribution matters. A good Slack draft should avoid over-tagging people, assigning blame, or announcing a decision before the owner confirms it. If the post mentions an incident, vulnerability, customer issue, personnel matter, or unreleased product, route it through the appropriate review path before posting.

Document, Spreadsheet, or Presentation Template

"Create a draft artifact only in the selected Work experience.
Base it only on the authorized sources we confirmed.
Include source labels for factual claims and an 'open questions' section.
Separate facts, assumptions, recommendations, and required approvals.
Do not share, publish, export, email, invite collaborators, or change permissions.
Before any external use, produce an evidence table and a reviewer checklist."

Use this template when you want a durable artifact that others may later inspect. The instruction to separate facts, assumptions, recommendations, and approvals is crucial. It prevents a polished document or slide deck from hiding uncertainty behind formatting. For spreadsheets, add a formula-review checkpoint before anyone relies on calculations.

Browser Plan Template

"Draft a browser task plan before doing anything in the browser.
Confirm the signed-in account or role if visible.
Goal: [inspection goal].
List the pages or fields to inspect, the evidence to capture, and the stop conditions.
Stop before editing, submitting, purchasing, booking, deleting, publishing, changing permissions, uploading files, or sending messages.
If sensitive personal, financial, identity, health, security, or confidential data appears, minimize exposure and pause for human review."

Use this template when a task may involve signed-in systems. A browser plan is especially important for administrators and operations teams because many web pages mix harmless information with powerful controls. If the task involves account access, roles, billing, production settings, customer records, or public publication, require a separate approval step and an audit note before proceeding.

Decision Rules for Moving From Read to Draft

Do not move from read to draft merely because ChatGPT produced a fluent summary. Move only when the account is correct, the sources are identified, the scope is appropriate, the critical fields are confirmed, and uncertainties are visible. If any of those conditions fail, repeat or narrow the read stage. A workflow that pauses is functioning correctly; a workflow that proceeds through ambiguity is failing silently.

Condition	Proceed to draft?	Reason
Correct account and workspace confirmed	Yes, if other checks pass	Prevents cross-account leakage and wrong-source drafting
Source attribution missing or vague	No	The draft cannot be audited against the underlying evidence
Recipient identity ambiguous	No	Misaddressed drafts can expose confidential information or reach the wrong person
Date, time, or time zone uncertain	No for scheduling; maybe for a question draft	Calendar and deadline errors are common and consequential
Source contains sensitive personal or regulated information	Only for minimal, authorized draft	Data minimization and specialist review may be required
Draft would make a legal, financial, HR, health, education, security, or public commitment	Only as a marked draft for authorized review	ChatGPT output does not replace qualified human approval
Assistant reports uncertainty about what it can access	No	Access uncertainty should stop the workflow until the user verifies manually

These decision rules are intentionally stricter than many casual productivity habits. Voice workflows are fast, and speed can hide errors. The goal is not to slow every task; it is to reserve speed for low-risk drafting while forcing deliberate review where an external person, record, account, customer, student, patient, employee, system, or public audience could be affected.

How to End the Voice Portion Without Losing Control

When the read and draft stages are complete, end the voice portion with an explicit handoff statement. OpenAI’s release notes and Work documentation state that if a Work task remains unfinished when the Voice call ends, it can continue in text. Use that feature as a controlled transition, not as a way to let work proceed unattended. The final spoken instruction should restate what has been drafted, what has not been approved, and what must remain blocked.

Safe voice-to-text handoff:
"End the voice portion after you write a text handoff.
The handoff must list:
1. Sources inspected
2. Draft artifacts created
3. Facts verified and facts still uncertain
4. Actions not taken
5. Approvals still required
6. Stop conditions that remain in effect
Do not send, post, schedule, submit, share, publish, purchase, book, delete, edit records, or change permissions unless I later approve through the required on-screen controls."

The handoff should also capture cleanup needs. If you opened sensitive records, used a shared screen, created a draft in a workspace, or generated an artifact that contains confidential material, note who must review it and whether it should be deleted, moved, restricted, or retained under policy. Do not assume archiving or closing the conversation deletes all associated data; OpenAI’s Voice documentation distinguishes deletion from archiving and describes retention behavior for Live and Advanced audio clips with transcripts.

A strong handoff gives the next text interaction enough context to continue safely without re-reading broad sources. Ask ChatGPT to use concise references to the evidence table rather than repeating unnecessary confidential content. If the next step requires action, the text continuation should begin with review, not execution: “Show me the final draft and evidence table again” is safer than “send it now.”

Approval, Action, and Handoff: Keep the Human in the Consequential Loop

The approval stage is where a Voice-to-Work workflow either becomes operationally useful or dangerously ambiguous. OpenAI states that Voice can use the tools and permissions available to the selected experience, including supported plugins, connected apps, browser work, and Work artifacts, but existing app permissions, provider authorization, workspace controls, approval requirements, and usage limits still apply. Treat every external side effect—sending an email, posting to Slack, creating or changing a calendar event, submitting a browser form, purchasing, booking, deleting, changing account settings, or making a legal or financial commitment—as a separate human-authorized action, not as a natural continuation of a spoken request.

OpenAI’s Work and Codex documentation makes a critical operational point for web and mobile: actions that require approval must be approved or declined through on-screen controls, and spoken approval is not supported. That means “yes, send it” or “go ahead” in the voice conversation should not be treated as enough for a gated action. In a governed workflow, voice is used to plan, retrieve, summarize, draft, and navigate the review process; the final approval for consequential actions happens on screen, where the authorized user can inspect the artifact, destination, account, and action label before choosing to approve or decline.

This section builds the controlled action layer for the workflow. It explains how to use on-screen approvals without narrating secrets, how to keep browser tasks inside a reversible sandbox, how to handle payment, account, and destructive-action gates, how to continue unfinished work in text after the call ends, and how to reconcile a possibly imperfect voice transcript with the actual artifacts and app logs you rely on later.

Use a Two-Part Approval Standard: Intent Plus Screen Evidence

A safe approval is not merely a statement of intent. It combines the user’s intent with visible evidence of the exact action that will happen. For example, “send the follow-up to Maya” is too vague if the screen does not show the sending account, recipient address or workspace identity, message content, attachments, and whether the action is send, schedule, save draft, or discard. A better standard is: “I can see the correct account, recipient, content, and action on screen; I approve this specific action.”

Because spoken approval is not supported for actions requiring approval on web and mobile, the spoken part should be used to request a review summary, not to execute the action. A user can say, “Before I decide, summarize what is on the approval screen: the account, action, recipient, artifact, and any irreversible effects.” The human then uses the actual on-screen control to approve or decline. This keeps the system aligned with OpenAI’s documented control model and creates a clean distinction between conversational guidance and operational authorization.

Approval element	What the human verifies on screen	Reason it matters
Account or workspace	The selected email account, calendar, Slack workspace, connected app, or browser session is the intended one.	Multi-account mistakes can expose private data or send from the wrong organization.
Action type	The visible action is draft, save, send, post, create, update, delete, submit, purchase, or another specific operation.	Similar-looking buttons can have very different consequences.
Destination	Recipient, channel, meeting participants, browser form target, or external service destination is correct.	Wrong destinations are among the most common and damaging workflow failures.
Content	Text, files, dates, numbers, commitments, links, attachments, and references match the reviewed draft.	ChatGPT outputs can be incorrect or misleading, so high-impact details require independent verification.
Consequence	The action can be undone, revised, canceled, or escalated; if not, the user applies a stricter approval gate.	Irreversible or externally binding operations require extra human control.

Recommendation: use a local policy that treats any missing screen evidence as a decline condition. If the account, destination, content, or consequence is not visible or understandable, do not approve. Ask ChatGPT to stop, summarize the uncertainty, and convert the operation back into a draft or checklist.

This agent-safety testing prompt pack covers containment verification, privilege-escalation checks, tool-boundary testing, and evidence-oriented red-team exercises that can strengthen reviews before browser-capable agents receive broader authority. The 30 ChatGPT Prompts for AI Agent Safety Testing: Red-Team Your Autonomous Systems Before They Red-Team You article is a focused companion for Browser Delegation Safety Prompts because it is a genuine AI-agent safety prompt collection and is relevant to browser delegation controls, replacing the draft bridge that incorrectly described it as a browser-specific prompt pack.

Why Spoken Approval Is Not the Same as On-Screen Approval

Voice interactions are optimized for conversation, not for secure final authorization. A spoken “approve” can be ambiguous because it may refer to the previous draft, the current plan, the next step, a different app, or a misunderstood transcript segment. OpenAI’s voice guidance also notes that transcripts may not exactly match what was said. That is another reason not to use the voice transcript as the controlling approval record for consequential operations.

The safer model is to let the voice conversation prepare a decision packet. The packet can include the proposed action, source evidence, unresolved questions, and a human-review checklist. The final action then waits for an on-screen approval, if the product surface presents one, or for the human to take the action manually in the provider app. This is especially important in enterprise, education, and regulated environments where auditability depends on clear evidence of who approved what, in which system, and under which authority.

Operational rule: voice may ask, explain, summarize, and draft; on-screen controls or manual provider-side actions authorize consequential execution.

Do not attempt to bypass an approval prompt by repeatedly restating permission in the voice call. Do not instruct ChatGPT to “remember that I always approve this type of action,” unless the organization has explicitly configured an appropriate permission mode and the action class is low-risk under local policy. OpenAI’s connected-app documentation states that changing an app permission changes when ChatGPT asks before using already-authorized access; it does not grant new service access, and provider authorization, workspace approval, app role access, and usage limits remain separate.

Browser Tasks: Control the Session, the Boundary, and the Stop Point

Browser tasks need a stricter control pattern than ordinary drafting because the browser can combine reading, navigation, form entry, account state, and external submission in one flow. In a safe workflow, the browser stage starts with a plan and ends before submission, payment, booking, deletion, or account change. The browser can gather public information, compare visible options, fill a draft form for review, or prepare a checklist, but the human must inspect and approve every external action.

Before a browser task starts, identify the signed-in account and the allowed destination. Do not narrate passwords, one-time passwords, private keys, recovery codes, bank credentials, identity documents, protected health information, or unapproved confidential data. If a sign-in, multifactor prompt, paywall, identity verification, or permission request appears, pause the workflow. The human should handle authentication directly in the provider’s interface without speaking or pasting credentials into the chat.

Use this browser-task boundary statement before beginning any browser work:

Browser task boundary:
- Use only the signed-in account I confirm on screen.
- Do not ask me to speak, paste, or store passwords, OTPs, recovery codes, private keys, bank credentials, identity documents, health information, or confidential material not needed for this task.
- You may read visible information and prepare drafts or form entries for review.
- Stop before sending, submitting, purchasing, booking, deleting, changing account settings, granting permissions, accepting legal terms, or publishing.
- If the page asks for payment, identity verification, account recovery, new permissions, or irreversible confirmation, stop and summarize the decision for me.

This boundary is deliberately conservative. It prevents the browser from turning a research request into a purchase, a scheduling request into a booked appointment, or a cleanup request into a deletion. It also gives the human a standard stop condition that can be reused across email, calendar, Slack, procurement portals, learning systems, CRMs, and administrative dashboards.

Credential Narration Is Never Part of the Workflow

A voice workflow should never require the user to speak credentials aloud. Spoken credentials can be captured in transcripts, overheard by nearby people, or mishandled in subsequent summaries. OpenAI’s voice documentation says Live and Advanced audio clips are retained with the transcript for 30 days, and deleting a chat deletes associated clips within 30 days subject to documented security, safety, legal, and previously disassociated-training exceptions. Since archiving does not delete clips, the safest design is to keep secrets out of the conversation from the beginning.

The same rule applies to text handoff. Do not paste passwords, one-time passwords, private keys, API keys, payment card numbers, bank credentials, identity documents, health records, or unnecessary confidential records into the chat after the call. If a provider requires authentication, the human should complete it directly in the provider’s secure interface. If the workflow needs a durable integration, use the provider authorization and workspace approval process rather than ad hoc credential sharing.

If the workflow asks for…	Safe response	Unsafe response
Password or OTP	Stop. The human authenticates directly in the provider interface.	Speak or paste the code into ChatGPT.
Payment card, bank, or tax identifier	Stop. Convert the task into a checklist for the authorized finance or account owner.	Dictate payment details or ask ChatGPT to store them for reuse.
Identity or health documents	Stop. Use only approved secure intake channels and minimize disclosed data.	Upload or summarize sensitive documents without a formal basis and review path.
Admin recovery or permission grant	Stop. Route to an authorized administrator and record the reason.	Let the workflow change access controls as part of a convenience task.

Recommendation: add a visible “no secrets in voice” note to your team’s standard operating procedure. The note should apply equally to Live conversations, Work tasks, connected apps, browser sessions, and end-of-call text continuation.

Payment, Account, Legal, and Destructive-Action Gates

Some actions require a hard gate even if the product surface technically allows the workflow to proceed. Payments, purchases, bookings, account changes, permission grants, publication, legal commitments, employment decisions, student discipline, medical or financial decisions, and destructive operations should not be executed through a voice instruction alone. They require an authorized human to review the context, verify the facts through appropriate sources, and use the provider’s formal approval process.

Use a three-level action gate. Level 1 covers reversible internal drafts, such as summarizing a meeting note or drafting a reply that remains unsent. Level 2 covers low-risk internal actions that may still affect colleagues, such as preparing a Slack update for review or creating a tentative calendar proposal. Level 3 covers consequential external or irreversible actions, including sending, posting, booking, buying, deleting, changing account settings, granting permissions, or making commitments. Level 3 requires explicit on-screen review and, where appropriate, an organizational approval outside ChatGPT.

Gate level	Examples	Permitted workflow outcome	Human requirement
Level 1: Draft only	Email draft, meeting agenda, spreadsheet outline, browser research notes.	Create or revise an artifact with no external side effect.	Human reviews before using externally.
Level 2: Internal low-risk proposal	Slack status draft, tentative calendar hold proposal, internal document update proposal.	Prepare for review; avoid automatic posting unless policy explicitly permits it.	Human confirms workspace, audience, and content.
Level 3: Consequential action	Send, post, submit, buy, book, delete, change account, grant access, accept terms.	Stop at approval screen or hand off to manual provider action.	Authorized human approval is mandatory.

For legal, finance, healthcare, education, employment, advertising, and youth-related workflows, treat the model output as a draft decision aid rather than final advice. OpenAI’s accuracy guidance states that ChatGPT can produce incorrect or misleading outputs, fabricated references, and confident but wrong claims. Important dates, amounts, legal obligations, policy interpretations, medical facts, and external references should be verified through reliable sources before any commitment or communication leaves the organization.

Full Hypothetical Example: Prepare Follow-Ups Without Sending, Booking, Posting, Buying, or Changing Accounts

The following example is intentionally hypothetical and stops before every external side effect. It demonstrates how a founder or operations lead might use Voice in Work to prepare follow-up materials after a partner call. The workflow drafts an email, a calendar proposal, a Slack update, and a browser research note, but it does not send, book, post, purchase, delete, submit, or change any account setting.

Scenario: The user wants to prepare a follow-up package for a possible vendor onboarding discussion. The user has a connected work email account, a calendar, Slack access, and a browser task capability available in the selected experience. The user is authorized to draft internal materials but must obtain finance approval before purchases, legal approval before terms are accepted, and an administrator’s approval before any vendor account is created.

1. Opening request: The user says, “Start a draft-only workflow for yesterday’s vendor discussion. Use my work account only. Summarize relevant email and calendar context if authorized, prepare a follow-up email draft, a proposed meeting agenda, a Slack status draft for the internal operations channel, and a browser research checklist. Do not send, post, book, submit forms, accept terms, create accounts, make purchases, or change settings.”
2. Account check: ChatGPT identifies the selected work context and asks the user to confirm that the visible connected accounts are correct. If any account is ambiguous, the workflow pauses until the user selects the right account or switches to manual drafting.
3. Read stage: ChatGPT summarizes only authorized email and calendar context. It labels each point with its source type, such as “calendar title,” “email thread subject,” or “user-provided note,” without exposing unnecessary personal data.
4. Draft stage: ChatGPT prepares the follow-up email as a draft artifact, not a sent message. It includes placeholders for any facts that require verification, such as pricing, implementation dates, security documentation, or contract terms.
5. Calendar proposal: ChatGPT drafts a meeting agenda and proposes candidate time windows, but it does not create or send an invitation. The user must verify participant availability and authorization before any calendar action.
6. Slack proposal: ChatGPT drafts an internal status update that says the vendor discussion is under review. It avoids commitments such as “approved,” “selected,” or “contracting begins” unless those decisions have already been formally made.
7. Browser research: ChatGPT opens a browser task only to gather public vendor documentation and prepare a checklist. If a login wall, payment prompt, account creation form, or terms acceptance appears, it stops and summarizes the next decision.
8. Approval review: The user reviews each artifact on screen. The user may approve saving drafts, but sending, posting, booking, purchasing, or creating accounts remains outside the workflow until the proper organizational approvals occur.
9. End-of-call handoff: If the user ends Voice before finishing, the remaining draft-only tasks continue in text, preserving the same stop conditions and approval gates.

A safe spoken prompt for the example looks like this:

Use draft-only mode for this workflow. I am preparing follow-up materials for a possible vendor discussion. Work only in the account I confirm on screen. You may summarize authorized email and calendar context, draft an email, draft a meeting agenda, draft an internal Slack update, and prepare a browser research checklist. Do not send, post, book, submit, buy, delete, create accounts, accept terms, grant permissions, or change settings. Before any action that could affect another person or external system, stop and show me the exact approval item for on-screen review.

A safe review prompt later in the call looks like this:

Before I decide anything, give me a review packet:
1. Every artifact created or modified.
2. The account or workspace used for each artifact.
3. All recipients, channels, dates, and commitments mentioned.
4. Any facts that still need verification from an authoritative source.
5. Any action that would require on-screen approval or a separate organizational approval.
6. A list of tasks that remain draft-only and have not been sent, posted, booked, bought, submitted, deleted, or changed.

The most important part of the example is not the vendor context; it is the stop discipline. The workflow remains useful because it prepares the human to decide faster, while refusing to treat preparation as authorization. This pattern applies equally to educator-parent communications, enterprise administrator updates, legal-technology document preparation, founder outreach, sales operations, research coordination, and engineering project follow-ups.

End-of-Call Text Continuation: Preserve the Same Gates

OpenAI’s release notes state that if a Work task remains unfinished when the Voice call ends, it can continue in text. That is a productivity feature, not an authorization reset. Ending the call does not erase prior uncertainty, does not reverse completed actions, and does not convert spoken intent into approval for sending, booking, posting, purchasing, deleting, changing accounts, or granting permissions. The text continuation should inherit the same accounts, limits, stop conditions, and review requirements established during the voice session.

At the end of a call, ask for a handoff note before disconnecting if time allows. The note should identify completed drafts, unfinished tasks, open verification points, pending approvals, and anything that must not happen without human action. If the call ends unexpectedly, begin the text continuation by asking ChatGPT to summarize the current state and explicitly confirm that no new external action should occur until you review the artifacts.

Text handoff instruction:
Continue from the Voice workflow in draft-only mode. First summarize:
- What artifacts exist.
- What sources were used.
- What remains unverified.
- What actions are pending approval.
- Whether anything has already been sent, posted, booked, bought, submitted, deleted, or changed.
Do not take any new external action until I review the summary and use the required on-screen or provider-side approval process.

This handoff instruction is especially useful when moving from mobile Voice to desktop review, from a founder’s call to an assistant’s operations queue, or from an educator’s planning session to a school-approved communication process. The text thread becomes the controlled workspace for completing draft edits, attaching evidence labels, and preparing approval packets.

This governance playbook covers ChatGPT Work event-triggered tasks, including burst limits, deduplication, approval pauses, shared links, and evidence practices. The ChatGPT Work Event-Trigger Governance Playbook: Burst Limits, Deduplication, Approval Pauses, Shared Links, and Evidence article is a focused companion for Work Event Trigger Governance because it directly addresses governance for event-triggered Work tasks, which is the specific operational concern behind this marker.

Progress Review During Long or Multi-App Tasks

Long tasks need periodic progress reviews because the risk profile changes as the workflow moves across apps. A read-only email summary may become a calendar proposal; a calendar proposal may become a draft invitation; a draft invitation may reveal an attendee privacy issue; a browser research task may encounter a vendor account creation form. Without checkpoints, the user may not notice when the workflow moves from harmless drafting toward consequential action.

Use a progress review every time the workflow changes app, account, artifact, or action class. Ask ChatGPT to state what it has done, what it is about to do, what data it used, and whether the next step has any external side effect. If the next step crosses from Level 1 to Level 2 or Level 3, require on-screen review or manual provider-side action before continuing.

Progress checkpoint:
Pause and report:
1. Which app, browser page, or artifact you are currently using.
2. Which account or workspace is active.
3. What information you read or drafted.
4. What you plan to do next.
5. Whether the next step sends, posts, books, submits, buys, deletes, changes settings, grants permissions, or commits externally.
6. If the next step has any external effect, stop until I review it on screen.

For enterprise administrators, the same checkpoint can be added to a standard operating procedure. For legal-technology teams, include matter number or client authorization status only if the organization’s policy allows that information in the workflow. For educators and parents, avoid exposing unnecessary student or child personal information; use initials, roles, or redacted descriptors where possible and rely on school-approved systems for formal communications.

Retry Limits and Failure Handling

Retries are useful for drafting and formatting, but they are risky around approvals, browser submissions, and account operations. A model may misunderstand a failed page load, a disabled button, a permission error, or a provider-side warning. If a task fails twice, stop the automation-like flow and switch to diagnosis. Repeated attempts can create duplicates, rate-limit issues, accidental submissions, or inconsistent records.

Use a retry limit that distinguishes between harmless artifact revisions and external operations. For drafting, multiple revisions are usually acceptable as long as the content remains internal and reviewed. For browser navigation, form entry, posting, sending, booking, purchasing, deleting, or permission changes, use a strict limit: one failed attempt triggers a pause; two failed attempts trigger manual review and incident-style notes.

Failure type	Recommended limit	After the limit
Draft wording or formatting does not meet requirements	Allow iterative revisions.	Keep version notes if the artifact is important.
Source ambiguity or conflicting facts	Do not retry as if the answer is known.	Mark the fact as unresolved and verify through an authoritative source.
Browser page load, navigation, or form mismatch	One retry if no side effect occurred.	Stop and provide a manual checklist.
Approval, submission, payment, booking, deletion, or account setting error	No blind retry.	Stop immediately and route to the authorized human or administrator.

Recommendation: record failed attempts in the handoff note. The note should say what failed, whether any side effect may have occurred, what evidence is visible, and which human owner is responsible for checking the provider system. This is not bureaucracy; it prevents silent duplicate actions and gives administrators a clear path to investigate.

Cancellation: Stop, Summarize, and Verify No Side Effect

Cancellation should be easy to say and operationally specific. “Stop” should mean stop the current task, do not continue to the next app, and do not take external action. For higher-risk tasks, cancellation should also trigger a status report that distinguishes drafts from completed actions and identifies any provider-side state that the user must check manually.

Use this cancellation prompt when a task appears to drift, when the wrong account is active, when a sensitive screen appears, when an approval prompt is confusing, or when you are interrupted and cannot supervise the task:

Cancel the active workflow now. Do not send, post, book, buy, submit, delete, change settings, grant permissions, or continue browser actions. Summarize what has been drafted, what has been read, what app or account was active, and whether you have evidence of any external side effect. If anything may have changed outside the draft, tell me exactly what I need to verify manually.

After cancellation, do not rely solely on the chat summary if the task reached a provider app or browser page. Check the provider’s sent folder, drafts folder, calendar, Slack channel, admin log, order page, or account settings as appropriate. OpenAI’s connected-app documentation notes that app calls are logged in the Compliance Logs platform for supported enterprise use, but availability and logging workflows depend on the enterprise environment. Teams should use their own administrative logging, provider audit logs, and incident process where applicable.

Transcript-Versus-Artifact Reconciliation

A voice transcript is not the same as an artifact record. OpenAI’s voice documentation states that transcripts may not exactly match what was said. For audit and quality purposes, reconcile three different records: the conversation transcript, the artifacts created or edited, and the provider-side state such as drafts, sent messages, calendar entries, Slack posts, browser submissions, or app logs. If these records disagree, trust the provider-side state for what actually happened and use the transcript only as contextual evidence.

Reconciliation is necessary because a user may have spoken “next Thursday,” while the draft artifact contains a specific date that falls on Friday, or the transcript may render a name incorrectly while the email recipient field contains the correct address. ChatGPT can also produce confident but wrong summaries. The human review process must therefore inspect the actual artifact fields and the relevant provider records, not just the conversational summary.

Record type	What it is good for	What it cannot prove by itself
Voice transcript	Conversation context, user intent, rough sequence of instructions.	Exact spoken wording, final approval, or provider-side completion.
Chat artifact	Draft content, revision history in the conversation, unresolved questions.	Whether an email was actually sent or an external form was submitted.
Provider record	Sent messages, calendar events, Slack posts, admin changes, orders, submissions.	Why the user intended the action unless paired with workflow notes.
Enterprise compliance or app logs where supported	Administrative trace of supported app calls or policy-relevant events.	Universal coverage across all plans, apps, surfaces, or regions.

Use this reconciliation prompt at the end of any workflow that touched more than one app:

Prepare a reconciliation summary:
- List the artifacts currently visible in this chat or Work task.
- List every app, account, workspace, or browser page used.
- Identify any action you believe remained draft-only.
- Identify any action that may have affected an external system.
- Highlight names, dates, recipients, amounts, addresses, commitments, links, and attachments that require manual verification.
- Do not assert that something was sent, posted, booked, bought, submitted, deleted, or changed unless there is visible provider-side evidence in the workflow.

For regulated teams, pair this summary with the organization’s records-retention policy and privacy controls. The OpenAI Privacy Center explains settings for areas such as memory, apps and plugins, multifactor authentication, model improvement, data export, and deletion, but opening the Privacy Center does not modify settings or override organization policy. Enterprise, Edu, and Healthcare availability and controls can differ from consumer settings, so administrators should document the applicable controls for their own workspace.

Action Review Checklist Before You Leave the Workflow

Before closing the browser, ending the text continuation, or handing work to another person, complete a final review checklist. The checklist should be short enough to use every time and specific enough to catch the major failure modes: wrong account, wrong destination, unverified facts, hidden commitments, accidental external side effects, and missing approvals.

1. Account confirmed: Verify the email account, calendar, Slack workspace, connected app, or browser session used during the workflow.
2. Artifacts listed: List every draft email, calendar proposal, Slack message, document, spreadsheet, presentation, browser note, or form draft created or edited.
3. External actions separated: Confirm which items are draft-only and which, if any, were sent, posted, booked, submitted, bought, deleted, or changed.
4. Facts verified: Check names, dates, recipients, amounts, addresses, links, attachments, policy statements, and commitments against authoritative sources.
5. Approvals recorded: Confirm that any consequential action used the required on-screen control or provider-side approval path, not spoken approval alone.
6. Secrets excluded: Confirm that no credentials, OTPs, private keys, payment details, identity documents, health records, or unnecessary confidential content were spoken or pasted.
7. Retry status captured: Note failed attempts, ambiguous provider states, or manual verification tasks.
8. Handoff prepared: If someone else must continue, provide a draft-only handoff with open questions and explicit stop conditions.
9. Cleanup planned: Remove unnecessary drafts, disconnect unused app access where appropriate, and follow workspace policy for retention or deletion.

This checklist is intentionally independent of any single app interface. UI labels, permissions, availability, and approval surfaces can vary by plan, account, app, region, rollout, and workspace policy. The stable practice is to keep the human decision visible, make the artifact inspectable, and refuse to let convenience collapse review into execution.

Safe Cleanup After Approval or Cancellation

Cleanup is part of the workflow, not an afterthought. If you created drafts that should not persist, remove them manually in the provider app after confirming they were not sent or needed for records. If you connected an app only for a temporary task, review whether the connection should remain authorized under your workspace policy. Installing or enabling a plugin does not itself grant provider authorization or workspace approval, but once access exists, administrators and users should periodically review whether it remains necessary.

For individual users, cleanup may include deleting unnecessary drafts, closing browser sessions, signing out of shared devices, reviewing app connections, and checking privacy settings. For enterprise administrators, cleanup may include reviewing connected-app permissions, compliance logs where supported, role assignments, workspace approval settings, and incident notes for failed or canceled workflows. Do not delete records that are subject to legal hold, school policy, contractual retention, financial recordkeeping, or security investigation requirements.

A practical cleanup prompt can be used without exposing secrets:

Prepare a cleanup checklist for this workflow. Do not request credentials or private data. Include:
- Drafts I should review or remove manually.
- App connections or permissions I may need to review under workspace policy.
- Browser sessions or provider pages I should close.
- Records I should retain because they document a decision or approval.
- Any items I must not delete because they may be subject to legal, compliance, education, financial, or security retention rules.

The goal is not to erase the workflow; it is to leave a controlled record and remove unnecessary exposure. A clean finish makes the next Voice-to-Work session safer because the user starts with fewer stale drafts, fewer ambiguous app states, and a clearer understanding of which permissions are still active.

Operating Checklists for a Reliable Voice-to-Work Runbook

A Voice-to-Work workflow is safest when it is operated like a lightweight production process rather than an informal conversation. OpenAI’s documentation says Voice uses the tools and permissions available to the selected experience, and connected apps retain their existing access, data permissions, and action restrictions. The practical implication is simple: your controls must exist before the conversation begins, because speaking to ChatGPT does not create a separate security boundary, a new approval model, or a universal undo function.

The checklists below are written for teams that use ChatGPT to draft email, prepare calendar proposals, summarize Slack threads, create documents or spreadsheets in Work, and plan browser tasks. They are conservative by design. They do not assume that every plan, region, app, workspace, or account has the same surfaces, approval modes, logs, or limits. They also assume that any external message, booking, purchase, payment, account change, deletion, publication, legal commitment, permission change, or other consequential step requires authorized human review before it happens.

Startup Checklist: Before the Voice Session Begins

Use this startup checklist before starting a voice call, especially when the task may read connected apps, draft communications, or involve browser work. The goal is to prevent accidental account mix-ups, over-broad access, and unreviewed actions before the assistant has any opportunity to use a tool.

• Confirm the selected experience. Verify whether you are using Chat, Work, or desktop Work/Codex, because OpenAI states that Voice uses the tools and permissions available to the selected experience. Do not assume a task started in one surface has the same tools, approvals, or limits as another.
• Verify the signed-in user and workspace. Check the active ChatGPT account, workspace, and connected provider account before asking to read email, Slack, calendar, documents, or browser content. Multi-account confusion is a common operational failure, not a model failure.
• Review app permissions. Confirm which apps are connected and whether their permission mode is appropriate for the session. OpenAI’s connected-app documentation says changing an app permission changes when ChatGPT asks before using already-authorized access; it does not grant the app new provider-side access.
• Prefer least privilege. Use the minimum app access needed for the task. Treat any broad mode such as an available “allow all” option as elevated risk, not as a routine default.
• Define the run objective. State the task in one sentence, such as “prepare drafts and a review checklist for tomorrow’s customer follow-ups without sending anything.” A narrow objective makes it easier to detect tool drift.
• Define stop conditions. Say what must pause the workflow: unknown recipient, ambiguous date, missing source, sensitive data, payment, booking, deletion, permission change, account setting change, legal language, health information, identity data, or a request to act outside authorization.
• Prepare redacted inputs. Do not speak, paste, upload, or store passwords, one-time passcodes, private keys, banking credentials, identity documents, protected health information, or unapproved confidential data. If sensitive details are needed, use approved systems and authorized staff outside the voice transcript.
• Decide evidence capture method. Choose how the operator will record the final plan, drafts, approvals, and exceptions. Depending on the account and enterprise support, app calls may appear in a compliance logging platform, but local teams should still maintain their own workflow evidence where policy requires it.

Execution Checklist: During the Voice Conversation

The execution checklist keeps the task in a read-draft-review-action sequence. It is designed around OpenAI’s documented constraint that actions requiring approval on web and mobile must be approved or declined through on-screen controls; spoken approval is not supported.

1. Restate scope out loud. Begin by saying the selected account, target app, business purpose, and no-send/no-post/no-book/no-buy rule unless the session has reached an explicit on-screen approval point.
2. Ask for source naming. Require the assistant to identify the app, account, thread, document, calendar, page, or browser source used for each claim. Voice transcripts may not exactly match what was said, so source attribution must be visible in the artifacts.
3. Keep read actions separate from drafts. First summarize authorized content; then draft artifacts; then review; then decide whether an action is appropriate. Do not combine “summarize this thread and send the reply” into one instruction.
4. Require uncertainty labels. Ask the assistant to mark assumptions, missing data, conflicts, and items requiring independent verification. OpenAI’s accuracy guidance says ChatGPT can produce incorrect or misleading outputs, including confident but wrong claims.
5. Inspect tool output on screen. Confirm names, dates, recipients, time zones, attachments, amounts, addresses, commitments, links, and account context from the visible source or authoritative system, not from memory or the transcript alone.
6. Pause before external effects. External messages, calendar invitations, Slack posts, purchases, bookings, deletions, permission changes, CRM updates, or account modifications must wait for authorized human review and any required on-screen approval.
7. Limit retries. If the assistant repeatedly selects the wrong account, misreads a source, invents a fact, or proposes an unsafe action, stop the workflow rather than trying to repair it indefinitely by voice.
8. Close with a status summary. Before ending the call, ask for a concise list of completed drafts, pending approvals, unresolved questions, actions not taken, and the next text-handoff instruction.

This monitoring playbook covers incident reporting, alignment gates, human control, and stop criteria for long-running AI agents. The Frontier AI Monitoring Playbook: Incident Reporting, Alignment Gates, Human Control, and Stop Criteria for AI Agents article is a focused companion for Human Review Gates because it provides a broad governance reference for human control and stop criteria, fitting the article’s approval and review-gate discussion without duplicating the browser-safety link.

Human Review Checklist: What Must Be Approved by a Person

Human review is not a ceremonial step. It is the control that prevents a fluent draft from becoming an unauthorized commitment. The reviewer must be someone with the right role, context, and authority for the action, not merely the person nearest to the keyboard.

Artifact or proposed action	Minimum human verification	Do not approve if
Email draft	Recipient identity, account context, attachments, tone, commitments, dates, amounts, confidential content, and source accuracy.	The recipient is ambiguous, attachments are unverified, the draft commits the organization beyond authority, or sensitive data is unnecessary.
Calendar proposal	Invitees, time zone, meeting title, description, location, conferencing details, recurrence, visibility, and conflicts.	The event invites external parties without approval, exposes private notes, creates a recurring obligation, or books a restricted resource.
Slack or chat message	Channel or recipient, workspace, audience sensitivity, factual claims, customer names, incident status, and escalation language.	The message could disclose confidential information, trigger an operational escalation, or appear as an official statement without authorization.
Document, spreadsheet, or presentation	Data provenance, formulas, labels, assumptions, copied text, citations, permissions, and distribution list.	The artifact includes unapproved confidential data, unsupported analysis, fabricated references, or hidden formulas that have not been checked.
Browser task	Target site, signed-in account, visible action, transaction terms, fields to be changed, and cancellation path.	The task involves payment, booking, deletion, account settings, identity verification, legal submission, or policy-sensitive activity without explicit authorization.
Permission or connection change	Business need, affected app, provider-side authorization, workspace policy, role impact, logging, and rollback plan.	The change broadens access for convenience, bypasses a workspace policy, or is not documented for later review.

A reviewer should reject any approval request that is based only on a spoken summary. OpenAI states that spoken approval is not supported for actions requiring approval on web and mobile, and operationally it is also too easy for speech recognition or memory to distort names, dates, and intent. Review the visible artifact or on-screen approval prompt before deciding.

Exception-Handling Checklist: When the Workflow Goes Off Track

Exceptions should be treated as workflow events, not annoyances. A good exception process prevents small uncertainties from turning into unauthorized messages, incorrect bookings, or hidden data exposure.

• Wrong account or workspace: Stop immediately, do not continue reading, and record which source may have been accessed. Switch only after the operator confirms the correct account on screen.
• Unexpected sensitive data: Stop summarization, avoid repeating the sensitive data in the transcript, and follow the organization’s data-handling policy. Do not ask the assistant to store or reformat protected health information, identity documents, credentials, or banking details.
• Conflicting sources: Ask for a table that separates each source, timestamp, and conflict. Do not let the assistant “pick the most likely answer” when the output would affect a commitment or external communication.
• Unsupported factual claim: Mark it as unverified and check an authoritative source. OpenAI’s accuracy guidance explicitly warns that ChatGPT can fabricate references or produce misleading outputs.
• Tool request exceeds scope: Decline the action, restate the boundary, and continue only with a safer subtask such as drafting a plan or checklist.
• Approval prompt appears unexpectedly: Pause and inspect the prompt. If the action was not part of the approved plan, decline it and capture the reason.
• Assistant cannot access a needed file or source: Do not work around policy by pasting confidential material into the chat. Use an approved access path or have an authorized human prepare a redacted excerpt.
• Voice quality degrades: Switch to text for precision. Names, addresses, figures, legal terms, and commitments are better reviewed in written form.

Disconnect and Interruption Checklist

OpenAI’s Work documentation states that if a Work task remains unfinished when the Voice call ends, it can continue in text. This text continuation is useful, but it is not a safety bypass: it does not reverse actions already taken, approve pending actions, or eliminate the need to preserve stop conditions and audit context.

1. Freeze external effects. After a dropped call or app interruption, assume no further external action is authorized until the operator reviews status in text.
2. Ask for a state summary. In text, request “List what was read, what was drafted, what was approved, what was not approved, what actions were taken, and what remains pending.”
3. Reconcile with visible systems. Check email sent folders, calendar events, Slack posts, document histories, browser confirmations, and app logs where applicable. Do not rely only on the conversation transcript.
4. Confirm pending approval prompts. If a prompt remains open, approve or decline only after rechecking the action, account, and artifact on screen.
5. Preserve the original boundary. Continue in text with the same “draft only,” “no external send,” or “human approval required” constraints unless an authorized reviewer changes the plan.
6. Record the interruption. Note the time, surface, task, unfinished item, and whether any external effect was confirmed. This helps later audit and troubleshooting.

Recommended text handoff after a disconnect:

Continue only in text. First summarize the exact state of the workflow:
1. Sources read and accounts used.
2. Drafts created and where they are stored.
3. Approval prompts shown, approved, declined, or still pending.
4. Any external actions already completed.
5. Unverified facts, conflicts, or missing information.
6. Next safest step that does not send, post, book, buy, delete, modify permissions, or make a commitment without human review.

Cleanup Checklist: Ending the Session Safely

Cleanup is the final control layer. It reduces lingering access, orphaned drafts, stale browser sessions, and ambiguous task state. It also creates evidence for later review if a message, booking, or artifact is questioned.

• Close the loop on artifacts. Label each draft as approved, rejected, needs revision, or retained for reference. Do not leave a draft that looks ready to send unless its status is clear.
• Remove unnecessary sensitive content. If policy allows deletion or redaction of unneeded working material, do it through approved controls. Do not ask the assistant to remember sensitive material for future convenience.
• End browser sessions where appropriate. Sign out or close sessions according to organizational policy, especially on shared devices or managed browser environments. Do not narrate credentials or one-time codes during cleanup.
• Check pending prompts. Decline any approval prompt that is no longer needed. A stale approval prompt can become a future accidental action.
• Document final status. Record what was read, created, changed, sent, posted, booked, deleted, or left pending. If no external action occurred, state that explicitly.
• Review chat retention expectations. OpenAI’s Voice help states that Live and Advanced audio clips are retained with the transcript for 30 days, and deleting a chat deletes associated audio/video clips within 30 days subject to stated exceptions. Archiving does not delete clips.

RACI: Who Owns Each Control in a Voice-to-Work Workflow

A RACI matrix prevents the operator, reviewer, workspace admin, security team, and business owner from assuming someone else handled the risk. Adapt the roles below to your organization, but keep one rule intact: the person who speaks the instruction should not automatically be treated as the approver for every consequential action.

Workflow activity	Responsible	Accountable	Consulted	Informed
Define task scope and stop conditions	Operator	Business owner	Security or compliance for sensitive workflows	Reviewer
Configure app connections and permission modes	Workspace admin	IT owner	Security, legal, data owner	Affected users
Select correct account and source	Operator	Operator’s manager or business owner	Data owner if source is restricted	Reviewer
Review email, Slack, calendar, and document drafts	Authorized reviewer	Business owner	Legal, finance, HR, or security when content requires it	Operator
Approve external sends, postings, bookings, purchases, or account changes	Authorized approver	Business owner or delegated executive	Legal, finance, procurement, security, or privacy as needed	Operator, audit owner
Investigate exceptions and suspected side effects	Security or operations lead	Incident owner	Workspace admin, app owner, legal, privacy	Affected stakeholders
Review permissions periodically	Workspace admin	IT or governance owner	Business owners, security, compliance	Users and reviewers
Maintain retention and audit evidence	Records owner	Compliance or legal owner	Security, privacy, app owners	Business owner

For smaller teams, one person may hold multiple roles, but the control should still be explicit. A founder can be both business owner and authorized approver, but they should still inspect the on-screen artifact before sending a customer commitment, calendar invitation, purchase order, or legal response.

Failure Taxonomy for Voice-to-Work Operations

A failure taxonomy helps teams log incidents consistently and improve the workflow over time. It also keeps the investigation focused on observable causes: account selection, source reliability, approval state, tool behavior, user instruction, and data handling.

Failure class	Example	Primary risk	Immediate response	Longer-term prevention
Account-context failure	The assistant reads a personal calendar instead of the company calendar.	Privacy exposure, wrong scheduling, unauthorized use of information.	Stop, document source, switch only after screen verification.	Preflight account labels, separate browser profiles, periodic connection review.
Source-attribution failure	A draft cites a fact without naming the source thread, document, or page.	Unsupported claims, fabricated references, weak audit trail.	Mark unverified and require a source table before review.	Use a source attribution contract in every prompt.
Speech-recognition failure	A name, amount, or date is transcribed incorrectly.	Wrong recipient, wrong commitment, wrong meeting time.	Verify on screen and switch to text for precision.	Spell critical terms in text, use written approval checklists.
Hallucination or reasoning failure	The assistant invents a policy, quote, or availability detail.	Misleading communication or operational decision.	Check authoritative sources and remove unsupported content.	Require uncertainty labels, tests, and human review for consequential use.
Approval-boundary failure	The operator verbally says “go ahead” without reviewing an on-screen approval prompt.	Unauthorized external action or false sense of approval.	Do not proceed; inspect and approve or decline on screen.	Train users that spoken approval is not supported for required approvals.
Sensitive-data failure	A user dictates a one-time code, bank credential, identity document detail, or protected health information.	Credential compromise, privacy breach, policy violation.	Stop, avoid repeating the data, follow security or privacy procedure.	Use opening prompts that prohibit credentials and regulated data.
Browser-side-effect failure	A browser task changes a setting, submits a form, or purchases an item without intended approval.	Financial, legal, operational, or account impact.	Record the action, reverse only through authorized channels if permitted, notify the owner.	Use browser plans, stop points, and explicit approval gates.
Retention or evidence failure	The team cannot reconstruct what was approved after a call.	Weak auditability, unresolved dispute, compliance gap.	Collect available artifacts, logs, sent items, histories, and user notes.	Adopt end-of-call status summaries and records retention rules.

Verification Checkpoints Before, During, and After Action

Verification checkpoints convert broad safety principles into concrete questions. The checkpoints below should be used even when the assistant’s output appears polished, because OpenAI’s accuracy guidance says important facts, dates, quotes, data, and external references should be verified through reliable sources.

Checkpoint 1: Identity, Account, and Authorization

• Which ChatGPT workspace and user account is active?
• Which connected app account is being used?
• Does the operator have authority to read this source?
• Does the reviewer have authority to approve the proposed action?
• Would a reasonable audit record show why this source was accessed?

Checkpoint 2: Source and Evidence

• What source supports each factual claim?
• Is the source current enough for the decision?
• Are there conflicts among email, calendar, Slack, documents, or browser information?
• Did the assistant separate observed facts from assumptions and suggestions?
• Are external references verified outside the model output when they matter?

Checkpoint 3: Artifact Quality

• Does the draft include only information approved for the intended audience?
• Are names, dates, amounts, addresses, links, and attachments correct?
• Does the artifact make a promise, concession, legal position, payment commitment, or operational guarantee?
• Are formulas, filters, charts, and spreadsheet calculations inspected by a person?
• Is the artifact labeled as draft, approved, sent, posted, or archived?

Checkpoint 4: Approval and External Effect

• Is an on-screen approval required by the surface or app?
• Has the reviewer inspected the exact visible action, not just a spoken summary?
• Is there a cancellation path before the action becomes irreversible?
• Is the action within the operator’s and approver’s delegated authority?
• Has the team recorded who approved the action and what they reviewed?

Checkpoint 5: Handoff and Retention

• What remains unfinished after the voice call?
• Can the next step continue safely in text without changing the approval boundary?
• What evidence must be retained under team policy?
• Are audio, transcript, app logs, browser histories, sent items, and document histories governed by the relevant retention rules?
• Have unnecessary drafts, pending prompts, and unused browser sessions been closed or labeled?

Audit Logs, Retention, and Evidence Capture

An auditable Voice-to-Work process needs more than a transcript. OpenAI’s Voice help states that transcripts may not exactly match what was said, and audio clip retention is governed separately from ordinary memory or archive expectations. Treat the transcript as one artifact among several, not as the definitive record of what happened.

For enterprise environments, OpenAI’s connected-app documentation states that app calls are logged in the Compliance Logs platform for supported enterprise use. That logging can help reconstruct app access, but teams should not assume every account, plan, app, region, or workspace has the same logging coverage. Administrators should document what is actually logged in their environment and what must be captured through local systems.

Evidence item	Why it matters	Recommended handling
Opening scope statement	Shows intended task, stop conditions, and no-action boundaries.	Keep in the chat or task record when policy requires traceability.
Source attribution table	Connects claims to email, calendar, Slack, document, or browser sources.	Attach to the draft or review packet; remove unnecessary sensitive content.
Draft artifacts	Shows what was proposed before human edits and approval.	Label version, owner, and status; avoid retaining unneeded confidential material.
Approval evidence	Shows who reviewed the visible artifact and what action was allowed.	Capture according to legal, compliance, and records rules; do not store credentials or regulated data unnecessarily.
External action confirmation	Shows whether an email, post, booking, purchase, deletion, or account change occurred.	Verify in the authoritative system, not solely in ChatGPT’s response.
Exception record	Supports investigation and process improvement.	Record the class of failure, source, time, impact, response, and prevention step.
Retention decision	Shows whether drafts and logs were retained, archived, deleted, or escalated.	Follow organizational retention schedules and OpenAI-documented data controls; archiving is not deletion.

Teams should also decide when not to retain a working artifact. If a draft contains unnecessary confidential information, personal data, or regulated content, retaining it “just in case” may increase risk. Follow legal, privacy, security, and records policies rather than using the chat history as an informal document repository.

Periodic Permission Review and Governance Cadence

Permission review is necessary because connected apps, provider permissions, workspace approvals, role assignments, and ChatGPT permission prompts are separate controls. Installing a plugin does not replace provider authorization, and changing when ChatGPT asks for approval does not grant new access inside the provider service. Administrators should review both sides of the connection: the ChatGPT workspace configuration and the provider’s own account or admin console.

Weekly Review for Active Teams

• Review recent high-impact workflows: customer communications, executive scheduling, procurement drafts, incident updates, and browser tasks.
• Check whether any approval prompt was declined, unexpected, or misunderstood.
• Sample drafts for source attribution, unsupported claims, and sensitive-data leakage.
• Confirm that unfinished Voice tasks moved to text with the same approval gates.
• Record workflow improvements, prompt changes, or training needs.

Monthly Administrator Review

• Inventory connected apps and identify owners for each connection.
• Confirm whether permission modes match current business need.
• Review broad action permissions and reduce them where possible.
• Check provider-side access, inactive users, departed employees, role changes, and shared accounts.
• Review available compliance logs or app activity logs where supported.
• Verify that users understand that spoken approval is not supported for approval-required actions on web and mobile.

Quarterly Governance Review

• Reassess which workflows are allowed in Chat, Work, and desktop Work/Codex.
• Update prohibited data categories, escalation rules, and browser-task boundaries.
• Review incident and exception trends by failure class.
• Test sample prompts against representative edge cases, ambiguous names, conflicting dates, and sensitive-data traps.
• Confirm retention practices for transcripts, audio clips, app logs, documents, and approval records.
• Update onboarding materials for new employees, contractors, educators, or family administrators using the workflow.

Operational recommendation: Treat permission review as a scheduled governance activity, not as a response to an incident. The safest time to remove unnecessary access is before an assistant, user, or reviewer mistakes that access for authorization.

Practical Runbook Template for Teams

The following template can be copied into an internal operating procedure. It is intentionally plain so that legal, security, education, enterprise administration, or startup teams can adapt it without relying on unsupported product assumptions.

Voice-to-Work Runbook Template

1. Authorized use
- Approved surfaces:
- Approved connected apps:
- Approved workflow types:
- Prohibited workflow types:
- Data that must never be spoken, pasted, uploaded, or stored:

2. Startup
- Confirm ChatGPT workspace:
- Confirm selected experience:
- Confirm connected account:
- Confirm app permission mode:
- State objective:
- State stop conditions:

3. Execution
- Read stage owner:
- Draft stage owner:
- Required source attribution:
- Required uncertainty labels:
- Retry limit:
- Switch-to-text conditions:

4. Human review
- Reviewer role:
- Approval authority:
- Required checks:
- Actions requiring on-screen approval:
- Actions always requiring escalation:

5. Browser tasks
- Approved sites or systems:
- Signed-in account verification:
- Stop points:
- Prohibited actions:
- Confirmation evidence:

6. Handoff
- End-of-call status summary required:
- Text continuation rules:
- Pending approval handling:
- Disconnect procedure:

7. Cleanup and retention
- Draft labeling:
- Browser/session cleanup:
- Evidence capture:
- Retention period:
- Deletion or archive rules:
- Exception record owner:

8. Periodic review
- Weekly workflow review owner:
- Monthly permission review owner:
- Quarterly governance review owner:
- Training update owner:

This runbook should be reviewed whenever OpenAI changes availability, surfaces, app behavior, or documented data controls, and whenever the organization changes its connected apps, provider permissions, workspace policies, or approval requirements. The point is not to freeze the workflow forever; it is to keep the operating boundary explicit as the product and your organization evolve.

Final Operating Principles

A robust Voice-to-Work workflow starts with the recognition that voice is an input method, not a replacement for governance. OpenAI’s September 2026 documentation expands what users can start by speaking, including supported plugins and Work tasks, but it also preserves existing app connections, permissions, usage limits, and approval requirements. The safest teams design around those boundaries instead of assuming the assistant can infer them.

Use voice for speed, structure, and drafting. Use on-screen review for precision. Use text handoff for unfinished work. Use connected apps only within least-privilege permissions. Use logs and evidence records to reconstruct what happened. Use humans for consequential judgments, external commitments, sensitive communications, payments, bookings, account changes, destructive actions, and legal or compliance decisions.

The practical test is whether a reviewer can answer five questions after the session: what account was used, what sources were read, what was drafted, what was approved, and what external effect occurred. If those answers are unclear, the workflow is not ready for higher-stakes use. Tighten the startup checklist, approval gate, and evidence capture before expanding the scope.

Useful Links

• OpenAI ChatGPT release notes
• OpenAI ChatGPT Voice help
• OpenAI ChatGPT Work and Codex help
• OpenAI Apps in ChatGPT help
• OpenAI accuracy guidance for ChatGPT
• OpenAI Privacy Center help