Skip to content
Notifications
Clear all

Help: Otter's Slack bot is randomly posting private meeting notes.

1 Posts
1 Users
0 Reactions
1 Views
(@crm_hopper_2027)
Reputable Member
Joined: 2 months ago
Posts: 133
Topic starter   [#17942]

Well, here’s a new one to add to the ever-growing list of "features" that sound great in a sales demo and then turn into operational nightmares. I’ve been using Otter.ai for about eight months now, primarily to document sales pipeline reviews and customer discovery calls, with the transcriptions feeding into our CRM via a (fragile) Zapier chain. The Slack integration was supposed to be the killer app—automatic sharing of action items and notes with the relevant channel.

Except now, it’s decided to become our town crier for confidential information.

The Slack bot has, on three separate occasions in the last two weeks, posted the full, detailed transcript of private, internal strategy meetings into a public Slack channel. We’re talking about revenue projections, competitor weaknesses, and frank assessments of team performance—just sitting there in #general for the whole company to see. It’s not a simple case of me mis-assigning a channel. The bot seems to be operating on a random delay, sometimes posting notes from a meeting hours after it ended, and it’s picking channels with a logic that is utterly inscrutable.

Here’s what I’ve already tried and verified, because I don’t just complain—I document:

* The Otter meeting was correctly assigned to a private ‘Leadership’ folder in my Otter workspace.
* The Slack app connection was configured to only post to a single, specific private channel (#exec-ops). The permissions were double-checked.
* There is no overlapping automation (Zapier, Make) that could be causing a conflict.
* The meetings in question were not started from the Slack bot command (e.g., `/otter`). They were started from the Otter mobile app and the Chrome extension.

This feels like a profound data governance failure. The entire value proposition of a tool like this hinges on it being a secure repository. If the conduit between the repository and our comms platform is springing leaks at random, the tool is functionally useless for anything beyond transcribing podcast episodes.

Has anyone else experienced this specific form of digital treason? I’m particularly interested if:

* You found a pattern (e.g., it only happens with meetings over 60 minutes, or with a certain number of speakers).
* You discovered a hidden setting or cache issue that resolved it.
* You’ve given up and are now using a different transcription service that doesn’t have aspirations of being an office gossip.

I’m about 72 hours away from initiating another vendor evaluation cycle, and I’d prefer to not have to explain another data breach to our legal counsel in the meantime.



   
Quote