How do I capture a project request that arrives in scattered messages?
Quick answer
Collect the messages that relate to the request, then sort what they say into the goal, deliverables, audience, deadline, constraints, and open questions. Keep explicit instructions separate from your interpretation; mark missing or conflicting details instead of silently filling them in. Share a short working brief and ask the requester to confirm the few points that could change the work before you proceed.
The question, the details, the next step.
A project request has come in across chat messages and email. How can I pull it together without accidentally turning my guesses into instructions?
Make one working brief from the relevant messages, but keep a visible boundary between what the requester said and what you inferred. Start by collecting messages about this request in one place. Then extract the details that affect the work: the goal, requested output, intended audience, deadline, constraints, and who will review it.
For each detail, label it as “explicit,” “inferred,” “unclear,” or “conflicting.” Preserve important wording or note where it came from so you can check it later. The brief is a summary for confirmation, not proof that the requester approved every line. Leave gaps marked “not specified” rather than supplying plausible-sounding details.
What if the messages mention different deadlines or describe the deliverable in different ways?
Don’t choose between conflicting details on the requester’s behalf. Put both versions in the open-questions section and ask which one to use. For example: “I saw Tuesday mentioned in chat and Thursday in the email. Which is the target date?”
Be equally concrete about a deliverable: “Should I prepare a one-page summary, or a slide deck?” If the wording could mean either, list the alternatives rather than presenting your preferred reading as settled. You can still prepare the rest of the brief while those points are unresolved.
Can you show me a template that keeps facts and assumptions apart?
Use a compact template and fill gaps with labels, not invented details:
Working brief — [project name]
- Goal: [explicit request, or “needs confirmation”]
- Deliverable: [what to produce; note any ambiguity]
- Audience: [stated audience, or “not specified”]
- Deadline: [date/time and time zone if stated; otherwise “not specified”]
- Constraints: [format, length, tools, or other stated limits]
- Reviewer/approver: [name or role if stated; otherwise “not specified”]
- Explicit instructions: [brief points, with message/date references if useful]
- My interpretation: [your reading, clearly labeled]
- Open questions or conflicts: [what needs an answer]
Keep it short enough to scan. If a detail does not affect the work, it may not need to be in the first confirmation.
What would a confirmation note look like for a made-up example, and what should I do after they reply?
Here’s a hypothetical example; the project details are placeholders, not a real request:
“Hi [name] — I’ve pulled the messages about [project] into this working brief. My current understanding is that the goal is [goal], and the deliverable is [deliverable] for [audience]. I found [date A] in [message] and [date B] in [message], so I haven’t treated either as confirmed. Could you confirm the deadline and whether you want [format A] or [format B]? I’ve labeled [other point] as my interpretation, not an instruction. If the summary looks right apart from those questions, please confirm or correct it before I proceed.”
Ask only questions that matter to scope, timing, format, or approval; you don’t need confirmation on every harmless wording choice. When the requester replies, update the brief and mark the point confirmed. If the answer changes the goal, deliverable, or deadline, revise the brief and share the updated version when others or work already underway could be affected. Keep unanswered points visible rather than treating silence as agreement.
A practical checklist
Gather only the messages relevant to this project request.
Sort details into goal, deliverable, audience, deadline, constraints, and reviewer.
Label each point as explicit, inferred, unclear, or conflicting.
Leave missing details marked as not specified; do not fill them in as facts.
Ask focused questions about uncertainties that could change the work.
Update the brief when a confirmed answer changes its scope or timing.
A few more useful answers
Should I copy every message into the brief?
Usually not. Summarize the relevant instructions and keep a message reference or key wording for details that may need checking.
What if the requester does not answer my confirmation note?
Keep unresolved points marked as unconfirmed and avoid treating your interpretation as approval. If the work cannot sensibly proceed without an answer, state which decision is needed and what part of the work depends on it.
How do I tell an assumption from an instruction?
An instruction is stated in the messages; an assumption is your interpretation or a detail you supplied to make the request seem complete. Label interpretations plainly and invite correction rather than presenting them as settled.