A client emails three changes, you answer two, and someone adds a new deadline at the bottom of the thread. By the time you start the work, the conversation has become your project plan. It is a difficult plan to follow.

This guide is for solo service providers who manage client projects in Gmail. Your result this week is one short working brief that separates agreed work from requests still waiting for an answer. Set aside about 15 minutes and choose one ordinary project. Keep the original messages beside the brief while you check it.

Why try this now

Google’s September 9 Workspace announcement describes a new way to turn an email thread into an editable Google Doc from Gmail. That makes this a useful moment to try a small email-to-brief workflow. The steps below are my suggested review method, not a promise of error-free output.

Google said the rollout began September 2 and could take up to 15 days. Its eligibility list includes Business Standard and Plus, Enterprise Standard and Plus, and Google AI Pro and Ultra; launch support is English. An ordinary free Gmail account is not listed. Check your own account before following the tool-specific steps. If the feature is missing, use the same brief structure manually; there is no need to buy a subscription for this exercise.

Choose one thread and define the job

Start with a small project whose messages you can read completely. Avoid a months-long conversation with several projects mixed together. For your first attempt, use invented details or material your business permits you to process with its AI tools.

Write the project name and the purpose of the brief before prompting. For example: “Autumn newsletter layout. Internal working brief for the designer.” This tells you what belongs in the output. A discussion about next year’s website redesign does not belong in this week’s newsletter plan.

Keep the result internal until you have checked it. A tidy document can make a tentative suggestion look settled, especially when the person reading it never saw the original conversation.

Check the context before asking

In Gmail, open Ask Gemini and inspect Add sources, then Gemini search settings. Review which search locations are enabled and turn off unrelated locations for this task. Adding a particular file prioritizes it; do not treat that alone as an exclusive boundary. Google also notes that administrator-enabled data and earlier conversation sources can affect context. Start a new conversation when excluding previously used material.

Use only the relevant thread and any specifically needed, current project document. After generation, inspect the Sources list if it is available, then open the actual material yourself. Google warns that source lists can contain errors, so a citation is a place to check, not proof that a sentence is right.

Ask for a brief that leaves questions open

Here is a prompt to adapt:

“Create a new Google Doc with an internal working brief for [project name], using this email thread and the project sources I explicitly identify. Include agreed deliverables, confirmed dates, dependencies, and open questions. Distinguish a request from an agreement. Do not invent owners or deadlines. For each important item, identify the message date and sender that support it; add a source link when available. If messages conflict, show both versions under Open questions. Do not send email, schedule anything, or change sharing. Keep the brief concise and provide the document link for my review.”

These instructions express the scope you want; they do not replace checking what the tool actually did. Google describes preview-and-confirm controls for external communication and calendar commitments. This exercise needs only a working document. Do not confirm an unexpected send or scheduling action.

If Gemini gives you an answer but no usable document, check whether a file was created before retrying. You can also paste the reviewed text into a new Doc yourself. The finish line is a checked brief you can find again.

Work through a small example

Imagine this fictional exchange for a freelance designer:

September 10, client: “Please make a two-page newsletter. I’ll send the final copy on September 16.”

September 11, designer: “I can deliver the first layout on September 18 if final copy arrives on September 16.”

September 14, client: “Could we add a one-page flyer too? And could I see the newsletter on September 17?”

The brief should keep the newsletter at two pages. It should preserve September 18 as the designer’s stated first-layout date, conditional on receiving the copy on September 16. The flyer and earlier date are requests with no recorded acceptance. They belong under Open questions.

An inaccurate brief might say: “Deliver newsletter and flyer on September 17.” Every part of that sentence sounds plausible, but the thread does not support the commitment. Correct the brief before using it to organize your work.

A useful open question is specific: “Can the designer accept the flyer and the requested September 17 newsletter date?” You can answer that business question yourself, then communicate your decision through your normal client process.

Review the promises first

Read the brief against the messages, starting with anything that changes your workload or a client’s expectations. Check each deliverable, date, owner, and condition. Open the message named beside the item. Does it actually support the wording?

Watch verbs closely. “Could we” should not become “we will.” “If the copy arrives” should survive the summary. If an owner was never assigned, write “owner to confirm.” Leave unresolved items visible instead of asking for a cleaner version that hides the uncertainty.

Then open the Doc from Drive, confirm its name and location, and inspect its sharing settings. Give it a clear title such as “Autumn newsletter working brief reviewed September 15.” Add your review date inside. The original thread remains the reference for what was said; update the brief when a decision changes.

You are finished when you can name the agreed work, see the conditions that affect it, and identify the next question you need to resolve. Try this on one thread this week. Keep the routine if it makes the project easier to start and easier to explain.

For other repeatable project tasks, the Project Leadership Prompt Pack has prompts for kickoffs, status updates, and risk tracking. The brief in this article works on its own.

Sources

Google Workspace Updates on cross app actions and availability

Google Workspace Blog on turning email threads into documents

Google Drive Help on Gemini sources and search settings