Turn messy notes into a project brief with AI

The problem hiding inside a polished brief

A page of messy notes can be surprisingly useful. It remembers that someone raised a concern, that a budget was tentative, and that a date depended on another team. A polished AI summary can lose all three distinctions. The sentences become easier to read while the project becomes harder to understand.

I would rather receive a brief with three clearly marked questions than one that sounds finished because an assistant filled the gaps. My approach is to separate sorting from writing. First I ask the model to tell me what the notes contain. Only after checking that inventory do I ask for a document somebody else could act on.

Consider a small agency preparing a client workshop. The project manager has a meeting transcript, a few Slack messages, and handwritten notes from a call. The client needs a proposal tomorrow. It is tempting to put everything into an assistant and request a professional brief. That is exactly when an unconfirmed delivery date can quietly become a promise.

The following workshop scenario is fictional. The prompts, example wording, and review process are practical exercises you can adapt in a general AI chat tool. No special integration is required if you can provide the relevant text. If your tool cannot read an attachment, paste a small excerpt and identify it explicitly instead of assuming that the file was processed.

Give the assistant a small, labeled source packet

Start by collecting only the material that affects the brief. A whole company chat history is unnecessary. A useful packet contains the current client request, the latest meeting notes, known constraints, and any correction that supersedes an earlier message. Label each item with its origin and date so the model can point back to it.

For our workshop, the source packet says that the client wants to train twelve account managers. A facilitator suggested a ninety-minute session. The client asked whether recordings would be available, but nobody answered. An operations message says Thursday is possible if the training room is free. The budget note says that the client has requested a quote, not that spending has been approved.

Keep those distinctions in the source. Do not help the model by rewriting Thursday is possible as Thursday workshop. Your cleanup should make the text readable, not resolve uncertainty. If two people use different names for the same project, add a small glossary. If the dates are ambiguous, write the actual calendar date next to each message.

I also remove material that has no job in the brief: unrelated jokes, signatures, old meeting invitations, and customer details the recipient does not need. A smaller source packet is easier for both a person and a model to audit. Preserve an untouched original alongside the working copy so you can check whether an apparent fact came from the source or your own preparation.

CLIENT, Sept 8: Train 12 account managers on discovery calls.
FACILITATOR, Sept 9: Suggest 90 minutes with role-play.
OPS, Sept 9: Thursday might work if room A is available.
CLIENT, Sept 10: Can we get a recording? Please send a quote.
PM, Sept 10: We have not confirmed the date, budget, or recording.

Sort facts, proposals, and unknowns before drafting

The first prompt should produce an inventory, not beautiful prose. Ask for confirmed facts, proposals, dependencies, contradictions, and unanswered questions. Require a short source reference for every item. This gives you something simple to approve and reduces the chance that a suggestion gets promoted into a requirement.

In the example, twelve account managers is a confirmed audience. Ninety minutes is a proposal. Room availability is a dependency. The recording is an unanswered request. The budget is unknown. These categories matter because they imply different next actions: write for twelve people, ask about duration, check the room, decide recording, and prepare pricing.

An assistant may still classify an item incorrectly. That is why this intermediate output is useful. Reviewing five categories is easier than finding one misleading sentence inside a finished page. Correct the inventory explicitly: duration remains proposed; do not move it into confirmed scope. Keep that correction in the conversation before drafting.

Do not use a confidence score as a substitute for evidence. A model saying it is ninety percent sure about Thursday tells you less than the original message saying might work. For this kind of task, direct wording and source references are more useful than numerical certainty. A missing answer should stay missing until a person with the relevant authority supplies it.

Read the labeled notes below as source material. First produce an inventory with five groups: confirmed facts, proposals, dependencies, conflicting statements, and unanswered questions. Cite the source label for each item. Do not turn possible dates into deadlines or suggestions into approved scope. Use 'not stated' for missing owners or budgets. Do not draft the brief yet.

[PASTE NOTES]

Decide who will use the brief

The same notes can support several useful documents. An internal delivery brief helps a team organize work. A client approval brief helps somebody agree to scope. A facilitator brief helps an instructor prepare exercises. Trying to serve all three readers equally often produces a long document with no clear decision.

For the workshop, I would make the first version a client approval brief. Its job is to confirm audience, intended outcome, proposed format, exclusions, and open decisions. It does not need a long account of how the agency brainstormed the session. The client needs to understand what they are approving and what is still being worked out.

Tell the assistant this explicitly. Include what the reader already knows, what decision you want, and the intended length. A one-page target can be useful here because it forces prioritization, but do not let a word limit remove a material condition. The brief should fit the reader's task before it fits a visual page.

Choose a tone through a short description instead of a pile of adjectives. Plain, collaborative, and specific gives more direction than professional, compelling, dynamic, persuasive, and engaging. If you have a previous brief that worked well, provide a short excerpt as a style reference and say that its dates, names, and project details must not be reused.

Write around the decision the client needs to make

Now request a draft based on the approved inventory. I prefer an opening that explains the project outcome in ordinary language. In this case, the workshop should help account managers ask better discovery questions and recognize when a follow-up question is needed. That is clearer than promising a transformative capability-building experience.

Follow the outcome with audience and scope. Name what will happen during the session and distinguish proposed elements from confirmed ones. Then state exclusions. If the agency is providing a workshop rather than a full sales process redesign, say so. A useful exclusion prevents disappointment later; it is not an apology for offering less.

Put unresolved decisions near the end under a heading that asks for action. The client should see that date, recording, and budget approval need confirmation. Avoid burying these in parentheses scattered across the document. An attractive paragraph that ends with subject to confirmation may be too easy for a hurried reader to overlook.

Microsoft's prompting guidance identifies goal, context, source, and expectations as useful ingredients. This drafting request applies that broad advice to a specific editorial task. The official framework supports the structure of the request; the workshop process and sample brief here are our own illustrative approach.

Write a client approval brief from the corrected inventory. Audience: the sales director who requested the workshop. Start with the practical outcome, then audience, proposed scope, exclusions, and decisions needed. Keep confirmed facts separate from proposed details. Use plain English. Do not add benefits, timelines, prices, or commitments absent from the inventory. End with three answerable questions for approval.

Sources: Microsoft: the ingredients of a Copilot prompt

What the first usable brief looks like

A useful draft might open like this: We propose a practical discovery-call workshop for your twelve account managers. The session will focus on asking follow-up questions and identifying what a customer needs to clarify before a proposal is prepared. A ninety-minute session with role-play is proposed for discussion.

The next paragraph should make the boundary visible: The workshop covers practice and feedback during the session. It does not include a redesign of the team's sales process or ongoing call coaching. That exclusion is an editorial suggestion for this fictional project, so the project manager must confirm it before sending. The model should not present it as something the client already agreed.

The closing could read: Please confirm whether a ninety-minute format suits the team, whether a recording is required, and who should approve the quote. Thursday remains provisional while room availability is checked. Notice that the recording question has not become a deliverable and Thursday has not become a booked date.

This is the kind of output I want from AI: easier to read, but no more certain than the underlying information. The project manager can now finish the brief by supplying real decisions. If a generated draft includes a price or promises that the recording will be shared within twenty-four hours, remove it and investigate why that detail appeared before continuing.

Read every sentence as a possible commitment

Before sending the document, scan for verbs that create obligations: will, deliver, include, provide, complete, approve, and guarantee. They are not forbidden words. They are useful signals that a sentence deserves a source check. An assistant can unintentionally strengthen language while trying to make a draft sound more decisive.

For each commitment, ask who agreed to it and where it appears in the source. If the answer is nobody, decide whether to remove the sentence, label it as proposed, or obtain approval. The model can help locate candidate commitments, but a person must determine whether the agency can honor them. This distinction is especially important in client-facing work.

Also check what disappeared. A brief can be misleading by omission even when every remaining sentence is true. The missing room dependency may matter more than an awkward phrase. Compare the unresolved-question list with the final draft and confirm that every material unknown appears somewhere a reader will notice.

Finally, inspect pronouns and ownership. We will review the materials may mean the agency, the client, or both. Replace vague ownership with a named role where the source supports it. When nobody has accepted ownership, write owner to confirm. A brief should help a team find the next decision, not manufacture an organizational chart.

Audit this brief against the source inventory. List every sentence that creates a commitment, the supporting source, and whether the wording is stronger than the source. Then list material unknowns or dependencies omitted from the brief. Do not rewrite yet; show the discrepancies first.

Handle corrections without rebuilding the whole document

Projects change while you are drafting. Suppose the client confirms Friday, declines recording, and asks for two shorter sessions. Add that as a dated update rather than quietly editing the original note. Ask the assistant to identify which parts of the brief the update affects before rewriting them.

The change reaches beyond the date line. Two sessions may alter the agenda, facilitator preparation, room booking, and quote. A useful model response points out those dependencies without inventing their cost. The update is confirmed input; its operational consequences are questions to check with the delivery team.

Keep a short decision log outside the prose. In a small project, three columns are enough: decision, source, and effective date. The log makes later revisions less dependent on remembering a long chat. It also helps someone else take over the project without replaying the entire drafting process.

When the client approves the brief, save that version separately. Continue drafting in a working copy and make future changes visible. AI can help compare versions, but it cannot tell you which approval process your organization uses unless you provide it. Treat the approved brief as a record, not as an endlessly editable chat answer.

Save the method without making every brief sound identical

A reusable prompt should preserve the questions that protect meaning, not force identical prose onto every project. Keep the source-inventory step, the reader definition, and the commitment review. Let the headings change when the task changes. An event brief may need logistics first; an internal research project may need the decision question and evidence standard first.

Save one strong example with annotations explaining why it worked. Note that the recording stayed unresolved, the date remained provisional, and the audience was concrete. Those annotations teach a colleague more than a template with seven empty headings. They describe judgment, not merely formatting.

Keep your style reference short. A full previous brief can tempt an assistant to reuse project facts or structure even when they do not fit. Two representative paragraphs and a list of preferences are usually easier to inspect. State that examples demonstrate writing style and are not sources for the current project.

Measure the method by the quality of the handoff. Can the recipient explain the intended outcome, name the next decision, and identify what has not been promised? If yes, the brief has done its job. A more impressive vocabulary does not improve that test. Clear boundaries and useful questions do.

Try it on one small project today

Choose a project where you already understand the source material. A familiar task lets you catch mistakes quickly and learn what the assistant tends to smooth over. Avoid starting with a huge, unfamiliar packet simply because the tool accepts large files. File capacity and review capacity are different things.

Spend the first few minutes labeling the notes and writing the recipient's decision in one sentence. Run the inventory prompt, correct the classifications, and then request the brief. The effort you invest before drafting should reduce backtracking afterward. If it does not, inspect which step is taking the time and simplify it.

Use the final review as a learning loop. Record one omission, one invented detail, and one useful editorial improvement if they occurred. Add a targeted instruction for the first two to your saved prompt. Keep the third as an example of what good looks like. Over several projects, your brief-writing process becomes more specific to the way your team works.

The finished artifact should include a readable brief, the labeled source packet, and the decisions still waiting for confirmation. Those three pieces make the work transferable. Tomorrow, when someone asks why Friday was chosen or whether recordings were included, you can answer from a record instead of asking the assistant to reconstruct what happened.

You do not need to automate the whole process to benefit from it. Even using AI only to separate confirmed information from open questions can make a rushed handoff more useful. Start there if you are short on time, and add drafting once the source inventory feels dependable.