Write a PRD

PRD: AI Meeting Summaries and Action Items

Product: Huddle Audience: Engineering and Design leads Status: Proposed MVP Launch decision: Ship reviewed summaries first; defer immediate, unreviewed owner emails.

1. Problem and opportunity

Huddle serves 3,000 companies. Meetings are recorded and transcribed with speaker labels, but attendees currently write their own notes afterward. This creates duplicated effort, inconsistent records of decisions, and missed follow-through.

We will generate a concise meeting summary containing decisions and action items, with evidence linking each item to the recording.

Two known limitations shape the design:

• Speaker labels are wrong approximately 8% of the time, especially during overlapping speech and shared-room participation.
• Approximately 15% of meetings include someone absent from the calendar invite.

Therefore, neither speaker labels nor calendar invitations are sufficient evidence for assigning work.

Non-negotiable requirement: An action must never be assigned to someone who did not attend the meeting. When attendance or identity cannot be established, leave the action unassigned.

2. Goals and non-goals

Goals

• Reduce time spent producing post-meeting notes.
• Capture decisions accurately, distinguishing decisions from proposals.
• Extract actionable commitments with owners and deadlines when supported.
• Include verified, uninvited attendees without treating all invitees as attendees.
• Make every decision and action inspectable and correctable.
• Deliver owner notifications only after safe assignment and publication.

Non-goals for MVP

• Live summaries or action assignment during meetings.
• Assigning work to absent colleagues, even if requested during the meeting.
• Inferring deadlines or assigning owners based on job title.
• External task-system integrations.
• Automatically publishing unreviewed summaries.
• Resolving identity using voice biometrics.

3. Users and primary workflow

Reviewer: Meeting organizer, or an explicitly designated attendee. Reviews and publishes the summary.

Attendee: Reads the summary, follows evidence links, and reports corrections.

Action owner: Receives published actions assigned to them.

Workflow:

1. Meeting ends; Huddle completes transcript processing.
2. Huddle reconciles actual attendance and generates a private draft.
3. Reviewer checks decisions, unresolved ownership, and attendance exceptions.
4. Reviewer edits and publishes.
5. Huddle makes the summary available to authorized viewers and, where enabled, emails owners their approved actions.

If no eligible reviewer is available, the draft remains unpublished. A non-attending organizer may designate an attending reviewer but cannot resolve attendance exceptions themselves.

4. Attendance and identity requirements

Engineering must establish an attendance ledger separate from the calendar invite.

Each record contains:

• Meeting ID and stable person ID, where resolved.
• Join/leave intervals and participant-session IDs.
• Identity source: authenticated join, verified guest identity, or shared-room roster.
• Verification state and evidence.
• Reviewer confirmation details, where required.

Calendar invitees are suggestions for identity matching, not proof of attendance. A directory search result is also not attendance evidence.

Assignment eligibility

An owner must map to a unique person with verified attendance in that meeting:

• Authenticated individual join: Eligible when attendance telemetry records the person’s session.
• Guest join: Eligible only after identity is resolved and verified; a display name alone is insufficient.
• Shared meeting room: The room endpoint proves room participation, not individual presence. A participating reviewer must explicitly confirm each person physically present before they become eligible.
• Uninvited attendee: Eligible through the same verification rules; invitation status is irrelevant.
• Invited but absent person: Ineligible.

If telemetry is unavailable, identity is ambiguous, or attendance is disputed, block assignment. Keep the action unassigned with an explanation.

The owner picker must show only eligible attendees. Every write path—including generation, manual edits, APIs, and publication—must enforce eligibility server-side. Model confidence must never override this rule.

These controls cannot independently observe who is physically in a room. If trustworthy roster confirmation is unavailable, shared-room individuals remain ineligible rather than weakening the constraint.

5. Summary and extraction requirements

The draft has four sections:

1. Overview: Two to four sentences describing the meeting’s purpose and outcome.
2. Decisions: Clear statements of agreed outcomes.
3. Action items: Task, owner or “Unassigned,” deadline if explicit, and status.
4. Needs review: Uncertain decisions, ownership, identity, or attendance.

Each decision and action must include transcript-span references and recording timestamps. Preserve the original supporting text even when the reviewer edits the final wording.

Decisions

Capture explicit agreement or a clearly accepted conclusion. Do not convert brainstorming, recommendations, or unresolved debate into decisions. If discussion reverses an earlier decision, represent the final outcome and retain supporting evidence.

Actions

Extract a concrete deliverable or next step. Record a deadline only when explicitly stated; normalize relative dates using the meeting’s date and timezone.

Examples:

• “I’ll send the revised deck tomorrow.” → Task with a candidate owner, subject to attribution review.
• “Someone should update the deck.” → Unassigned action.
• “Ask Priya to update it,” when Priya was absent → Unassigned action; note that an absent person was mentioned.
• “We could revisit this next quarter.” → Not an action without a clear commitment.

Speaker labels provide evidence, not authority. Overlap, shared-room speech, ambiguous pronouns, and conflicting commitments must trigger ownership review. Candidate owners are draft suggestions, not assignments, until approved.

6. Review experience

The summary page opens in Draft state with a clear “Review before sharing” banner.

Design must provide:

• Editable decision and action cards.
• Evidence links opening the relevant transcript and recording segment.
• Visible distinction between verified attendance and uncertain attribution.
• “Unassigned” as a first-class owner option.
• A dedicated queue for identity and attendance exceptions.
• A publish preview showing recipients and notification settings.

For each assigned action, the reviewer must approve the owner. Bulk approval is permitted for straightforward items, but flagged attribution requires item-level review.

Attendance verification and ownership approval are separate controls: confirming that someone attended does not prove they accepted a task.

Publication is blocked if any assigned owner is ineligible. Unassigned actions and unresolved decision candidates do not block publication; uncertain decisions must be omitted from the final Decisions section or explicitly labeled unresolved.

7. Email policy and Sales request

Sales requests automatic emails immediately after each meeting. MVP will not send unreviewed action assignments. Given the known speaker errors, immediate delivery would spread incorrect ownership before correction.

Instead:

• Notify the reviewer when the draft is ready.
• Default owner emails to off; enable through workspace settings.
• When enabled, automatically email approved owners after publication.
• Send each owner only their actions, meeting title, deadlines, and an authorized summary link.
• Never email a calendar invitee solely because they were invited.
• Do not send to guests without a verified address and permitted access.

Email dispatch must recheck eligibility and publication version. Use idempotency keys to prevent duplicate sends. Published ownership changes generate a correction for the previous recipient and an updated notification for the new eligible owner.

Future immediate automation requires a separate launch decision and evidence that it preserves the attendance constraint.

8. Technical implementation

Use an asynchronous pipeline:

`Meeting ended → Transcript ready → Attendance reconciled → Draft generated → Reviewed → Published → Notifications`

Proposed records:

• `Summary`: meeting ID, transcript version, state, generated content, revision.
• `Decision`: text, evidence spans, review state.
• `Action`: task, proposed owner, approved owner, deadline, evidence, review state.
• `AttendanceRecord`: identity, evidence, verification state.
• `AuditEvent`: actor, change, timestamp, revision.

Generation returns schema-validated structured data. Treat transcript content as untrusted input: instructions spoken during a meeting must not alter system rules, access controls, or recipient selection.

Owner writes and publication run through a centralized eligibility validator. Notification jobs check the current revision before sending. Attendance corrections invalidate affected assignments and cancel queued notifications. Maintain an audit trail rather than silently rewriting history.

9. Reliability, privacy, and access

Target draft availability: within five minutes of transcript completion for 95% of supported meetings.

Generation failures must leave recordings and transcripts usable, show retry status, and send no owner emails.

Drafts are visible only to reviewers. Published summaries inherit meeting-content access rules; attendance alone does not grant access. Recording evidence links must enforce existing permissions. Apply workspace retention and deletion policies to summaries, attendance evidence, and generated artifacts.

10. Success metrics and acceptance

Proposed launch gates

• Zero assignments to ineligible attendees across automated invariant tests.
• Zero emails to ineligible owners in the pilot; any confirmed incident pauses rollout.
• At least 90% of published decisions require no substantive reviewer correction.
• Median review time below three minutes for meetings under one hour.
• At least 30% less self-reported note-taking time in the pilot.

Measure owner-correction rate separately from attendance violations: a wrong attending owner is still a quality failure.

Required acceptance cases

Test absent invitees, verified uninvited guests, shared rooms, overlapping speakers, duplicate names, failed identity resolution, missing telemetry, absent people named in requests, transcript reprocessing, attendance revoked before dispatch, and repeated notification retries.

In every uncertain-attendance case, expected behavior is an unassigned action and no owner email.

11. Rollout and dependencies

Start with internal meetings, then an opt-in pilot across varied company sizes and shared-room usage. Expand only after launch gates pass.

Before implementation, confirm availability of participant-session telemetry, guest identity verification, room-roster confirmation, reviewer permissions, and verified email addresses. If these dependencies are missing, ship summaries with unassigned actions for affected participants rather than substituting calendar membership as attendance proof.