Resources / MeetInsight
DeveloperRoles
People in the room follow up and prepare. A processor publishes. IT governs access.
MeetInsight does not treat every seat as the same kind of user. Attendees should not have to run transcription. Processors should not rebuild a chatbot admin screen. Admins should not sit in every meeting.
A notetaker bot can join as secretary. A processor publishes when the insight is ready. The product is not built to auto-mail a raw AI dump to everyone on the calendar.
Three roles
| Role | Typical person | What they come for |
|---|---|---|
| User | Attendee, project member, manager | Open shared meetings, review insight and minutes, check the calendar, keep personal notes and reminders |
| Processor | Secretary, coordinator, meeting ops / PMO | Capture or claim recordings, correct speakers and wording, generate minutes, publish, keep saved knowledge |
| Admin | IT / platform owner | People, roles, access, usage policy, and logs |
How a meeting gets published
- Capture — upload a file, or a bot joins a calendar event you chose to record.
- Unprocessed work waits for a processor. They claim the meeting, set who may open it, and fix names and wording.
- Insight and minutes are generated and edited in the workspace.
- The processor publishes. Attendees can then be notified that the record is ready.
Access is per meeting: the people who should see this room, not a public dump of every recording. Processors can change that list after save. Exact access labels live in the product, not in a public policy spec.
Why the split exists
- Attendees get a clean package without operating the pipeline.
- Wrong names and the wrong audience are caught before anyone else sees the meeting.
- IT can govern cost and access without a seat in every call.
System view: How it works. Ask the record: Meeting AI Agent.