BLOG
To use ChatGPT consistently at work, put recurring context, necessary files, and delivery instructions into a project. Keep separate chats for different tasks, then review each result before sending it to a client. A project helps maintain continuity; the quality still depends on choosing reliable sources, defining the required output, and checking the final file.
When a project is more useful than a standalone chat
A project makes sense when several deliverables depend on the same customer, product, or source set. OpenAI’s Projects and chats documentation describes shared files, project instructions, connected sources, and related chats. A one-off question can remain a standalone conversation. The deciding factor is recurring context, not a need to place every prompt in a project.
For a small agency, one project might represent a client’s website redesign. Separate chats can cover site structure, content review, and the presentation. This keeps each outcome focused without repeating the entire brief. It also makes the reason for a decision easier to find later.
Avoid one project named “all clients” that mixes different businesses. An example, offer, or restriction from one brand can appear in another deliverable. Group work by context that can safely be shared. When access must be narrower, reflect that boundary in the project and the files you connect to it.
| Element | Include | Check |
|---|---|---|
| Project instructions | Audience, voice, scope, repeated quality rules | Still valid for current tasks |
| Sources | Current brief and authorized reference files | Version, origin, relevance |
| Task chat | Specific request and output format | One clear outcome |
| Final result | File or text for review and use | Content, links, structure, integrity |
Write a brief that makes decisions possible
Before uploading files, identify the audience and the problem the deliverable will solve. “Write a good page” leaves audience, channel, depth, and desired action undefined. For a service page, name the service, region served, common questions, intended next step, and claims that need proof.
A practical brief could say: “Prepare the structure for a page aimed at companies that need to connect forms with a CRM. Return sections, the purpose of each, and missing information. Preserve documented differentiators. Do not invent testimonials.” This creates review criteria and keeps missing facts from becoming permission to make them up.
OpenAI’s prompting guidance recommends describing the goal, context, output, and boundaries that matter. In a revision request, also say what must stay unchanged: URLs, names, commercial conditions, and approved passages. That lets the tool change the requested part without rewriting finished work.
Choose files for the question they can answer
Include only sources needed for the task. A folder full of old slide decks can create more conflicts than useful context. List the files, identify the current approved brief, and explain how each document should be used. A visual reference may guide composition without being an authoritative source for the service description.
OpenAI’s file guidance covers creating and reviewing documents, spreadsheets, presentations, PDFs, and HTML previews where available. The ability to generate a file does not remove the need to check what was read. If an answer depends on a table, ask for the relevant rows. If it depends on a commercial decision, ask where the supporting condition appears.
When one document replaces another, remove the older one from the working set or label it as historical. Use names such as “approved-brief” and “old-reference.” State which source wins if they disagree. A date in a filename helps people, but it does not by itself explain precedence to a person or tool reviewing the project.
Keep shared instructions separate from task requests
Project instructions should hold recurring rules: audience, tone, quality criteria, and boundaries. A chat should specify the task happening now. This avoids enormous permanent prompts that try to predict every situation and become difficult to maintain. Keep the stable rules short and give each deliverable its own brief.
For content work, a recurring instruction might require direct answers, links beside technical claims, and explicit identification of missing information. The task request then says whether you need a video outline, proposal, or content review. One project can support different formats without treating them as interchangeable.
When a rule changes, update the primary record and state the change when resuming a task. Do not rely on an old message buried in a chat. For a team, maintain a human-readable copy of the standard where reviewers can see why a result was accepted.
Separate creation from checking
Begin with a short diagnosis of the material: understood objective, available sources, and open decisions. Check it before requesting a long deliverable. Correcting a misunderstood audience early can save a full rewrite, but the diagnosis should clarify the task rather than become an endless planning exercise.
For production, request one verifiable outcome at a time. A website task might need a content structure; a report, a synthesis with references; a proposal, a scope and review points. Avoid combining creation, approval, and sending to a client in one vague instruction when those actions have different owners.
Review with concrete questions. Did the output preserve approved passages? Does each number have a source? Are fictional examples identified? Do links support the precise claims they accompany? Ask for discrepancies with locations and reasons, rather than a generic opinion that the result “looks good.”
A reusable starting prompt
Use this as a starting point, then replace the brackets with actual information: “Context: I work on [activity] for [audience]. Outcome: I need [file or content] for [use]. Sources: use [documents] in the priority order given. Preserve [approved elements]. Do not invent [missing facts]. If information is missing, name the gap. Deliver [structure] and check the result against [criteria].”
Make the final checks observable. “All links reach the correct destination” and “the proposal separates design, review, and implementation” are more useful than a list of adjectives such as professional or strategic. Explain what each quality word would mean in the finished artifact.
For a focused revision, add a boundary such as: “Change only the CRM integration section and keep the rest of the page.” If the tool notices a different issue, ask it to list that issue separately. This lets a reviewer compare before and after without losing approved material during a general rewrite.
Open the generated file and review it
A “file complete” message does not prove the deliverable is ready. Open the result in an appropriate viewer and check its format, tables, images, links, and characters. The official file guide specifically describes previewing and refining outputs. For professional work, this check is part of delivery.
If the result is HTML, inspect it where it will appear. A standalone page may look fine while duplicating a title that the website theme already generates. For a spreadsheet, inspect formulas and ranges; for slides, check text wraps and image crops. Each format needs its own review.
Record the approved version and destination. A local file, saved site draft, and public page are distinct states. A record prevents someone from confusing document creation with an external action such as sending, installing, or publishing.
Check access and customer data
Available features depend on account, environment, and permissions. Confirm the function in the interface before designing a process around it. This workflow concerns ChatGPT projects and files; an app subscription does not by itself establish API access or automatic access to client systems.
Choose data according to the task and your organization’s rules. If a fictional example is enough to review a page structure, do not upload a whole customer database. When real client files are needed, document who approved their use and who reviews the output.
Frequently asked questions
Do I need a project for every question?
No. Use one when work continues over time or shares sources and instructions. A self-contained question can stay in a standalone chat.
Does a project guarantee the correct source version?
No. Identify current sources, remove conflicts, and request references to the passages used. Organization reduces ambiguity but does not replace checking the response.
Can I treat the output as automatically approved?
No. Define observable checks and a reviewer for client deliverables. Creating a file and authorizing its release are separate steps.
Start with one recurring deliverable
Choose a task you already do regularly, organize its source files, and test the route from brief to reviewed final file. Adjust instructions based on actual errors. A small, understandable process is more useful than many projects whose sources and approvals no one maintains.
