Your first dot: a setup and acceptance checklist

Write the work order first

Before opening setup, write a one-page work order. Identify the recurring problem, the intended user of the output, and the source that settles disagreements. Choose a task whose result a knowledgeable person can review quickly. A draft meeting preparation note is usually easier to assess than a broad instruction to manage client relationships. Narrow scope makes both the first result and the inevitable correction more informative.

For an illustrative first assignment, ask for a weekly internal project brief from an approved status document. Specify the headings: changes since the previous version, approaching decisions, missing information, and questions for the project owner. Require source links and dates. State that the dot should prepare the brief for review and should not post it to customers or change the project plan. This is a proposed workflow, not a claim about measured outcomes.

Confirm access in the intended account

Check current plan and workspace eligibility before assigning the workflow. The September 29 documentation describes a gradual rollout; an eligible plan does not ensure immediate availability. Create the dot from the desktop app or a desktop browser. Mobile use follows initial desktop setup and depends on the supporting app update. Enterprise administrators may need to enable the relevant capability for the intended member.

Use the account that will actually operate the workflow during acceptance testing. A founder's unrestricted account can hide a missing permission that later stops a team member. Write down the workspace, the responsible employee, and the business systems involved. Keep secrets out of the work order. Authentication belongs in the product's supported connection or private sign-in flow.

Connect only the required sources

During setup, app connections and local-computer access are distinct choices. Start with the sources required by the work order. Check which account each connection uses and which actions it permits. A successful connection can still point to the wrong folder, tenant, or organization. Have the dot identify the intended source by its visible name and show that it can retrieve the specific permitted material.

If local files are necessary, record the device requirement: the computer must be connected, online, and running the ChatGPT app. If the work can use approved cloud sources, avoid making a personal device an accidental scheduling dependency. Cloud website sessions are separate from your personal browser. Verify the actual session that will be used, especially when several business accounts look similar.

Run a small, observable assignment

Give the dot the work order and request a first draft. Keep the initial source set small enough that the reviewer knows what it contains. Examine factual statements against that material, inspect source links, and look for omissions. Ask whether the brief distinguishes a documented decision from a suggestion. A beautifully formatted result can still be incomplete or based on an obsolete document.

Correct the instruction at the level where the problem occurred. If the source was wrong, repair source selection. If the information was missing, define the exception behavior. If the writing was unclear, provide a concrete example of the desired output. Avoid adding a vague instruction such as “be more accurate” when the real cause is an unresolved conflict between two project records.

Exercise the exceptions

Repeat the assignment with an intentionally missing input in a safe test set. Check that the dot identifies the missing source and leaves the relevant conclusion open. Then provide two conflicting dates and require it to surface the conflict. Finally, give an instruction outside the approved scope and inspect whether the workflow asks for the right decision. Never use live customer messaging as a convenient test channel.

Practice stopping the workflow. Open Activity to inspect delegated tasks and Scheduled to inspect recurring work. Pausing the main dot, stopping a delegated task, and canceling a schedule are separate operations. Record the actual steps your owner should follow. A stopped task does not reverse a completed edit or recall an already delivered message, so prevention and recovery need separate plans.

Accept the responsibility deliberately

Use a short acceptance record after the trial. Keep a copy of the reviewed output, the source set, the instruction, and any failures. State whether the workflow is approved for another supervised run, needs correction, or should stop. A single successful example establishes a useful starting point, not general reliability across all future situations.

Only add another responsibility when someone can explain why the first one is acceptable. Keep the original checklist with the workflow so a new owner can repeat it after a connection, policy, or source changes.

• The output answers the work order and links to the correct sources.
• Missing or conflicting information is visible to the reviewer.
• The permitted actions match the connected account and business owner.
• The review destination and escalation contact are clear.
• Recurring timing, time zone, and end date are confirmed when a schedule is needed.
• The owner can inspect active tasks and stop future runs.