Weekly notes often mix completed work, actions in progress, requests awaiting a response, and ideas for next week. Before asking an AI assistant for a report, give each item a status and a pointer to the record that supports it. The result should let a reader distinguish what happened from what still needs a decision.
This guide uses a fictional team preparing an event. The sample notes are invented for practice; the table is an expected report format, not a measured status of a real project.
Label the source notes before summarizing
Imagine three notes: “Event notice draft written and available in the shared document”; “Asked two venues about available times; replies pending”; and “Reviewing registration fields; the contact field needs a decision.” A request sent to a venue is evidence of outreach, not evidence that a venue is booked. A draft written is evidence of a draft, not of publication. Keep those verbs when the notes move into a report.
Use three status labels for this exercise: Completed, In progress, and Needs confirmation. If a note contains two stages, split it into two rows. A deadline or owner that does not appear in the source stays “to decide.” A report becomes more useful when these open fields remain visible.
Build the report around evidence and next action
| Work item | Status | Evidence to open | Next action |
|---|---|---|---|
| Event notice draft | Completed: draft stage | Shared draft and date | Ask content owner to review |
| Venue availability | In progress | Two inquiry records | Compare replies when received |
| Registration contact field | Needs confirmation | Current form proposal | Decide whether the field is needed |
“Completed: draft stage” is deliberate: it names what finished without implying that the notice is already public. In a real report, add the exact document name, check date, and an authorized link. Keep personal information out of example inputs; share only what the assistant needs to classify the work.
Ask for an evidence-aware first draft
Turn the weekly notes below into a report table with Work item, Status, Evidence, Next action, Owner, and Due date. Use only Completed, In progress, or Needs confirmation as the main status. Preserve the stage described in each note: distinguish a request from approval, and a draft from publication. Leave an owner or date as “to decide” when it is not supplied. Add at most three questions for me to answer before sharing. Do not add achievements or measurements absent from the notes.
Review the assistant's table against the original notes. A status label is useful only if its evidence points to the claimed stage. Check numbers and dates character by character. Open the linked record when a row says a draft or outreach exists, and verify that it is the intended item. Assign owner and due date in the team's normal decision process rather than treating a suggestion as an agreement.
Carry the report into next week
Keep the previous report as a reference, then add new observations instead of silently replacing old statuses. When a venue replies, record the reply date and the decision it enables. When a draft is approved for publication, add that new stage with its own evidence. This produces a short history of what changed rather than a report that looks the same every week.
Try it: Choose three shareable work notes and give each a status, evidence pointer, and next action. Compare the AI draft with the source notes before sharing. The diagram below shows how the three sample items land in different status lanes.
Read the Korean edition of this article.
Diagram: a fictional event team sorts a written draft, venue inquiries, and a contact-field decision into three evidence-based status lanes.
댓글