Evelyn, the Chatbot That Does More Than Answer Questions

This is a story about how a small chat bubble can become an entry point to a more helpful donation flow: from understanding a user's intent, to choosing a program, to guiding them toward payment.

Inspired by an AirAsia support experience, I built Evelyn, an AI assistant for Unpad's endowment donation platform.

A Small Experience That Stayed With Me

At one point, when I was planning to travel with AirAsia, I needed to add extra baggage to my booking. I looked for the support page and was directed to AirAsia's help center. There, a small chat bubble appeared.

At first, I assumed it was just another FAQ chatbot: template-based, rule-based, and useful only for general information. But when I tried it, the experience felt different.

The assistant asked for a few details, understood what I needed, and guided me toward a transaction to add more baggage. I clicked through, paid, and it actually worked.

That small moment stayed with me. It showed me that a chatbot does not have to stop at answering questions. It can become a doorway into a complete process: from intent, to data collection, to transaction. From there, I started asking myself a simple question: what if this kind of experience could be applied to campus donations?

Donating Looks Simple, But It Is Not Always Simple

On paper, donating looks straightforward. You choose a program, enter an amount, select a payment method, and complete the transaction. In practice, that short flow often carries many small questions. Someone may want to donate but still be unsure which program fits them best. Some people may care about scholarships. Others may be more interested in education facilities or social initiatives. Some simply need reassurance that the process is clear, the payment is secure, and the donation will be properly recorded.

The problem is that a form cannot always respond to those doubts. A form is a quiet place. It waits for people to fill in fields, but it cannot explain options, answer follow-up questions, or say, "don't worry, there is only one step left." That is where I felt there was room for a more human experience.

I Did Not Want to Build Another FAQ Bot

When I began imagining Evelyn, I did not want to build a chatbot that only looked modern on the surface. Many bots stop at being FAQ lists wrapped in a conversation. The user asks a question, the bot replies with text, and everything after that is still left to the user.

I wanted Evelyn to be slightly different. If a user asks about donation programs, Evelyn should retrieve the actual program data. If a user wants to donate, Evelyn should help assemble the donor information, donation amount, and payment method. If a user wants to check a donation status, Evelyn should connect the question to the available system data.

In other words, Evelyn was not designed merely to answer. It was designed to help complete one specific task: guiding people through a donation flow in a way that feels lighter, clearer, and more natural.

A Conversation That Does Not Force People Into a Form

What makes conversation interesting is its flexibility. In a regular form, the order is already fixed: name first, email first, amount first, program first. In a conversation, people can start from wherever they are.

For example, a user can simply say that they are an alumnus of the Faculty of Cultural Sciences and want to donate Rp50,000. From that one sentence, Evelyn can capture several pieces of information at once, then ask only for what is still missing.

User: "Saya alumni FIB, mau donasi 50 ribu."

Evelyn: "Baik, saya catat ya: alumni Fakultas Ilmu Budaya dengan nominal Rp50.000. Tinggal pilih metode pembayaran. Mau menggunakan Virtual Account, QRIS, atau e-wallet?"

It is a small interaction, but it changes the feeling of the flow. The user does not feel like they are facing a rigid system. They feel assisted. For me, that is the core of good service design: technology does not always need to look complicated, but it should make the next step feel clear.

How It Works, Without Making It Complicated

At a simple level, Evelyn has two important parts. The first is its ability to understand conversation. It reads the user's intent, recognizes context, and decides what should happen next.

The second is its ability to act. Evelyn is connected to services that can search donation programs, create donation records, check transaction status, and help prepare donation receipts. So when a user asks for available programs, Evelyn does not invent an answer. It retrieves information from the system. When a user is ready to pay, the flow still leads to the proper payment mechanism.

This boundary matters. Evelyn is not the place where money is stored, and it is not the main donation system. The main system still handles the data and transaction process. Evelyn sits as a conversational layer above it, helping users understand their options and move from one step to the next.

Safe, Polite, and Aware of Its Limits

Because Evelyn sits close to a donation flow, security and conversational boundaries cannot be treated as extras. They have to be part of the design from the beginning. Evelyn needs to know what it is allowed to discuss, what it should refuse, and when it needs to ask for confirmation.

If a user asks about something outside the Dana Abadi context, Evelyn does not need to force an answer. It can politely decline and guide the user back to the relevant topic. If information is missing, it asks first. If the flow moves toward a donation, it confirms important steps so the user does not choose the wrong program, amount, or payment method.

For me, this part is just as important as the AI capability itself. A good assistant is not one that always answers everything. A good assistant knows when to answer, when to ask, and when to stop.

What I Learned

Building Evelyn helped me see AI from a more practical angle. Its value is not only in the sophistication of the model, but in how it is placed inside a real service flow. A conversation that sounds smart is not enough if the user still feels confused at the end.

I also learned that conversation design is closely related to interface design. Long answers make people tired. Overly technical instructions make people hesitate. Short, clear, contextual responses can make a process that initially feels heavy become easier to follow.

Another lesson is responsibility. Once a conversation touches data, transaction status, and a user's decision to pay, the system cannot be built on the assumption that everything will go well. It needs boundaries, confirmation, and a clear design for failure.

Evelyn started from a small experience with an airline support assistant. But throughout the process, it grew into a project with its own character: friendly, focused, and able to help users move from good intention to completed action.

For me, the project is a reminder that AI is most useful not when it seems able to answer everything, but when it helps complete one need well, in a way that is clearer, safer, and more human. Sensitive technical details are intentionally left out to keep the system secure.