Keep the meeting record when Teams blocks AI notetakers

Your notetaker bot is denied at the lobby, and the meeting still starts. The record is what slips. A small team needs a named owner, a checked policy, and a tested fallback before the next call.

The failure is rarely dramatic. Someone starts the discussion, the assistant never joins, and the team keeps talking. By the end, nobody knows who owns the follow-up. The fix is a ritual.

Teams will block outside notetakers, not every recap

Microsoft Teams will start denying outside AI notetaker bots automatically in August 2026. Roadmap entry 566201 in Microsoft 365 provides an August 2026 capability for Teams tenants to deny fingerprinted outside AI meeting assistants at the administrator level. The control is not a full ban. ExternalBotAccessMode, the Teams control for outside third-party bots, leaves Microsoft 365 Copilot and tenant-registered Entra ID applications, which live inside your own tenant, unaffected. That distinction matters because the team may still need a recap, just not from a participant that joins the call.

Otter, Fireflies, and Fathom are notetakers; Otter sends OtterPilot into meetings, Fireflies sends an assistant called Fred, and Fathom appears in the participant list as a visible bot. If the bot is denied, the transcript never starts. The ritual has to cover that gap.

Run a four-step capture ritual

• Name the owner of meeting capture. The step is complete when a single person, usually the ops lead, owns the record for every recurring meeting and can answer which tool is allowed in a given room. That person should also own the meeting invite, the note location, and the follow-up list.
• Check the bot policy before the next all-hands. Ask the administrator which scope applies, and confirm whether your notetaker is blocked. The policy is clear when the answer is written in the ops doc. The common mistake is assuming a recap means every bot is allowed.
• Enable Microsoft Copilot meeting recap, which is available only where Copilot licensing exists, operates from the organizer's side, and can be controlled by administrators. If the recap is unavailable, the owner should not promise it in the invite.
• Test the fallback before you need it. Granola, a desktop-capture tool, is not caught by the Teams bot block because it records computer audio locally without joining the call as a participant. The fallback is ready when a test call produces a saved transcript, and a human note-taker backup is named in the meeting invite. The fallback owner should know which laptop runs the capture, and who takes over if the laptop is closed.

Keep the ownership map in the ops doc

Administrators can apply the ExternalBotAccessMode policy to the whole tenant with the Global identity or limit it to particular groups through per-group Teams meeting policies. The organizer owns the recap. The named owner owns the fallback. That person checks the local-audio route, assigns a human note-taker when the recap is unavailable, and keeps the meeting record in the same place every time.

Run the test in a low-stakes call. Put the fallback in the meeting invite, not in a chat thread. When the bot is blocked, the team should not be deciding what to do while the discussion is already moving.

Post the record as an operating document

A transcript is raw material. The record is what the team uses to follow up: decisions, owners, open questions, and the next checkpoint. The owner should post the record where the team already works, and link it from the meeting invite. If the recap is unavailable, the human note-taker writes the same fields. If the local-audio capture works, the owner cleans it into the same format. The owner should date the record and name the next review after the call. The record is posted before that review.