Evelyn, the Chatbot That Does More Than Answer Questions

Figure 1. Tura guiding a user through the donation process, from collecting donor information to initiating payment and confirming the transaction.

Update: Evelyn has now been renamed Tura, the official mascot of Unpad. Link https://endowment.unpad.ac.id

─

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

Under the hood, Evelyn connects several moving parts: the chat interface, the AI model, the donation system, and the payment gateways.

But from the user's perspective, the experience stays simple. They talk to Evelyn, and Evelyn figures out which action needs to happen next.

Evelyn sits as a conversational layer above the existing donation platform, helping users understand their options and move from one step to the next. When an action is needed, such as finding a campaign, creating a donation, or checking its status, Evelyn uses a small set of controlled tools to interact with the platform rather than handling those operations herself.

The architecture below shows a simplified view of how those pieces work together. The important part is the separation of responsibilities: Evelyn understands and coordinates the conversation, while the donation platform remains the system of record and the payment gateways remain responsible for transactions.

Figure2. Simplified architecture of Evelyn, showing how the conversational agent connects visitors with the existing donation platform and external services.

The architecture is intentionally separated this way. Evelyn can help users navigate the donation process, but she does not replace the systems responsible for donation records or payment processing.

That separation also makes it easier to control what the AI can and cannot do. Instead of giving the model unrestricted access to the application, Evelyn works through predefined tools and actions, keeping the conversational experience flexible while the underlying operations remain controlled. 

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.