AI in Practice
ChatGPT Pages: How to Bring AI Drafts Into Team Review
ChatGPT Pages gives teams a shared document for AI-assisted work. Here is a practical way to test it on one reviewable document, keep claims and decisions clear, and assess the handoff before expanding.
On this page
- What changes when the draft becomes a Page
- Choose a document with a clear finish line
- Separate evidence from the writing decision
- Give each reviewer a different job
- Use a small handoff structure inside the document
- Review the content before sharing access
- Don’t turn every document into a dashboard
- Measure the review burden you actually care about
- Start with one reviewable outcome
ChatGPT Pages gives a team somewhere to work on an AI-generated document together. For an agency owner or operations leader, the useful question is whether that shared document can make review clearer: who checks the facts, who resolves feedback, and who decides the work is ready to leave the building.
OpenAI introduced Pages on September 29, 2026, as documents for people and agents to collaborate on. The announcement lists writing, research, charts, images, and information visualization, with access on Pro, Business, and Enterprise. Those are announced capabilities, rather than results from a Rise Productive product test. OpenAI’s DevDay recap
My recommendation is to try Pages on one document with a recognizable review problem. A client brief, internal FAQ, or research summary is a better starting point than moving your entire document library. Give that document an owner, a source boundary, and an approval condition before inviting everyone to help.
The opportunity is practical. A team may be able to develop its draft closer to the conversation that produced it. Whether that actually reduces work depends on the quality of the handoff. A shared draft helps only if the team resolves the comments it collects.
What changes when the draft becomes a Page
OpenAI’s September 29 release notes describe several starting points: turn a conversation into a Page, use a template, or begin writing in Space. People can edit directly, ask ChatGPT for revisions, and leave comments; each collaborator uses their own ChatGPT. ChatGPT release notes
That creates a useful possibility for work that usually crosses several boundaries. Someone develops an initial idea in a chat. Someone else needs to inspect the draft. A subject expert adds qualifications. A project lead makes the final call. A shared document could keep those contributions attached to the thing being developed.
It’s tempting to evaluate this only as a writing feature. I would evaluate it as a review surface. Generating a paragraph is one operation. Getting a group to agree that the paragraph is accurate, useful, and approved is a different operation with different failure points.
Consider an internal service FAQ. An AI draft might explain the service clearly while leaving the cancellation terms vague. The account lead knows what clients have been promised. Operations knows what the team can deliver. The owner knows which exceptions require a decision. The document becomes valuable when it makes those differences visible and helps the group resolve them.
This also changes what a good initial prompt needs to accomplish. Ask for a draft that exposes missing information. Give the AI a defined reader and a limited source set. Tell it which claims require confirmation. That produces work a reviewer can inspect without having to reverse-engineer where every sentence came from.
Choose a document with a clear finish line
The first Pages pilot should have a specific audience and a small number of decision makers. That keeps the experiment understandable. If the team can’t explain who approves the existing document, changing its location won’t resolve the approval problem.
A useful candidate is an internal onboarding guide for one role. The reader needs to know what to do in their first week, where to find the required information, and whom to ask when an instruction is unclear. The owner can check whether the guide answers those questions. A colleague can inspect it from the new hire’s perspective.
A less useful first candidate is a company-wide knowledge hub with dozens of owners and years of conflicting material. There may be a good reason to improve that hub, but it mixes document quality, access rules, migration, ownership, and search into one test. When something goes wrong, you won’t know which change caused it.
Choose a document where feedback has been difficult to reconcile. Perhaps the project manager collects comments from a chat, an email, and a shared file. Perhaps different people review different copies. Perhaps the AI keeps reintroducing language that a subject expert removed. Those are observable problems you can track.
Write down the finish line before drafting. For an onboarding guide, it might be that the department lead confirms the process, a new colleague can locate the required resources, and the final approver accepts the wording. For a client brief, it might be that the requested work, exclusions, assumptions, and unanswered questions are explicit. You don’t need a complicated scoring model to recognize a finished document.
Separate evidence from the writing decision
An AI-assisted document needs a way to distinguish what the team knows from what the team is proposing. Otherwise, a well-written sentence can slide from possibility to commitment during editing.
Imagine a hypothetical agency preparing a campaign brief. Its materials include the client’s approved positioning, notes from a discovery call, and a rough proposal for a new landing page. Those inputs have different authority. Approved positioning may govern wording. Call notes may record a preference that still needs confirmation. The landing-page proposal may be an idea the client hasn’t accepted.
Before asking for a draft, describe those differences in ordinary language. Specify which material establishes a fact, which material records a request, and which material is a suggestion. Ask the AI to preserve unanswered questions rather than confidently complete the gaps.
Then review the consequential claims. A sentence about the client’s target audience needs support from the brief or a confirmed conversation. A proposed launch date needs a decision. A claim about expected results needs evidence, or it needs to be removed. The task is manageable when reviewers inspect the claims that affect decisions instead of treating every line as equally important.
Keep links near the statements they support. A source list at the bottom is useful, but it doesn’t tell the reviewer which source supports a specific promise. In an internal document, a short note such as “based on the approved brief” may help orient the reader, provided the linked material is actually accessible to them.
Finally, preserve the distinction when rewriting. A request to make the draft more confident should improve clarity without turning an unapproved idea into a fact. Clear uncertainty is useful information. Removing it may make the paragraph shorter while making the decision harder.
Give each reviewer a different job
Inviting several people to review everything often creates redundant comments and missed responsibilities. Each person assumes someone else checked the detail they don’t understand. The document receives plenty of attention without receiving the right attention.
For a small Pages pilot, assign review by decision. The subject expert checks factual accuracy and operating constraints. The intended reader checks comprehension. The project owner resolves conflicting feedback. The final approver decides whether the document can be used for its intended purpose.
These roles can belong to two people rather than four. The value comes from naming the job, not adding another meeting. An owner may handle the subject review and final approval while a colleague checks whether the instructions are usable.
A useful comment identifies the passage, the problem, and the required change. “This sounds wrong” tells the writer almost nothing. “This paragraph promises a Friday delivery, but the approved scope only commits to sending a draft that day” gives the team something it can fix and verify.
When two reviewers disagree, record the decision that resolves the conflict. If sales wants a stronger promise and operations needs a narrower commitment, the owner should choose wording that both teams can stand behind. Asking the AI to blend the comments can produce polished ambiguity. The conflict itself requires judgment.
A short decision note can prevent the next revision from reopening the same issue. In the hypothetical service FAQ, the owner might write: “Approved: Friday is the day we send a draft, not the day the service goes live. Keep that distinction in the client version.” A later AI revision can be checked against that sentence. If it changes the promise again, the reviewer has a specific reason to reject the wording. The note can be removed from the client-facing copy once the approved commitment is reflected accurately.
It’s also worth deciding how to use AI during review. A reviewer might ask for a simpler explanation or a summary of unresolved questions. That can help them understand the work. It should still be clear which changes they are proposing and which changes the owner has accepted. Shared editing doesn’t eliminate the need for an accountable final version.
Use a small handoff structure inside the document
The most useful document structure gives someone entering the project enough context to contribute without rereading the entire history. That structure can be simple: the purpose, the current draft, the outstanding decisions, and the approved result.
For a research summary, start with the question being answered and the source window. For a client brief, start with the requested outcome and the approved scope. For an internal guide, start with who should use it and when. Those details help both people and AI make revisions that fit the job.
Keep outstanding decisions separate from polished prose. If a campaign budget hasn’t been approved, put that question where the owner can see it. Don’t bury it inside a paragraph that looks finished. A clean draft can otherwise create the impression that the planning work is further along than it really is.
Then define what happens after approval. Will the document remain the working reference? Will someone transfer the approved copy to another system? Will it be shared with a client? Each destination may require a different final check. Internal approval of the argument doesn’t automatically approve public release or external access.
Here’s a hypothetical handoff note for a service FAQ: “Operations has checked the delivery steps. The account lead still needs to confirm the escalation wording. After that decision, the owner will approve the final version for the client portal.” It names the completed review, the remaining decision, and the intended use without pretending the document is finished.
This structure should earn its space. If a small draft has one reviewer and one decision, a short note may be enough. Avoid building an administrative layer that costs more attention than the document itself.
Review the content before sharing access
OpenAI documents view and edit permissions, workspace sharing controls, and the ability to revoke access. It also makes an important distinction: sharing a Page doesn’t share your private chats or Memory, but information written onto the Page is visible to its readers. The feature is rolling out gradually, so it may not yet appear in every eligible account. Space sharing, data, and controls
That distinction should shape the content check. A document can contain information that belongs to a different audience even when its settings are configured correctly. The team should read the actual Page before sharing it, particularly when an AI has helped assemble the draft from several contexts.
Consider a hypothetical client proposal that includes an internal discussion of delivery risk. The discussion may be useful for the team’s planning. The client-facing version may need a different explanation of the same constraint. Review which audience each passage serves before distributing the document.
Treat quoted or summarized source material with the same care. The fact that a paragraph came from somewhere else doesn’t establish that it belongs in this document. Review whether the information is relevant, accurate, and appropriate for the people who will receive it. OpenAI says a file uploaded into a Page follows that Page’s permissions, while a link to a separately stored file does not grant access to the file. A summary copied onto the Page is still visible there. For a handoff, check both the Page and the materials it points to.
For the pilot, choose material the team is already allowed to share with the intended reviewers. That keeps the experiment focused on document collaboration. Once the workflow is useful, the organization can decide which other document types fit its existing information rules.
If someone can’t access the Page, inspect the account and workspace conditions before assuming the feature is broken. The goal is to understand the actual collaboration boundary in your organization, rather than to infer universal behavior from one person’s account.
Don’t turn every document into a dashboard
Pages’ ability to include richer material raises a useful design question: what does the reader need to understand or decide? A chart, image, or interactive element should make that job easier.
A chart might help a reviewer compare categories in an actual dataset. A diagram might clarify a handoff between departments. A table might expose which commitments are approved and which remain open. Each element needs a reason to exist that you can explain without using the word “engagement.”
For a small service FAQ, plain text may be the best format. The reader wants an answer they can find quickly. Turning the FAQ into an elaborate dashboard could increase maintenance and make the document harder to scan. Use the richer format where it explains a relationship that prose alone makes difficult to see.
Keep essential answers in text even when a visual helps. If a diagram shows the approval sequence, describe that sequence beside it. If a chart shows a conclusion, explain the data and the limitation. The document should remain useful to a reader who can’t interpret the image or who is skimming a narrow screen.
Review visual claims as carefully as written claims. An arrow can imply that one step automatically triggers another. A highlighted result can imply a recommendation. A generated illustration should never stand in for a real product screenshot or evidence that a test happened.
During the pilot, limit visual complexity to what the document needs. You’re evaluating whether the team can create and approve better work together. The most elaborate Page isn’t automatically the most useful one.
Measure the review burden you actually care about
A Pages trial is easier to assess when you track the points where the existing process loses attention. The relevant outcome might be fewer conflicting versions, clearer unresolved questions, or a reviewer who can understand the draft without a separate explanation.
Record a small baseline from a comparable document. Note how the team collected feedback, how it resolved disagreements, and whether someone had to ask which copy was current. Then observe the same questions during the pilot. These are proposed evaluation steps, not claims about results Pages will produce.
For the hypothetical service FAQ, a useful review record might say: “Friday deadline disputed; approved scope checked; owner kept draft-only wording; portal copy approved.” That is more informative than counting the comment as one resolved item. It shows which evidence settled the disagreement and where the final wording went. If the next update repeats the dispute, the owner can inspect the handoff rather than assuming a faster first review solved it.
Review time can matter, but a faster review isn’t always better. A draft that receives quick approval because nobody checked its sources has a different outcome from one that is accurate and ready to use. Keep quality and speed separate so one doesn’t hide the other.
It may help to distinguish necessary revision from avoidable rework. Necessary revision improves the argument or resolves a real decision. Avoidable rework includes reconciling two copies, restoring a deleted qualification, or finding a source that should have been attached. The pilot should show which type of work changed.
Ask the reviewers what they needed to leave the document to find. If they still relied on a private chat, an inaccessible file, or a conversation with the owner, that tells you where the handoff remains incomplete. You may need better inputs or a different document structure rather than another feature.
Finally, assess the maintenance burden. A document that is easy to create but difficult to keep accurate can become a liability. Identify who will update it, what change should trigger a review, and how people will recognize an outdated instruction. A useful pilot ends with an operating decision, not just a successful first draft.
Start with one reviewable outcome
ChatGPT Pages is worth evaluating where AI drafting and human review currently feel disconnected. Its announced collaboration features give teams a new place to develop the work. The team still needs to decide what counts as evidence, who owns the document, and when the result is approved.
Choose one document this week. Write down its reader, its purpose, its source boundary, and its final approver. Draft it with missing information exposed, invite the people who can resolve those gaps, and inspect the finished result before using it elsewhere.
If the pilot makes those decisions easier to see, you have a reason to expand it. If it simply relocates the same unclear handoffs, keep the useful parts and fix the process before adding more documents. The best outcome is a team that can spend less attention reconstructing the draft and more attention deciding whether it is good enough to use.
Product documentation checked September 30, 2026. Availability and workspace controls may change during rollout.
Checked for this article
Sources
Keep going
Related notes.
AI in Practice
GPT-6.1 Sol Cost Accounting: Caches, Retries and Review
A dated guide to GPT-6.1 Sol request accounting: price cache writes and reads correctly, apply the long-context rule, and attach retries and review to accepted work.
Read the article
AI in Practice
GPT-6.1 Sol: When to Use It for Everyday Agent Work
Use GPT-6.1 Sol where a bounded everyday task passes your checks. This guide develops document and coding trials, escalation rules and a reversible adoption decision.
Read the article
AI in Practice
GPT-6 Astra Computer Use: When Is It Better Than an API?
GPT-6 Astra can use computer-use tools, but the model does not supply the environment or decide whether a user-interface route is better than an API. Use it when the interface is part of the work, then compare it with the narrowest reliable
Read the article