Cuộc hội thoại khách hàng là gì? Hiểu đúng Conversation trong hệ thống CSKH

Cuộc hội thoại khách hàng là gì?

Cuộc hội thoại khách hàng (Customer Conversation) là tập hợp các Message và ngữ cảnh liên quan giữa khách hàng với doanh nghiệp, được hệ thống quản lý như một đơn vị tương tác hoặc đơn vị công việc có thể theo dõi xuyên suốt quá trình xử lý.

Để hiểu rõ khái niệm này, hãy xem xét một cuộc trao đổi đơn giản giữa khách hàng và nhân viên tư vấn của cửa hàng.

Customer: “Shop còn size M không?”

Agent: “Dạ bên em còn ạ.”

Customer: “Màu đen thì sao?”

Agent: “Dạ màu đen vẫn còn size M.”

Mặc dù cuộc trao đổi gồm bốn Message, doanh nghiệp không nên xem đây là bốn công việc độc lập. Các Message đều thuộc cùng một nhu cầu tư vấn sản phẩm và có thể được hệ thống tập hợp trong một Conversation.

Conversation không chỉ chứa Message

Ngoài nội dung trao đổi, một Conversation còn có thể được gắn với những thuộc tính phục vụ quá trình quản lý và xử lý công việc.

Ví dụ, Conversation #1024 có những thông tin sau:

Những thuộc tính này giúp doanh nghiệp xác định Conversation thuộc về khách hàng nào, xuất phát từ Channel nào, đang ở trạng thái gì và ai chịu trách nhiệm xử lý.

Nhờ đó, Conversation không chỉ lưu trữ lịch sử giao tiếp mà còn trở thành một đối tượng có thể được phân công, theo dõi và quản lý trong quy trình vận hành.

Phân biệt Message và Conversation

Hai khái niệm này có vai trò khác nhau:

• Message là một đơn vị giao tiếp, chẳng hạn một tin nhắn do khách hàng hoặc Agent gửi.
• Conversation là đối tượng tập hợp các Message và mang những thuộc tính, trạng thái vận hành của quá trình trao đổi đó.

Sự khác biệt này là nền tảng để hiểu những khái niệm liên quan trong hệ thống nhắn tin đa kênh, bao gồm Unified Inbox, Conversation Status, Pending, Unassigned, Assignment, SLA, Handoff và Resolution.

Tại sao cần khái niệm Conversation?

Nếu doanh nghiệp chỉ quản lý từng Message, hệ thống chủ yếu giúp nhân viên trả lời câu hỏi: “Có tin nhắn nào mới?”

Tuy nhiên, trong hoạt động Sales và CSKH, việc biết một tin nhắn đã được đọc hay chưa là chưa đủ. Doanh nghiệp còn cần xác định:

• Conversation này đã được xử lý chưa?
• Ai đang phụ trách?
• Khách hàng đang chờ điều gì?
• Case có còn cần hành động không?
• Conversation đã được bàn giao cho ai?
• Khách hàng đã trao đổi những gì trước đó?

Những thông tin này không nằm ở bản thân một Message riêng lẻ mà thuộc về Conversation Context — ngữ cảnh của toàn bộ quá trình trao đổi và xử lý yêu cầu.

Ví dụ: Message đã đọc nhưng Conversation chưa hoàn tất

Giả sử khách hàng gửi tin nhắn:

Customer: “Bạn kiểm tra giúp mình đơn #1024.”

Agent đọc tin nhắn và liên hệ bộ phận kho để kiểm tra tình trạng đơn hàng.

Lúc này, Message có thể mang trạng thái:

Read = Yes

Tuy nhiên, Conversation vẫn đang chờ thông tin từ bộ phận kho:

Nếu doanh nghiệp chỉ quản lý bằng Read / Unread, tin nhắn đã đọc có thể không còn tạo thông báo mới, trong khi yêu cầu của khách hàng vẫn chưa được giải quyết.

Ngược lại, khi quản lý theo Conversation, hệ thống có thể duy trì trạng thái Pending và thông tin Owner để Agent tiếp tục theo dõi, Follow-up khi có kết quả từ bộ phận kho.

Đây là một trong những lý do Conversation trở thành đối tượng quan trọng trong hệ thống CSKH: giúp doanh nghiệp quản lý công việc cần hoàn thành, thay vì chỉ quản lý những tin nhắn đã nhận.

Message là gì?

Message là một đơn vị nội dung được gửi từ một bên sang bên khác trong quá trình giao tiếp.

Ví dụ, câu hỏi “Shop còn hàng không?” do khách hàng gửi là một Message.

Một Message thường có những Attribute như Sender, Receiver, Content, Timestamp, Channel, Attachment và Direction.

Ví dụ mô tả Message theo mô hình EAV

Entity–Attribute–Value (EAV) là cách biểu diễn một đối tượng thông qua những thuộc tính và giá trị tương ứng.

Các Attribute giúp hệ thống ghi nhận ai đã gửi tin nhắn, gửi qua Channel nào, vào thời điểm nào và nội dung được gửi là gì.

Tuy nhiên, những dữ liệu này chưa đủ để xác định toàn bộ yêu cầu của khách hàng đang được xử lý đến đâu.

Có thể phân biệt ngắn gọn:

Message mô tả: Điều gì đã được gửi?

Conversation mô tả: Quá trình trao đổi này đang diễn ra như thế nào?

Conversation khác Message như thế nào?

Message và Conversation có mối quan hệ chặt chẽ nhưng không phải cùng một đối tượng dữ liệu.

Message là đơn vị giao tiếp riêng lẻ. Conversation tập hợp những Message liên quan và có thể mang thêm những thuộc tính phục vụ việc quản lý toàn bộ quá trình tương tác.

Sự khác biệt quan trọng nằm ở phạm vi quản lý.

Một Message cho biết nội dung cụ thể đã được gửi hoặc nhận. Trong khi đó, Conversation cho biết toàn bộ quá trình tương tác đang được doanh nghiệp theo dõi và xử lý như thế nào.

MESSAGE = WHAT WAS SAID

CONVERSATION = WHAT INTERACTION IS BEING MANAGED

Một Conversation thường gồm những gì?

Không phải mọi nền tảng đều sử dụng cùng một Data Model. Tuy nhiên, trong hệ thống quản lý hội thoại, Conversation thường có thể liên kết với những thành phần và thuộc tính sau:

Tùy theo Operating Model và khả năng của từng nền tảng, Conversation có thể được mở rộng với những thành phần bổ sung như SLA, Internal Notes, Order Context, Service Context, Custom Fields và Automation Events.

Những thành phần này giúp Conversation trở thành một đối tượng có thể quản lý xuyên suốt quá trình tương tác, từ lúc khách hàng gửi Message đầu tiên đến khi yêu cầu được giải quyết.

EAV của một Conversation

Theo mô hình Entity–Attribute–Value (EAV), một Conversation có thể được biểu diễn thông qua các thuộc tính và giá trị tương ứng.

Ví dụ, Conversation #1024 có những thông tin sau:

Điểm quan trọng là Conversation không chỉ là một đoạn văn bản chứa nội dung trao đổi. Nó là một Entity có Attributes, cho phép hệ thống lưu trữ, truy vấn và quản lý thông tin vận hành.

Chẳng hạn, hệ thống có thể tìm kiếm tất cả Conversation đang chờ xử lý:

WHERE Status = Pending

Hoặc tìm những Conversation do một Agent phụ trách:

WHERE Assignee = Agent An

Doanh nghiệp cũng có thể kết hợp nhiều điều kiện để xác định những Conversation cần được ưu tiên:

WHERE Tag = Complaint AND Priority = High

Khả năng truy vấn theo Attribute là nền tảng để xây dựng Queue, Search, Filter, Assignment và Analytics trong hệ thống CSKH.

Conversation là “đơn vị vận hành” nghĩa là gì?

Khi nói Conversation là đơn vị vận hành, ý chính là doanh nghiệp tổ chức công việc xoay quanh toàn bộ quá trình tương tác với khách hàng, thay vì chỉ quản lý từng Message riêng lẻ.

Ví dụ, một Conversation có thể trải qua quy trình:

Conversation #1024 → New → Assign Agent A → In Progress → Pending → Continue → Resolved

Trong quy trình này, công việc của Agent không chỉ dừng ở hai thao tác Read → Reply.

Agent còn cần hiểu ngữ cảnh, xác định trách nhiệm xử lý, cập nhật trạng thái, theo dõi những việc chưa hoàn thành và xác nhận khi yêu cầu đã được giải quyết.

Read → Understand Context → Assign / Own → Reply → Update State → Follow-up → Resolve

Nhờ vậy, Conversation có thể trở thành đơn vị để doanh nghiệp thực hiện việc phân công, quản lý trạng thái, xác định mức độ ưu tiên, theo dõi SLA, bàn giao công việc, tìm kiếm và đo lường hiệu suất.

Ví dụ: Conversation hỏi sản phẩm

Giả sử khách hàng gửi tin nhắn:

Customer: “Shop còn size M không?”

Hệ thống tạo Conversation với thông tin ban đầu:

Khi Agent An tiếp nhận, hệ thống cập nhật Assignee thành An và Status thành In Progress.

Trong quá trình tư vấn, Agent cần kiểm tra tồn kho. Conversation được chuyển sang Pending để thể hiện rằng yêu cầu chưa hoàn tất và đang chờ thông tin.

Khi có kết quả kiểm tra, Agent chuyển Conversation trở lại In Progress, trả lời khách hàng và cuối cùng cập nhật Status thành Resolved.

New → In Progress → Pending → In Progress → Resolved

Như vậy, ngay cả một câu hỏi đơn giản cũng có thể tạo ra một Lifecycle vượt ra ngoài nội dung của Message ban đầu.

Ví dụ: Conversation khiếu nại

Giả sử khách hàng gửi tin nhắn:

Customer: “Tôi đã thanh toán nhưng đơn vẫn báo chưa thanh toán.”

Conversation có thể mang những thông tin sau:

Nếu Agent cần liên hệ bộ phận Finance để xác minh giao dịch, Conversation có thể được cập nhật:

Status = Pending

Reason = Waiting Internal Confirmation

Sau khi có kết quả xác minh, Conversation được chuyển trở lại In Progress. Agent tiếp tục xử lý, trả lời khách hàng và cập nhật Status thành Resolved khi yêu cầu đã hoàn tất.

Trong trường hợp này, Conversation liên kết nhiều thành phần:

Message + Customer + Order Context + Ownership + Status + Priority

Các thành phần này giúp doanh nghiệp theo dõi cả nội dung khiếu nại lẫn quá trình xử lý. Đó là lý do hệ thống không nên coi Conversation đơn thuần là một Chat Bubble.

Một Customer có thể có nhiều Conversation không?

Có. Một Customer có thể liên kết với nhiều Conversation khác nhau.

Ví dụ, khách hàng Nguyễn A có ba Conversation:

Điều này cho thấy Customer và Conversation là hai đối tượng khác nhau.

Customer đại diện cho một người hoặc hồ sơ khách hàng.

Conversation đại diện cho một đơn vị tương tác cụ thể giữa khách hàng và doanh nghiệp.

Quan hệ thường gặp là:

ONE CUSTOMER → MANY CONVERSATIONS

Việc phân biệt hai đối tượng giúp hệ thống duy trì Customer History mà không buộc mọi nhu cầu hoặc mọi lần liên hệ của khách hàng phải nằm trong cùng một Conversation.

Một Conversation có bắt buộc phải biết Customer là ai không?

Không phải lúc nào hệ thống cũng xác định được danh tính khách hàng ngay khi Conversation bắt đầu.

Ví dụ, một khách truy cập Website Chat nhưng chưa cung cấp thông tin cá nhân.

Ban đầu, hệ thống có thể ghi nhận:

Anonymous Visitor #A102 → Conversation #204

Trong quá trình trao đổi, khách hàng có thể cung cấp thêm Phone, Email hoặc Name. Khi có đủ thông tin phù hợp, hệ thống mới liên kết Conversation với Customer Profile tương ứng.

Vì vậy, cần phân biệt hai khái niệm:

• Conversation Identity: Định danh của Conversation, giúp hệ thống theo dõi quá trình tương tác.
• Resolved Customer Identity: Danh tính khách hàng đã được xác định và liên kết với Customer Profile phù hợp.

Không nên tự động Merge các Customer Profile khi chưa có tín hiệu định danh đủ tin cậy, vì việc gộp sai có thể khiến lịch sử tương tác hoặc dữ liệu của những khách hàng khác nhau bị liên kết không chính xác.

Một Conversation có thể có nhiều Channel không?

Điều này phụ thuộc vào Data Model và Architecture của từng hệ thống.

Một số nền tảng quản lý Conversation theo từng Channel. Theo mô hình này, Facebook Conversation và Zalo Conversation là hai Conversation riêng biệt nhưng cùng liên kết với một Customer.

Ví dụ:

Customer → Conversation A (Facebook)

Customer → Conversation B (Zalo)

Một Architecture khác có thể xây dựng Interaction Model rộng hơn để liên kết những tương tác trên nhiều Channel.

Vì vậy, không nên mặc định rằng Omnichannel có nghĩa là tất cả Message từ mọi Channel phải được gộp vào một Conversation duy nhất.

Mục tiêu quan trọng hơn là Customer Context Continuity — duy trì ngữ cảnh khách hàng giữa những Conversation có liên quan, giúp Agent hiểu được lịch sử tương tác ngay cả khi khách hàng chuyển Channel.

Conversation Boundary là gì?

Conversation Boundary là quy tắc xác định Message nào thuộc cùng một Conversation và khi nào hệ thống nên tạo một Conversation mới.

Ví dụ, khách hàng liên hệ với doanh nghiệp ở những thời điểm khác nhau:

Không có một Boundary Rule duy nhất phù hợp với mọi doanh nghiệp. Cách xác định Conversation Boundary có thể phụ thuộc vào Channel, thời gian, Lifecycle, Customer Intent, Business Case và Platform Architecture.

Ở phạm vi bài C02-001, điều quan trọng là hiểu Conversation Boundary quyết định cách các Message được nhóm thành những đơn vị tương tác có thể quản lý.

Các quy tắc Lifecycle cụ thể sẽ được phân tích sâu hơn trong bài C02-004 — Vòng đời một cuộc hội thoại khách hàng.

Conversation khác Thread như thế nào?

Thread thường là một chuỗi Message được hệ thống hoặc Platform nhóm lại với nhau.

Ví dụ, một Thread có thể chứa Message A, Message B và Message C thuộc cùng một chuỗi trao đổi.

Trong hệ thống phục vụ vận hành, Conversation có thể sử dụng Thread đó làm nền tảng nhưng bổ sung những thuộc tính quản lý như Status, Assignee, Priority, Customer Context và SLA.

Tuy nhiên, tùy từng sản phẩm, Thread và Conversation có thể được sử dụng gần như đồng nghĩa. Vì vậy, khi đánh giá phần mềm, điều quan trọng không phải là tên gọi mà là đối tượng đó có quản lý được Lifecycle và Ownership mà doanh nghiệp cần hay không.

Conversation khác Ticket như thế nào?

Conversation và Ticket có những chức năng giao nhau nhưng không hoàn toàn đồng nghĩa.

Một mô hình vận hành có thể bắt đầu từ Customer Conversation. Khi hệ thống hoặc Agent phát hiện một Support Issue cần quy trình xử lý riêng, Conversation có thể dẫn đến việc tạo Ticket.

Một số nền tảng lại sử dụng chính Conversation như một đối tượng có chức năng tương tự Ticket, với các thuộc tính Status, Priority, Assignee và SLA.

Vì vậy, cần phân biệt:

CONVERSATION ≠ ALWAYS A TICKET

TICKET ≠ ALWAYS A CONVERSATION

Ví dụ: Conversation không cần Ticket

Khách hàng hỏi:

“Shop mở cửa đến mấy giờ?”

Agent trả lời câu hỏi và cập nhật Conversation thành Resolved. Trường hợp này không nhất thiết phải tạo một Support Ticket riêng, chẳng hạn Ticket #5021.

Ví dụ: Conversation có thể tạo Ticket hoặc Case

Khách hàng phản ánh:

“Tôi đã thanh toán nhưng hệ thống trừ tiền hai lần.”

Yêu cầu này có thể cần Escalation và Payment Investigation trước khi được giải quyết.

Trong mô hình này, Conversation tiếp tục đóng vai trò là lớp Customer Communication. Ticket hoặc Case là đối tượng phục vụ một quy trình xử lý vấn đề riêng, có thể liên quan đến các bộ phận khác trong doanh nghiệp.

Conversation khác Live Chat Session như thế nào?

Một Live Chat Session thường gắn với khoảng thời gian kết nối hoặc một phiên tương tác trên Live Chat.

Ví dụ:

Khi khách rời Website, Session có thể kết thúc. Tuy nhiên, Customer Conversation về cùng vấn đề vẫn có thể được tiếp tục sau đó, tùy theo Architecture của hệ thống.

Live Chat Session thường là một Technical Session hoặc Interaction Session, trong khi Conversation có thể là đối tượng vận hành với phạm vi rộng hơn.

Vì vậy, hai khái niệm này không nên tự động được xem là một.

Conversation History là gì?

Conversation History là lịch sử các Message và sự kiện liên quan đến một Conversation.

Tùy theo hệ thống, lịch sử này có thể bao gồm Messages, Status Changes, Assignment Changes, Tags, Internal Notes, Automation Events và Resolution.

Ví dụ, Conversation có thể ghi nhận các sự kiện sau:

Conversation History giúp Agent và Team hiểu Conversation đã trải qua những bước nào, ai từng phụ trách, những phản hồi nào đã được gửi và yêu cầu đã được giải quyết hay chưa.

Conversation History khác Customer History

Đây là hai phạm vi lịch sử cần được phân biệt khi xây dựng hoặc đánh giá hệ thống CSKH.

Conversation History là lịch sử các Message và sự kiện nằm trong một Conversation cụ thể.

Ví dụ, Conversation #1024 có thể chứa Message 1, Message 2, một Assignment Change và sự kiện Resolved.

Customer History có phạm vi rộng hơn, bao gồm nhiều lần tương tác và những dữ liệu liên quan đến cùng một khách hàng.

Ví dụ, Customer Nguyễn A có thể liên kết với Conversation #1001, Conversation #1024, Conversation #1088 và Order #505.

Trong nhiều Architecture, Conversation History là một phần của Customer History rộng hơn.

CONVERSATION HISTORY ⊂ BROADER CUSTOMER HISTORY

Sự phân biệt này giúp doanh nghiệp hiểu rõ hai nhu cầu khác nhau: theo dõi quá trình xử lý một Conversation cụ thể và duy trì bức tranh tổng thể về lịch sử tương tác của khách hàng.

hình 3

Conversation Status là gì?

Conversation Status là Attribute mô tả trạng thái xử lý hiện tại của một Conversation.

Tùy theo hệ thống, Conversation có thể sử dụng các trạng thái như New, In Progress, Pending và Resolved.

Ví dụ, khi Status = New, Conversation vừa được tạo và đang chờ tiếp nhận. Khi Status = Pending, Case vẫn tồn tại nhưng đang chờ thông tin hoặc hành động tiếp theo. Khi Status = Resolved, yêu cầu đã được xử lý xong theo quy trình hiện tại.

Trong phạm vi bài, điều quan trọng là hiểu Status là một Attribute phục vụ việc quản lý Conversation. Quy tắc chuyển trạng thái và cách sử dụng từng trạng thái sẽ được trình bày chi tiết trong bài Trạng thái hội thoại là gì?

Unread có phải Conversation Status không?

Không nhất thiết. Unread và Conversation Status mô tả hai khía cạnh khác nhau của một Conversation.

Unread thường cho biết có Message mới mà người dùng chưa đọc hay không. Trong khi đó, Conversation Status thể hiện trạng thái xử lý công việc.

Ví dụ, một Conversation có thể có:

Điều này có nghĩa là Conversation đang được xử lý nhưng vẫn có Message chưa đọc.

Ngược lại, một Conversation cũng có thể có:

Trong trường hợp này, Agent đã đọc tin nhắn nhưng Case vẫn chưa hoàn tất vì đang chờ một điều kiện hoặc phản hồi.

Vì vậy, doanh nghiệp cần phân biệt:

READ STATE ≠ WORK STATE

Việc đánh dấu một Message đã đọc không đồng nghĩa với việc Conversation đã được giải quyết.

Khái niệm Unread sẽ được phân tích riêng trong bài Hội thoại chưa đọc là gì?

Assignee của Conversation là gì?

Assignee là người hoặc Entity vận hành được giao trách nhiệm xử lý một Conversation.

Ví dụ:

Trong một mô hình có phân chia Team, Conversation có thể được giao cho bộ phận CSKH và một Agent cụ thể.

Nếu Conversation chưa được giao cho Agent nào, hệ thống có thể sử dụng giá trị Assignee = Unassigned.

Assignment giúp doanh nghiệp trả lời câu hỏi quan trọng: Ai chịu trách nhiệm xử lý Conversation tiếp theo?

Các khái niệm liên quan sẽ được trình bày trong những bài chuyên sâu:

• Hội thoại chưa được phân công là gì?
• Cách phân công hội thoại cho nhân viên.
• Phân công hội thoại tự động là gì?

Priority của Conversation là gì?

Priority là Attribute mô tả mức độ ưu tiên tương đối của một Conversation.

Ví dụ, một hệ thống có thể sử dụng hai mức Priority là Normal và High.

Một Conversation liên quan đến khiếu nại nghiêm trọng có thể mang các thuộc tính:

Priority giúp Agent và Manager xác định Conversation nào cần được chú ý trước, đặc biệt khi Queue có nhiều yêu cầu cần xử lý.

Tuy nhiên, Priority và Status không có cùng ý nghĩa.

Một Conversation có thể đồng thời mang Status = Pending và Priority = High.

STATUS ≠ PRIORITY

Tag của Conversation là gì?

Tag là nhãn phân loại có thể được gắn với Conversation để mô tả đặc điểm hoặc nhóm yêu cầu.

Ví dụ, hệ thống có thể sử dụng các Tag như:

Complaint | Product | Inquiry VIP

Tag có thể hỗ trợ Filter, Routing, Analytics và Automation. Chẳng hạn, doanh nghiệp có thể lọc những Conversation mang Tag Complaint để theo dõi các yêu cầu khiếu nại.

Tuy nhiên, Tag không nên thay thế tất cả Structured Attributes.

Ví dụ, nếu Conversation được giao cho Agent An, thông tin này nên được lưu bằng Assignment:

Assignee = Agent An

Thay vì tạo một Tag để biểu diễn người phụ trách:

Tag = Agent An

Cách phân biệt này giúp hệ thống duy trì dữ liệu có cấu trúc và hỗ trợ các quy trình phân công, tìm kiếm, báo cáo một cách rõ ràng hơn.

Conversation liên quan đến SLA như thế nào?

Khi Conversation có Timestamp và Lifecycle đủ rõ ràng, hệ thống có thể sử dụng các mốc thời gian để tính toán những Metric vận hành.

Ví dụ, khoảng thời gian từ lúc Conversation được tạo đến khi Agent phản hồi lần đầu có thể được sử dụng để tính First Response Time, tùy theo cách định nghĩa Metric của hệ thống.

Tương tự, Created Time và Resolved Time có thể hỗ trợ việc tính toán các Metric khác, tùy theo phương pháp đo lường mà doanh nghiệp áp dụng.

Ở phạm vi bài C02-001, chỉ cần hiểu rằng Conversation là đối tượng để các Metric vận hành có thể được gắn và đo lường theo Lifecycle. Phương pháp tính SLA cụ thể sẽ được trình bày trong nội dung chuyên sâu riêng.

Conversation được hiển thị ở đâu?

Một trong những nơi phổ biến để Agent tiếp nhận và quản lý Conversation là Unified Inbox (Hộp thư đa kênh).

Trong một hệ thống nhắn tin đa kênh, Message từ các Channel có thể được tiếp nhận, tổ chức thành Conversation và hiển thị trong Unified Inbox để Agent xử lý.

Unified Inbox có thể cung cấp những thành phần như Conversation List, Current Conversation, Customer Context, Search, Filters và Queue.

Nhờ đó, Agent không chỉ xem nội dung tin nhắn mà còn có thể truy cập ngữ cảnh khách hàng, tìm kiếm các Conversation liên quan và quản lý những yêu cầu cần xử lý.

Để hiểu rõ hơn về Workspace được xây dựng phía trên Conversation, xem bài Hộp thư đa kênh là gì?

Conversation có phải chỉ dành cho CSKH?

Không. Conversation không chỉ dành cho bộ phận chăm sóc khách hàng (CSKH) mà còn có thể được sử dụng trong Sales, Marketing, Retail và các doanh nghiệp dịch vụ.

Về bản chất, Conversation là một Entity nền tảng để quản lý quá trình tương tác giữa khách hàng và doanh nghiệp. Tùy theo Business Context, Conversation có thể phục vụ những mục tiêu và quy trình vận hành khác nhau.

Conversation trong Sales

Trong Sales, Conversation có thể bắt đầu khi khách hàng tiềm năng gửi yêu cầu tìm hiểu về sản phẩm hoặc dịch vụ.

LEAD INQUIRY → SALES CONVERSATION → QUALIFICATION → FOLLOW-UP

Conversation giúp nhân viên kinh doanh theo dõi nội dung trao đổi, đánh giá nhu cầu và thực hiện các hoạt động Follow-up.

Conversation trong CSKH

Trong CSKH, Conversation thường được sử dụng để tiếp nhận và xử lý các yêu cầu hỗ trợ.

SUPPORT REQUEST → CONVERSATION → PENDING → RESOLUTION

Ví dụ, khi khách hàng phản ánh một vấn đề cần xác minh, Agent có thể cập nhật Conversation thành Pending trong thời gian chờ phản hồi từ bộ phận liên quan. Khi yêu cầu được giải quyết, Conversation có thể chuyển sang Resolved.

Conversation trong Marketing

Trong Marketing, Conversation có thể hình thành khi khách hàng phản hồi một chiến dịch truyền thông.

CAMPAIGN → CUSTOMER RESPONSE → CONVERSATION → SALES / CSKH HANDOFF

Tùy theo nội dung phản hồi, Conversation có thể được chuyển cho Sales để tư vấn bán hàng hoặc CSKH để hỗ trợ khách hàng.

Conversation trong Retail

Trong Retail, Conversation có thể bắt đầu từ một câu hỏi về sản phẩm và phát triển thành nhu cầu mua hàng.

PRODUCT INQUIRY → CONVERSATION → PURCHASE INTENT → ORDER CONTEXT

Ví dụ, khách hàng hỏi về kích thước hoặc màu sắc sản phẩm. Trong quá trình trao đổi, Agent có thể xác định Purchase Intent và liên kết Conversation với Order Context khi cần.

Conversation trong Service Business

Đối với doanh nghiệp dịch vụ, Conversation có thể hỗ trợ tiếp nhận yêu cầu, xác định nhu cầu và dẫn đến Booking hoặc Case.

SERVICE INQUIRY → CONVERSATION → QUALIFICATION → BOOKING / CASE

Như vậy, Conversation là một Entity nền tảng có thể được sử dụng xuyên suốt nhiều Business Context, thay vì chỉ giới hạn trong hoạt động CSKH.

Conversation không phải Lead

Một Customer Conversation có thể chứa Commercial Intent, nhưng không phải Conversation nào cũng là Sales Lead.

Ví dụ, khách hàng gửi tin nhắn:

Customer: “Shop mở cửa mấy giờ?”

Đây là một Conversation nhưng chưa chắc đã đại diện cho một cơ hội bán hàng.

Ngược lại, nếu quá trình trao đổi và Qualification cho thấy khách hàng có nhu cầu mua sản phẩm hoặc dịch vụ, Conversation có thể dẫn đến việc tạo Lead.

CONVERSATION → QUALIFICATION → LEAD

Do đó, cần phân biệt:

CONVERSATION ≠ LEAD

Doanh nghiệp không nên tự động tạo Lead cho mọi Conversation nếu chưa có tiêu chí Qualification phù hợp.

Conversation không phải Customer

Customer và Conversation là hai Entity khác nhau.

Customer là Entity đại diện cho một người hoặc tổ chức. Trong khi đó, Conversation là Interaction Object đại diện cho một quá trình tương tác cụ thể.

Một Customer có thể có nhiều Conversation tại những thời điểm khác nhau hoặc liên quan đến những nhu cầu khác nhau.

Ví dụ, Customer Nguyễn A có thể có:

• Conversation #1001
• Conversation #1024
• Conversation #1088

Vì vậy:

CUSTOMER ≠ CONVERSATION

Sự phân biệt này cho phép hệ thống quản lý từng lần tương tác riêng biệt, đồng thời duy trì lịch sử tổng thể của cùng một khách hàng.

Conversation không phải Order

Conversation và Order có thể liên quan đến nhau nhưng quản lý hai đối tượng và hai Lifecycle khác nhau.

Ví dụ, khách hàng gửi tin nhắn:

Customer: “Đơn của mình tới đâu rồi?”

Agent tiếp nhận yêu cầu và kiểm tra thông tin đơn hàng.

Conversation có thể đang ở trạng thái Pending vì Agent còn chờ thông tin hoặc cần thực hiện bước xử lý tiếp theo. Trong khi đó, Order vẫn đang ở trạng thái Shipping.

CONVERSATION STATUS ≠ ORDER STATUS

Order là một Contextual Entity có thể được hiển thị bên cạnh Conversation để Agent nắm được thông tin cần thiết khi trao đổi với khách hàng.

Conversation không phải Booking

Tương tự, trong doanh nghiệp dịch vụ, Conversation và Booking có thể tồn tại song song nhưng có Lifecycle khác nhau.

Conversation đang Pending không đồng nghĩa với việc Booking chưa được xác nhận.

Conversation quản lý quá trình Communication giữa khách hàng và doanh nghiệp. Trong khi đó, Booking quản lý thông tin và trạng thái của Appointment.

Hai đối tượng có thể liên kết với nhau nhưng không nên bị đồng nhất.

Khi nào một Conversation được xem là hoàn tất?

Về nguyên tắc vận hành, một Conversation có thể được xem là hoàn tất khi không còn Next Action mà doanh nghiệp cần thực hiện theo Workflow hiện tại.

Ví dụ, khách hàng gửi một yêu cầu, Agent xử lý thành công và không còn công việc cần tiếp tục.

CUSTOMER ASKS → AGENT RESOLVES REQUEST → NO FURTHER ACTION → RESOLVED

Tuy nhiên, điều kiện đóng Conversation không phải lúc nào cũng giống nhau giữa các doanh nghiệp và nền tảng.

Các quy tắc như điều kiện đóng, Auto Close, Reopen và thời gian chờ phụ thuộc vào Operating Model của từng hệ thống.

Những nội dung này sẽ được trình bày chi tiết trong các bài:

• C02-004 — Vòng đời một cuộc hội thoại khách hàng
• C02-026 — Quy trình đóng một hội thoại
• C02-027 — Khi nào nên mở lại hội thoại?

Nếu khách nhắn lại sau khi Conversation đã Resolved thì sao?

Khi khách hàng gửi tin nhắn mới sau khi Conversation đã được đánh dấu Resolved, một cách xử lý là mở lại Conversation và đưa nó trở về trạng thái cần xử lý.

RESOLVED → NEW CUSTOMER MESSAGE → REOPENED / ACTIVE → AGENT QUEUE

Sau đó, Conversation có thể quay lại Queue để Agent tiếp nhận và xử lý yêu cầu mới.

Tuy nhiên, hệ thống cũng có thể tạo một Conversation mới thay vì mở lại Conversation cũ. Cách xử lý phụ thuộc vào Conversation Boundary Rule và Platform Design.

Bài không áp đặt một quy tắc cố định cho tất cả nền tảng.

Điểm quan trọng cần hiểu là: Resolved không có nghĩa toàn bộ mối quan hệ giữa doanh nghiệp và Customer đã kết thúc.

Một Conversation tốt cần trả lời được những câu hỏi nào?

Ở mức Foundation, một Conversation Object nên cung cấp đủ thông tin để hệ thống và Agent hiểu được nguồn gốc, nội dung, trạng thái và trách nhiệm xử lý của từng yêu cầu.

Dưới đây là 10 câu hỏi quan trọng mà một Conversation Model nên hỗ trợ trả lời.

Nếu hệ thống không thể trả lời nhiều câu hỏi trong số này, nó có thể đang hoạt động gần với một Message Viewer hơn là một Conversation Management System.

Conversation Model tốt không có nghĩa phải thật phức tạp

Một doanh nghiệp SME nhỏ có thể bắt đầu với Conversation Model đơn giản, chỉ bao gồm những Attribute thực sự cần thiết cho quá trình vận hành.

Mô hình cơ bản gồm:

• Customer
• Channel
• Messages
• Status
• Assignee

Khi quy mô và mức độ phức tạp của hoạt động tăng lên, doanh nghiệp có thể bổ sung Tag, Priority, SLA và Automation.

Không nhất thiết phải triển khai ngay một mô hình có 20 Status, 100 Tags hoặc 30 Custom Fields nếu chưa có nhu cầu thực tế.

Nguyên tắc cần ghi nhớ:

Conversation Model nên đủ để phản ánh Operational Reality, không phải càng nhiều Attribute càng tốt.

Minimum Conversation Model cho SME

Một Minimum Conversation Model có thể bao gồm các thuộc tính nền tảng sau:

Doanh nghiệp có thể bổ sung Tags và Priority khi có Use Case rõ ràng.

Với mô hình này, Message không chỉ được đánh dấu Read hoặc Unread mà còn được tổ chức thành một Conversation có trạng thái và người chịu trách nhiệm.

Message Viewer:

MESSAGE → READ / UNREAD

Conversation Management:

MESSAGE → CONVERSATION → STATUS + ASSIGNEE → AGENT ACTION

Đây đã là bước tiến đáng kể so với mô hình chỉ hiển thị Message và trạng thái Read / Unread.

Một Conversation Model trưởng thành hơn

Khi hoạt động vận hành phát triển, doanh nghiệp có thể mở rộng Conversation Model để hỗ trợ quản lý Team, SLA, Customer Context, Automation và Analytics.

Một mô hình mở rộng có thể bao gồm:

• ID
• Channel
• Customer
• Messages
• Status
• Team
• Assignee
• Priority
• Tags
• SLA
• Customer Context
• Internal Notes
• Created Time
• Updated Time
• First Response Time
• Resolved Time
• Audit History

Mô hình mở rộng cho phép hệ thống theo dõi nhiều khía cạnh hơn của Conversation, từ quá trình giao tiếp đến phân công, đo lường hiệu suất và lịch sử thay đổi.

Tuy nhiên, mỗi Attribute được bổ sung đều cần có Business Purpose rõ ràng.

Tại sao Conversation là Entity trung tâm của Unified Inbox?

Unified Inbox cần một Object để tổ chức và hiển thị các tương tác trong danh sách công việc của Agent.

Nếu hệ thống chỉ sử dụng Message làm đơn vị hiển thị, Agent có thể nhìn thấy nhiều dòng tin nhắn riêng lẻ nhưng khó xác định những Message nào thuộc cùng một Customer Issue.

Ví dụ, Agent nhìn thấy Message 1, Message 2, Message 3 và Message 4 nhưng không biết chúng có thuộc cùng một yêu cầu hay không.

Conversation giải quyết vấn đề này bằng cách nhóm những Message liên quan thành một Operational Unit có ngữ cảnh và trạng thái xử lý.

Ví dụ:

Từ Conversation Object, Unified Inbox có thể xây dựng các chức năng như Conversation List, Search, Filter, Queue và Assignment.

MESSAGE → CONVERSATION → UNIFIED INBOX

Đây là một Semantic Relationship cốt lõi của hệ thống quản lý hội thoại đa kênh và toàn bộ nhóm nội dung C02.

Conversation là nền tảng của Queue

Một Queue thường có thể được hiểu là tập hợp những Conversation đáp ứng một hoặc nhiều điều kiện xác định.

Ví dụ:

Unassigned Queue chứa những Conversation chưa được phân công cho Agent.

Pending Queue chứa những Conversation đang ở trạng thái Pending.

My Conversations hiển thị những Conversation được giao cho Agent hiện tại.

Nếu không có Conversation Object và các Attribute được định nghĩa rõ ràng, việc xây dựng Queue sẽ khó bảo đảm tính chính xác.

Conversation là nền tảng của Assignment

Assignment cần một Entity được phân công và một Relationship thể hiện người hoặc bộ phận chịu trách nhiệm.

Trong trường hợp này, Entity là Conversation và Attribute quan trọng là Assignee.

Ví dụ:

Conversation #1024 có Assignee = An.

Khi cần chuyển người phụ trách, hệ thống có thể cập nhật Assignee từ An sang Bình.

Reassignment:

Assignee: An → Bình

Team Handoff:

Team: Sales → CSKH

Vì vậy, Assignment không phải một hành động hoàn toàn tách rời Conversation. Nó là quá trình thay đổi một Relationship liên quan đến Conversation.

Conversation là nền tảng của Analytics

Conversation Model cung cấp dữ liệu nền để hệ thống tính toán và phân tích những Metric vận hành.

Khi Conversation Model được định nghĩa nhất quán, hệ thống có thể sử dụng các Attribute và Timestamp để xây dựng báo cáo phù hợp với Operating Model.

Ngược lại, nếu định nghĩa Conversation không ổn định hoặc các Attribute không được chuẩn hóa, Analytics phía trên cũng khó đáng tin cậy.

Conversation là nền tảng của Automation

Automation có thể sử dụng Conversation làm Entity được quan sát để phát hiện sự kiện, kiểm tra điều kiện và thực hiện hành động.

Ví dụ, doanh nghiệp muốn tự động tăng Priority khi có một Conversation mới được gắn Tag Complaint.

TRIGGER: New Conversation

CONDITION: Tag = Complaint

ACTION: Priority = High

Một ví dụ khác là tự động nhắc nhở khi Conversation ở trạng thái Pending quá lâu.

TRIGGER: Conversation Pending too long

ACTION: Notify Assignee

Tùy theo Workflow, Automation có thể thay đổi Status, Tag, Priority hoặc Assignee của Conversation.

Do đó, Automation sẽ hoạt động nhất quán hơn khi Conversation Attributes được chuẩn hóa và các điều kiện xử lý được định nghĩa rõ ràng.

Một Architecture tổng thể

Trong hệ thống quản lý hội thoại khách hàng, Conversation đóng vai trò kết nối dữ liệu giao tiếp (Communication Data) với dữ liệu vận hành (Operational Data).

Một Architecture tổng thể có thể được hình dung từ Customer, Channel và Message, sau đó tổ chức thành Conversation để quản lý trạng thái, phân công nhân viên và duy trì ngữ cảnh khách hàng.

[CHÈN SVG 42 – Architecture tổng thể của hệ thống Conversation Management]

Sơ đồ thể hiện luồng tổng thể:

CUSTOMER → CHANNEL → MESSAGE → CONVERSATION

Từ Conversation, hệ thống kết nối với ba thành phần:

• Status: Theo dõi trạng thái xử lý hiện tại của Conversation.
• Assignment: Xác định Agent hoặc Team chịu trách nhiệm xử lý.
• Customer Context: Cung cấp những thông tin liên quan đến khách hàng để hỗ trợ quá trình tương tác.

Các thành phần này hỗ trợ Agent thực hiện công việc trong Unified Inbox, tiếp tục xử lý các yêu cầu vận hành và đưa Conversation đến Resolution.

Luồng tiếp theo:

AGENT → UNIFIED INBOX → OPERATIONAL ACTION → RESOLUTION → ANALYTICS

Trong mô hình này, Conversation nằm gần trung tâm vì nó kết nối Communication Data với Operational Data.

Nhờ đó, hệ thống không chỉ lưu trữ Message mà còn có thể quản lý trạng thái, phân công trách nhiệm, hỗ trợ xử lý yêu cầu và cung cấp dữ liệu cho Analytics.

Checklist: Hệ thống có thực sự quản lý Conversation không?

Để đánh giá một nền tảng có hỗ trợ Conversation Management hay chỉ dừng lại ở việc hiển thị và phản hồi Message, doanh nghiệp có thể sử dụng checklist dưới đây.

Câu hỏi thường gặp

Tóm lại

Một hệ thống giao tiếp khách hàng có thể được mô tả bằng luồng từ Channel đến Message, Conversation, Unified Inbox và cuối cùng là Agent.

Trong đó, cần phân biệt hai khái niệm cốt lõi:

• Message: Đơn vị giao tiếp, đại diện cho một tin nhắn cụ thể giữa khách hàng và doanh nghiệp.
• Conversation: Đơn vị tương tác và vận hành, tập hợp các Message liên quan cùng những thông tin cần thiết để quản lý quá trình xử lý.

Một Conversation có thể kết nối nhiều thành phần, bao gồm Messages, Customer, Channel, Status, Assignee, Tags, Priority và Customer Context.

Nhờ đó, doanh nghiệp không chỉ biết:

“Có tin nhắn nào mới?”

Mà còn có thể trả lời những câu hỏi quan trọng hơn trong quá trình vận hành:

• Conversation nào còn cần xử lý?
• Ai đang chịu trách nhiệm?
• Đang chờ điều kiện hoặc phản hồi gì?
• Customer Context là gì?
• Khi nào Conversation được xem là hoàn tất?

Đây là lý do Conversation trở thành một trong những Entity trung tâm của Customer Communication Operations. Nó giúp doanh nghiệp chuyển từ việc quản lý những tin nhắn riêng lẻ sang quản lý toàn bộ quá trình tương tác và xử lý yêu cầu của khách hàng.

Khi đã hiểu Conversation là gì, câu hỏi tiếp theo là:

Những Conversation này được tổ chức và xử lý ở đâu khi chúng đến từ nhiều Channel?

Đó là nội dung của bài viết tiếp theo:

Hộp thư đa kênh là gì?

Đọc tiếp

Theo contextual flow của C02:

1. Cuộc hội thoại khách hàng là gì?
2. Hộp thư đa kênh là gì?
3. Quản lý hội thoại khách hàng là gì?
4. Vòng đời một cuộc hội thoại khách hàng
5. Trạng thái hội thoại là gì?
6. Hội thoại chưa đọc là gì?
7. Hội thoại chờ xử lý là gì?
8. Hội thoại chưa được phân công là gì?
9. Cách phân công hội thoại cho nhân viên