VoC-responsive agent builder
Entering
Recently, the Moonlight team has been handling the VoC response process with agents. In this article, I will try to summarize what problems I saw in the process and how I solved them.
The reason I started this project was because a small team was handling numerous VoCs and fatigue was accumulating among team members, and I started thinking about how to solve this problem and how to handle it more efficiently.
Actual VoC response does not end with writing a single sentence in response. You should read the inquiry, check the policy document, look at the code base, search the DB if necessary, and if you still have difficulty deciding, ask the question again to a team member who knows the context well. In other words, VoC response is a task closer to inquiry and judgment than writing.
Recently, there are customer service automation tools with various AI functions. However, what the team needed was not a general answer generator, but a way to access the policies, code, data, and context of our service and query and query like an actual team member.
What was the problem?
There were three problems.
First, a small team had to deal with more than 10 incoming VoCs per day, both in time and context switching costs.
Second, each team member had different contexts, so there were differences in the basis for confirmation and the method of answering. If I couldn't immediately remember where to find the evidence I needed, I had to ask another team member.
Third, even if we tried to automate answers, it was difficult to access the internal context with just the general AI answer function. In real-world operations, this limitation was evident because grounded responses were more important than natural sentences.
So there were two problems we wanted to solve. One was an issue of operational efficiency that enabled more VoCs to be handled with fewer people, and the other was an issue of quality that reflected the actual service context and internal rationale.
To achieve this, the Moonlight team structured a processing flow to collect VoC, explore the required evidence, draft it, and finally have it reviewed by a human.
Agentic VoC processing flow
The first thing I focused on while working on this project was structuring the response process.
The first thing I thought about was “what should I look at first?” When I summarized the steps that team members repeatedly take when responding, the overall flow was as follows.
- Check existing conversation history
- Check policy document
- Check the code base
- DB inquiry if necessary
- Draft your response
The first goal was to make this flow reproducible for agents.
The second goal was to ensure that responsibility still lies with humans. Because automatic sending was burdensome in terms of quality and security, we configured it to have agents do the searching and drafting, and have humans make the final decision. This is the commonly referred to human-in-the-loop method.
So this project wasn't just an answer generator, it was more about creating a processing flow to collect VoC, explore evidence, create a draft, and send it out for human review.
Moonlight VoC processing flow
Customer Inquiry
- Customer inquiries come into the VoC channel.
- Customer inquiries are received through webhooks, and cycle inquiry is used as an auxiliary method to recover from omissions.
- Determine whether the VoC is eligible for processing.
- For processing purposes, the evidence is explored in a sequence similar to the human flow.
- View embedded existing conversations
- View code base and policy documents
- Database query if necessary - Create a draft response based on navigation results and templates.
- Forward drafts to Slack.
7. After the person in charge checks the summary and details of Slack, select a processing method through the Send, Retry, and Deny buttons.
Results of applying agentic flow
The biggest change after applying this structure is that team members no longer have to personally carry out the response process from start to finish. Previously, people had to read the inquiry, decide what evidence to check, find the necessary information, and organize the draft. On the other hand, for about 50% of all inquiries, agents first handle the repetitive inquiry and drafting stages, and the person in charge only has to make the final decision in Slack.
This change wasn't just about response speed. We were able to reduce the differences in context for each team member and also lower the cost of “who should I ask this to?” In particular, by combining existing conversation history, policy documents, code base, and data inquiries into one flow, we were able to make the process of finding evidence more consistent.
So, rather than a system that automatically sends responses, this project was positioned as an operational tool to reduce the costs of repeated exploration and drafting during the VoC response process.
Connection with MoonClaw
Basic VoC collection, evidence search, draft creation, review, and sending can be accomplished using the VoC processing flow described previously. However, in actual operation, there are cases where this flow does not end. Sometimes you need to tweak the draft a bit, and sometimes you need to double-check the project context related to the current inquiry. There are times when you want to check again to see if the basis the agent came up with is correct even by the current standards.
In this case, what I am writing above isMoonClawIt is. MoonClaw is not a tool that replaces the VoC processing flow itself, but rather a tool that operates on top of it.Supervisor AgentClose to . Normally, the VoC processing flow handles most inquiries, and only talks to MoonClaw to refine the results when additional confirmation or correction is needed.
For example, a team member might ask MoonClaw to “Please double-check only the payment policy portion of this answer against the latest code.” Or, you can review once more whether the basis referenced by the agent is still valid in the current operational context and whether certain expressions are consistent with actual policy. In other words, if the VoC processing flow is the basic path, MoonClaw can be seen as a path that accepts exception situations or additional queries above it.
The biggest advantage of this structure isOperational FlexibilityIt is.
- Independent Engine:The VoC response flow handles routine tasks reliably 24 hours a day without the need for a higher-level agent.
- Interactive reinforcement:Only when complex judgments or modifications are necessary, we communicate with the agent through MoonClaw and refine the results.
- Share context:Since MoonClaw holds the context of the entire project, it can ensure response in accordance with the update direction of the entire service beyond simple VoC processing.
Through loose connection with higher-level agents, routine processing is automated and complex problems are solved through collaboration between agents.Scalable operating structurehas been equipped.
finish
The biggest thing I gained from this deployment was a sense of how the agentic system can share the work of humans. Rather than replacing all human work, we found that it was effective to divide it into exploration, gathering evidence, drafting, and approval, and then entrust the repeatable parts to the system first.
On the contrary, it was clear that things had to be left to people until the end. It was still up to humans to decide whether to actually send it to the customer, determine what context to add in exceptional situations, and take responsibility for incorrect responses. So, this project was not about automation that eliminates people, but was closer to creating a structure that reduces repetitive tasks while maintaining responsibility for people.
In the end, this project was a case of experimenting with how actual operational tasks could be transferred to an agentic system, rather than VoC automation itself. For the Moonlight team, this experience went beyond simple response automation and became a standard that could be applied when dealing with other operational areas in the future.