Alright, gather 'round the virtual war room. This isn't about p99 latency or a cascading pod failure, but about a different kind of production risk: client trust. And the tool in question is Otter.ai.
I've been using Otter for over a year to transcribe our internal post-mortems and engineering syncs. For that, it's fantastic. It's like having a junior SRE taking notes so we can focus on the discussion. We ingest the transcripts into our wiki, pull out action items, and move on. The accuracy is *good enough* for us who share the same technical context.
But let me tell you a story about using it on a client call. We were in a tense negotiation with a major stakeholder about SLA penalties following a significant availability incident. My lead, thinking it would be helpful, had Otter running. We shared the transcript afterwards as a "courtesy." Big mistake.
The transcript had critical errors. A key phrase: **"We will *not* be applying the penalty clause for this event due to the extenuating circumstances of the AWS us-east-1 outage"** was transcribed as **"We will be applying the penalty clause..."** The omission of that one word "not" sent the client's legal team into a frenzy. It took three days of back-and-forth, escalated calls, and finally providing the actual recorded audio (which we only had because someone was also running a separate Zoom recording) to douse the fire.
Here’s the post-incident review breakdown, because metrics matter:
* **Accuracy Delta:** Internal jargon-filled tech chat: ~92% word accuracy. Client call with higher-stakes, nuanced language: ~78% accuracy (our estimate based on the error).
* **MTTR (Mean Time To Resolution) for the miscommunication:** 72 hours of senior engineer time diverted.
* **Blast Radius:** Legal, account management, and two principal engineers involved.
The pitfall is subtle. Internally, we all know the systems. If Otter writes "the HPA wasn't scaling the deploys," we mentally correct it to "deployments." A client doesn't have that context. The errors compound.
My workflow rule now is as rigid as a production deployment pipeline:
```yaml
transcription_policy:
internal_meetings:
tool: otter.ai
action: auto_share_to_notion
verification: low
client_facing_calls:
tool: manual_notes_primary
otter.ai:
enabled: false # Or if legally required, run but NEVER share raw output
post_call_process:
- engineer_cleans_transcript_against_recording
- key_points_validated_by_second
- share_only_summary_email
```
The liability isn't in Otter being a "bad" tool. It's in misapplying it. It's a fantastic assistant for internal, low-risk communication where speed > absolute precision. For client calls, where every word carries weight and nuance, treat its output like an unverified, uncorroborated monitoring alert from a single source. You would never page someone based on that alone. You wouldn't share it with stakeholders without triage.
Use it to augment your own note-taking, never replace it. The cost of a cleanup is far higher than the time saved.
-- sre_tales
-- sre_tales