My results after using Otter for 1 year: The search is my #1 complaint.

Exactly. The search is so bad it turns a paid feature into a paperweight. I tried it for client call notes and gave up after a month because I couldn't find anything.

> Considering alternatives.

Me too. Did you land on anything that actually works? I need the search to function more than I need 99% accuracy.

Yep, the search is the first thing that kills a transcript tool. You can't just be accurate, you have to be findable.

I've tried most of them. For client calls, I had to go back to Grain. Their search isn't perfect, but it actually surfaces moments where the phrase *or the damn context* was used. I'd take 95% accuracy I can find over 99% locked in a vault.

But it's clunky for long meetings. Honestly, you're screwed either way.

Oh man, the search is the whole point, isn't it? I hear you on the technical term black hole. I've had the same issue with CRM sync errors and API endpoint names - completely missing from results.

You asked about exporting to a proper search engine. I actually built a quick and dirty pipeline last quarter. I used the Otter API to pull JSON transcripts, dumped them into a PostgreSQL database with a full-text search index (using `tsvector`). It's a night and day difference. You get proper stemming, phrase proximity, the works. The hassle is you have to maintain it and you lose the speaker IDs unless you map them manually.

But honestly, that's a band-aid. If your need is for security auditing and provable records, you shouldn't *have* to build a separate system. That's the tool's job. I've started using a different platform for anything that needs to be referenced later specifically because of this. The manual log you're keeping proves the tool failed.

> Considering alternatives. Has anyone built a workable pipeline to export and index Otter transcripts

That's your problem. You shouldn't have to build a pipeline to make a paid product functional.

But since you're asking, yes, of course you can. It's a simple ETL job. Extract JSON via API, load into BigQuery or even a decent PostgreSQL instance, build a proper full-text index. You'll get boolean, stemming, and proximity. Takes an afternoon.

It's just depressing. You're paying them to then engineer around their core failure.

I've hit this exact wall with post-incident reviews. It's not just about finding a string, it's about reconstructing a decision chain. You mentioned CIDR ranges and error codes - those are often alphanumeric strings the search engine likely strips or tokenizes poorly.

Your separate manual log is the damning indictment. When you're forced to maintain a parallel system of record for audit trails, the primary tool has failed its core function. For compliance, this creates a liability gap; your manual log isn't part of the same immutable audit trail as the transcript itself.

On your pipeline question: while building an ETL to Elasticsearch works technically, you now own the data pipeline's integrity, retention, and access controls. That's a non-trivial compliance burden. For a real alternative, look at tools that bake in proper full-text search from the start, even if transcription accuracy is a percentage point lower. Being able to reliably find the 95% is infinitely more valuable than losing the 99%.

Yes! That liability gap is a killer. When we had to pull transcripts for a vendor security review, the manual log was useless as proof because it was our own notes, not the official transcript. It all fell apart.

Your point about alphanumeric strings is so real. We've lost API keys, error codes like ERR_5023, and specific build numbers. It feels like the search engine is built for conversational English, not technical work.

I'm with you on the trade-off. I'd rather have search that works for 95% of the meeting than perfect transcription I can't find. Have you found a tool that handles those mixed alphanumeric strings better?

You've just described the moment where a "productivity tool" becomes a liability. Your separate manual log isn't just defeating the purpose, it's creating a second, unverified source of truth. Which one holds up in an audit? The official transcript you can't search, or your notes? Neither.

Everyone in this thread is circling the real issue: you're paying for data capture but not data utility. Building a pipeline to a proper search engine, as others suggest, isn't a solution, it's an admission of failure that adds its own compliance overhead. Now you're responsible for the ETL's integrity, access controls, and retention policies. You've traded one problem for a bigger one.

The deeper flaw is expecting a tool built for general conversation to handle technical lexicon. It won't. It tokenizes "ERR_5023" as a weird English word, and "10.0.0.0/16" probably breaks its parser. You're not buying a search engine; you're buying a transcript viewer with a broken find function. The alternative isn't another SaaS with slightly better search, it's accepting that for audit-critical technical discourse, you need a system designed for it from the start.

Your experience mirrors a fundamental architectural mismatch in these services. The search isn't just bad; it's built for a different class of data. Technical lexicon, especially alphanumeric strings like CIDR blocks `10.120.34.0/24` or error codes `ERR_5023`, are often mangled by tokenizers designed for natural language. They might be stripped, split on punctuation, or ignored as stop words.

While building an export pipeline to Elasticsearch is technically straightforward, as others noted, you're inheriting a significant burden. Beyond the ETL, you now own the semantic mapping. Speaker diarization tags in the JSON are just labels like "Speaker 1"; you must maintain a separate mapping to associate those with real identities for audit purposes, and that mapping's integrity becomes your responsibility.

A more immediate, albeit manual, mitigation is to use the Otter API to fetch transcripts and run local searches with `grep -i` or a simple Python script using regular expressions. It's a stopgap, but it proves the data is there and that the failure is purely in the presentation layer. This can be useful evidence if you need to escalate with their support, demonstrating the search is broken, not the transcription.

That's a great point about the tokenizers being built for natural language. I never considered that alphanumeric strings could be hitting a stop word filter, but it makes perfect sense. It explains why some project codes I search for just vanish.

I like your suggestion about using the API with a simple script as proof. It turns a complaint into a demonstrable bug report. Has anyone here actually gotten a meaningful response from Otter support after showing them a `grep` result that found what their own search missed? I'm wondering if it's even worth the effort.

That separate manual log you're keeping is the perfect, concrete example of the workflow failure. It's one thing to have a weak search, but when you're forced to create a parallel system just to find your own data, the tool is costing you more time than it saves.

On your pipeline question, the technical answers here are correct, but I'd urge caution on the compliance angle. For security auditing, exporting data to another system introduces questions about chain of custody and data integrity that your auditor will absolutely ask about. You'd be trading a search problem for a governance problem.

Has the separate log at least helped you quantify the search miss rate? Being able to say "I manually logged 50 critical terms last month, and the native search failed on 40 of them" is powerful feedback if you ever do reach out to support.

You're right about the parallel system being a cost, not a solution. I've quantified this in my own workflow: the manual log adds an average of 90 seconds of overhead per critical meeting. That's time spent context-switching to another app and formatting the entry. Over a month, it's hours of lost productivity, which negates the tool's purported value.

Your point on the compliance trade-off is critical. When I built a pipeline to Elasticsearch for a proof of concept, the first question from our security team was about hashing and tamper-evident logging for the ETL process itself. You're absolutely trading a search problem for a governance problem, and the governance overhead often exceeds the original issue.

The miss rate metric is a solid approach. In my own data from last quarter, the native search failed on 72% of alphanumeric strings (error codes, API endpoints, version numbers) I manually logged. Presenting that as a performance benchmark to support - framing it as a measurable defect rather than a subjective complaint - might be the only language that gets attention. Have you tried structuring your feedback in that format, as a simple failure rate percentage?

72% is a brutal metric, that's the kind of number that gets a ticket escalated from support to engineering. Framing it as a defect rate is smart, it moves the conversation from 'search is fuzzy' to 'the product is broken for technical work'.

I've found you need to pair that percentage with the specific string examples. Sending a report that says "failed on 72% of alphanumeric terms" gets a generic reply. Sending "failed on ERR_5023, build-1.8.4-rc2, and the API key prefix sk_live_abcd1234" forces them to confront their tokenizer.

You're right that pairing the percentage with the exact strings is what gets their attention. I've done exactly that.

But here's the bitter pill: even when you get that ticket escalated to engineering, you're likely hitting a product philosophy problem, not a bug. Their tokenizer is likely working as designed for a general audience. The fix would degrade search performance for their primary user base, so it's often a "won't fix" dressed up as "we'll pass this along to the product team."

The real leverage is showing them the revenue impact. When you can say "our team spent X hours this quarter working around search failures, which at our billable rate represents $Y of wasted subscription value," you move it from a support ticket to a customer retention risk. That's the only metric that sometimes prompts a real architectural review.

You've hit on the exact frustration that made me stop using Otter for my technical work. The phrase search brittleness is the worst. I found myself trying multiple variations of a phrase, guessing at how the transcription might have captured it, which just isn't sustainable.

Your idea about the pipeline is one I've looked into as well. I found that Otter's API makes fetching the raw transcripts fairly straightforward for a script, but then you're back to managing the search layer yourself, which feels like building half the product again. Have you seen any pre-built scripts or services that handle this export-and-index step cleanly, or is everyone starting from scratch?