← Back to Blog

The Meeting Is Over. Who Takes the Next Step?

Separate suggestions, decisions and commitments. Confirm deliverables, owners and deadlines before handing meeting tasks to the systems your team uses.

OOMOL

A request for a Friday first draft in the meeting notes, with the owner and deadline on the adjacent task card still awaiting confirmation

AI-generated conceptual illustration, content is a hypothetical example.

Suppose that after a client meeting ends, the assistant organizes three action items: deliver the new proposal on Friday, Xiaolin is responsible for the quote, and schedule a demo next week. The minutes look clear, and each item seems to have a person and a date.

But back in the meeting record, what the client asked was “could we see a first version on Friday”; what Xiaolin said was “I’ll check with sales about the price”; and the demo has to wait until the client has the test data ready.

If these three items are written directly into the task system, the team acquires commitments it never made. By Friday, the client is waiting for the proposal, Xiaolin receives a reminder about the quote, and the demo invitation has already been sent. The uncertainty left in the meeting disappears during the organizing process.

Post-meeting handoff should preserve these distinctions. The assistant can extract to-dos, add context, and prepare them for writing, but each task should state: what has been determined, and what still needs to be decided by whom.

Separate suggestions, decisions, and commitments

“We could try another pricing model” is a suggestion. “This time we’ll use monthly pricing” is a decision. “I’ll send you the quote sheet on Thursday” contains a specific commitment. All three sentences relate to pricing, but they are handled differently afterward: a suggestion waits for someone to adopt it, a decision is already in effect, and a commitment creates an obligation the recipient can reasonably rely on.

When a meeting summary labels all three as “action items,” that distinction disappears. Lindy’s meeting minutes guide and Viktor’s same-day follow-up approach post-meeting work through meeting documentation and cross-app follow-up, respectively, but what was actually agreed still has to be judged separately.

Use evidence in the source material: whether someone adopted it, whether it was approved, whether it was said by the person making the commitment, and whether a time was specified. When such evidence cannot be found, treat it as a suggestion or as pending confirmation.

For the hypothetical meeting above, it could be organized like this:

What was said in the meetingWhat can currently be determinedWhat still needs confirmation
The client asked, “Could we see a first version on Friday?”The client hopes to see a first draft on FridayWhether the team accepts, and what the first draft includes
Xiaolin said, “I’ll check with sales about the price”Xiaolin has taken on the inquiry workWhen to report back, and who ultimately determines the quote
”Wait until the test data is ready before the demo”The demo has a prerequisiteWho confirms the data is ready, and how to schedule a time afterward

When organizing, preserve the relevant original wording and source location. If a transcript paragraph can be located, attach the paragraph; if the original material provides a timestamp, preserve the timestamp. When speaker identification is unclear, mark it for verification; do not guess a name based on what was said.

A to-do missing an owner can temporarily remain in the pending-confirmation area. Filling in every field in the table does not mean the handoff is more complete.

Assign only the work someone agreed to do

Xiaolin agreed to check on pricing, so “confirm the price with sales” can be assigned to Xiaolin. Assuming that Xiaolin is also responsible for setting the quote, approving discounts, or sending it to the client expands the original commitment.

Someone who raises a problem has not necessarily agreed to solve it. Job title, number of speaking turns, and historical division of labor can help identify whom to ask, but they should not be used directly as the basis for this assignment. If the team already has clear assignment rules, the assistant can propose assignments according to those rules and explain the basis.

Describe the deliverable precisely enough for its owner to know what to produce. “Follow up on the quote” leaves too much room for interpretation; “confirm with sales the prices for these two options and add the results to the quote draft” explains what needs to be done. Whether sending it to the client is included must be clarified separately.

Dates are the same. The expected time proposed by the client, the deadline accepted by the team, and the next time to check progress each have different meanings. If the meeting only says “as soon as possible,” keep it undetermined; the assistant can suggest a date for confirmation, but should not write the suggestion as an arrangement the meeting has already approved.

When asking for confirmation, ask only about the parts not yet decided

Sending the entire set of minutes to the owner and adding “please confirm” still leaves the other person to find all the questionable points themselves. A more useful handoff asks specific questions about each unresolved item.

For example, the assistant can first prepare a confirmation request like this. The content below is still a fictional example:

The client hopes to receive the first draft of the proposal on Friday, and no record was found in the meeting of the team accepting that date. The project owner needs to confirm whether to agree, and what this version needs to include.

Xiaolin has agreed to check pricing with sales, and the feedback time is undetermined. Xiaolin needs to confirm when to report back.

The demo needs to wait for the client to provide test data, so do not create a calendar invitation for now. Please confirm who will check whether the data is ready.

Send each question to the person who can answer it. Items already confirmed do not need to wait along with them; items still missing conditions remain as they are. In this way, one reply can resolve one clear gap.

Confirmation is valid only for the version of the task that was reviewed. After the owner agrees to “give the first draft on Friday,” if the deliverable is later expanded to “the complete proposal and quote,” that reply cannot cover the added scope. What needs to be reconfirmed is the part that changed; the rest remains valid.

Write tasks where the person taking them over actually works

Meeting notes retain the discussion and its evidence, the task system records responsibilities, and external emails communicate confirmed arrangements. The three link to one another, and each preserves the part of the information it needs.

A task suitable for handoff usually includes the deliverable, the owner, the confirmed deadline or prerequisite, and the relevant meeting record. The person taking it over should be able to follow the link to find the source of the agreement, and start without rereading the entire meeting.

Before writing, first check whether this matter already has a task. This week’s meeting may only add a date to last week’s item; creating another to-do with the same name will scatter progress across two places. The assistant should check existing tasks and their projects, propose updates, and when it cannot determine whether they are the same item, hand the candidate records to the owner for confirmation.

External emails should be organized separately. Discounts still being discussed internally and delivery dates not yet approved should not enter a client reply just because they appeared in the same set of minutes. The email draft should express only what has been allowed for external communication, while internal to-dos remain in the corresponding workspace.

After a task is created, its location and assignment can be reported. The owner field only indicates assignment, not that the other party already knows or has started; whether the other party takes it on is determined by the team’s agreed confirmation method.

Use OOMOL to connect meeting materials with the task system

In this round of handoff, the assistant needs to do two kinds of things: read from meeting records and existing tasks, and write to the task system and email. The reading part determines whether it can distinguish suggestions from commitments, and the writing part determines whether misjudgments will land directly on someone else.

OOMOL’s Connector SDK provides a path for calling connected app accounts. First connect the app that stores meeting records and the team’s task tool in Connections. Before connecting, check whether each app provides the needed read, query, create, and update operations. Meeting transcription is still provided by the original meeting tool; connecting an app does not mean OOMOL will record meetings or identify speakers.

Enable reading first so the assistant can prepare a handoff draft. Once it reliably distinguishes suggestions from commitments, enable write operations such as creating tasks and sending messages according to the access control guide, and confirm the target account, project, recipients, and final content.

App connections provide read and write capabilities. The distinction between suggestions and commitments, owner matching, confirmation records, and task association still need to be implemented by assistant instructions or business workflows, with specific rules configured according to the team’s actual practices.

Start with a handoff draft from one meeting

Choose a meeting that has already ended and whose original record can be checked, and limit the scope to this discussion and the corresponding project. Have an assistant already connected to the needed apps handle the following request:

Based on this meeting record, organize the confirmed decisions, tasks people explicitly accepted, and items pending confirmation. For each task, write the deliverable, owner, deadline or prerequisite, and attach the source; keep fields without a basis undetermined. Find existing related tasks in the specified project, and propose additions or updates separately. Give me the handoff draft first; do not create tasks or send messages. For places that need confirmation, write the specific questions and the people suitable to answer them.

When reviewing, check three things: whether the client’s wishes have been written as team commitments, whether the person asking the question has been assigned as the owner, and whether items whose conditions are not yet met have been scheduled in advance.

After confirmation, have the assistant write the corresponding items into the target system and return the actual task links and the items still awaiting a decision. The next person taking over can open the task and know what they agreed to, what they need to deliver, and which conditions have not yet been fulfilled.