ChatGPT for Word deployment checklist: admin gates, permissions and pilot tests

Rolling out ChatGPT for Word is not one installation task. A managed organization has to align Microsoft 365 deployment, ChatGPT workspace access and the permissions behind any connected sources a user expects to bring into the sidebar. If those controls are treated as one switch, a missing ribbon item, an unavailable workspace and an inaccessible SharePoint file can all arrive at the help desk as the same vague complaint: “ChatGPT is not working in Word.”

This checklist turns those layers into an auditable rollout. Its workbook separates prerequisites from observed pilot results, gives every control an owner and records evidence without asking teams to paste documents, access tokens or other secrets into the file. The four tabs cover readiness gates, context permissions, pilot tests and rollout sign-off; matching CSVs let teams use the same rows in another system. The fields begin blank where only a real tenant test can supply the answer.

The checklist is designed for a managed pilot rather than an individual installing an add-in for personal use. OpenAI's Word guide says the add-in is available across ChatGPT plans, while Microsoft's listing says access can still vary with plan, region, workspace settings, the Microsoft 365 environment and admin controls. Availability therefore establishes that the product exists for a plan; it does not establish that an employee's Microsoft account has been assigned the add-in, that the intended ChatGPT workspace permits it, or that a connected source is authorized.

Download the complete Excel workbook or use the matching CSVs for readiness gates, context permissions, pilot tests and rollout sign-off. The artifact README defines the allowed status values and the evidence required before a row can move out of Not started. For launch, capability, context and plan background, read OpenTools' separate ChatGPT for Word report; this guide owns the operational deployment workflow.

Treat the rollout as three separate controls#

The first control is Microsoft 365 deployment. Microsoft decides whether the OpenAI-published add-in is available to the intended users and whether it appears in Word. The official Marketplace page identifies the publisher as OpenAI, LLC and says the same add-in covers Word, Excel and PowerPoint. That publisher check matters because a search for “ChatGPT in Word” can return unrelated third-party add-ins with different access and data practices.

The second control is ChatGPT workspace access. After the add-in appears, the user signs in with a ChatGPT account and selects an organization workspace when applicable. OpenAI documents a separate workspace setting that can turn Word access on or off. It says Word will be enabled by default beginning October 1, 2026, but that default does not distribute an Office add-in or override Microsoft 365 policy. Before relying on the date, record both the Microsoft assignment and the ChatGPT workspace decision in Readiness gates.

The third control is task context. The sidebar can work with the document that is open and with text pasted into a prompt. OpenAI's current limitations say it cannot reference other files on the computer automatically. That local-file boundary is compatible with a different capability: supported connected apps can bring in permitted material from services such as Outlook, SharePoint, Google Workspace and Dropbox. Whether a connected source works depends on the plan, workspace settings, provider authorization and the user's permission to the source. Context permissions records each route separately so a successful open-document test cannot be mistaken for proof that connected data is ready.

Verify Microsoft 365 readiness before assigning the pilot#

Microsoft recommends a phased add-in rollout that begins with a small group of business stakeholders and IT staff, expands after evaluation, and proceeds to the full population only after another successful review. Its admin-center deployment guide allows assignment to everyone, specific users or groups, or only the administrator. “Just me” is useful for an initial technical check, but it does not exercise the group membership, user environment or support path that a managed pilot needs.

The readiness tab begins with tenant conditions from Microsoft's centralized deployment requirements. Centralized deployment depends on compatible Microsoft 365 or Office licensing, active Exchange Online mailboxes and a directory in or federated to Microsoft Entra ID. Those are conditions for that deployment method, not universal requirements for every personal Marketplace installation. Record which deployment route the organization is actually using before applying the rows.

Group structure deserves its own check. Microsoft supports assignments to individuals, eligible groups or everyone, but its centralized deployment documentation says nested groups are not supported and excludes non-mail-enabled security groups. A pilot can therefore look correctly assigned at the parent-group level while intended users in a nested group never receive the add-in. Record the exact top-level group used for the pilot, an owner for membership, and evidence that the pilot users are direct eligible members. Do not put user passwords, tokens or document contents in the evidence field; a ticket, approved screenshot location or internal change record is enough.

Microsoft's documented propagation windows also belong in the plan. Its centralized deployment FAQ says a new deployment can take up to 24 hours to appear for all users, an update or on/off change can take up to 72 hours, and removal can take up to 24 hours. A separate deployment page uses the broader 24–72-hour range for ribbon appearance and notes that users may need to relaunch Office. These are documented upper bounds, not service guarantees. The sign-off tab records the change type and observation time so a team does not declare failure immediately after an authorized change or wait indefinitely after the relevant window has passed.

Keep workspace access separate from connected-source access#

Once the add-in appears, PT-002 asks the pilot user to sign in and confirm the intended ChatGPT workspace. That test should stop after the workspace name and access state are recorded. It should not use a sensitive document merely to prove authentication. If the workspace is unavailable, the relevant checks are the ChatGPT account, the selected workspace and the Word setting in the ChatGPT admin console. Redeploying the Microsoft add-in is not the first response to a workspace-selection problem.

Connected sources add another set of controls. OpenAI's administrator documentation for apps separates workspace or role access, provider authorization, OAuth scopes, enabled actions and the user's connection. For Microsoft connected apps in particular, an Entra permission grant does not itself enable a ChatGPT action or connect an individual's account. The workbook therefore gives Outlook, SharePoint, Google Workspace and Dropbox separate rows, with fields for workspace availability, provider authorization, user authorization and a minimal approved test source.

That separation protects both accuracy and data handling. A connected-source test should use a document or message deliberately prepared for the pilot, with a known expected fact and an owner who is allowed to verify access. If the add-in cannot retrieve it, record the observed error and check the source's own permission, provider connection and ChatGPT app setting before changing broader tenant controls. If it can retrieve it, the result proves only that test user's access to that test source at that time. It does not prove that every employee can access every file.

OpenAI says conversations in the add-in remain separate from ChatGPT conversation history and that memory and skills do not carry over automatically. At the same time, Word supports skills created for repeatable document tasks. PT-009 tests the absence of assumed carryover by asking the user to identify whether the sidebar has any expected prior context before supplying it. The goal is to teach the operating boundary, not to force memory or a skill into the pilot.

Run tests that produce evidence rather than demonstrations#

A useful pilot starts with a harmless document created for the test. It should contain a short paragraph, one known fact, a small table and a term used inconsistently in two places. That single fixture can support several bounded checks without exposing a real customer document or confidential report. Keep a pristine copy so every pilot user starts from the same input.

The first tests verify the control layers in order. PT-001 records whether the OpenAI-published add-in appears for a directly assigned pilot user after the documented deployment window and an Office relaunch. PT-002 records sign-in and workspace selection. PT-003 asks the sidebar to summarize the open fixture and compares the response with the known paragraph. PT-004 selects one sentence and requests a revision that preserves a named fact. These rows make it possible to identify whether failure occurred before the add-in appeared, during ChatGPT authentication, or during work with the open document.

Only then should the pilot test connected context. PT-005 uses one source that the user and administrator have explicitly approved, such as a small SharePoint file prepared for the pilot. The expected result should name one fact the source contains without copying the whole source into the workbook. PT-006 checks the documented local-file boundary: a file that is neither open, pasted nor available through an authorized connected app should not be assumed accessible. That test protects against a misleading rollout message that the add-in can browse an employee's computer.

The final checks focus on review behavior. OpenAI warns that complex formatting, tables and charts may need manual adjustment and tells users to verify important facts, figures, citations and edits. PT-007 compares the fixture before and after a formatting task; PT-008 confirms that a human checked the known fact and retained a recoverable copy. PT-009 verifies the separate-history and memory boundary. PT-010 confirms that the support owner can follow the recorded evidence to the failed layer without asking the user to share credentials.

Every pilot status begins as Not started. A row can move to Pass only when it has an owner, observed result, timestamp and evidence reference. Fail or Blocked requires a blocker and next action. Not applicable requires a reason. This prevents a prefilled checklist from becoming evidence merely because its expected-result column looks complete.

Diagnose the symptom at the layer that owns it#

The table is a starting sequence rather than an exhaustive support tree. It directs each symptom toward the documented control most likely to explain it without treating every problem as a redeployment issue.

Expand access only after the evidence has owners#

The sign-off tab asks four people or functions to make distinct decisions: the Microsoft deployment owner, the ChatGPT workspace owner, the data/content owner and the support owner. One person may hold more than one role, but the decisions stay separate. The deployment owner confirms assignment and timing evidence. The workspace owner confirms Word and connected-app settings. The data owner confirms that the pilot material and source permissions were appropriate. The support owner confirms that failures can be triaged without collecting secrets.

An Expand decision should be unavailable while a required readiness gate is failed or blocked, a critical pilot test has not passed, or a high-severity issue remains unresolved. A team can choose Pilot only when basic operation works but evidence is not yet sufficient for a broader group. Hold keeps the current population unchanged. Rollback records a decision to remove or disable access and starts the documented observation window for that change.

The workbook also gives the rollout an expiry date. OpenAI's launch-era Word documentation and Microsoft Marketplace listing can change quickly, especially around the October 1 default. Record the source-review date and schedule a recheck after any relevant product, permission or manifest change. A rollout that passed last month is evidence about that version and configuration; it is not permanent proof that every control remains the same.

Used this way, the checklist does more than confirm that a ribbon button appeared. It creates a traceable path from tenant readiness to workspace selection, source permission, safe task testing and an owned rollout decision—the evidence a team needs before turning an individual success into organization-wide access.