Claro AI: Frustration Analysis

I used session recordings, heatmaps, clickstream data and interviews with customer success managers and clients to investigate this problem. I noticed recurring patterns such as users rephrasing questions, repeating requests, correcting the bot and eventually abandoning the conversation or escalating. These findings showed that a failed conversation was not always a frustrated conversation, and helped me prioritise a Frustration Analysis module that let clients filter potentially frustrated conversations and inspect the behaviour behind them. I wrote the PRD and feature specification, then worked with engineering on signals, model thresholds, scope and UI/UX for the first version.

I led the work from discovery to pilot launch, where feedback from clients and customer success managers helped assess whether the filtering and analysis were useful. To test whether the module actually helps an analyst find a real problem faster, I would measure the following. These are proposed measurements, not measured pilot outcomes.

Threshold comparison: Lenient: 54.1% precision, 88.4% recall, 109 reviews. Middle: 70.2% precision, 77.9% recall, 73 reviews. Strict: 81.5% precision, 58.1% recall, 47 reviews. Analyst workload: Lenient catches more frustrated users but creates a higher false-alarm load. I would not choose Middle just because it looks balanced. Strict creates fewer false alarms but misses over 40% of frustration cases. I would set the minimum acceptable recall with stakeholders first, based on the cost of a missed frustration case, then choose the threshold that minimises review effort while meeting that floor.

This work demonstrates user research, translating evidence into a product priority, writing requirements and collaborating across product and engineering