My Work

The Problem

Enterprise support teams were drowning in repetitive, high-volume tickets — flight cancellations, policy queries, order status — the kind of requests that don't need human judgment, just accurate information and the ability to take action. Existing bots could answer FAQs but couldn't actually do anything, and they broke the moment a customer phrased a request slightly differently than expected.

​

What I Built

As founding PM, I built the SaaS bot platform itself — not a single feature within it. The core modules were mine end to end:

Bot training module: The interface that let customer-facing teams retrain the model themselves from real conversations — no ML engineer required for every update.

​

Data ingestion, intent creation, and entity creation: Intent creation could use external data and real-time conversation data (more about it below). Entities included custom entities that could be defined and global entities (PNR number, phone number, email, source, destination, etc.) that could be reused directly across customers rather than rebuilt from scratch each time — a meaningful lever for how fast we could onboard a new account.

​

Intent creation was designed to be fast end-to-end: A team could create a new intent directly from the UI, map it to utterances pulled from existing data, configure the response, and deploy—all without engineering involvement. That speed mattered a lot for onboarding and iteration; customers weren't waiting on a dev cycle to teach the bot something new.

​

Responses were also platform-aware, not generic text dumped everywhere. A Facebook bot could use Facebook-native elements like carousels, while other channels rendered the equivalent response in their own native format — so the same underlying intent and workflow could surface correctly across very different channel UIs.

​

Workflow configuration tool: This was the piece that turned the bot from a Q&A tool into something that could complete a task. A customer could define a multi-step workflow — for example, flight ticket cancellation — where the bot gathers required entities and variables step by step, and once everything's collected, the agent (or the bot itself) takes the final action. This is what separated Netomi from chatbots that could only answer questions.

​

Built into the workflow was automatic human handoff: Any conversation where the system's confidence dropped below the threshold was routed to a human agent rather than forced response. This was a deliberate trust decision — better to hand off cleanly than let the bot guess on a low-confidence classification and damage the customer experience. This was also facilitated when the end user explicitly asked to be transferred to an agent. Here the experience was flagged and conversation was transferred to a human agent.

​

Zendesk and Freshdesk integrations: I built the agent-assist apps for both platforms. Contact center agents got a recommended response inline in their existing workflow and could accept it as-is, edit it, or reject it. Every one of those three outcomes fed a training pipeline, so the model kept improving from real agent behavior instead of static labelled data alone — this closed the loop between production usage and model quality.

​

Self-serve model retraining: Built so the model could be upgraded directly from the SaaS platform over time, without involving engineering for every version bump.

​

Role-Based Access Control: Defined the full role-vs-action matrix for the platform — who could train, publish, edit workflows, and access what, across customer teams of varying technical maturity.

​

Integrations with the broader ecosystem of platforms our enterprise customers ran on.

​

I also built and led a team of 2 PMs — one owned analytics (the reporting layer, dashboards, and charts customers used to track bot performance), which let me stay focused on the core platform while giving her real end-to-end ownership.

​

Why It Mattered

This wasn't just an NLP feature bolted onto a support tool — it was the platform other features got built on. The workflow engine plus entity/variable framework meant the same core system could serve an airline (flight cancellations) and an insurance company (claims status) without a rebuild, just reconfiguration. That reusability is a big part of how the product scaled to $5M+ ARR across a small number of very different verticals.

​

KPIs I Owned

• Deflection rate — share of conversations the bot resolved without human escalation - 91% Customer support FAQs were handled by the chatbot with correct resolution.

• Agent-assist acceptance rate — how often agents accepted, edited, or rejected bot-suggested responses across Zendesk/Freshdesk, and how that fed model retraining - More than 90% agents started using our recommendations in the first 3 months. (recommendations use was optional)

• Time-to-onboard a new customer — Time to create new intents and entities from existing data and global entity data, train the model, test it and deploy it - Reduced by 50%

• Workflow completion rate — for task-based flows like cancellations, whether the bot successfully gathered all required entities and completed the action - 100% of entities were gathered correctly in 70% of workflows.

​

Looking Back

Owning both the platform and a growing team taught me the real constraint wasn't the model — it was making the system configurable enough that non-technical teams could trust and operate it themselves. If I were doing it again, I'd invest earlier in the RBAC and workflow-template layer, since that ended up being the biggest unlock for scaling across very different customer verticals without linear increases in engineering effort.