When a customer asks for a refund, the person handling the message needs to know whether it is allowed, how much to return, and when to ask for approval. Some of those decisions may be documented. Others may follow practices the team has developed over time.
Now we want AI to handle the same request. It can read the message, find the transaction, and call a function in an application to submit a refund. I think we need to be more specific about the work we are handing over, including which decisions it may make without checking with our team again.
An AI agent, as used here, is an AI system that can choose steps and use tools to carry out a task, then check the results before continuing. A tool is a function the AI can call, such as looking up a transaction or requesting a refund. Anthropic also explains this way of working.
We will use one example: a refund. We will follow it from the customer's message until we know the outcome from the payment system. Every amount, case count, and handling time below is illustrative. None comes from a particular company's operations.
What Does a Refund Request Actually Involve?
Suppose we run a business that receives customer requests through WhatsApp. A message comes in:
Hi, the item I received yesterday is the wrong size. I'd like to return it. Can I get a refund?
If the AI only needs to explain the refund process, we can give it our returns policy. It reads the document and explains the conditions and steps to the customer.
Now suppose we want it to handle the request through to completion. The system needs to establish who the customer is and which transaction they mean. Then it needs to check the purchase date, the items being returned, whether those items have arrived, and how much can be refunded. After that, it can submit the refund to the payment system and update the customer.
For this example, assume our policy requires the returned goods to be received and inspected before a refund can be processed. The customer's message alone is therefore not enough. The AI needs information from the order, warehouse, and payment systems. Each may have a different status at the same point in time.
The customer might say they have shipped the item back, while the warehouse has not received it yet. Or the warehouse might have received it but not finished the inspection. The request is the same, but the next step depends on the available information.
This is where the AI's ability to understand the customer's language helps. The customer does not need to know what our internal process is called or supply every detail in the right format at the start. The AI can ask for missing information and find the relevant records, provided we have given it access.
Who Decides Whether the Refund Is Allowed?
Suppose our team decides that refunds of up to Rp 200,000 can be processed automatically if all the conditions are met. Larger amounts need a supervisor's approval. The Rp 200,000 limit is an example of a business decision, not a general standard.
We still have to explain what those conditions are. Does the amount include shipping? What if the purchase used a voucher? What if some of the items have already been refunded? What if the customer asks for the money to go to a different bank account? Our answer also has to follow the payment provider's rules. Stripe, for example, restricts refund destinations to the original payment method. Stripe refund destinations.
These questions existed before we started using AI. An experienced support team may already know the answers, or know whom to ask. To automate the work, we need to write down the rules the team uses and build a system that can apply them.
AI can help read the documents and propose rules. The company still needs to decide who qualifies for a refund, how much they can receive, and who can approve an exception.
Once the limit is agreed, the system that executes refunds should also check each requested amount against it. If the AI requests Rp 500,000, the system should require the appropriate approval before proceeding. Putting a Rp 200,000 limit in the AI's instructions alone does not ensure that larger transactions cannot happen.
We also need to think about the total amount that can be processed in a day. Suppose there are 100 refunds of Rp 150,000 each. Every refund is below the limit, but 100 times Rp 150,000 is Rp 15 million. The company may be comfortable with that, or it may want another check once the daily total reaches a certain amount.
We can start with a small limit and adjust it after seeing the results in production. A better AI model still needs rules about how much money it is allowed to process automatically.
What Happens When the Work Is Only Partly Done?
Now suppose the customer qualifies and the refund has been approved. The AI submits a Rp 150,000 refund, but the connection drops before it receives the result.
We do not yet know whether the request failed to arrive, is still being processed, or was processed but the response never reached our system. If we immediately submit another request as a new transaction, we could refund the money twice.
One way to handle this is to give each refund request a fixed ID. If the payment system supports this mechanism, we send that ID as an idempotency key when submitting the refund and reuse it when retrying the same request. The payment system can then recognize the retry and avoid creating another transaction. This is called idempotency. Stripe, for example, provides idempotency keys for retrying requests after connection problems. Their use is subject to the provider's rules, including how long keys are retained. Stripe documentation.
Idempotency here means that sending the same request again does not create a second refund. The application needs to store the request ID so it stays the same even if the AI resumes the work in a different conversation.
An accepted request does not necessarily mean the refund is complete either. Stripe's documentation describes refunds that are pending, need further action, or fail. Our message to the customer needs to reflect the status the system actually knows. Acceptance of the request is not enough to say the money has reached their account. Stripe refund documentation.
The Rp 150,000 refund already has approval. We now need to know the result of submitting it to the payment system. If it is still pending, the AI can tell the customer that the refund is being processed, and our system needs to check its progress again. We need to decide which status is sufficient to close the customer request and who follows up if the refund fails.
If the status is unclear, the system needs to record the request and its latest status for another check. If it still cannot be completed, the case needs to go to the person or team responsible. They need the full context, including which transaction was attempted and the last result, so they can continue without asking the customer to explain everything again.
Does Our Team Need to Approve Everything?
Asking for approval on every refund can be a reasonable starting point with AI. The team can check its work before money is processed. We also need to understand which tasks people still carry out after the AI has helped.
Suppose we receive 1,000 refund requests a month. Before AI, the support team spends an average of 6 minutes of active work per request, from reading the message and checking records to recording the result and updating the customer. That is 1,000 times 6 minutes = 6,000 minutes, or 100 hours a month. Physical inspection of returned goods and time spent waiting for payment processing are outside this calculation, both before and after AI.
With AI, collecting the information and preparing a recommendation happen automatically. For the same number and types of requests, suppose all the support work still done by people takes an average of 2 minutes per request. This includes reviewing the recommendation, correcting errors, and giving approval. Any other work the team still performs must also be included in that average.
The team's time becomes 1,000 times 2 minutes = 2,000 minutes, or 33 hours and 20 minutes a month. That saves 66 hours and 40 minutes. The 2-minute average is an illustrative assumption. During a pilot, we need to measure whether it is enough to handle the requests according to our rules.
Even with those savings, every refund still waits for a person's approval. If the supervisor has not had time to check it, the request cannot proceed. That waiting time is separate from the active work we counted, so the reduction in working hours does not tell us how quickly the customer receives the result.
I think approval should depend on the type of case and the limits we have agreed. Suppose the Rp 150,000 refund meets the conditions, the returned-goods records are complete, and the amount is within the Rp 200,000 automatic limit. Once testing gives us sufficient grounds to allow automatic processing, the system can execute it without approval on each case. Requests above the limit or requiring an exception still go to someone authorized to decide.
We can also keep approval on every refund if the risk remains unacceptable. The example still has savings from collecting information and preparing recommendations. To assess the benefit, we also need to count monitoring, integration maintenance, and error handling outside the work on individual cases. The hours saved may reduce overtime or give the team time to serve other customers, depending on the company.
Where Should We Start?
For a pilot, we can choose one type of refund with clear conditions. Have the AI make recommendations first, then compare them with the team's decisions on the same cases. When the results differ, we need to work out why. Did the AI misread the data? Was information missing? Or do people on our own team understand the rules differently?
Before giving the AI access to execute transactions, we should also test cases where the process breaks down. For example, a customer sends the request twice, the connection drops, the amount changes after approval, or the returned-goods status changes while the refund is being processed. Approval needs to be tied to the transaction, amount, and conditions that were checked. If those details change before execution, the system needs to check eligibility again and obtain fresh approval where required.
From those results, we can decide which cases can be processed automatically and which still need a person. The transaction record should show the data used, the rules applied, the approval given, and the payment system's result. That gives the team enough information to investigate a complaint or improve the process.
During the pilot, we also need to record the team's remaining work, how long customers wait, and errors that need correction. Those results help us judge whether the process is useful and whether any types of cases are ready to proceed without approval on every request.
Of course, this refund example simplifies quite a few things. Every business has its own return conditions, payment systems, and customer situations. To try this in our own company, we can ask the team to choose one of their most frequent requests and explain the steps they take and the decisions they make until it is complete.