Hello, my name is Seunghyun Yoon, and I prepared this lecture on VOC
as part of the SERVEONE MRO process course
In the overall MRO process, today’s focus will be on this VOC section
The goals of this session are as follows:
First, to understand what VOC means at SERVEONE
Second, to learn how SERVEONE manages VOC
Third, to understand the characteristics of exception VOC related to physical flows,
such as exchanges, after-sales service, returns, and cancellations
In addition, in the FAQ, we will briefly cover the questions
most often asked in the field and their answers
First, I am a father of a 3-month-old daughter,
and I am spending very happy days
My hobby is sports, and I especially enjoy badminton
Currently, I am in my 8th year, responsible for managing and planning operations-related systems
This is the VOC overview
What is VOC?
VOC stands for Voice of Customer,
meaning the voice of the customer,
and it refers to all requests and inquiries delivered by customers
Including every customer inquiry within SERVEONE
from questions about using the SERVEONE front before ordering to requests
that occur after delivery during the sales
and settlement process
and SERVEONE manages VOC in two categories
General VOC and exception VOC
General VOC refers to customer inquiries and requests,
while exception VOC refers to VOC that involves the movement of goods,
returns, exchanges, after-sales service, and cancellations
These are four exception VOC
General VOC ends once the inquiry is checked and answered,
but exception VOC requires checking whether the physical movement is completed
because it is linked to sales settlement and cash flow,
so it needs to be reviewed in depth
So later, we will take time to explain each of these in detail
The table below shows the cumulative VOC status
from January to December 2024
It shows what customers most often asked SERVEONE
and what services they requested
As shown here, SERVEONE customers
most frequently asked about delivery dates
Looking at this data, you may wonder how it is managed
and how it was extracted
So now, let’s take a look
at SERVEONE’s VOC management system, Zendesk
For operations staff, Zendesk is familiar,
but for others, it may feel a bit new
Zendesk is a cloud-based customer service software
that integrates and analyzes inquiries
coming in from multiple channels
To explain the present, we need to understand the past
Until 2020, VOC was not in one system
but was managed separately through each channel
For example, if an inquiry came by email to A, A replied and closed it
If a call came to B, B answered and closed it
If a customer left a post on the front,
C checked it in the SMRO VOC menu,
answered, and closed it
It happened like this
This kind of individual handling meant history could not be tracked
When a person missed something
or was absent, the work could not be processed properly
To solve these problems, SERVEONE introduced Zendesk
The process works like this:
requests from phone, email, chatbot, and the front system
are all integrated into Zendesk
Then, based on predefined logic,
they are automatically assigned to the responsible staff
The staff complete the work directly within Zendesk
This allows one-stop processing in a single system,
with data integrated and managed
Tasks are shared in the system,
so collaborative work is possible,
and teams can handle requests together
This prevents work from piling up on a single person
Since assignments are shared in real time,
customer requests receive faster handling and feedback
Even when someone is absent or replaced, other staff can flexibly
continue the work without interruption
Every step from request to completion is tracked in the system,
so nothing is missed
Records can also be checked and used as valuable data for market sensing
Have you understood the management process and the system features?
Now let’s look at how operations actually run
and how the system is structured
Considering the nature of client work, there are three operating models
First, C team, Shared
Second, J team, Dedicated
Third, S team, Onsite
These are three operating models
C team handles requests that come in through the main channel
02-6363-7900 and support@sub1.co.kr
After the request reaches the service vendor,
the rest is automatically assigned to staff for processing
This model is suitable for clients with simple inquiries,
where most cases can be answered based on common processes and handled by a broad group of staff
The second model is J team, Dedicated
As shown here, requests come in through the team’s main channel
and are automatically assigned to that team for handling
In many cases, clients use their own systems in addition to SERVEONE’s
So a certain level of knowledge is required
to communicate effectively,
and that is why a dedicated team handles these VOCs
The third model is S team, Onsite
Here, requests come in through a channel for each staff member,
and they are fixed to that staff member for processing VOC
This model is used when on-site checks and immediate responses are required
Sometimes people think the dedicated J team
and the onsite S team both operate as one-to-one with clients
But in fact, only the S team assigns one staff member per client
The C and J teams consist of multiple staff,
and each team serves multiple clients
If you want to know how Zendesk is operated by unit,
you can check in the SMRO Manager and Customer Helper Manager menus
To see the operating model,
you can identify it by the Zendesk group name,
C team, J team, and so on
And if you want to request an inquiry task,
you can check each team’s contact number and email address, and send your request there
Now let’s look at the Zendesk handling process
and the actual screen
From here, you’ll often see the word
Ticket
A ticket is simply a request
So a ticket number is a request number,
and the number of tickets means the number of requests
A ticket refers to each individual request
that flows into Zendesk through various channels
And tickets follow the process shown in this diagram
When an inquiry comes in, it is marked N – New
Once a staff member is assigned, it becomes O – Open
If the operations staff is checking it, it is marked H – Holding
If waiting on a related department or a client partner, it is marked P – Pending
When the answer is completed, it is S – Solved,
and after 24 hours it becomes C – Closed
At that point, the ticket is finished
During this process, when a staff member is first assigned
or when a public reply is completed,
a notification email is sent to the customer, as shown in this diagram
This is the actual screen
As you can see, customer requests received from various channels,
phone, email, chat,
are all updated together on one screen
On the left, tickets are grouped by preset conditions:
unsolved tickets, tickets on hold, and closed tickets
On the right, you can see a full list of all tickets
There are six Zendesk channels
API is for incoming phone calls
Email is for requests coming by email
Web form is when operations staff directly create a ticket
or when RPA creates a VOC ticket
Chat comes from chat URLs
or the customer front chatbot’s 1:1 inquiry
Web widget is when a ticket is created outside business hours
or when chat connection is delayed
Closed ticket is when a ticket is already closed
but a request is made or a staff member replies by email
These are the six types of tickets
Looking more closely at the screen and field values,
on the left are the default view items,
and each staff member can also set their own
On the right is the list of request tickets,
showing the unique IP generated with each ticket,
the request channel, reason, and requester
When you click on a specific ticket in the list,
a detailed screen opens like th
At the top left, you can see the requester’s name and the assigned staff information
Second, ticket field values can be entered or edited
Third, you can use the public reply function
to respond by email to the requester or CCs
There is also an internal note function,
which does not go to the requester,
but allows communication among internal staff
On the right, you can view detailed requester information
and the full history of past interactions
In addition, VOC received offline
or through personal contact channels
can still be managed in Zendesk
by creating a new ticket
By entering requester and staff information, ticket fields,
title, content, and task details, a new ticket is generated
There are cases that must be handled with more care and higher priority than general VOC
These are complaints containing customer dissatisfaction
In Zendesk, complaint VOC
is managed through a separate process
As shown here,
tickets with negative keywords in VOC
are automatically detected by AI and flagged as potential complaint tickets
These complaint tickets are prioritized as urgent and handled first
During the resolution process, a team leader confirms the reply before it is sent,
to prevent the issue from escalating
The status of complaints can also be checked in Teams and BI
In Teams, you can track unresolved complaints,
the responsible staff,
and the number of unresolved days
In BI, analysis is available based on completed tickets
You can view complaint status by client,
top divisions and operating units with complaints, and department status
This information is used to identify internal issues and prevent recurrence,
as well as for improvement purposes
As part of VOC management, you can check team performance
and review detailed ticket handling records
That concludes our look at the Zendesk process
and system for VOC management
Now let’s look at the process for exception VOC
that involves physical movement, exchange, after-sales service, return, and cancellation
The overall flow of exception VOC is common, so we will cover that first
and then explain each case in detail
When a customer requests a return, exchange, or A/S through the operations staff,
the staff first confirms with the supplier offline
Once the agreement is complete, the VOC is marked as closed in the system
When it is closed,
depending on delivery type,
the hub or supplier handles the physical movement
Once the physical movement is complete, the VOC is fully closed
Now for the exchange VOC process
For delivered products, an exchange must follow the exchange policy
and be confirmed with the original supplier
If the exchange is approved as “YES,”
closing the VOC triggers an exchange request under the VOC number,
and the supplier or hub carries out the exchange
A separate order is not created
The exchange is carried out under the VOC number,
with the same supplier and delivery type as the original order
This is in the order I mentioned
I recommend reading it throuh
A/S follows the same basic process
For delivered products, the operations staff confirms with the supplier that A/S is possible,
and then proceeds
After the VOC is closed in the system, an A/S request is sent under the VOC number
to the designated supplier hub, depending on the delivery type
Unlike exchanges, A/S may not always be possible with the original supplier
So the request does not have to go to the original supplier
It can be assigned to a supplier designated by
the operations staff
However, note that the delivery type must remain
the same as the original order
It would be good to read the details of direct delivery and no-stock items below
One key difference: exchanges always go through the original supplier,
but because products are often used for a long time before A/S occurs,
it may not
That is why A/S can be assigned to a different supplier
designated by operations staff
The return exception VOC has different characteristics from exchange or A/S
For delivered products, returns also follow the return policy
and must be confirmed with the original supplier,
just like exchanges and A/S
However, after the VOC is closed, a return order number is generated starting with “900”
The return must then proceed under that return order number, with the same supplier
and the same delivery type as the original order
This is in the order of the parts metioned before
Return VOC requires extra checks
There are additional points to check for return VOC
You must pay close attention to the return order status by delivery type
and whether sales settlement is possible
based on the VOC status
For direct delivery, the return order completion time and the VOC closure time are the same
After processing ends, a return order is generated
Once the supplier accepts the return order
and the product is physically returned, the return is complete
and the VOC is closed simultaneously
So, sales settlement is possible at that point in time
But once the product is physically returned to the hub,
the return is complete, the VOC is closed,
and settlement becomes possible at that point
However, for non-stock items, a return order is generated after processing ends,
and the VOC is marked complete when the hub collects the product from the client
At this point, the product has not yet been returned to the supplier,
so sales settlement is not possible
In conclusion, even if the VOC is closed,
sales settlement is only possible
once the return order status shows that the product has been returned to the supplier
Therefore, from the VOC closure until the final completion of the return,
continuous monitoring is required
While return, exchange, and A/S VOC apply to delivered orders,
the cancellation VOC applies to orders that have not yet been confirmed for shipment
For such orders, when a customer requests cancellation,
the operations staff confirms with the supplier and cancels the order
In this case, the VOC is closed automatically without any physical movement
When canceling an order, you must always check the order status
to confirm whether supplier approval and cancellation are possible
After the supplier has already accepted the order, it is likely that processing has begun,
so supplier confirmation is required
In conclusion, order cancellation is possible
when orders before supplier acceptance, and orders after acceptance
where the supplier has confirmed cancellation
However, please note that the cases just mentioned apply only to orders before shipment confirmation
Once the status changes to shipment confirmed, order cancellation is no longer possible,
and it must be processed as a return instead
That concludes our look at exchange, A/S, return, and cancellation VOC
Compared to general VOC, exception VOC
requires prior knowledge of processes,
so it may be confusing
Here are some frequently asked questions
Before that, it would be good to read the SERVEONE return/refund policy,
which is clearly stated here
Yes, here is a list of frequently asked questions about this
Q1. I want to change a product under exchange to a return
This is not possible
Exchange and return have different processes
In the system, changing a product
under exchange to a return based on the physical product
is not possible, because it causes a mismatch between
the physical flow and the system flow
Q2. The client asks if a collected return product can be reused
Is there any way to process this?
Since the product has already been collected, there is no way to reverse it in the system
It must be handled as a new order in agreement with the client
Q3. Due to budget reasons,
the client wants to return a product that was ordered three months ago
For products more than 15 days after receipt,
prior confirmation with the supplier is mandatory
Also note that returns without the physical product must never be processed,
even if requested by the client
Q4. Can I directly specify the delivery type when handling return, exchange, or A/S?
Because the delivery type is automatically determined during order simulation,
the answer is no
Next is the cancellation status for return, exchange, and A/S VOC
As shown in the table,
the cancelability differs depending on the VOC type or the delivery type
Please make sure to understand this when performing your work
That concludes our session on SERVEONE’s VOC management system, Zendesk,
the system processing of exception VOC, and the related physical flows
Thank you very much for your time and effort