OttoMate
Designed & engineered a dual-screen AI tool contextually updating based on live call context to increase call specialist efficiency
Timeline
January - August 2026
Team
-
Progressive Insurance Commercial Auto
-
CMU MHCI Capstone
Role
-
Product Designer
-
Technical Lead
-
Product Manager
Responsibilities
-
Live Interaction Design
-
Real-Time AI Engineering
-
Research & Strategy
Context
Commercial auto insurance is a highly regulated domain, with different legal requirements for every one of the U.S.’s 50 states. Coupled with internal policies, Progressive’s call specialists constantly have difficulty navigating through large amounts of information in real-time.
I led the design and UI engineering of OttoMate, an integrated, AI-powered workspace that centralizes fragmented tools and workflows to surface information faster and reduce the decision-making burden.
By taking away the churn of getting to the right information, we greatly increase efficiency and allow Commercial Auto service call specialists to focus on the human connection during live calls.
Screenshot of OttoMate, de-identified and generalized
Impact
-
Redesigned a core enterprise workflow for Progressive specialists, delivering a fully functional, end-to-end AI prototype for continued development
-
Reduced interface complexity and cognitive load by prioritizing the information specialists needed at each stage of a live call
-
Streamlined the specialist workflow to reduce context switching, leading to higher efficiency and shorter calls on average
-
Demonstrated the feasibility of low-latency, real-time AI support during live conversations
-
Created reusable design components and research insights that are scalable across specialist departments
Certain product designs specifics and research findings are generalized or omitted under confidentiality agreements.
Research
Specialists need a Tool that Adapts to Live Calls
We began by investigating where specialists spent the most attention and effort during complex calls, and which parts of that work could be supported within system constraints.
Composite screenshot of selected prototypes, models, and diagrams used and produced by our research
Our research included:
-
Reviewing 100+ articles and academic sources
-
Exploring 6 analogous domains with [X] study sessions
-
Conducting 5 experiential-learning sessions to deepen our understanding of the work
-
Conducting 50 sessions with 41 Progressive specialists using role-play, think-aloud testing, co-creation, and interactive prototypes
Screenshot of early research affinity diagram
We found that the most difficult aspect was finding the right information at the right time. Specialists needed us to streamline their workflow and centralize the information so that they didn’t have to spend unnecessary information tracking down specific details.
These findings shifted our direction away from a tool specialists would have to actively manage and toward an adaptive workspace that responded to the call itself.
Test what support is needed—and when
Screenshot of prototype used for live transcription study iteration 1
For my research, I designed and built an interactive transcription prototype, then created and facilitated role-play studies with eight Progressive specialists.
Rather than testing transcription as a single feature, I designed several ways the system could support specialists throughout a call. We then examined how the value of each feature changed between the beginning, middle, and end of a call. This gave us evidence for deciding what information should appear, when it should update, and which forms of support were distracting.
Shaping chatbot output for live calls
Our team also conducted 10 think-aloud sessions to understand whether an AI assistant could support specialists during live calls and decrease escalations.
Screenshot of prototype used for helper chatbot study iteration 1
We tested how specialists interpreted differences in:
-
Tone
-
Response length
-
Content
-
Persona
These insights directly shaped our prompt guidelines and the output of our chatbot’s multi and single-turn responses. This ensured that our assistant’s behavior was intentionally designed around the expectations and constraints of the people using it.
Design & Engineering
Designing & Building our Tool’s Engine
Photo of some team members working
Separate Transcription from Reasoning
I first built a lightweight prototype with Chrome’s Web Speech API to explore the limits of live transcription, including latency, autofill, and speaker diarization, without having to use our budget.
I then rebuilt the system in TypeScript, React, and Next.js using Deepgram Nova-3. My early prototypes treated transcription and reasoning as one.
Through iteration and discussion with my teammates, we realized that asking one agent to transcribe and reason at the same time made the experience slower, more expensive, and more vulnerable to incomplete transcription.
Simplified model of transcription system
We separated the pipeline into two distinct responsibilities:
-
Deepgram Nova-3 handled speech-to-text transcription in real time.
-
GPT-4o-mini processed only confirmed dialogue, converting it into structured, machine-readable context.
This division of labor:
-
kept the live experience responsive
-
prevented incomplete speech from triggering analysis downstream
-
reduced cost by reserving the more expensive reasoning model
-
created a clean handoff between what the system heard and what it understood.
This division of labor:
-
kept the live experience responsive
-
prevented incomplete speech from triggering analysis downstream
-
reduced cost by reserving the more expensive reasoning model
-
created a clean handoff between what the system heard and understood
I then built the second parsing layer itself: a continuously updated record of the call that became the product’s shared source of truth. Instead of having each feature reinterpret the transcript independently, all features read from the same context.
This keeps the chatbot’s follow-up responses grounded in the latest context, reducing the risk of conflicting or outdated guidance.
Engineering for reliability, security, and cost
Once the core pipeline worked, I focused on the infrastructure needed to make the prototype dependable for testing and hand off, such as:
-
Short-lived authentication tokens that kept AI credentials safe
-
Silence detection that paused audio transmission during extended periods of silence without stopping connection to reduce API calls & budget costs
-
Strict structured outputs so downstream features received predictable, machine-readable AI responses
-
Automated evaluations that tested intent extraction, procedure retrieval, parsing behavior, and speaker-role identification.
These decisions moved the system beyond a proof-of-concept toward an architecture that could be evaluated systematically and developed further.
Product & Stakeholder Collaboration
Designing with Multiple Teams and Constraints
Building the parsing pipeline was only useful if the rest of the product could reliably use it. I worked closely with teammates across design and engineering to define how the structured call context would be presented in the interface and the separate chatbot agent.
As Product Manager and Technical Lead, I also
-
conducted usability studies with Progressive specialists
-
incorporated iterative feedback from client stakeholders
-
worked with Progressive’s data and security teams to understand implementation constraints
In the end, we delivered a functional, high-fidelity AI prototype and a set of recommendations for change management, scalability, and future AI development at Progressive.