Capture Action Items Without Inventing the Owner

TL;DR

• The failure mode is invention. An assistant assigns an owner and a date the conversation never specified, and the resulting task looks entirely legitimate.
• Classify before capturing. A suggestion, an intention and a commitment read almost identically in a transcript and mean very different things.
• A schema with an explicit unspecified value beats one that guesses, because a missing owner becomes visible instead of wrong.
• Relative dates such as early next week have to be stored with their reference point, or they silently decay into the wrong date.

"Let's get legal involved" is not a complete action item.

It does not identify who will contact legal, what legal needs to review or when the review is required. Turning it into "Jordan will complete legal review by Friday" creates three facts that were never established.

This is an expensive kind of neatness. The note looks organized, but somebody now owns a promise they did not make.

A better action-item process keeps the missing parts visible and gives the team a way to resolve them. The assistant should help document the conversation without upgrading every suggestion into a commitment.

Meeting-summary research supports checking for substantive errors rather than relying on fluent wording. Individual meeting-assistant reviews also describe corrections to ownership and other details. Those sources justify careful review; they do not provide a head-to-head accuracy ranking of commercial products. 1 2

Classify the statement before creating the task

There are several different things a person might be doing when they mention future work.

Making a commitment: "I will send the sample tomorrow." The action and owner are explicit, with a relative deadline to resolve.

Suggesting an action: "We should send a sample." The action is proposed. Ownership and acceptance may be missing.

Describing a dependency: "Procurement needs to approve the agreement before we can use production data." This is a condition. It does not establish who will manage procurement.

Asking a question: "Could someone show this to finance?" The request may become an action after someone accepts it.

Expressing an intention: "We would like to launch in January." That is a target or preference, not necessarily a launch commitment.

Put these in separate states. If the tool or downstream system only offers a completed task or an assigned task, resolve the ambiguity before writing to it.

Use a schema that exposes missing information

Capture the following fields for a sales action item:

Evidence should be real. Use exact quotations only when the actual wording is available. Do not create timestamps or links just to make the row look authoritative.

Keep the action narrow enough that someone can tell whether it happened. "Follow up" is usually too broad. "Send the fictional-data sample to the technical lead" is easier to assign, complete and verify.

Six ambiguous examples

These examples are fictional and illustrate an intended review process. They are not product-test results.

1. The missing owner

Someone should check the access requirements with IT.

Record the proposed action with the owner and deadline as not stated. The follow-up question is who will coordinate the check. Do not assign it to the person who happened to say the sentence.

2. The ambiguous pronoun

Jordan and Casey reviewed the proposal. They will send the revised version.

The word "they" may refer to both people, one person or another team in the conversation. Preserve the ambiguity unless the surrounding material resolves it. A correct document title paired with the wrong owner is still an incorrect task.

3. The conditional commitment

I can schedule the pilot once the security review is complete.

Record scheduling as conditional on the review. Do not mark the pilot as scheduled or infer a start date. Clarify whether the speaker has accepted responsibility for scheduling or is only describing a possible process.

4. The relative date

I will send it next Friday.

Keep the original wording and resolve the date with the meeting's date, locale and context. If "next Friday" could reasonably refer to two dates, ask. Do not let the software's preferred interpretation become an external promise without checking it.

5. The changed commitment

Earlier: I will send the full sample tomorrow.

Later: I need legal to review it first. I will confirm timing after that.

The later statement changes the commitment. The current action should reflect legal review and an unconfirmed delivery date. Retaining the original deadline as though nothing changed will create a false overdue task.

6. The rejected proposal

Seller: Let's arrange a pilot next week.

Buyer: We cannot start a pilot until the budget is approved.

Record the blocked proposal and budget dependency. Do not generate a confirmed pilot task from the seller's sentence while discarding the buyer's response.

Write the template around those failure cases

A useful prompt should state the behavior required for ambiguity, not merely request a table.

Extract sales meeting action items from the available conversation.

First classify each item:
- Confirmed commitment.
- Proposed action.
- Dependency or approval requirement.
- Unresolved question.

For confirmed commitments, produce:
Action | Owner | Due date | Dependency | Evidence | Review note

Rules:
- Assign an owner only when the conversation supports it.
- Use "Not stated" for absent owners or deadlines.
- Preserve relative-date wording if the exact date is uncertain.
- Keep conditions beside the action they limit.
- Do not convert a suggestion into an accepted commitment.
- Reflect an explicit change or withdrawal later in the conversation.
- Flag unresolved contradictions instead of silently choosing one.
- Do not create CRM tasks or send messages.
- Use quotations and meeting references only when available.

Put proposed actions and unresolved questions in separate sections.
Keep each action specific enough to verify when it is complete.

Magic Screen supports reusable meeting-note templates. Save this as a snapshot format for action items, attach it to the appropriate meeting and review the generated note. That avoids recreating the extraction instructions after every call. 3 4

The template makes the desired structure repeatable. It does not eliminate the need to confirm who accepted a commitment.

Handle dates as data, not decoration

A due date may include a date, a time, a time zone and a condition. Losing one part can change the meaning.

"Before our next review" depends on a meeting that may move. "By end of day" depends on whose day. "Within five business days of approval" depends on a starting event and a calendar convention.

Preserve the original terms when they matter. When creating a downstream reminder, store or document the interpretation your team used. If the source does not support a precise deadline, keep it unconfirmed rather than choosing one for convenience.

This is particularly important when several organizations are involved. The seller may control delivery of a document, while the buyer controls its internal review. Do not give the seller ownership of a customer approval simply because the seller is managing the opportunity.

Close the loop before the call ends

An assistant cannot recover an agreement that was never reached. Use the end of the conversation to make important responsibilities clear.

For example:

I will send the sample. Casey, will you be the person who circulates it to IT? What timing should we plan around for their feedback?

If Casey does not know, the note should reflect that. The useful outcome is an accurate next step, including an unresolved dependency when necessary.

For several actions, read them back in the sequence they need to happen. This catches situations where two people are waiting on each other or a proposed deadline precedes a required approval.

Review before creating tasks elsewhere

Creating a row in a note is different from assigning a task in a CRM or project system. Before writing downstream, confirm the destination, owner identity, date interpretation and duplicate behavior.

An owner name may match more than one user. A buyer may not exist as an assignable internal user. An account can have multiple opportunities. Those mappings require explicit rules.

Also decide what happens when a later meeting changes the commitment. Will the system propose an update, create a new task or leave the old one untouched? A second meeting should not silently produce a duplicate reminder that conflicts with the first.

Use the CRM-ready notes guide to define the handoff contract. Keep high-impact changes subject to a clear review process.

Make unresolved work visible to the right person

An action-item list should make coordination easier. That includes showing what is still unassigned.

A proposed action with no owner is useful information for the seller or meeting organizer. A task incorrectly assigned to a person creates confusion for everyone else. Favor an explicit unresolved state over invented completeness.

Start with the template, test the six ambiguous examples and inspect the results. Then apply the same review standard to approved customer meetings. The record should preserve the commitment the people made, with enough detail to carry it out and enough restraint to avoid making a new one for them.

Frequently asked questions

How do I stop AI inventing action item owners?

Use a schema with an explicit unspecified value. When the model must choose that rather than guess, a missing owner becomes visible instead of silently wrong.

What is the difference between a suggestion and a commitment in a meeting?

A suggestion proposes, an intention signals, and a commitment binds. All three read almost identically in a transcript, which is why classification has to happen before capture.

How should relative deadlines be recorded?

Store the phrase and its reference point, not just a calculated date. Early next week decays into the wrong date the moment it is resolved without context.

Sources

1. Kirstein, Ruas and Gipp / COLING. What's Wrong? Refining Meeting Summaries with LLM Feedback. January 2025. Checked September 10, 2026.
2. G2 / Fireflies reviewers. Fireflies reviews: pros and cons. Individual reviews; experiences and dates vary. Checked September 10, 2026.
3. Magic Screen. Notes and Templates Overview. Checked September 10, 2026.
4. Magic Screen. Creating Note Templates. Checked September 10, 2026.