Customer Services có gì ở trỏng?
Customer Services có gì ở trỏng?
Hế lô anh em. Như đã hứa, hôm nay mình đã quay trở lại và nguy hiểm hơn gấp bội với bài viết nói về nghiệp vụ Customer Service
Anh em đã đồng hành với mình ở nghiệp vụ Sales và Marketing. Hôm nay mình sẽ tiếp tục nói về Customer Service. Mục đích của nó là gì, bao gồm những gì và tổ chức hoạt động ra sao.
1…2…3…zôôôôô!!!
Nội dung [Hide]
- 1. Lý do tồn tại
- 2. Cách thức hoạt động
- 2.1. Yêu cầu support
- 2.2. Tiếp nhận yêu cầu support
- 2.3. Đưa vào hàng chờ
- 2.4. Ngâm cứu
- Knowledge Base Article
- Desk
- 2.5. Giải quyết
- 2.6. Gửi và nhận khảo sát
- 3. Tóm gọn
1. Lý do tồn tại
Ai cũng biết, Customer Service là chăm sóc khách hàng. Nhưng không phải ai cũng hiểu: Customer Service là hoạt động xuyên suốt quá trình bán hàng. Từ lúc mà cái ông đó chưa phải là khách hàng, cho đến lúc ổng đã mua hàng của mình.
Chứ hổng phải Customer Service là hoạt động chỉ để phục vụ những ông nào đã là khách hàng của tui. Ông nào đã mua hàng của tui thì tui mới phục vụ. Còn ông nào chưa mua hàng thì tui hông care là hổng phải. Nó phải xuyên suốt từ đầu tới cuối.
Mục đích của Customer Service chỉ đơn thuần là chăm sóc “khách hàng” tốt hơn. Do đó ở đâu có vấn đề, có thắc mắc của khách hàng thì ở đó phải có hoạt động Customer Service.
Làm khách hàng phê vẫn luôn là ưu tiên số một.
Ví dụ thằng bạn mình nó mới mở shop bán đồ đá banh. Nó lập 1 fanpage và 1 website bán hàng.
Lâu lâu nó hay nhận được mấy câu hỏi trên fanpage đại loại như:
“Áo Chen-si sân khách về chưa shop?”, “Áo Man-Chét-Tơ Du-Nái-Tít màu hồng có size em bé hôn?”
Thằng bạn mình nó mà trả lời những câu hỏi này thì đó gọi là hoạt động Customer Service, giải đáp thắc mắc của bà con cô bác.
Hoặc lâu lâu khách mua giày đá banh về, đá mấy hôm bị súc chỉ, cũng a-lô cho shop nhờ may lại. Thằng bạn mình không những chấp nhận may lại miễn phí, mà còn tặng thêm 1 đôi vớ đá banh nữa. Đó là hoạt động Customer Service quá rõ.
Chỉ khi thằng bạn mình nó chăm sóc khách hàng, nâng niu khách hàng như nâng trứng, thì khách mới nhớ tới shop của nó, để lần sau còn quay lại mua hàng.
…
Tóm lại, mục đích thì anh em đã rõ. Giúp chăm sóc khách hàng tốt hơn >> Khách hàng nhớ tới mình >> Tăng tỉ lệ mua hàng.
Nói về Customer Service thì anh em cứ lấy Thế Giới Di Động ra làm ví dụ là rõ nhất.
Tiếp theo đây mình sẽ chém gió về cách mà 1 hệ thống Customer Service hoạt động, theo như best practice của Microsoft và mapping thực tế với cách mà Thế Giới Di Động đang vận hành.
2. Cách thức hoạt động
Hãy tưởng tượng, một shop bán hoa có 2 bạn chuyên làm về chăm sóc khách hàng (dưới đây mình sẽ gọi là Service Agent nghe cho sang ).
Do ăn nên làm ra nên một ngày shop này nhận tầm 200 cú điện thoại. Nào là điện thoại đặt hoa, rồi hỏi về hoa, rồi nào là khiếu nại hoa giả, hoa thúi.
Chưa kể 2 bạn này còn phải trả lời cả trăm tin nhắn trên fanpage nữa. Nói chung sẽ rất overload cho 2 bạn này khi mỗi người phải trả lời gần cả trăm cuộc điện thoại và cả mấy chục câu hỏi đổ về trong một ngày. Chưa kể mỗi câu hỏi, mỗi cuộc điện thoại là một đề tài khác nhau nữa.
Do đó phải có best practice để giải quyết vấn đề này. Best practice đó được thể hiện theo hình sau.
Hình này đơn giản nên chắc anh em nhìn cũng dễ hiểu. Quy trình cơ bản của Customer Service gồm một vài bước nhẹ nhàng sau.
2.1. Yêu cầu support
Khách hàng có thể raise yêu cầu support qua nhiều kênh. Từ digital như website thương mại điện tử. Cho đến các mạng xã hội như Facebook, Instagram, Zalo. Hoặc raise trực tiếp tại cửa hàng.
Ví dụ thằng bạn mình mới mua con iPhone, mà không rõ cái gì thì nó gọi điện trực tiếp cho Thế Giới Di Động nhờ hỗ trợ. Hoặc nó lên thẳng website Thế Giới Di Động tự tìm hướng dẫn.
Hoặc ví dụ anh em đi mua hàng ở Thế Giới Di Động. Mới chân ướt chân ráo bước vô cửa, đã thấy có ngay nhân viên cười tươi rói bu lại hỏi: “Anh chị có cần em hỗ trợ gì không ạ?”
Đó cũng được xem như anh em đã raise yêu cầu hỗ trợ. Do mới bước vào cửa, mặt còn ú ớ chả biết đi đường nào thì Thế Giới Di Động họ nhận ra ngay và support kịp thời. Đó là chính sách phục vụ tận răng của họ.
Do đó khách hàng có thể raise yêu cầu support qua nhiều kênh. Có một số thông tin đáng chú ý về các kênh mà mình lụm lặt được như sau .
Hình chôm từ Microsoft, theo báo cáo của Forrester vào tháng 3/2013.
Rõ ràng, đa phần khách hàng thích gọi điện hơn. Vừa nhanh, vừa gọn, vừa lẹ. Tuy nhiên không cần thiết phải làm nguyên một hệ thống Call Center chi cho hoành tráng. Đối với các shop nhỏ lẻ chỉ cần để số Hotline kèm logo Skype hoặc Zalo vô là êm rồi :3
*Note: Online Self Service là khách hàng tự giải quyết problem của họ, bằng cách tự search giải pháp trên website của đơn vị bán hàng, rồi sau đó tự khắc phục. Đây là xu thế trong tương lai nhé anh em
2.2. Tiếp nhận yêu cầu support
Sau khi khách hàng raise yêu cầu xong, Thế Giới Di Động sẽ nhận diện, lắng nghe và tiếp nhận các yêu cầu này.
Yêu cầu support được raise từ nhiều kênh, nhiều nơi. Nhưng các yêu cầu này phải được tập trung về 1 nơi duy nhất để quản lý và đánh giá.
“Nơi này” có thể là một cuốn sổ tay tổng hợp các yêu cầu. Hoặc các file excel phân chia theo kênh. Nhưng tối ưu nhất, nó sẽ được lưu vào các hệ thống như CRM, E-commerce. Để sau này còn lấy dữ liệu đó ra làm những chuyện “kinh thiên động địa” khác, kaka.
2.3. Đưa vào hàng chờ
Sau khi các yêu cầu support được đưa vào 1 chỗ, tiếp đến nó sẽ được xếp vào… các hàng chờ. Tại sao lại như vậy?
Vì cùng một lúc có cả hàng chục, hàng trăm yêu cầu gửi đến. Nào là gửi đến từ phone, từ email, từ fanpage, từ website. Chưa kể mỗi yêu cầu gửi đến là một lĩnh vực khác nhau. Có ông thì hỏi về điện thoại Asus, có ông hỏi về iPhone, có ông lại hỏi về chính sách đối trả. Nói chung là tùm lum tùm la hết.
Do đó các yêu cầu này (dưới đây mình sẽ gọi là case) cần phải được sắp xếp và tổ chức hợp lý.
Case nào từ phone thì đưa vào hàng chờ của phone. Case nào từ email thì đưa vào hàng chờ email. Case nào hỏi về chính sách đối trả thì đưa vào hàng chờ chính sách. Case nào liên quan tới sản phẩm thì đưa vào hàng chờ của bộ phận kỹ thuật. Vâng vâng và mây mây.
Đúng người đúng việc thì mới hiệu quả được.
Ví dụ các Queues được tạo ra trên hệ thống
Một điểm nữa là các bước nãy giờ đều phải được làm tự động. Tức là từ việc thu thập các Case từ email, phone, fanpage hay website đều phải để hệ thống chạy tự động và tập trung data về 1 chỗ. Chứ đâu ai rảnh mà ngồi copy từng cái rồi dán vào excel, hay tạo thủ công trên hệ thống đúng không.
Để chạy được tự động thì cần phải có trigger. Tức là điều kiện chạy, khi nào thì tạo. Để hệ thống hiểu thì nó mới chạy theo ý mình được.
Ví dụ lúc anh em vào TGDĐ mua đồ. Hành động thò chân vào cửa chính là trigger để nhân viên ở đó biết mà bay lại phục vụ. Có ai đã từng mua hàng ở TGDĐ mà khi bước vào cửa hàng không được ai hỏi thăm chưa? Never. Vì những cái này đã được training kỹ càng cho nhân viên thành một cái gì đó quán tính, tự động luôn rồi.
Hoặc khi có một email gửi về hộp thư cskh@thegioididong.com mà trong nội dung email có bao gồm chữ “hỗ trợ” hoặc “giúp tui zới” thì ngay lập tức, hệ thống sẽ tự động tạo ngay một case.
Có thêm keyword “iPhone” thì đưa case đó vào hàng queue của đội kỹ thuật iOS. Có keyword “Samsung” thì đưa vào hàng queue của đội Android. Ví dụ zậy.
Mỗi Service Agent đều đã được phân công vào các Queue trước đó. Ai phụ trách lĩnh vực gì thì phải được phân chia rõ ràng. Khi các Cases đã được route tự động vô các Queues rồi, thì nhiệm vụ của các bạn Service Agent là chỉ việc chui vào trong Queue của mình, bốc từng Case ra giải quyết thôi.
2.4. Ngâm cứu
Và tất nhiên, phải có cái gì đó hỗ trợ anh em Service Agent giải quyết vấn đề. Chứ không thể khơi khơi mà để con người ta tự thân vận động vậy được :3 Có hai thứ sẽ giúp Service Agent giải quyết vấn đề hiệu quả hơn.
Một là Knowledge Base Article. Hai là một cái Desk.
Knowledge Base Article
Knowledge Base Article nôm na là những kho tàng kiến thức, được tổng hợp lại theo từng chủ đề. Mà các Service Agent dựa vào đó để giải quyết vấn đề nhanh hơn và chính xác hơn.
Những Knowledge Article này được lưu trữ trên các hệ thống CRM, hoặc các hệ thống khác (mà mình hông biết).
Khi bạn Service Agent mở một Case ra để giải quyết, hoặc nhận một cuộc điện thoại từ khách hàng. Bạn này sẽ đọc hoặc lắng nghe khách hàng mô tả vấn đề.
Nếu biết cách giải quyết thì quất luôn, giải quyết luôn tại chỗ. Còn nếu không biết thì bạn đó chỉ cần search một vài từ khóa liên quan đến vấn đề của khách hàng. Hệ thống sẽ trả ra các Knowledge Article có liên quan. Bạn này chỉ việc dựa vào Knowledge Article này để trả lời khách hàng thôi.
Desk
Yep, desk chính là cái bàn. Anh em có thể hiểu nôm na vậy cho dễ hình dung. Tại sao lại cần có cái bàn. Nó xuất phát từ thực tế sau.
Ví dụ có một khách hàng gọi điện tới TGDĐ. Service Agent nhấc máy. Ông khách trả lời:
“À lố. Tui nè. Nhớ tui hôn. Nhớ à. Nãy tui mua hàng nè? Sao tui mới mua cái ốp lưng gắn zô mà giờ điện thoại không chụp hình được zậy cà?”
Bạn Service Agent khẽ bối rối trong vài giây, nhưng sau đó kịp lấy lại bình tĩnh, cô trả lời lại ông khách:
“Dạ xin lỗi, em có thể xin tên của anh được không ạ. Sau khi anh nói tên anh xong, thì em phải hỏi tiếp ngày tháng năm sinh, chứng minh nhân dân, mã khách hàng, số đo 3 vòng, à nhầm, số điện thoại của anh để xác thực. Cụ thể là em phải dò hết các thông tin này trên hệ thống, để xem thử thực sự anh có tồn tại không. Nếu không tồn tại thì anh là khách hàng mới. Mà là khách hàng mới thì em có kiểu chăm sóc khác. Còn nếu anh là khách hàng cũ thì em phải mò… thông tin của anh xem thử anh có phải khách hàng VIP không. Nếu mà anh là khách hàng VIP thì em còn chăm sóc đặc biệt hơn nữa. Chứ còn nếu là kh…”
Ông khách: “tút, tút, tút…”
Anh em hiểu vấn đề chưa
Việc trong tích tắc khi nhận một cuộc gọi, một email, một tin nhắn từ khách hàng mà biết ngay ông khách đó là ai, khách hàng loại gì, mua hàng mấy lần, abc, xyz… là một trong những nhu cầu vô cùng thiết thực đối với Service Agent. Nhưng để làm được điều này thì giải pháp là… khá phức tạp.
Cụ thể, anh em cần có 1 cái desk, tức là một cái bàn đủ rộng, để có thể chứa đầy đủ hồ sơ thông tin của bất kỳ người khách nào cần support.
Không phải cái bàn này, mà là cái bàn ở dưới
Cái desk này có thể là một desktop application, web application hoặc thậm chí là một mobile application. Mà nó có khả năng tập trung data khách hàng từ bất kỳ hệ thống nào và show lên cái desk này. Từ thông tin khách hàng, đơn hàng, lịch sử mua hàng, lịch sử chăm sóc khách hàng, abc, xyz…
Khi một khách hàng gọi đến tổng đài. Hệ thống sẽ bắt được số điện thoại gọi đến là số nào. Sau đó tự động quét trên hệ thống để dò được ai là người gọi đến. Cuối cùng là show ra màn hình cho Service Agent làm nốt phần việc còn lại.
Lúc đó, Service Agent chỉ việc nhẹ nhàng bắt máy lên và dõng dạc nói: “Hế lôôôôô, có phải là anh Tủn bên công ty phân bón 3 con dê hôn, bất ngờ chưa “.
Điều này tương tự với Email, Profile Facebook, Instagram, LinkedIn, vâng vâng. Hệ thống sẽ dựa vào những thông tin này và tự động tra được “người ấy” là ai.
Do đó, Service Agent chỉ cần 1-2 cú click chuột là đã có ngay thông tin mình cần. Mà không phải switch qua bất kỳ một ứng dụng nào khác, một tab khác. Hay tệ hơn là phải… hỏi ngược lại xin thông tin từ khách hàng.
2.5. Giải quyết
Sau khi đã có đầy đủ đạo cụ trong tay, Service Agent sẽ tiến hành giải quyết các Case, và nhận phản hồi từ phía khách hàng. KPI của Service Agent thường sẽ được tính theo SLA (Service Level Agreement – mức độ cam kết chất lượng dịch vụ).
Ví dụ anh Trung là khách hàng VIP, thì Service Agent phải đảm bảo giải quyết vấn đề cho ảnh trong vòng tối đa 5 nốt nhạc. Sang nốt nhạc thứ 6 là thấy hổng zui rồi.
Còn anh Hải là khách bình thường, thì các vấn đề của ảnh cũng giải quyết ở mức thời gian bình thường, không vội vã, cũng không lâu la.
SLA thường được đo theo 2 tiêu chí:
- Thời gian phản hồi (First Response By)
- Thời gian giải quyết vấn đề (Resolve By)
Ví dụ anh Trung là khách hàng xịn, thì từ lúc ảnh gửi yêu cầu đến khi ảnh nhận được phản hồi từ phía nhân viên công ty thì chỉ cho phép tối đa trong vòng 30 phút thôi. Sau đó vấn đề của ảnh phải được giải quyết ngay trong vòng 24 giờ đồng hồ.
Ví dụ SLA của Jira.
Phải có SLA thì anh em mới đo lường được hiệu quả công việc của các bạn Service Agent. Ai làm việc hiệu quả, năng suất cao, mức độ hài lòng khách hàng cao. SLA sẽ giúp đưa ra nhưng con số không biết nói dối :3
2.6. Gửi và nhận khảo sát
Phần này cũng không có gì nhiều để chém gió với anh em. Đơn thuần chỉ là hệ thống tự động gửi một bảng khảo sát cho khách hàng qua email. Khách hàng làm khảo sát trong vòng 5 giây và nhấn submit. Hệ thống nhận kết quả và tính KPI cho các bạn Service Agent.
Tuy nhiên, cái hay ở đây là xây dựng bảo khảo sát sao cho phù hợp và hiệu quả. Đó là cả một nghệ thuật sắp xếp câu chữ, dẫn dắt ý đồ dựa trên hàng loạt các câu hỏi vô cùng nguy hiểm
Túm cái váy lại, một hệ thống Customer Service sẽ hoạt động theo cơ chế sau.
- Số 1, 2, 3 được thực hiện hoàn toàn tự động
- Màn hình bự chảng bên phải là ví dụ cho một cái Desk.
Hình chôm từ Microsoft
3. Tóm gọn
Nói dong dài nãy giờ vậy thôi chứ thực ra cách hoạt động của một hệ thống Customer Service cũng khá đơn giản.
Việc tích hợp với Call Center và các nền tảng Social Network khác sao cho hệ thống chạy êm mới khó. Chứ quy trình cơ bản nhìn chung cũng không có gì quá phức tạp, chỉ gồm 6 bước cơ bản sau:
Khách hàng gửi yêu cầu support >> Công ty nhận yêu cầu support >> Đưa vào hàng chờ >> Service Agent ngâm cứu >> Service Agent giải quyết vấn đề >> Gửi và nhận khảo sát đánh giá chất lượng.
Xuyên suốt quá trình này sẽ có 1 vài đối tượng quan trọng trong hệ thống Customer Service:
- Case: các yêu cầu support được raised từ nhiều nguồn khác nhau.
- Queue: các hàng chờ được sắp xếp theo nhiều tiêu chí.
- Knowledge Base Article: kho tàng tri thức để Service Agent giải quyết vấn đề.
- Desk: một cái “bàn đủ rộng” để có thể chứa được toàn bộ data liên quan tới khách hàng.
- SLA: mức độ cam kết chất lượng dịch vụ với khách hàng.
- Survey: khảo sát đánh giá chất lượng phục vụ.
That’s it! Cơ bản là vậy thôi. Hẹn gặp anh em ở những bài sau nhé. Có gì thắc mắc hay cần trao đổi anh em cứ quăng cho mình cái comment ở dưới nhé. Bái baiiiii!
Nguồn: thinhnotes.com