Write a PRD

PRD: AI-Generated Meeting Summaries with Decisions and Action Items

Audience: Engineering and Design leads Status: Ready for build planning Owner: Product

1. Summary

Huddle records and transcribes meetings with speaker labels, and the attendee list comes from the calendar invite. Today, people write their own notes after calls, and those notes are often late, incomplete, or missing. This feature generates a summary after each meeting that lists the decisions made and assigns action items to attendees. Action items are emailed to their owners, with Sales' requirement for immediate delivery balanced against the accuracy limits described in Section 4.

2. Goals and Non-Goals

Goals - Produce a summary within 5 minutes of meeting end for 95% of meetings. - Every action item names an owner who was present in the meeting. - Every decision and action item links to the transcript moment that supports it. - Give Sales automatic, immediate delivery for high-confidence action items.

Non-Goals (v1) - Calendar write-back or task creation in external tools (Jira, Asana). Design for it, but do not build it. - Summaries for meetings without a transcript. - Sentiment, coaching, or participation analytics.

3. Definitions

• Attendee: A person present in the meeting, determined by the participant session log (the platform's record of who joined), not only by the calendar invite. The calendar invite is a hint, not proof of attendance.
• Identified participant: A participant tied to a Huddle account or a verified email address.
• Unidentified participant: A guest who joined by name only, with no verified identity.
• Action item: A task with an owner, a description, and optionally a due date, derived from transcript content.
• Decision: A statement that the group agreed on a course of action, with supporting transcript evidence.

4. Known Limits and Design Responses

5. Functional Requirements

FR-1: Roster resolution Build the attendee roster from the participant session log at meeting end. Merge in calendar invitees for context, but do not treat invitees who never joined as attendees. Each roster entry is tagged as identified or unidentified.

FR-2: Summary generation Produce a summary containing: - A 3–5 sentence overview. - A decisions list. Each decision has a one-sentence statement, a timestamp, and a transcript link. Decisions are not assigned to individuals unless the transcript clearly states who made them. - An action items list (FR-3).

FR-3: Action item extraction Each action item includes: description, owner (a roster member), due date if stated, timestamp, transcript link, and attribution confidence (high, medium, low).

FR-4: Hard constraint: no non-attendee owners (must-pass) Before any summary is stored or sent, a deterministic validator checks that every action item owner matches a roster entry from FR-1. If an owner does not match, the item is removed and logged as a pipeline error. This check does not depend on the model or on confidence scores. The model is never the final authority on membership.

FR-5: Unidentified owners If the model attributes an action to an unidentified participant, the item is kept, but the owner is shown as "Unidentified participant (Name as joined)." These items are never emailed. They appear in the organizer's review view only.

FR-6: Confidence gating for delivery Each action item is sent automatically only if all of the following are true: - Owner is an identified roster member. - Attribution confidence is high. - The supporting transcript segment has no overlapping speech flag. - The item's source is not a multi-person room device.

Items that fail any check go to the organizer's review queue. The organizer can confirm, reassign to another roster member, or dismiss. Confirmed items are then sent.

FR-7: Multi-person sources When an action item comes from a multi-person source, the owner field is set to "Confirm owner" and the item is held for review. The review UI lets the organizer or the item's likely owner claim it from the roster.

FR-8: Delivery - Auto-sent items go to the owner's email within 5 minutes of meeting end. - Emails contain: the meeting name, the action item, the due date if any, a link to the summary, and a link to the transcript moment. - Each meeting produces one email per owner, grouping that owner's items. - Emails go only to identified roster members. Admins can disable delivery to external email domains.

FR-9: Review queue Organizers see a summary page with held items, can edit or confirm them, and can see which items were auto-sent. Edits made after sending generate a correction email to the owner.

FR-10: Controls and privacy - Admins can turn summaries on or off per workspace and per meeting type. - Any participant can opt out of their own speech being summarized. Their items are excluded from the summary and their name is removed from the roster. - Summaries and transcripts follow the same retention and access rules as the source recording.

6. Sales Requirement: Immediate Auto-Send

Sales wants action items emailed as soon as the meeting ends. This PRD supports that for high-confidence items (FR-6, FR-8). It does not send low-confidence items immediately, because a wrong owner gets a task they didn't agree to, and an email that is later corrected erodes trust. Sales can see the auto-send rate in the admin dashboard. If the held rate is too high for their workflows, the threshold can be tuned with data from the pilot. It should not be lowered without evaluation.

7. Acceptance Criteria

• AC-1: Across a 300-meeting eval set, zero action items name an owner absent from the participant log. This is a hard gate for launch.
• AC-2: Every decision and action item has a working transcript link that lands within 10 seconds of the cited statement.
• AC-3: For a labeled eval set, owner precision on auto-sent items is at least 97%.
• AC-4: Summaries are generated within 5 minutes of meeting end for 95% of meetings with transcripts under 90 minutes.
• AC-5: An uninvited identified joiner appears in the roster and can receive items. An unidentified joiner never receives email.
• AC-6: Opt-out removes the participant's items and name from the output within one processing cycle.

8. Metrics

• Adoption: Percentage of eligible meetings with a summary delivered.
• Quality: Action items edited or reassigned by the organizer, by confidence band.
• Trust: Post-send corrections per 100 auto-sent items. Target: under 2.
• Usage: Percentage of owners who open the linked transcript from an email.

9. Open Questions

1. Should the review queue notify the organizer by email, Slack, or in-app only?
2. When an owner is an external email address, what is the policy under the admin domain setting?
3. How will we handle meetings where the transcript contains no clear owner for a decision or action?
4. Do we need a per-workspace setting to require organizer approval for all items?
5. Should multi-person room devices be fixed at the hardware or SDK level, which would change FR-7?

10. Phasing

• Phase 1 (pilot, 20 workspaces): FR-1 through FR-5, FR-8 through FR-10, with all items held for organizer review. This validates the constraint and attribution quality.
• Phase 2: Enable confidence gating (FR-6) and auto-send for Sales and other pilot workspaces, based on Phase 1 precision data.
• Phase 3: Multi-person source handling at scale (FR-7), and general availability.

PRD: AI-Generated Meeting Summaries and Action Items

Audience: Engineering and design leads Product: Huddle Status: Draft

1. Summary

Huddle will generate a post-meeting summary that highlights decisions and action items, identifies owners when it can do so reliably, and can email confirmed action items to their owners automatically. This replaces the manual note-taking people do after calls.

The core safety requirement is non-negotiable: an action must never be assigned to someone who did not attend the meeting. Calendar invitations alone cannot establish attendance: some invitees do not join, and around 15% of meetings include someone who was not invited. Speaker labels also cannot establish identity on their own; they are wrong about 8% of the time, especially during interruptions or when several people share a meeting-room connection.

The product must therefore separate three questions: what was decided, what needs to be done, and who—if anyone—can be safely identified as the owner. When attendance or ownership is uncertain, Huddle must leave the action unassigned rather than guess.

2. Problem and goals

Today, attendees write their own notes after meetings. This is inconsistent, takes time, and makes it easy for decisions and follow-ups to be lost.

Goals - Produce a concise, useful summary after a recorded meeting. - Clearly distinguish decisions from discussion, proposals, and unresolved questions. - Extract action items and assign them only to verified meeting attendees. - When enabled, email confirmed action items to their owners shortly after the meeting ends. - Let users correct mistakes and give feedback.

Non-goals for the first release - Replacing full meeting transcripts or recordings. - Creating tasks in external project-management tools. - Inferring deadlines, priorities, or owners that were not stated. - Automatically assigning work when the owner is unclear. - Resolving disagreements about whether a decision was made without review.

3. Users and primary workflow

Users: meeting attendees who need an accurate recap; organizers who want to review or share it; and action owners who need a clear follow-up.

1. A recorded meeting ends. Huddle gathers the transcript, speaker labels, calendar context, and actual session attendance data.
2. Huddle generates a summary with separate Decisions, Action items, and, where useful, Open questions sections.
3. For each action, Huddle identifies the supporting transcript evidence and checks the proposed owner against the verified attendee roster.
4. If automatic action-item email is enabled for the organization, Huddle emails only actions with a sufficiently clear owner whose attendance is verified.
5. The organizer and attendees can view the summary, correct it, and report errors. Unassigned actions remain visible for follow-up but are not emailed as assigned work.

4. Functional requirements

4.1 Establishing who attended

• Use Huddle’s meeting-session join/leave records as the attendance source of truth. The calendar invite is context, not proof that someone attended.
• Include identifiable people who joined without a calendar invitation. Exclude invitees who did not join.
• Represent an attendee using a verified Huddle account, authenticated guest identity, or another approved identity mechanism.
• If a meeting-room device represents several people and Huddle cannot reliably map speakers to individuals, do not treat the device name or a guessed speaker identity as a person. The organizer may confirm identities or owners in the summary UI.
• If reliable session attendance data is unavailable, fail closed: generate the summary, but do not assign or email action items.

4.2 Generating decisions and action items

• Generate a short overview and the three optional sections: Decisions, Action items, and Open questions.
• Include a decision only when the transcript supports an explicit agreement or choice. Label proposals or unresolved discussion as open questions, not decisions.
• Phrase each action as a concrete task. Include a due date only if one was explicitly stated; otherwise show no due date.
• Attach a brief transcript excerpt and timestamp to each decision and action so users can check the source.
• Do not invent missing details. If the task is clear but no owner is, show it as Owner not confirmed. If the task itself is ambiguous, flag it for review rather than present it as certain.

4.3 Assigning owners safely

• Every proposed owner must match a verified person in the actual attendee roster. Enforce this as a backend validation rule, not just a model instruction or UI check.
• A calendar invitee who did not join must never be assigned. A person who joined without an invite may be assigned if their identity and attendance are verified.
• Speaker labels may help identify who volunteered, but must not independently authorize an assignment. When overlap, room audio, or attribution uncertainty makes ownership unclear, leave the action unassigned.
• Users may assign or change an owner in the UI only to a verified attendee. Record the change and its actor in the audit log.
• Recheck the attendance invariant before saving an assignment and immediately before sending an email.

4.4 Automatic emails

• Provide an organization-level setting to enable automatic action-item emails. Once enabled, send an email after generation to each verified owner with at least one confirmed action.
• Do not send an assignment email for an unassigned action or to anyone not verified as having attended. Do not send the full transcript by default.
• Include the meeting title and date, the recipient’s confirmed actions, any explicitly stated due dates, a link to the Huddle summary, and a way to report an incorrect assignment.
• If the meeting has no verified owners, send no owner emails. The organizer may receive a link to the summary according to organization settings.
• Target delivery within five minutes of the meeting ending at the 95th percentile. If generation or identity checks fail, do not send speculative emails; show the organizer that the summary or email is delayed or needs review.
• Provide clear controls to turn automatic emails off. Email delivery status and failures must be visible to the organizer.

5. UX requirements

The summary should make confidence and uncertainty understandable without exposing raw model scores. Show an Owner confirmed state for verified assignments and Owner not confirmed when a person cannot be safely identified. Present source timestamps as links into the recording or transcript, subject to existing access permissions.

Organizers must be able to edit summary text, remove an incorrect item, or assign an unassigned item to a verified attendee. Edits must be saved with a clear indication of who made them. If an action email has already been sent, do not silently replace the original assignment: notify the organizer that the owner changed and offer a corrected email to the new verified owner. Never email the former owner again unless explicitly requested.

The UI should explain that the calendar list may include people who did not attend and that unidentified room participants require confirmation. Use clear empty states when there are no decisions or actions.

6. Data, privacy, and operational requirements

Use only meeting data already available to Huddle for recording, transcription, and attendance, subject to existing recording consent and organization policies. Apply existing access controls to summaries, transcript evidence, and recording links. Store generated summaries, edits, assignment records, email status, and relevant audit events under Huddle’s existing retention and deletion policies. Do not use action-item content to train models unless the organization’s existing data policy explicitly permits it.

Generation and email must be idempotent: retries must not create duplicate summary items or send duplicate emails. Log the evidence reference, proposed owner, roster-validation result, any human correction, and delivery outcome for troubleshooting and audit.

7. Acceptance criteria

The release is acceptable only if: 1. A calendar invitee who did not join is never assigned or emailed an action. 2. An identifiable, authenticated attendee who joined without an invite can be assigned when the transcript supports the assignment. 3. An unclear speaker in overlapping audio produces an unassigned action, not a guessed owner. 4. A shared-room connection with no reliable person mapping cannot result in an individual assignment without organizer confirmation. 5. Every emailed action has a verified attendee owner and a link to its supporting summary. 6. Email retries do not result in duplicate messages. 7. Users can correct an assignment, and the correction is restricted to verified attendees.

8. Success metrics and rollout

Track summary generation success, time to summary, owner-confirmation rate, action-item correction and removal rates, email delivery time, duplicate-email rate, and user feedback. The primary safety metric is the number of assignments or assignment emails to non-attendees; the target is zero. Also monitor missed or unassigned owners to understand the trade-off between safety and usefulness.

Roll out behind an organization-level feature flag. Start with internal meetings, then a small customer cohort. Review false assignments and user corrections before expanding. Do not broaden automatic-email availability until attendance validation, idempotency, and failure handling pass the acceptance criteria.

9. Dependency to resolve before implementation

Engineering must confirm that Huddle can provide reliable, person-level join/leave records, including authenticated guests and shared-room behavior. If that data is unavailable or insufficient for a meeting, the safe behavior is to generate the summary without assigning or emailing owners.

PRD: AI Meeting Summaries with Decisions and Action Items

Status: Draft for engineering and design leads Product: Huddle

1. Problem

Huddle records and transcribes meetings with speaker labels, but attendees still write their own notes afterward. Notes are late, inconsistent, or never written, so decisions get lost and action items have no clear owner. We will generate a summary after each meeting that lists decisions and proposes action items with owners.

2. Goals and non-goals

Goals - Produce a summary within 5 minutes of meeting end: decisions, action items (task, owner, due date if stated), and open questions. - Never assign an action item to someone who was not in the meeting (hard constraint, see §4). - Keep the host's review to under 60 seconds for a typical meeting.

Non-goals (v1) - Fully automatic emailing of action items to owners (see §3). - Cross-meeting task tracking or integrations with Jira, Asana, and similar tools. - Summaries for meetings without a transcript.

3. Decision on the Sales request

Sales asked for action items to be emailed automatically to owners the moment a meeting ends. We are not building that for v1. Instead, we will send the draft summary to the host at meeting end. The host can send it to owners with one click, and owners are emailed on send.

Reasons: - Speaker labels are wrong about 8% of the time. An automatic email would sometimes tell a real person they own a task they never agreed to. Because it goes out with no human check, the error becomes visible to a customer's colleagues. - Email is irreversible, so a wrong or non-attendee assignment cannot be quietly fixed afterward. - The underlying Sales need is that owners hear about their tasks quickly and nothing falls through the cracks. A host prompt at meeting end with one-click send meets that need at the cost of a few seconds.

Path to automation: Auto-send will be an opt-in, per-workspace setting, considered after launch once the gates in §9 are met. It would send only high-confidence, presence-verified items and leave everything else for host review. Engineering should build the send pipeline so that auto-send is later a policy change rather than a rebuild.

4. The hard constraint: who can own an action item

Rule: An action item's owner must be a participant who was actually in the meeting when the item was discussed. Anyone else is ineligible.

This rule cannot rely on the calendar invite, and it cannot rely on the model behaving well.

Attendance source. The eligible-owner roster is built from Huddle's session join/leave logs, not from the calendar invite. This handles both failure modes: - Invitees who never joined are not on the roster. - The roughly 15% of meetings with uninvited joiners include those people, matched to a user account when possible.

Presence at time of item. A person is eligible for an item only if they were in the session at the timestamp of the relevant utterance. Someone who left at minute 10 cannot own an item from minute 40.

Enforcement is structural, not prompt-based. 1. The extraction step receives the roster as a list of participant IDs and must return an owner ID from that list or `null`. 2. A deterministic validator runs after the model. It rejects any owner ID not on the roster or not present at the item's timestamp, and it converts that item to unassigned. 3. The UI and email layers accept only validated owner IDs. There is no free-text owner field on the model output path. 4. Names mentioned in the transcript who were not present ("have Dana look at it") produce an unassigned item. The text may keep the speaker's wording, but Dana gets no assignment and no email.

Shared rooms. A room device usually appears as one participant, so individuals in the room are not in the presence log. We cannot verify that a named person is in the room. Such items become unassigned by default, and the host can attest who was in the room during review (§6). That attestation counts as human-verified presence.

Uninvited joiners without an account (guests) can be eligible owners, shown by display name. They receive email only if the host supplies an address during review. We never guess addresses.

5. Handling speaker-label errors

The 8% label error rate is concentrated in crosstalk and shared rooms. Eligible-owner enforcement does not solve it, because a mislabel can still pick the wrong person who was present. Mitigations:

Confidence tiers (High/Medium/Low) are stored on each item, shown to the host in review, and used later to gate auto-send. Thresholds are set empirically during the evaluation in §9. The tiers themselves are a v1 requirement.

6. User experience

Host flow 1. The meeting ends and the host gets a notification: "Summary ready to review." 2. The review screen lists: - Decisions as short statements, each linked to the transcript moment. - Action items with the task, owner chip, due date if stated, and a confidence indicator. - Unassigned items grouped at the top of the actions list, so gaps are visible. 3. The host can edit text, reassign from a picker limited to eligible people, delete items, or add room attendees ("Who was in the room?"). Adding room attendees makes them eligible for items in the room segments. 4. Send emails each owner their own items plus the decisions. Unassigned items go to no one.

Design requirements - Every item has a "jump to source" link that plays the transcript segment. Reviewing should be verification, not re-listening. - The owner picker never offers non-attendees. If the host wants to assign to an absent person, show a separate option, "Send as a follow-up (not from the meeting)," which is a different item type with clearly different wording and no "you agreed to" language. Design to decide whether this ships in v1; the default is that it does not. - Low-confidence owners appear as suggestions ("Suggested: Sam") and never as assignments. - Email copy says "Action item from Meeting name, date", includes the source excerpt, and offers a "This isn't mine" link that notifies the host. This gives owners a correction path. - If the host does not review, send a reminder at 24 hours. Nothing is sent to owners without host action in v1.

7. Functional requirements

1. Roster service: builds the per-meeting roster with join/leave intervals from session logs and links to user accounts where possible.
2. Extraction: from the transcript and roster, produce decisions, action items, and unassigned items. Each action item has task text, owner ID or null, due date or null, source timestamps, and a confidence tier.
3. Validator: enforces §4 as code with unit tests, independent of the model, and logs every rejection.
4. Review UI: as described in §6, on web and desktop. Mobile is view-only for v1.
5. Delivery: per-owner emails on host send, with a record of who was emailed. Sends are idempotent, and edits after sending trigger an explicit "send update" action.
6. Audit log: stores for each item the model output, validator result, host edits, and send events.
7. Admin setting: workspace-level toggle for summaries, plus retention aligned with existing transcript retention.

8. Edge cases to specify and test

• Invitee never joined but is mentioned as owner.
• Uninvited joiner takes an action; the guest has no account.
• Person leaves and rejoins (multiple intervals).
• Two people share a first name; ownership must resolve by roster, and ambiguity means unassigned.
• Whole meeting in a shared room (all items default unassigned until the host attests).
• Multiple languages, or a transcript with large gaps.
• Nobody commits to anything: show "No action items detected" rather than inventing some.

9. Success metrics and launch gates

Launch gates (must all pass) - Zero non-attendee assignments across a labeled evaluation set of at least 500 meetings, deliberately oversampled for uninvited joiners, shared rooms, no-show invitees, and crosstalk. Any production occurrence afterward is a Sev-1 incident. - Among High-confidence items, wrong-attendee assignment rate of 3% or less (target, to be validated against the evaluation set; propose a stricter figure if data supports it). - Median summary delivery within 5 minutes of meeting end.

Post-launch metrics - Share of meetings where the host sends the summary within 1 hour. - Host edit rate per item, and owner "This isn't mine" rate. - Share of action items left unassigned. Some is healthy, but a high rate means the model is too timid.

Auto-send criteria (future): two consecutive months of High-tier precision above the agreed bar and no non-attendee incidents. Sales and Support are consulted before enabling.

10. Risks and open questions

• Sales disagreement. Sales may see the host step as friction. We should share §3 with them early and offer a pilot of auto-send with a few design-partner accounts after the gates are met.
• Hosts skipping review. If sending rates are low, the fix is better reminders and faster review, not removing the check.
• Presence data quality. Do our session logs reliably capture join/leave for all clients and dial-in users? Engineering to confirm in week 1.
• Guest privacy. Can we email or display guest names without consent, given customer policies? Legal to advise.
• Room attestation. Is host attestation adequate for the constraint, or should room participants confirm individually? Recommend host attestation for v1.
• Follow-up items for absent people. Ship in v1 or defer? Design and Product to decide.

11. Milestones

1. Weeks 1–2: roster service, presence data audit, evaluation set labeling begins.
2. Weeks 3–5: extraction, validator, confidence tiers, offline evaluation.
3. Weeks 4–7: review UI and email delivery, in parallel.
4. Weeks 8–9: internal dogfood, gate review.
5. Week 10: limited beta with design-partner customers, including Sales' accounts.