Arun TSSenior AI Product Manager

The Problem: Agents Were the Search Engine

At a large telecom enterprise, customer service agents relied on a basic chatbot interface that could respond, but couldn't resolve. For most real customer questions, the chatbot returned partial or surface-level information — enough to start, never enough to finish. Agents still had to manually check 4–5 separate knowledge bases and internal tools mid-conversation to piece together a complete answer.

This created a dual pain point that hit both sides of the conversation at once. Agents lost time navigating between systems while a customer waited on the line. Customers experienced the friction directly — repeated "let me check that for you" moments, growing impatience, and visible frustration on calls that should have taken a fraction of the time.

It wasn't framed internally as just a customer experience problem, or just an agent efficiency problem. It was both — which is part of why it gained the urgency and traction to get built.

The Approach: One Resolution Layer, Not Another Chatbot

Rather than building a better chatbot, the team built a cognitive layer that sits between the existing chat interface and the underlying knowledge bases. It queries multiple internal sources in parallel, collates what comes back, and returns one plain-language, complete answer — directly inside the conversation the agent was already having.

Internally, this was deliberately framed not as "we added AI" but as "we removed a manual step that never needed to exist." The agent's job changed from searching to confirming — read the resolution layer's answer, validate it against the customer's actual need, and move on.

The Hard Decisions: Knowing When Not to Answer

The system needed a way to know its own limits — not through a confidence score, but through two deliberate, rule-based escalation paths built directly into the design:

This distinction mattered more than it might first appear. It separates "the system doesn't know" from "this isn't the system's call" — a designed scope boundary, not a limitation papered over after the fact.

A Real Tradeoff: Speed vs. Cleanliness, Under Pressure

A new product launch surfaced a data-readiness gap — product details from upstream knowledge bases didn't sync in time for a new offering to be fully represented in the system. The choice was between two paths: wait for a fully engineered, properly tested fix, or ship a fast, pragmatic patch to close the immediate gap.

The call was made to ship the quick fix — closing the customer-facing gap immediately rather than letting it sit through a longer, more thorough engineering cycle. That decision meant navigating real disagreement with engineering, who reasonably preferred the more careful approach.

It wasn't a clean win. It was a genuine tradeoff, made with incomplete time and two valid perspectives in the room — exactly the kind of judgment call that doesn't show up in a feature spec but shapes how a platform actually gets built.

The Outcome: What Actually Changed

Response time held under 3 seconds even during peak business hours — when load on the system was highest and the old experience was at its slowest.

What This Taught Me

The most durable lesson from this project wasn't about model performance — it was about scope. Knowing when a system shouldn't answer is as important as making it answer well. The two escalation paths weren't a safety net bolted on at the end; they were a design decision made early, and they're the reason the resolution rate could climb to 95% without the system ever overstepping into decisions that genuinely required a human.

It's a principle I now apply to every AI product decision I make: scope the system's authority before scoping its intelligence. The next platform I build will start with the same question — not "what can this answer?" but "what should this never decide alone?"

A Regulatory Requirement, Not a Customer Request

This product began differently from most of the work on this page. It didn't start with a user pain point or an internal pitch — it started with a new regulatory requirement. A major Australian bank needed to offer a renewable energy financing product within a fixed compliance window.

I worked alongside Legal and Compliance from the outset, translating a broad regulatory outcome into something that could actually be built, tested, and launched on time.

The Regulation Set the Outcome. Everything Else Had to Be Designed.

The requirement specified only that such a product needed to exist — not its structure, its eligibility criteria, or how it would work in practice. Most of the real product work happened in the space the regulation left open.

The team designed those details from the ground up: offering it as an add-on to existing home loans, funding renewable energy installations like solar and wind systems, at a reduced interest rate for customers who qualified.

Eligibility Designed Around More Than Compliance

Rather than a single financial cutoff, eligibility was modeled around a combination of factors — outstanding loan balance alongside customer tenure and loyalty.

Nothing in the regulation required factoring in tenure or loyalty. That was a deliberate addition — using the opportunity to also reinforce retention among long-standing customers, not just satisfy the minimum requirement. It wasn't a clever workaround so much as a sensible design choice once the team had room to decide.

A Short Window, Shaped by Two Pressures

The delivery timeline was short — driven by both the compliance deadline itself and the bank's interest in launching early. The most difficult decisions were practical ones: where to set the eligibility criteria, and how to meet the deadline without compromising on compliance review.

What the Product Delivered

A straightforward delivery metric, not a projection — tied back simply to the eligibility design above, without overstating the connection.

A Brief Note on Compliance-Driven Work

The lesson I keep from this project is a quiet one: regulatory requirements set a floor, not a ceiling. There's often real room to design something that does more than the minimum, even within a fixed mandate.