News · CRED's Cleo: one conversational surface, three query types, and a routing layer underneath

Jan, 214 min to read
Frontend

CRED's Cleo: one conversational surface, three query types, and a routing layer underneath

How CRED built a customer-facing AI companion plus two internal tools, and what its reported metrics reveal about the frontend design choices

Three query types, one intent-classification step

CRED describes Cleo as an AI conversational companion built on OpenAI models — it names GPT-4.0, GPT-5, and o3 — that handles three explicitly defined query categories: informational ("What is CRED Cash?"), contextual ("Am I eligible for CRED Cash?"), and transactional ("Can I refund to my wallet or original payment method?").

What matters for anyone designing a customer-facing AI surface is the sequence CRED lays out. Cleo does not answer first. According to Seetharaman, it "diagnoses the issue, classifies the intent, maps it to the right SOP, and frames a contextual, accurate response." The SOP mapping is the constraint: the response is anchored to an existing standard operating procedure rather than freely generated. That is a frontend decision as much as a backend one, because it shapes what the member actually sees and trusts.

The distinction between contextual and transactional queries is telling. An eligibility question and a refund action require different guardrails — one reads state, the other changes it. Splitting these at the classification layer lets the same chat surface behave conservatively where money moves.

The metrics CRED chose to report

CRED cites a 14 percentage point improvement in CSAT, a 98% resolution accuracy rate for Cleo in the three months since launch, 18% more multi-intent conversations resolved successfully, and a 31% drop in session drop-offs. It also says average handling times fell across all three tools.

The session drop-off figure is the one worth dwelling on from a frontend perspective. Drop-offs measure whether a member abandons the conversation mid-flow — a direct signal of interface friction, not just answer quality. A 31% reduction suggests the conversational surface is holding people through resolution rather than pushing them to a human or to giving up.

The multi-intent number points the same direction. Real support conversations bundle several requests into one message; resolving 18% more of those successfully implies Cleo's classification step is decomposing compound queries rather than latching onto the first intent it detects. These are self-reported early results, and CRED frames them as such, but they name the specific behaviors a designer would actually optimize.

Thea and Stark: the surfaces members never see

CRED built two internal tools alongside Cleo. Thea serves support agents, summarizing multi-format conversations — text, voice, and Hinglish — and suggesting next steps. Stark serves operations teams, letting them create or update SOPs "in minutes instead of days."

The Hinglish detail is concrete and locally grounded: agents in India field code-mixed conversations, and a summarization tool that handles that mixture is doing real work, not demo work. Stark is arguably the more structural choice. Because Cleo answers by mapping to SOPs, the quality of the member-facing experience is bounded by how current those SOPs are. Stark shortens the loop for keeping them fresh, which means the internal authoring tool and the customer front door are coupled by design.

The design implication: closing the loop between dead-ends and documentation

CRED's stated next step is building tools that detect "data dead-ends" — queries Cleo cannot answer — and feed them back into the knowledge base to improve SOPs in real time. This is the logical completion of the architecture already described.

The specific lesson from CRED's setup is that an SOP-anchored conversational front end only stays accurate if failed queries become fuel for the documentation behind it. Cleo's 98% resolution rate is a snapshot; the dead-end detector is the mechanism meant to defend it as query patterns shift. For teams building similar concierge surfaces, the takeaway is that the classification step, the authoring tool, and the gap detector are not three separate projects — they are one loop, and the customer-facing chat is only as good as how quickly the other two feed it.

Find this story relevant to you?

Contact us to find a unique solution

Contact us

Need an AI engineering partner that can actually build?

We help businesses integrate AI, build AI-powered products, automate high-value workflows, and modernize the software systems behind them.

Get in touch

Related reading

More analysis around product delivery, operational AI, and the systems work that makes deployment hold up in reality.

Jul, 134 min to read
Frontend

DNP put ChatGPT Enterprise in front of ten departments and treated the chat window as the interface

Jul, 134 min to read
Frontend

AdventHealth deploys ChatGPT across nine states by treating adoption as the product

Jul, 134 min to read
Frontend

AP+ uses Codex to build behaving payment prototypes, not just clickable screens