Otto Routes
An AI-powered email routing SaaS that solves the noreply paradox. Otto automatically classifys and routes emails from shared business inboxes to the right teams, with a custom machine learning layer that gets smarter over time.
Most B2B companies arrive at one of two solutions to their shared inbox problem, and both of them are wrong. The first is assigning someone to manage it manually: one person triaging a generic address, forwarding things to the right team, dropping the ball when they're busy or out. The second is sending from a noreply address and cutting off the channel entirely, sidestepping the routing problem by making sure nobody can reply in the first place.
The noreply approach is more common than it should be, because it's easy. But it means that every campaign reply, every "I'm interested" buried in a bounce address, every customer who hits reply out of habit goes nowhere. Companies spend significant resources building outbound communication systems, then actively suppress the signal that comes back.
Working in lifecycle marketing and marketing automation for years, I kept seeing both versions of this problem. The manual inbox manager who was also somehow supposed to be doing three other jobs. The campaigns going out from noreply addresses because nobody had built the infrastructure to handle responses. The revenue signals sitting unread, or not arriving at all, because the receiving side of the communication stack had never been properly built.
The "noreply paradox": companies invest heavily in building outbound communication systems, then tell customers not to reply to them. Otto Routes exists to make replying the default, by handling what happens when they do.
Otto Routes connects to a company's shared inboxes via OAuth and automatically classifies incoming emails into routing categories: Sales, Support, Demo requests, Feedback, and General, with custom categories supported as the ML layer learns the specific patterns of each account.
Emails that meet confidence thresholds are routed automatically. Emails that don't are flagged for manual review, with the reviewer's decision feeding back into the classification model. Over time the system routes more automatically and requires less human intervention, without sacrificing accuracy.
The confidence thresholds are deliberately category-specific. High-intent categories like Sales and Demo requests auto-route at 85%+ confidence. Boundary-ambiguous categories like General require 95%+ before auto-routing. Below 75%, a confidence warning surfaces regardless of category.
The goal was always for the ML layer to carry the classification weight over time. Using the Claude API as the AI backbone meant getting to a capable, accurate system faster, without the distraction of building and training a model before the product had customers. The architecture is designed with a clear migration path: if the business eventually reaches a scale where a proprietary model makes sense, that's a contained swap, not a rebuild.
Real-time classification would have been simpler to build but expensive to operate at scale. The Anthropic Message Batches API processes emails asynchronously, achieving 50–70% cost savings compared to synchronous calls. For a shared inbox use case where most emails don't require instant routing, the latency tradeoff is acceptable and the cost structure makes the product viable at mid-market price points.
Not all misroutes are equal. A sales inquiry landing in support has a different cost than a general inquiry landing in the wrong queue. The confidence thresholds reflect those asymmetric costs: high-stakes categories require higher confidence before auto-routing, with multi-layer validation on top of the threshold check to catch cases where the model is confident but wrong.
Most shared inbox tools charge per seat, which creates friction for the exact use case Otto Routes is built for. Shared inboxes aren't owned by one person. A pricing model tied to email volume rather than user count aligns cost with actual usage and removes the negotiation about how many “seats” a shared inbox requires.
Only metadata and Gmail message ID references are stored. This was both a privacy decision and a practical one: storing email bodies at scale creates compliance surface area that a company at this stage doesn't need. The classification and routing system works from metadata and signals, not stored content.
I didn't build Otto Routes to learn how to build software. I built it because the problem was real and I didn't have another way to tackle it. The learning was a byproduct of actually shipping something.
The most significant shift was learning to operate as a product manager on my own work. When you're inside a company, someone else is usually making the prioritization calls, the pricing decisions, the architecture choices about what to build now vs. defer. Building Otto Routes meant making all of those decisions myself, and being wrong about some of them, and adjusting.
On the technical side: integrating production OAuth flows across three platforms (Google, Microsoft, Salesforce) taught me more about authentication architecture than years of working adjacent to it. Designing a database schema that needs to support multi-tenancy, audit logging, and ML feedback simultaneously is a different problem than designing one for a single use case. And using AI as a practical component of a production system, rather than as a subject of curiosity, changes how you think about what it's actually useful for.
The catch-22 is real: you can't get this kind of experience without building something, and you don't usually get to build something without the experience. Otto Routes is how I broke that loop.