Why Generic Meeting Summaries Fail Different Readers

Why Generic Meeting Summaries Fail

Generic meeting summaries fail because compression is not the same as usefulness. A recap can accurately describe the conversation and still omit the decision, evidence, commitment, risk, or next context a particular reader needs.

The answer is not a separate reality for every attendee. It is one shared decision record with role-specific views built from it.

The buyer and seller leave with different work

Michael Daugherty uses a sales call to explain Quill's original product insight in Venture Step episode 108.

The buyer may need to explain the product internally, compare it with an existing process, gather missing evidence, and identify who can approve a purchase. The seller may need to record objections, decision makers, promised follow-up, timing, and a next step in the CRM.

Both people heard the same words. Their next decisions are different.

A generic recap usually splits the difference. It produces a polished narrative that is too broad for either person's actual job.

There are three records, not one

A strong recap system separates the conversation record, shared decision record, and personal next-context view.

flowchart TD
    A["Transcript and artifacts"] --> B["Shared facts and decisions"]
    B --> C["Buyer decision view"]
    B --> D["Seller follow-up view"]
    B --> E["Product evidence view"]
    B --> F["Executive risk view"]

Personalization happens after the shared layer. That prevents the seller's optimism and the buyer's caution from becoming two incompatible official records.

Fixed length is the wrong goal

Many recap systems optimize for a length or template. The output has an overview, discussion topics, and action items whether the meeting was a recruiting screen, product incident, sales call, coaching session, or one-on-one.

Research suggests that recap needs vary. A Microsoft study on summaries, highlights, and action items found value in both concise highlights and structured hierarchical minutes. The evaluation involved seven users, so it should be read as design evidence rather than a market-wide outcome claim.

Research on reader-focused meeting summarization makes the target reader part of the prompt and evaluation. Work on query-focused meeting summarization similarly treats the user's question as part of the task.

The useful length is earned by the decision. A three-hour workshop may need a short executive decision and a detailed implementation appendix. A fifteen-minute incident call may need a precise timeline, owners, and evidence rather than a flowing summary.

Put the next decision near the top

Readers usually open a recap to answer a question.

What changed? What do I owe? What must I decide? What risk remains? What should happen before the next meeting?

If the document begins with a long chronological retelling, the reader has to reconstruct the working state. That is exactly the post-meeting labor the system was meant to reduce.

An answer-first recap leads with the confirmed outcome and current state. Supporting evidence and narrative follow when they help the reader trust or act on it.

This does not mean every takeaway becomes a bullet list. Natural prose, a compact decision table, or a short owner-and-state section can carry the same information without turning the page into a machine-generated checklist.

Role is not enough

"Write this for a product manager" improves a prompt, but role alone cannot determine relevance.

The same product manager may attend a discovery call, roadmap review, incident response, hiring interview, and customer escalation. Meeting type changes the decision. Project stage changes the evidence. Authority changes the allowable action. The destination changes the required structure.

A useful recap combines the reader, meeting purpose, current decision, confirmed commitments, evidence, and canonical destination.

Quill's current documentation describes meeting-type-aware documents and cross-meeting context. Daugherty describes adding the user's job and recurring templates to that selection. Those inputs create a better starting point, but the reader must still review the result.

Personalization can manufacture certainty

The risk is not only omission. A personalized system can create a story the reader wants to hear.

A seller's recap might convert interest into purchase intent. A manager's recap might turn a tentative idea into an employee commitment. An executive view might remove dissent in the name of brevity. A product summary might interpret a customer workaround as a feature request.

The system should label direct statements, confirmed decisions, attributed opinions, and inferred implications differently. It should preserve uncertainty instead of smoothing it away.

If a participant disputes the shared record, the system needs a correction path. Personal views can change after the correction, but they should not silently rewrite the underlying transcript.

Action items need more than a verb

An action item is usable when the commitment is confirmed, the owner accepts it, the destination is known, the timing is clear enough, and the source remains available.

"Follow up with legal" may be a suggestion, not a commitment. "We should probably fix that" may be brainstorming. "Jordan can handle it" may come from someone who cannot assign Jordan's work.

That is why automatic task extraction should create candidates before canonical writes.

Read [[How to Turn Meetings Into Actions Without Losing Control]] for the full state model.

Design from the next use

Start a recurring recap by asking what the reader will do with it.

For a recruiting screen, the output may need the rubric, evidence, open questions, and a recommendation held for review. For a customer call, it may need the customer's stated problem, decision process, objections, commitments, and a proposed CRM update. For a product incident, it may need a timeline, confirmed impact, mitigation, owners, and unresolved risk. For a one-on-one, it may need private follow-up with a much narrower sharing boundary.

The structure follows the use, not the meeting platform.

Preserve portability

A summary becomes part of operating memory. The reader should be able to export it, link it to its source, and move it to the canonical system without losing the decision and provenance.

Daugherty compares this trust effect with Obsidian. Plain files and accessible exports reduce the fear that years of context will be trapped inside one vendor.

The local-first software model treats longevity and user control as core ideals. A recap product does not need to be fully local-first to respect those principles, but it should make the data reachable and interpretable.

A better recap contract

The recap should say what happened, what was decided, what remains uncertain, who committed to what, and which source supports the claim. It should then present the subset each reader needs for the next decision.

That contract is more demanding than summarization. It is also more useful.

Read [[Michael Daugherty on Building Quill Into an AI Chief of Staff]], [[What Is an AI Chief of Staff]], and [[What Local-First Means for an AI Meeting Assistant]] next.

AI assisted with research organization and drafting. Dalton Anderson remains responsible for the analysis and publication decision.