Alia

The volume was not mysterious. Support could name the questions from memory, and the ticket data agreed: deposits, stablecoins, verification, pending. They had known answers. What they did not have was a place to be answered at the moment the customer was confused, which was inside the app, usually with a transfer in flight.

The obvious fix was a chatbot, and the obvious risk was that a chatbot about money is not a chatbot about shoes. A model will answer “why is my deposit pending” in the same steady voice whether it knows or not, and the customer has no way to tell the two apart. The product had to make that difference visible before the customer could be hurt by it.

Alia lives one tap from the home screen, as Ask Alia in the header. That entry says nothing about AI, on purpose: the introduction does. The first screen is a name, a mark, one sentence, I’m your AI-powered assistant, and a link to the disclaimer. Then a sheet rises over it and asks the customer to acknowledge what an AI answer is before the first one is sent.

The sheet is legal text, and I would not pretend anyone reads it. Its job is the tap. I understand is the moment the customer agrees that what follows is generated and may be wrong, and the product is allowed to hold them to that. What the sheet does not do is make the answers trustworthy. That takes the rest of the system, and it starts right after the sheet goes down.

The disclaimer is the beginning of the trust model, not the whole of it.

The worst state of a chat is the empty one: a cursor, a placeholder, and a person who does not know what this thing can do. So Alia asks first. Its opening message is one sentence and four cards, and tapping a card sends it as the customer’s own message. Most conversations never need the keyboard.

The keyboard is still there, because the four questions are the most common ones, not the only ones. But free input has a limit: 160 characters, with a counter, and at the limit the counter turns red and the field stops. Short questions map well to answers. Long stories do not, and long stories are exactly the conversations that needed a person anyway, so the limit pushes them toward one instead of toward a worse answer.

A question and an answer took a week to design. The map of everything else took the rest of the project. I drew the conversation as a flow before any screen existed, and most of it is not the happy path: is the model on or off, is it slow, did it understand, was the answer any good, does the customer want a person, does the person turn up.

Each branch became a state the interface had to be able to show, and each state got a rule for what Alia must do and what it must not. The must-nots are the important half. A model left alone will guess, complete your sentence for you, and answer the nearest question it knows. In this product, every one of those is a bug.

Every answer ends in two buttons. Thumbs-up is a data point. Thumbs-down is not: it is a person saying this did not work, about their money, and the only honest reply is a way out. So the next thing on screen is not a second attempt or a survey. It is Sorry I couldn’t help. Would you like me to open a ticket for you so our support team can take over?, with a yes and a no.

That gives the conversation exactly two endings. Either the customer got what they came for, or a human has the thread. There is no third state where someone argues with a bot about a transfer. The rule cost us something: every thumbs-down opens a ticket offer, including the ones where the customer just disliked the tone, and support absorbs that. It was the right side to err on.

Every conversation resolves or hands off. “No dead ends” is a rule about what the last message can be.

The number I watched was not how many people used Alia. It was how many asked for a human on the first try. If the suggested questions were getting people in the door without helping them, escalation would stay high, and the whole thing would be a slower way to open a ticket.

Window and cohort: the first two weeks after release, all conversations, measured as the share that ended in a hand-off to a human. No baseline existed: before Alia every one of these was a ticket.

The assumption that changed. I went in thinking the work was the conversation: tone, the suggested questions, making a bot sound like Yellow Card. That was a fortnight. The work that took the rest of the project was deciding what Alia does in the moments the model cannot carry: a sentence it cannot parse, an answer that was wrong, an outage. The failure states are the product; the happy path is a demo.

What it taught me about AI in a money product. In a money product, a confident wrong answer is worse than no answer. So the design has to be more honest than the model: say what it is before it speaks, quote the customer's words back when it does not understand rather than guess, and treat a thumbs-down as a request for a person rather than a data point. None of that makes the model better. All of it makes being wrong survivable.

Not the same outcome. Escalation falling from above 20% to around 9% is not the same as Alia being right. It says fewer people asked for a human; it does not say the ones who stayed got a correct answer. A rate that low could also mean people stopped bothering to rate at all. Correctness needed a different measure, and we did not have one.

What I would measure earlier. Answer quality on a sample, from the first day: a support agent reading a hundred conversations a week and marking each answer right, partial or wrong. The escalation rate told us how the exits behaved. It said nothing about the answers, and the answers were the point.

What is still unclear. Whether the disclaimer changed anything. Everyone tapped I understand; nobody could have told you what it said. It did the legal job. Whether it did the trust job, or whether the trust came from the clarification and the hand-off, I cannot separate.