Meeting knowledge base: turn conversations into reliable team memory

A meeting knowledge base contains more than recordings and summaries. It gives the team a reliable route from a later question to the meeting evidence, the reviewed outcome, the responsible person, and the work that followed. A product decision should be retrievable as a decision. A customer promise should remain connected to the account and source excerpt. An open question should not appear as settled knowledge.

Use separate record types for meetings, decisions, actions, commitments, objections, risks, and open questions. Keep the meeting date, stable provider ID, participants, subject, artifact version, timestamps, source access, and retention state with the raw record. Add owner, status, audience, effective date, and review condition to every promoted item.

Use the downloadable meeting knowledge base record model to assign the required fields, authority default, review owner, access rule, lifecycle trigger, retrieval behavior, and source evidence for each record type.

The distinction matters over time. A summary helps somebody catch up today. A maintained knowledge record helps the team understand what still applies three months later, why it was decided, and who can correct it.

People think aloud in meetings. They correct themselves, explore options, and make promises that depend on later approval. Indexing every sentence can improve recall while weakening authority. A search result may surface an early proposal as if it were the final decision.

Keep the transcript, recording reference, participant list, meeting ID, and timestamps as evidence. Create separate records for the parts the business will act on: a decision, an assigned action, a customer commitment, an objection, a risk, or a question that remains open.

Each promoted record should point back to the evidence. That gives a later reader enough context to challenge a summary without searching a ninety-minute call from the beginning.

Google Meet can publish events when meeting resources change. Its developer guidance explicitly describes listening for a transcript so the file can be parsed and logged into a CRM or database. Microsoft Graph provides a corresponding route to list Teams transcripts.

Treat the event as a pointer, not the payload. Fetch the current artifact under an approved identity, attach the meeting's stable ID, and record which version was processed. A webhook may arrive more than once or before every artifact is ready, so the handler must be repeatable and able to retry without duplicating records.

Calendar metadata helps establish subject and participants, but it is not enough to decide which client, project, or policy a discussion belongs to. Use explicit identifiers where possible and route ambiguous matches for review.

A decision record should state what was decided, who owns the decision, when it takes effect, and what earlier record it supersedes. An action needs an owner, due date, destination, and completion state. An objection belongs beside the decision it limits. An unresolved question must remain visibly open rather than being completed by a plausible model guess.

The separation changes retrieval. A later query for current pricing should prefer an approved decision or contract, while a query about why the team rejected an alternative may need the objection and transcript excerpt. One generic meeting summary cannot reliably serve both jobs.

Google documents that Meet transcript entries returned by the REST API are available for 30 days after the conference, while transcript files stored in the organizer's Drive follow Drive retention rules. It also notes that API entries may differ from a Docs transcript after the file is edited.

Choose the long-term evidence artifact deliberately. If the team corrects speaker names or transcription errors in the Drive document, the knowledge record should refer to the reviewed artifact version rather than an expiring API snapshot. If the raw transcript must be deleted under retention policy, decide whether the promoted record remains valid and what evidence it can still disclose.

Access also needs promotion rules. A leadership meeting should not become visible to the whole company merely because a general knowledge index processed it. Carry source access into the raw artifact and assign a separate approved audience to each promoted record.

Human review does not have to mean proofreading the transcript. Put review where interpretation changes an obligation. A manager can confirm the final decision, an account owner can approve a customer commitment, and an assignee can accept or correct an action. Low-impact topic tags may not need the same gate.

Show the candidate record beside the source excerpt and timestamp. A reviewer should be able to edit the record, reject it, merge it with an existing item, or mark the meeting as having produced no durable knowledge. That last outcome is legitimate.

Use a meeting where the decision changes near the end, one with two people who share a name, one with an external guest, one that is rescheduled, and one where no transcript is produced. Repeat a transcript event. Delete the source. Revoke a participant. Confirm that the workflow does not create duplicates, promote an abandoned proposal, or expose the wrong audience.

Measure the percentage of promoted records that owners accept without material correction, the time from meeting end to reviewed record, duplicate rate, unmatched subjects, stale open questions, and source-link failures. Do not use the count of generated summaries as proof that the knowledge base improved.

If the meeting result also belongs in a customer record, continue with the separate CRM and meeting-notes integration guide. The shared knowledge record and the CRM write may share evidence, but they have different owners and acceptance rules.