TL;DR: A solo remote business should define service windows, decision authority, and handover rules before using an always-on assistant to support clients in different time zones. An assistant can collect information or prepare a draft while the owner is away; that does not establish a promise of continuous human support. The original agreement and fictional rehearsal below show how to separate receipt, review, and resolution. They are operational examples, not legal contract advice, product performance claims, or a recommendation about where to live.
The service promise travels with you
A nomadic consultant can move between locations while the client continues working from the same office. The consultant's local morning changes; the client's meeting may not. A calendar full of ambiguous times makes this relationship harder, especially if every new location requires an improvised explanation of when the owner will answer.
Consider a fictional one-person research and design business with clients in three regions. The owner delivers research notes, project drafts, and scheduled review calls. There is no emergency support product and no second employee. The business wants an assistant to organize incoming material while the owner sleeps, so the next working window begins with useful preparation.
The owner's first temptation is to advertise round-the-clock responsiveness. That phrase conceals several different promises. A system might receive a request immediately. It might acknowledge receipt. It might produce a draft. A human might review the draft later. The client might receive a completed decision later still. Calling all these states responsiveness prevents the client from knowing which one has occurred.
ChatGPT Dots are described as assistants that can make ongoing progress between conversations. Their default computer is in the cloud, while access to a local computer is optional. The launch documentation, checked October 1, 2026, provides the relevant product context. It does not establish that a particular solo business can meet a particular response deadline. OpenAI's Dot documentation.
The useful design question is therefore about the service, not the destination or the product's personality. What must the client know to plan their own work? What can the assistant do while the owner is unavailable? Which requests must wait for a person? Answering these questions can make a modest service promise more valuable than a broad promise nobody can explain.
A proposed service agreement, clause by clause
The following terms are illustrative operating language for the fictional business. They are not a jurisdiction-specific contract. Their purpose is to make the service understandable before the owner configures tools or asks clients to rely on them.
1. Publish one stable service clock
Proposed clause: “Our published review window is stated in UTC and shown in the project calendar. The calendar is the reference for scheduled review and delivery commitments. When travel changes our available window, we will agree the change before it affects a committed review.”
A stable service clock gives the client a reference that does not require tracking the owner's location. The owner can also display local equivalents for convenience. Avoid relying solely on an abbreviation that readers may interpret differently. A timestamp with a date and a clear offset is more useful than “tomorrow morning,” particularly when the sender and recipient are already on different calendar days.
The clock does not need to maximize overlap with every client. It needs to make overlap predictable. A solo operator can decide that one portion of the day serves one region and a different scheduled slot serves another. The agreement should state what is actually offered, rather than imply that the owner will repeatedly shift sleep to satisfy the latest message.
Changing location then becomes an internal scheduling problem unless a service commitment changes. If the owner can maintain the published window, the client does not need a travel narrative. If the window must change, the client needs the new practical arrangement in time to plan, not a last-minute explanation after a missed call.
2. Separate a received request from an accepted commitment
Proposed clause: “A receipt confirms that your request reached the project channel. A request becomes a delivery commitment when the owner confirms its scope and date. Automated preparation does not accept a new deadline or change the agreed scope.”
This distinction is especially important when an assistant can respond quickly. A friendly acknowledgment may sound like acceptance if it contains “we will handle this” or names a date the owner has not reviewed. The owner should design receipt language that is useful without inventing a commitment. The client needs to know what will happen next and when a person will inspect the request.
For example, the assistant can organize the supplied files and identify the requested decision. It can prepare a question about a missing detail. It should not silently convert “could we have this before our meeting?” into an accepted deadline. The business relationship deserves a clear answer from the person authorized to make it.
Clients benefit from this separation too. They can distinguish a request still awaiting scope review from one that is scheduled. Without that distinction, the client may make promises to colleagues based on an automated acknowledgment. A service agreement should reduce this uncertainty rather than transfer it downstream.
3. Name the assistant's permitted preparation
Proposed clause: “While the owner is unavailable, the assistant may organize project material, identify missing inputs, and prepare internal drafts within the current scope. External delivery, commercial changes, and new commitments require the owner's review unless a specific routine action has been agreed in advance.”
The exact permitted actions should follow the service. A research consultant may allow source collection and draft preparation. A designer may allow organizing feedback by page. Neither description should imply that the assistant has authority to resolve a disputed requirement merely because it can summarize the disagreement.
Be concrete about what remains internal. A draft placed in a client-visible shared folder may already be an external disclosure, even if its filename contains “draft.” The owner should decide where preparation occurs and how reviewed outputs are distinguished. Merely labeling a file does not establish that the intended audience will interpret it correctly.
OpenAI documents custom rules for actions and warns that a Dot can make mistakes, including in following rules. The service should therefore include review appropriate to the commitment rather than assume the tool's settings are a guarantee. OpenAI's controls documentation within the Dot guide.
4. Define what happens when information conflicts
Proposed clause: “If a new instruction conflicts with the agreed brief, preparation may continue only where the conflict does not affect it. The conflicting decision will be placed in the next review queue, with the current scope kept visible until a change is confirmed.”
A client's colleague may ask for a different emphasis while the named project owner expects the original deliverable. This need not be malicious or unusual. People make requests from different perspectives. The assistant's job is to preserve the disagreement in a form the owner can resolve, rather than merge incompatible instructions into a confident draft.
The review queue should say which choice is pending, who can resolve it, and what work depends on it. “Conflicting feedback detected” is too vague. “The project owner requested an executive summary; a new reviewer requested a technical appendix before the same deadline” gives the owner something actionable.
If some work remains clearly useful, allow it to continue. Source organization may not depend on the final format. A design's unaffected pages may still be prepared. The point is to avoid both unauthorized decisions and unnecessary paralysis. The service owner should determine these continuation rules for the particular workflow.
5. Explain absence without selling invisible coverage
Proposed clause: “During travel or planned absence, the project calendar shows whether preparation, review, and delivery are available. If human review is unavailable, no urgent resolution is promised. We will agree a backup reviewer separately when the project requires one.”
A solo operator has no automatic substitute. An assistant does not become a second qualified consultant simply because it remains accessible. A client whose work requires continuous expert decisions may need a different service arrangement or a real partner with agreed authority. Saying so early can preserve trust more effectively than pretending the gap will never matter.
Preparation can still make an absence less disruptive. The assistant may organize a backlog so the owner can review it efficiently on return. But the calendar should not display the same status for an active human review window and an unattended preparation period. Those states offer different value to the client.
Travel should be planned around existing commitments where possible. If a change is unavoidable, negotiate the affected commitment directly. The service design should support a conversation about practical options, not supply a technological excuse for missing an obligation.
A fictional day rehearsal: where the clauses meet reality
The timeline below is a planning exercise. Its times are illustrative and do not describe an actual business, client, or measured assistant performance. The owner has published a review window from 08:00 to 12:00 UTC for this project and has an already agreed review call at 10:00 UTC.
| UTC time | Event in the rehearsal | Service state |
|---|---|---|
| 01:20 | A client submits new source material | Received, awaiting review |
| 03:40 | Another stakeholder requests a revised emphasis | Conflict recorded, commitment unchanged |
| 07:50 | The assistant prepares an internal handover | Ready for owner inspection |
| 08:15 | The owner confirms the next action | Reviewed, scope clarified |
| 10:00 | The agreed call takes place | Human decision window |
| 12:00 | The owner ends the published review window | New decisions wait for the next window |
01:20 — receipt. The client sends two documents and asks whether they can be incorporated before the scheduled call. The assistant identifies the files and the question. The acknowledgment says the request will be reviewed during the published window. It does not guarantee inclusion or suggest that the owner is currently awake.
03:40 — a conflicting request. A second stakeholder asks for the report to emphasize a different audience. The assistant records the new request beside the existing brief. It can continue organizing the documents, but it does not rewrite the whole report under the assumption that the latest message has superseded the project's named owner.
07:50 — preparation for a person. The assistant's handover contains the submitted material, the changed audience request, and the decision required before the call. It also identifies which sections might need revision. The owner receives a short decision summary rather than a long unstructured history of every message.
08:15 — review. The owner checks the source material and asks the project owner to confirm the audience. Some new information can be included in the current report; the requested expansion would need separate scope. The owner explains the distinction to the client and confirms what will be discussed at the existing call.
10:00 — the scheduled conversation. The client can make an informed decision because receipt, preparation, and acceptance were not confused overnight. The owner does not need to pretend that the assistant already resolved the disagreement. The call can concentrate on the actual tradeoff rather than repairing a misleading promise.
12:00 — closing the window. The owner leaves a handover for the next preparation period: the confirmed scope, the remaining questions, and the next published review time. The assistant can work within those boundaries. A later request will enter the queue under the same arrangement rather than create a new expectation of instant human response.
A useful handover contains decisions rather than atmosphere
A handover should let the owner begin with the question that requires judgment. “The client is excited and several messages arrived” gives atmosphere but little direction. “The client supplied two documents and asked whether they fit the existing deliverable before tomorrow's review” identifies a task and its relationship to a commitment.
Include the evidence needed for that judgment. Link to the relevant files, identify the current brief, and distinguish the client's request from the assistant's interpretation. If the assistant proposes an option, label it as a proposal. The owner should not have to search a transcript to discover whether a statement came from the customer or the tool.
Preserve unresolved questions without amplifying them into emergencies. A missing preference about presentation style may wait. A request to share material with a new recipient may need authorization before any disclosure. The distinction follows the actual service and agreed rules. It should not depend on how insistently a message is worded.
Keep completed preparation visible too. If the assistant has organized source material, say where it is and what it contains. A handover that lists only concerns can hide useful progress and encourage the owner to redo work unnecessarily. A handover that lists only accomplishments can hide the decision that prevents delivery.
Finally, include the next expected action and its owner. “Waiting” is not sufficient. Waiting for whom, to decide what, under which current commitment? A solo business benefits from this clarity because the owner may return tired from travel and should not need to reconstruct the entire project from memory.
The client experience should explain the state in ordinary language
Clients do not need a tour of the assistant's architecture. They need to know whether their request arrived, whether the owner reviewed it, and whether a delivery date was accepted. The business can provide these distinctions without discussing internal prompts or implementation details in every interaction.
A receipt can be short: the material has arrived, it will be reviewed in the next window, and the current delivery remains unchanged. A clarification can be direct: the requested addition changes the scope, and the owner needs a decision before confirming a new date. These statements help the client plan.
Do not imitate a human presence that the business is not providing. If the client is speaking with an automated assistant, make that role understandable. The client should not have to infer from subtle wording that a friendly answer represents preparation rather than a qualified human decision.
Offer a clear route to the person responsible. This does not require immediate availability. It requires a reliable channel and a stated review arrangement. A client should know how to raise a substantive concern without experimenting with prompts to discover whether the assistant will behave differently.
When a mistake occurs, explain the service consequence and the correction. The client does not need a defensive story about how advanced the tool is. They need to know which commitment remains valid, what has changed, and what the owner will do next. A clear correction can preserve the relationship even when the preparation process was imperfect.
The business model must pay for the promise
A service window is a resource. If a client requires more overlap, faster decisions, or a backup reviewer, that requirement changes the work being sold. An assistant may reduce some preparation, but the owner should not assume it eliminates review time or the cost of keeping a commitment available.
Before broadening coverage, examine the actual workload. How much preparation is useful? How much does the owner revise? Which requests genuinely need decisions outside the existing window? The answers should come from the business's own observations. This article supplies no universal productivity estimate or pricing benchmark.
Keep the comparison honest. An assistant that produces many drafts may still increase the owner's inspection burden if the drafts do not reflect the current brief. A smaller amount of relevant preparation can be more valuable. The owner should evaluate saved effort alongside the time needed to verify and communicate the result.
A client who wants immediate expert resolution may be willing to pay for a staffed service. A client who needs dependable asynchronous research may prefer a predictable solo arrangement. These are different offers. The business can choose which one it can deliver instead of using broad AI language to blur the distinction.
The owner also needs recovery time. A service design that leaves every hour potentially interruptible can make travel feel like a permanent shift. Publish a realistic arrangement, inspect whether it works, and adjust the offer when it does not. An always-on assistant should support the business's boundaries, not quietly erase them.
Rehearse the travel day before the client lives it
Choose a planned travel period and walk through the service as if the owner cannot inspect messages for several hours. Do not create a live disruption merely to test the idea. Use a fictional request or a copy of an already resolved case, with private information removed, to inspect what would be visible and what would wait.
Ask whether the published calendar is clear on both sides of the trip. A flight can cross a date boundary, but the client's committed timestamp should remain unambiguous. Check whether automated language still says “today” or “tomorrow” in a way that might refer to the wrong local day. Use explicit dates for material commitments.
Inspect the preparation queue before departure. Retire old instructions that were limited to a previous phase. Record which decisions are complete and which remain open. The assistant should not carry yesterday's urgent request forward as a permanent priority merely because nobody marked its completion.
Make a return plan. The owner should know what to review first and which clients need a confirmed update. A travel day can create a backlog even when nothing fails. Treating review capacity as finite helps the owner communicate honestly about the sequence rather than promising simultaneous resolution of every accumulated request.
The rehearsal may reveal that the proposed service is too broad for one person. That is useful information. Narrow the promise, move a review window, or arrange real backup coverage. Better preparation cannot turn an impossible human schedule into a sustainable commitment.
The morning queue needs an order the owner can defend
A preparation queue can become crowded even when every task is authorized. The owner should decide how review order follows existing commitments. A promised delivery due in the next window may come before an exploratory request with no accepted date. A missing input that blocks several tasks may deserve early attention. The assistant can organize these relationships, but the owner should establish the priorities rather than accept whichever item arrives with the most urgent wording.
Consider another fictional variation: three clients send requests overnight, and all three ask for an immediate answer. The business has accepted only one relevant deadline. The owner should preserve that commitment and review the other requests without treating their requested dates as automatically binding. A fast acknowledgment can explain the queue while leaving room for a later scope decision. It should not offer three simultaneous guarantees that the owner cannot fulfill.
The queue can also include work that is ready for delivery and work that is merely ready for inspection. Keep those states distinct. A source summary with unresolved attribution may be useful preparation, yet still require revision before the client receives it. A completed routine formatting task may need only a quick check. If every item is marked ready, the owner must rediscover these differences each morning.
Periodically inspect what waits longest. A task may remain pending because it is low priority, but it may also lack a named decision maker or contain a question nobody understands. Long waiting time is a signal to investigate, not automatic proof that the assistant needs to work faster. A clearer question may resolve the delay more effectively than producing additional drafts.
Tell clients when a new request cannot fit the existing window. A specific alternative gives them a choice: retain the current scope, accept a later date, or arrange a separate service. This conversation protects the meaning of the published schedule. A queue is useful only if the business is willing to acknowledge its finite capacity.
A client agreement earns its value during a quiet night
The ideal overnight period is ordinary. Requests arrive, permitted preparation happens, unresolved decisions remain visible, and the owner returns to a manageable queue. The client does not have to know where the owner slept or how many background tasks ran. They can rely on the service state because it was explained in advance.
This arrangement is compatible with a mobile life, but it does not depend on mobility. A consultant working from the same desk every day faces the same distinction between tool availability and personal availability. Travel makes the distinction more obvious because time zones prevent an informal promise of constant proximity from remaining plausible.
The assistant's contribution is bounded progress. It can prepare work the owner would otherwise organize later, while the service agreement preserves the decisions that need a person. The client receives predictability, the owner retains a workable day, and neither party needs to confuse an acknowledgment with an accepted obligation.
A sustainable solo service therefore begins with an honest sentence: this is when you can expect review, this is what can happen before it, and this is who confirms the result. The technology can make that sentence easier to honor. It should not be used to make the sentence disappear.
Sources
- OpenAI: Getting started with your dot, ongoing work, computing environment, and controls checked October 1, 2026.
The service clauses, company, client requests, UTC schedule, and handover method are original operational examples. No legal interpretation, service-level guarantee, or measured product performance is asserted.