1 00:00:13,600 --> 00:00:16,951 Hello, my name is Seunghyun Yoon, and I prepared this lecture on VOC 2 00:00:16,951 --> 00:00:19,963 as part of the SERVEONE MRO process course 3 00:00:20,380 --> 00:00:25,320 In the overall MRO process, today’s focus will be on this VOC section 4 00:00:25,659 --> 00:00:28,459 The goals of this session are as follows: 5 00:00:28,899 --> 00:00:32,739 First, to understand what VOC means at SERVEONE 6 00:00:32,959 --> 00:00:36,319 Second, to learn how SERVEONE manages VOC 7 00:00:36,579 --> 00:00:41,040 Third, to understand the characteristics of exception VOC related to physical flows, 8 00:00:41,041 --> 00:00:46,721 such as exchanges, after-sales service, returns, and cancellations 9 00:00:47,140 --> 00:00:51,379 In addition, in the FAQ, we will briefly cover the questions 10 00:00:51,380 --> 00:00:54,400 most often asked in the field and their answers 11 00:00:55,039 --> 00:00:59,120 First, I am a father of a 3-month-old daughter, 12 00:00:59,120 --> 00:01:01,280 and I am spending very happy days 13 00:01:01,719 --> 00:01:04,601 My hobby is sports, and I especially enjoy badminton 14 00:01:04,601 --> 00:01:09,813 Currently, I am in my 8th year, responsible for managing and planning operations-related systems 15 00:01:10,600 --> 00:01:12,519 This is the VOC overview 16 00:01:12,799 --> 00:01:15,080 What is VOC? 17 00:01:15,500 --> 00:01:17,340 VOC stands for Voice of Customer, 18 00:01:17,564 --> 00:01:18,804 meaning the voice of the customer, 19 00:01:19,069 --> 00:01:22,929 and it refers to all requests and inquiries delivered by customers 20 00:01:23,280 --> 00:01:27,151 Including every customer inquiry within SERVEONE 21 00:01:27,152 --> 00:01:30,112 from questions about using the SERVEONE front before ordering to requests 22 00:01:30,899 --> 00:01:34,319 that occur after delivery during the sales 23 00:01:34,319 --> 00:01:36,020 and settlement process 24 00:01:37,139 --> 00:01:41,639 and SERVEONE manages VOC in two categories 25 00:01:41,779 --> 00:01:44,679 General VOC and exception VOC 26 00:01:45,159 --> 00:01:48,200 General VOC refers to customer inquiries and requests, 27 00:01:48,200 --> 00:01:52,019 while exception VOC refers to VOC that involves the movement of goods, 28 00:01:52,019 --> 00:01:54,560 returns, exchanges, after-sales service, and cancellations 29 00:01:54,560 --> 00:01:56,661 These are four exception VOC 30 00:01:57,500 --> 00:02:03,040 General VOC ends once the inquiry is checked and answered, 31 00:02:03,200 --> 00:02:06,901 but exception VOC requires checking whether the physical movement is completed 32 00:02:06,901 --> 00:02:09,661 because it is linked to sales settlement and cash flow, 33 00:02:09,662 --> 00:02:12,822 so it needs to be reviewed in depth 34 00:02:13,792 --> 00:02:18,259 So later, we will take time to explain each of these in detail 35 00:02:18,659 --> 00:02:23,100 The table below shows the cumulative VOC status 36 00:02:23,101 --> 00:02:25,121 from January to December 2024 37 00:02:25,121 --> 00:02:28,660 It shows what customers most often asked SERVEONE 38 00:02:28,661 --> 00:02:31,372 and what services they requested 39 00:02:32,240 --> 00:02:35,220 As shown here, SERVEONE customers 40 00:02:35,221 --> 00:02:39,441 most frequently asked about delivery dates 41 00:02:39,920 --> 00:02:44,280 Looking at this data, you may wonder how it is managed 42 00:02:44,281 --> 00:02:47,101 and how it was extracted 43 00:02:47,260 --> 00:02:50,140 So now, let’s take a look 44 00:02:50,140 --> 00:02:52,843 at SERVEONE’s VOC management system, Zendesk 45 00:02:53,300 --> 00:02:56,620 For operations staff, Zendesk is familiar, 46 00:02:56,620 --> 00:02:59,420 but for others, it may feel a bit new 47 00:02:59,920 --> 00:03:03,759 Zendesk is a cloud-based customer service software 48 00:03:03,760 --> 00:03:07,000 that integrates and analyzes inquiries 49 00:03:07,000 --> 00:03:10,980 coming in from multiple channels 50 00:03:11,500 --> 00:03:15,380 To explain the present, we need to understand the past 51 00:03:15,540 --> 00:03:19,199 Until 2020, VOC was not in one system 52 00:03:19,199 --> 00:03:21,913 but was managed separately through each channel 53 00:03:22,239 --> 00:03:27,540 For example, if an inquiry came by email to A, A replied and closed it 54 00:03:27,540 --> 00:03:32,280 If a call came to B, B answered and closed it 55 00:03:32,280 --> 00:03:34,740 If a customer left a post on the front, 56 00:03:34,740 --> 00:03:38,359 C checked it in the SMRO VOC menu, 57 00:03:38,964 --> 00:03:40,604 answered, and closed it 58 00:03:40,604 --> 00:03:42,499 It happened like this 59 00:03:42,819 --> 00:03:46,899 This kind of individual handling meant history could not be tracked 60 00:03:46,900 --> 00:03:48,380 When a person missed something 61 00:03:48,380 --> 00:03:52,500 or was absent, the work could not be processed properly 62 00:03:52,740 --> 00:03:57,020 To solve these problems, SERVEONE introduced Zendesk 63 00:03:58,220 --> 00:04:00,779 The process works like this: 64 00:04:01,279 --> 00:04:04,300 requests from phone, email, chatbot, and the front system 65 00:04:04,300 --> 00:04:07,741 are all integrated into Zendesk 66 00:04:08,020 --> 00:04:10,719 Then, based on predefined logic, 67 00:04:10,720 --> 00:04:12,805 they are automatically assigned to the responsible staff 68 00:04:12,805 --> 00:04:16,140 The staff complete the work directly within Zendesk 69 00:04:17,080 --> 00:04:22,079 This allows one-stop processing in a single system, 70 00:04:22,079 --> 00:04:24,640 with data integrated and managed 71 00:04:25,160 --> 00:04:28,379 Tasks are shared in the system, 72 00:04:28,380 --> 00:04:30,729 so collaborative work is possible, 73 00:04:30,729 --> 00:04:32,839 and teams can handle requests together 74 00:04:33,079 --> 00:04:36,119 This prevents work from piling up on a single person 75 00:04:36,120 --> 00:04:39,420 Since assignments are shared in real time, 76 00:04:39,420 --> 00:04:43,320 customer requests receive faster handling and feedback 77 00:04:44,200 --> 00:04:49,319 Even when someone is absent or replaced, other staff can flexibly 78 00:04:49,319 --> 00:04:51,940 continue the work without interruption 79 00:04:52,160 --> 00:04:57,880 Every step from request to completion is tracked in the system, 80 00:04:57,880 --> 00:04:59,839 so nothing is missed 81 00:04:59,840 --> 00:05:04,880 Records can also be checked and used as valuable data for market sensing 82 00:05:05,580 --> 00:05:09,399 Have you understood the management process and the system features? 83 00:05:09,619 --> 00:05:12,940 Now let’s look at how operations actually run 84 00:05:12,940 --> 00:05:17,339 and how the system is structured 85 00:05:17,919 --> 00:05:22,299 Considering the nature of client work, there are three operating models 86 00:05:22,479 --> 00:05:24,980 First, C team, Shared 87 00:05:24,981 --> 00:05:27,202 Second, J team, Dedicated 88 00:05:27,202 --> 00:05:28,903 Third, S team, Onsite 89 00:05:28,903 --> 00:05:32,080 These are three operating models 90 00:05:32,300 --> 00:05:35,840 C team handles requests that come in through the main channel 91 00:05:35,841 --> 00:05:41,861 02-6363-7900 and support@sub1.co.kr 92 00:05:41,861 --> 00:05:44,360 After the request reaches the service vendor, 93 00:05:44,360 --> 00:05:47,259 the rest is automatically assigned to staff for processing 94 00:05:47,839 --> 00:05:51,799 This model is suitable for clients with simple inquiries, 95 00:05:51,799 --> 00:05:56,959 where most cases can be answered based on common processes and handled by a broad group of staff 96 00:05:57,399 --> 00:06:00,040 The second model is J team, Dedicated 97 00:06:00,040 --> 00:06:04,259 As shown here, requests come in through the team’s main channel 98 00:06:04,259 --> 00:06:07,799 and are automatically assigned to that team for handling 99 00:06:08,099 --> 00:06:12,979 In many cases, clients use their own systems in addition to SERVEONE’s 100 00:06:12,979 --> 00:06:15,960 So a certain level of knowledge is required 101 00:06:15,961 --> 00:06:18,190 to communicate effectively, 102 00:06:18,190 --> 00:06:21,360 and that is why a dedicated team handles these VOCs 103 00:06:21,720 --> 00:06:24,420 The third model is S team, Onsite 104 00:06:24,580 --> 00:06:28,539 Here, requests come in through a channel for each staff member, 105 00:06:28,539 --> 00:06:33,180 and they are fixed to that staff member for processing VOC 106 00:06:33,600 --> 00:06:37,559 This model is used when on-site checks and immediate responses are required 107 00:06:37,719 --> 00:06:40,099 Sometimes people think the dedicated J team 108 00:06:40,100 --> 00:06:45,944 and the onsite S team both operate as one-to-one with clients 109 00:06:46,519 --> 00:06:51,200 But in fact, only the S team assigns one staff member per client 110 00:06:51,200 --> 00:06:54,419 The C and J teams consist of multiple staff, 111 00:06:54,419 --> 00:06:58,599 and each team serves multiple clients 112 00:06:59,239 --> 00:07:02,600 If you want to know how Zendesk is operated by unit, 113 00:07:02,600 --> 00:07:08,800 you can check in the SMRO Manager and Customer Helper Manager menus 114 00:07:09,460 --> 00:07:11,340 To see the operating model, 115 00:07:11,340 --> 00:07:14,520 you can identify it by the Zendesk group name, 116 00:07:14,521 --> 00:07:17,756 C team, J team, and so on 117 00:07:17,980 --> 00:07:20,940 And if you want to request an inquiry task, 118 00:07:20,940 --> 00:07:24,679 you can check each team’s contact number and email address, and send your request there 119 00:07:24,959 --> 00:07:27,240 Now let’s look at the Zendesk handling process 120 00:07:27,241 --> 00:07:30,121 and the actual screen 121 00:07:32,360 --> 00:07:35,140 From here, you’ll often see the word 122 00:07:35,140 --> 00:07:37,320 Ticket 123 00:07:37,500 --> 00:07:42,180 A ticket is simply a request 124 00:07:42,400 --> 00:07:45,160 So a ticket number is a request number, 125 00:07:45,160 --> 00:07:49,199 and the number of tickets means the number of requests 126 00:07:49,999 --> 00:07:52,399 A ticket refers to each individual request 127 00:07:52,399 --> 00:07:57,759 that flows into Zendesk through various channels 128 00:07:57,959 --> 00:08:01,039 And tickets follow the process shown in this diagram 129 00:08:01,379 --> 00:08:04,499 When an inquiry comes in, it is marked N – New 130 00:08:04,499 --> 00:08:08,020 Once a staff member is assigned, it becomes O – Open 131 00:08:08,300 --> 00:08:12,759 If the operations staff is checking it, it is marked H – Holding 132 00:08:12,999 --> 00:08:18,799 If waiting on a related department or a client partner, it is marked P – Pending 133 00:08:19,459 --> 00:08:22,159 When the answer is completed, it is S – Solved, 134 00:08:22,379 --> 00:08:26,399 and after 24 hours it becomes C – Closed 135 00:08:26,399 --> 00:08:29,140 At that point, the ticket is finished 136 00:08:29,900 --> 00:08:33,239 During this process, when a staff member is first assigned 137 00:08:33,239 --> 00:08:35,259 or when a public reply is completed, 138 00:08:35,259 --> 00:08:39,300 a notification email is sent to the customer, as shown in this diagram 139 00:08:40,020 --> 00:08:41,659 This is the actual screen 140 00:08:41,659 --> 00:08:46,180 As you can see, customer requests received from various channels, 141 00:08:47,140 --> 00:08:51,199 phone, email, chat, 142 00:08:51,199 --> 00:08:53,390 are all updated together on one screen 143 00:08:53,739 --> 00:08:57,820 On the left, tickets are grouped by preset conditions: 144 00:08:57,820 --> 00:09:01,839 unsolved tickets, tickets on hold, and closed tickets 145 00:09:01,839 --> 00:09:05,339 On the right, you can see a full list of all tickets 146 00:09:05,699 --> 00:09:08,360 There are six Zendesk channels 147 00:09:08,360 --> 00:09:10,160 API is for incoming phone calls 148 00:09:10,277 --> 00:09:12,717 Email is for requests coming by email 149 00:09:12,900 --> 00:09:16,440 Web form is when operations staff directly create a ticket 150 00:09:16,440 --> 00:09:19,939 or when RPA creates a VOC ticket 151 00:09:20,279 --> 00:09:24,740 Chat comes from chat URLs 152 00:09:24,740 --> 00:09:28,139 or the customer front chatbot’s 1:1 inquiry 153 00:09:28,759 --> 00:09:32,400 Web widget is when a ticket is created outside business hours 154 00:09:32,400 --> 00:09:35,160 or when chat connection is delayed 155 00:09:35,660 --> 00:09:39,379 Closed ticket is when a ticket is already closed 156 00:09:39,379 --> 00:09:44,459 but a request is made or a staff member replies by email 157 00:09:44,459 --> 00:09:47,020 These are the six types of tickets 158 00:09:47,380 --> 00:09:50,819 Looking more closely at the screen and field values, 159 00:09:50,819 --> 00:09:54,139 on the left are the default view items, 160 00:09:54,279 --> 00:09:57,960 and each staff member can also set their own 161 00:09:58,320 --> 00:10:01,759 On the right is the list of request tickets, 162 00:10:01,759 --> 00:10:06,280 showing the unique IP generated with each ticket, 163 00:10:06,280 --> 00:10:09,400 the request channel, reason, and requester 164 00:10:09,900 --> 00:10:13,499 When you click on a specific ticket in the list, 165 00:10:13,499 --> 00:10:16,980 a detailed screen opens like th 166 00:10:17,440 --> 00:10:21,539 At the top left, you can see the requester’s name and the assigned staff information 167 00:10:21,719 --> 00:10:25,119 Second, ticket field values can be entered or edited 168 00:10:25,659 --> 00:10:29,140 Third, you can use the public reply function 169 00:10:29,140 --> 00:10:31,360 to respond by email to the requester or CCs 170 00:10:31,580 --> 00:10:34,540 There is also an internal note function, 171 00:10:34,540 --> 00:10:37,180 which does not go to the requester, 172 00:10:37,180 --> 00:10:39,359 but allows communication among internal staff 173 00:10:39,999 --> 00:10:43,200 On the right, you can view detailed requester information 174 00:10:43,200 --> 00:10:46,919 and the full history of past interactions 175 00:10:47,539 --> 00:10:50,719 In addition, VOC received offline 176 00:10:50,719 --> 00:10:53,539 or through personal contact channels 177 00:10:53,539 --> 00:10:56,139 can still be managed in Zendesk 178 00:10:56,139 --> 00:10:58,280 by creating a new ticket 179 00:10:58,820 --> 00:11:02,640 By entering requester and staff information, ticket fields, 180 00:11:03,080 --> 00:11:08,599 title, content, and task details, a new ticket is generated 181 00:11:09,639 --> 00:11:14,900 There are cases that must be handled with more care and higher priority than general VOC 182 00:11:15,180 --> 00:11:18,779 These are complaints containing customer dissatisfaction 183 00:11:19,239 --> 00:11:21,700 In Zendesk, complaint VOC 184 00:11:21,700 --> 00:11:24,780 is managed through a separate process 185 00:11:25,460 --> 00:11:27,539 As shown here, 186 00:11:27,539 --> 00:11:30,739 tickets with negative keywords in VOC 187 00:11:30,739 --> 00:11:35,820 are automatically detected by AI and flagged as potential complaint tickets 188 00:11:36,940 --> 00:11:42,639 These complaint tickets are prioritized as urgent and handled first 189 00:11:42,639 --> 00:11:46,299 During the resolution process, a team leader confirms the reply before it is sent, 190 00:11:46,299 --> 00:11:49,519 to prevent the issue from escalating 191 00:11:50,279 --> 00:11:55,279 The status of complaints can also be checked in Teams and BI 192 00:11:55,459 --> 00:11:58,760 In Teams, you can track unresolved complaints, 193 00:11:58,760 --> 00:12:01,339 the responsible staff, 194 00:12:01,339 --> 00:12:06,840 and the number of unresolved days 195 00:12:07,140 --> 00:12:11,079 In BI, analysis is available based on completed tickets 196 00:12:11,339 --> 00:12:16,320 You can view complaint status by client, 197 00:12:16,320 --> 00:12:20,260 top divisions and operating units with complaints, and department status 198 00:12:20,520 --> 00:12:23,820 This information is used to identify internal issues and prevent recurrence, 199 00:12:23,820 --> 00:12:26,420 as well as for improvement purposes 200 00:12:28,340 --> 00:12:32,339 As part of VOC management, you can check team performance 201 00:12:32,339 --> 00:12:36,740 and review detailed ticket handling records 202 00:12:38,380 --> 00:12:42,080 That concludes our look at the Zendesk process 203 00:12:42,080 --> 00:12:44,100 and system for VOC management 204 00:12:44,500 --> 00:12:47,279 Now let’s look at the process for exception VOC 205 00:12:47,279 --> 00:12:54,020 that involves physical movement, exchange, after-sales service, return, and cancellation 206 00:12:56,040 --> 00:13:01,979 The overall flow of exception VOC is common, so we will cover that first 207 00:13:01,979 --> 00:13:05,459 and then explain each case in detail 208 00:13:05,839 --> 00:13:11,120 When a customer requests a return, exchange, or A/S through the operations staff, 209 00:13:11,120 --> 00:13:15,639 the staff first confirms with the supplier offline 210 00:13:15,639 --> 00:13:20,180 Once the agreement is complete, the VOC is marked as closed in the system 211 00:13:20,900 --> 00:13:23,900 When it is closed, 212 00:13:23,900 --> 00:13:27,260 depending on delivery type, 213 00:13:27,261 --> 00:13:30,720 the hub or supplier handles the physical movement 214 00:13:30,720 --> 00:13:33,720 Once the physical movement is complete, the VOC is fully closed 215 00:13:34,500 --> 00:13:37,020 Now for the exchange VOC process 216 00:13:37,440 --> 00:13:40,679 For delivered products, an exchange must follow the exchange policy 217 00:13:40,679 --> 00:13:44,740 and be confirmed with the original supplier 218 00:13:45,500 --> 00:13:49,039 If the exchange is approved as “YES,” 219 00:13:49,039 --> 00:13:53,879 closing the VOC triggers an exchange request under the VOC number, 220 00:13:53,879 --> 00:13:57,199 and the supplier or hub carries out the exchange 221 00:13:57,719 --> 00:14:00,120 A separate order is not created 222 00:14:00,120 --> 00:14:02,820 The exchange is carried out under the VOC number, 223 00:14:02,820 --> 00:14:08,019 with the same supplier and delivery type as the original order 224 00:14:09,839 --> 00:14:13,840 This is in the order I mentioned 225 00:14:13,840 --> 00:14:16,340 I recommend reading it throuh 226 00:14:17,920 --> 00:14:19,879 A/S follows the same basic process 227 00:14:19,879 --> 00:14:24,139 For delivered products, the operations staff confirms with the supplier that A/S is possible, 228 00:14:24,139 --> 00:14:25,900 and then proceeds 229 00:14:26,540 --> 00:14:30,919 After the VOC is closed in the system, an A/S request is sent under the VOC number 230 00:14:30,919 --> 00:14:34,120 to the designated supplier hub, depending on the delivery type 231 00:14:34,420 --> 00:14:38,460 Unlike exchanges, A/S may not always be possible with the original supplier 232 00:14:38,460 --> 00:14:41,659 So the request does not have to go to the original supplier 233 00:14:41,659 --> 00:14:44,939 It can be assigned to a supplier designated by 234 00:14:44,939 --> 00:14:46,839 the operations staff 235 00:14:47,799 --> 00:14:52,019 However, note that the delivery type must remain 236 00:14:52,019 --> 00:14:53,180 the same as the original order 237 00:14:53,480 --> 00:14:58,760 It would be good to read the details of direct delivery and no-stock items below 238 00:15:00,100 --> 00:15:06,019 One key difference: exchanges always go through the original supplier, 239 00:15:06,879 --> 00:15:11,999 but because products are often used for a long time before A/S occurs, 240 00:15:11,999 --> 00:15:15,399 it may not 241 00:15:15,399 --> 00:15:18,739 That is why A/S can be assigned to a different supplier 242 00:15:18,739 --> 00:15:21,760 designated by operations staff 243 00:15:23,160 --> 00:15:28,099 The return exception VOC has different characteristics from exchange or A/S 244 00:15:28,399 --> 00:15:31,200 For delivered products, returns also follow the return policy 245 00:15:31,200 --> 00:15:33,799 and must be confirmed with the original supplier, 246 00:15:33,799 --> 00:15:36,020 just like exchanges and A/S 247 00:15:36,360 --> 00:15:42,480 However, after the VOC is closed, a return order number is generated starting with “900” 248 00:15:42,480 --> 00:15:47,639 The return must then proceed under that return order number, with the same supplier 249 00:15:47,639 --> 00:15:49,359 and the same delivery type as the original order 250 00:15:49,799 --> 00:15:53,400 This is in the order of the parts metioned before 251 00:15:53,400 --> 00:15:55,659 Return VOC requires extra checks 252 00:15:56,959 --> 00:16:01,080 There are additional points to check for return VOC 253 00:16:01,980 --> 00:16:06,180 You must pay close attention to the return order status by delivery type 254 00:16:06,180 --> 00:16:09,720 and whether sales settlement is possible 255 00:16:09,720 --> 00:16:12,339 based on the VOC status 256 00:16:12,939 --> 00:16:18,060 For direct delivery, the return order completion time and the VOC closure time are the same 257 00:16:18,520 --> 00:16:21,359 After processing ends, a return order is generated 258 00:16:21,359 --> 00:16:24,159 Once the supplier accepts the return order 259 00:16:24,159 --> 00:16:28,440 and the product is physically returned, the return is complete 260 00:16:28,440 --> 00:16:30,959 and the VOC is closed simultaneously 261 00:16:31,419 --> 00:16:34,899 So, sales settlement is possible at that point in time 262 00:16:35,159 --> 00:16:40,539 But once the product is physically returned to the hub, 263 00:16:40,539 --> 00:16:44,680 the return is complete, the VOC is closed, 264 00:16:44,680 --> 00:16:48,140 and settlement becomes possible at that point 265 00:16:48,460 --> 00:16:52,439 However, for non-stock items, a return order is generated after processing ends, 266 00:16:52,439 --> 00:16:56,280 and the VOC is marked complete when the hub collects the product from the client 267 00:16:56,280 --> 00:17:01,280 At this point, the product has not yet been returned to the supplier, 268 00:17:01,280 --> 00:17:04,220 so sales settlement is not possible 269 00:17:04,800 --> 00:17:07,560 In conclusion, even if the VOC is closed, 270 00:17:07,560 --> 00:17:10,399 sales settlement is only possible 271 00:17:10,399 --> 00:17:15,019 once the return order status shows that the product has been returned to the supplier 272 00:17:15,419 --> 00:17:19,239 Therefore, from the VOC closure until the final completion of the return, 273 00:17:19,239 --> 00:17:22,479 continuous monitoring is required 274 00:17:23,119 --> 00:17:29,239 While return, exchange, and A/S VOC apply to delivered orders, 275 00:17:29,239 --> 00:17:34,460 the cancellation VOC applies to orders that have not yet been confirmed for shipment 276 00:17:35,100 --> 00:17:38,940 For such orders, when a customer requests cancellation, 277 00:17:38,940 --> 00:17:45,059 the operations staff confirms with the supplier and cancels the order 278 00:17:45,579 --> 00:17:50,720 In this case, the VOC is closed automatically without any physical movement 279 00:17:51,500 --> 00:17:54,119 When canceling an order, you must always check the order status 280 00:17:54,119 --> 00:17:58,699 to confirm whether supplier approval and cancellation are possible 281 00:17:59,239 --> 00:18:04,800 After the supplier has already accepted the order, it is likely that processing has begun, 282 00:18:04,800 --> 00:18:07,999 so supplier confirmation is required 283 00:18:08,499 --> 00:18:11,539 In conclusion, order cancellation is possible 284 00:18:11,540 --> 00:18:13,500 when orders before supplier acceptance, and orders after acceptance 285 00:18:13,500 --> 00:18:19,420 where the supplier has confirmed cancellation 286 00:18:19,920 --> 00:18:24,819 However, please note that the cases just mentioned apply only to orders before shipment confirmation 287 00:18:24,819 --> 00:18:29,679 Once the status changes to shipment confirmed, order cancellation is no longer possible, 288 00:18:29,679 --> 00:18:33,259 and it must be processed as a return instead 289 00:18:33,619 --> 00:18:39,760 That concludes our look at exchange, A/S, return, and cancellation VOC 290 00:18:40,100 --> 00:18:42,839 Compared to general VOC, exception VOC 291 00:18:42,839 --> 00:18:45,640 requires prior knowledge of processes, 292 00:18:45,641 --> 00:18:48,019 so it may be confusing 293 00:18:48,260 --> 00:18:51,440 Here are some frequently asked questions 294 00:18:52,060 --> 00:18:56,120 Before that, it would be good to read the SERVEONE return/refund policy, 295 00:18:56,120 --> 00:18:58,419 which is clearly stated here 296 00:19:02,700 --> 00:19:07,560 Yes, here is a list of frequently asked questions about this 297 00:19:07,780 --> 00:19:12,439 Q1. I want to change a product under exchange to a return 298 00:19:12,859 --> 00:19:16,680 This is not possible 299 00:19:17,000 --> 00:19:21,439 Exchange and return have different processes 300 00:19:21,559 --> 00:19:24,240 In the system, changing a product 301 00:19:24,241 --> 00:19:26,886 under exchange to a return based on the physical product 302 00:19:26,886 --> 00:19:30,400 is not possible, because it causes a mismatch between 303 00:19:30,400 --> 00:19:31,969 the physical flow and the system flow 304 00:19:32,859 --> 00:19:37,960 Q2. The client asks if a collected return product can be reused 305 00:19:37,960 --> 00:19:40,019 Is there any way to process this? 306 00:19:40,499 --> 00:19:44,980 Since the product has already been collected, there is no way to reverse it in the system 307 00:19:44,980 --> 00:19:48,439 It must be handled as a new order in agreement with the client 308 00:19:50,159 --> 00:19:52,820 Q3. Due to budget reasons, 309 00:19:52,820 --> 00:19:56,291 the client wants to return a product that was ordered three months ago 310 00:19:56,291 --> 00:20:01,280 For products more than 15 days after receipt, 311 00:20:01,281 --> 00:20:04,961 prior confirmation with the supplier is mandatory 312 00:20:05,400 --> 00:20:10,719 Also note that returns without the physical product must never be processed, 313 00:20:10,720 --> 00:20:12,820 even if requested by the client 314 00:20:13,199 --> 00:20:18,880 Q4. Can I directly specify the delivery type when handling return, exchange, or A/S? 315 00:20:19,520 --> 00:20:25,499 Because the delivery type is automatically determined during order simulation, 316 00:20:25,500 --> 00:20:29,240 the answer is no 317 00:20:29,459 --> 00:20:34,679 Next is the cancellation status for return, exchange, and A/S VOC 318 00:20:34,899 --> 00:20:37,500 As shown in the table, 319 00:20:37,501 --> 00:20:43,412 the cancelability differs depending on the VOC type or the delivery type 320 00:20:43,412 --> 00:20:47,620 Please make sure to understand this when performing your work 321 00:20:48,020 --> 00:20:53,280 That concludes our session on SERVEONE’s VOC management system, Zendesk, 322 00:20:53,497 --> 00:20:56,637 the system processing of exception VOC, and the related physical flows 323 00:20:56,780 --> 00:20:59,819 Thank you very much for your time and effort