Cách đánh giá một hệ thống nhắn tin đa kênh: 15 tiêu chí cần kiểm tra

Cách đánh giá một hệ thống nhắn tin đa kênh

Việc lựa chọn hệ thống nhắn tin đa kênh không nên chỉ dựa trên số lượng Channel được hỗ trợ hoặc danh sách tính năng mà nhà cung cấp giới thiệu. Một nền tảng có nhiều tính năng chưa chắc đã phù hợp với cách doanh nghiệp tổ chức đội ngũ Sales, CSKH và quản lý hội thoại khách hàng.

Để đánh giá một hệ thống nhắn tin đa kênh, doanh nghiệp cần xem xét mức độ phù hợp với mô hình vận hành (Operating Model) thực tế: hệ thống có tiếp nhận đúng Conversation, phân công trách nhiệm rõ ràng, duy trì Customer Context, hỗ trợ Workflow, đo lường hiệu suất và mở rộng quy mô mà không tạo thêm quá nhiều phức tạp hay không?

Khung đánh giá tổng quát

Quá trình đánh giá nên bắt đầu từ nhu cầu kinh doanh, sau đó xác định những yêu cầu kỹ thuật và vận hành cần thiết trước khi tiến hành thử nghiệm thực tế.

Khung đánh giá này giúp doanh nghiệp tránh lựa chọn phần mềm chỉ dựa trên những tính năng hấp dẫn trong bản Demo nhưng ít được sử dụng trong hoạt động hằng ngày.

Feature Count không đồng nghĩa với System Fit

Một nền tảng có 50 tính năng, hỗ trợ 10 Channel và tích hợp AI chưa chắc phù hợp hơn hệ thống chỉ hỗ trợ 5 Core Channels nhưng có Conversation Model rõ ràng, Assignment hiệu quả và Customer Context đáng tin cậy.

Ví dụ, nếu vấn đề chính của doanh nghiệp là nhân viên phải kiểm tra nhiều Inbox, Conversation không có Owner và khách hàng phải lặp lại thông tin khi chuyển kênh, những khả năng cần ưu tiên sẽ là:

• Unified Inbox: Tập trung Conversation từ các Channel quan trọng.
• Strong Conversation Model: Quản lý hội thoại như một đơn vị công việc có trạng thái và lịch sử.
• Clear Assignment: Xác định nhân viên hoặc Team chịu trách nhiệm.
• Reliable Customer Context: Duy trì những thông tin liên quan để nhân viên tiếp tục hỗ trợ khách hàng.

Trong trường hợp này, các tính năng nâng cao như AI hoặc Complex Automation có thể được xem xét sau khi doanh nghiệp đã giải quyết những vấn đề vận hành cốt lõi.

Feature Count ≠ System Fit.

Một hệ thống phù hợp là hệ thống đáp ứng được những yêu cầu quan trọng của doanh nghiệp với chi phí, độ phức tạp và khả năng mở rộng có thể chấp nhận được.

Bắt đầu từ Workflow, không phải danh sách tính năng

Thay vì đặt câu hỏi “Phần mềm nào có nhiều tính năng nhất?”, doanh nghiệp nên xác định những Customer Communication Workflows quan trọng cần được cải thiện.

Chẳng hạn, một đội CSKH có thể cần tiếp nhận tin nhắn từ Facebook và Zalo, phân loại yêu cầu, chuyển Conversation đến đúng nhân viên, theo dõi các trường hợp Pending và đo lường First Response Time.

Một doanh nghiệp bán lẻ nhiều chi nhánh có thể cần thêm Store Routing, Product Context và Order Context. Trong khi đó, doanh nghiệp dịch vụ có thể ưu tiên lịch sử tư vấn, quy trình Handoff và theo dõi các yêu cầu cần xử lý trong nhiều ngày.

Câu hỏi quan trọng nhất không phải là hệ thống có bao nhiêu tính năng, mà là: “Hệ thống nào giải quyết tốt nhất những Customer Communication Workflows quan trọng của doanh nghiệp?”

Trước khi đánh giá phần mềm: Xác định rõ vấn đề cần giải quyết

Trước khi liên hệ nhà cung cấp, doanh nghiệp cần xác định những vấn đề cụ thể đang tồn tại trong hoạt động Customer Communication. Thay vì đưa ra yêu cầu chung chung như “Cho tôi xem Demo Omnichannel”, hãy chuẩn bị danh sách từ 5–10 vấn đề cần giải quyết và những tình huống vận hành tương ứng.

Ví dụ, một doanh nghiệp có thể đang gặp các vấn đề sau:

1. Agent phải kiểm tra Facebook, Zalo và Website trên những giao diện riêng biệt.
2. Không biết conversation nào chưa có người tiếp nhận.
3. Những conversation ở trạng thái Pending thường bị bỏ quên.
4. Sales và CSKH bàn giao thiếu Conversation History.
5. Manager không đo lường được First Response Time.

Những vấn đề này cần được chuyển thành các Capability cụ thể để kiểm tra trong quá trình Demo và Pilot.

Bảng này có thể trở thành cơ sở để xây dựng Requirement Checklist, so sánh các nền tảng và thiết kế những kịch bản kiểm thử thực tế.

Đây là bước nền tảng của toàn bộ quá trình lựa chọn phần mềm. Nếu xác định sai Requirement, việc so sánh càng nhiều tính năng càng có thể khiến doanh nghiệp tập trung vào những khả năng không giải quyết được vấn đề chính.

Phân biệt Must-have, Should-have và Nice-to-have

Không phải mọi tính năng đều có mức độ quan trọng như nhau. Doanh nghiệp nên phân loại Requirement theo ba nhóm trước khi bắt đầu đánh giá nhà cung cấp.

Must-have: Những khả năng bắt buộc

Đây là những Capability mà nếu thiếu, hệ thống không thể đáp ứng các Use Case cốt lõi của doanh nghiệp.

Ví dụ:

• Required Channels.
• Conversation Management.
• Assignment.
• Pending Status.
• Customer History.

Nếu doanh nghiệp thường xuyên xử lý các yêu cầu kéo dài nhiều ngày nhưng hệ thống không có Pending Queue hoặc cơ chế theo dõi tương đương, đó có thể là khoảng trống nghiêm trọng trong khả năng đáp ứng nhu cầu vận hành.

Should-have: Những khả năng nên có

Nhóm này mang lại giá trị rõ ràng nhưng có thể được triển khai ở giai đoạn tiếp theo nếu doanh nghiệp chưa cần sử dụng ngay.

Ví dụ:

• SLA Management.
• Basic Automation.
• Advanced Search.
• Analytics.

Nice-to-have: Những khả năng bổ sung

Đây là các tính năng có thể hữu ích trong tương lai nhưng chưa phải lý do chính để lựa chọn nền tảng ở thời điểm hiện tại.

Ví dụ:

• Advanced AI.
• Complex Segmentation.
• Large Automation Library.

Việc phân nhóm giúp doanh nghiệp tập trung đánh giá những Capability thực sự cần thiết, thay vì bị phân tán bởi một danh sách tính năng dài.

Một hệ thống thiếu Must-have không nên được lựa chọn chỉ vì sở hữu nhiều Nice-to-have.

1. Đánh giá Channel Coverage

Channel Coverage là khả năng hệ thống hỗ trợ những kênh giao tiếp mà doanh nghiệp đang sử dụng hoặc dự kiến triển khai.

Câu hỏi đầu tiên không phải là “Phần mềm hỗ trợ tổng cộng bao nhiêu Channel?”, mà là:

“Hệ thống có hỗ trợ đầy đủ những Channel quan trọng đối với hoạt động Customer Communication của doanh nghiệp không?”

Ví dụ, doanh nghiệp đang sử dụng bốn Core Channels: Facebook, Zalo, Website và TikTok.

Một nền tảng hỗ trợ 15 Channel nhưng không có Zalo có thể không đáp ứng được Requirement, trong khi một nền tảng chỉ hỗ trợ 6 Channel nhưng bao phủ đầy đủ bốn kênh trên lại phù hợp hơn với nhu cầu hiện tại.

Vì vậy, Channel Coverage cần được đánh giá dựa trên danh sách Required Channels thay vì chỉ dựa vào tổng số tích hợp được công bố.

Đánh giá Channel Coverage theo hai lớp: Breadth và Depth

Để đánh giá chính xác khả năng tích hợp, doanh nghiệp nên xem xét cả độ rộng và độ sâu hỗ trợ của từng Channel.

Breadth – Độ rộng hỗ trợ

Breadth trả lời câu hỏi: Hệ thống có hỗ trợ Channel mà doanh nghiệp cần hay không?

Ví dụ:

Tuy nhiên, việc một Channel xuất hiện trong danh sách tích hợp chưa đảm bảo mọi nghiệp vụ trên Channel đó đều hoạt động như mong đợi.

Depth – Độ sâu tích hợp

Depth trả lời câu hỏi: Trên mỗi Channel, hệ thống hỗ trợ được những thao tác và dữ liệu nào?

Doanh nghiệp cần kiểm tra:

• Inbound Message: Tiếp nhận tin nhắn từ khách hàng.
• Outbound Reply: Cho phép Agent phản hồi.
• Attachment: Hỗ trợ những loại tệp đính kèm cần thiết.
• Identity: Ghi nhận thông tin định danh khách hàng trong phạm vi Channel cho phép.
• Reply Status: Hiển thị trạng thái gửi hoặc phản hồi khi được hỗ trợ.
• Conversation History: Lưu giữ lịch sử hội thoại.
• Error Handling: Có cách xử lý hoặc thông báo khi gửi, nhận tin nhắn thất bại.

Những Capability này có thể khác nhau giữa các Channel do giới hạn API, chính sách của nền tảng hoặc phạm vi tích hợp của nhà cung cấp.

Channel Supported không đồng nghĩa với Channel Fully Usable.

Không đánh giá Channel chỉ bằng logo trên Website của Vendor

Danh sách logo Channel trên Website hoặc tài liệu giới thiệu chỉ nên được sử dụng để lập danh sách kiểm tra ban đầu.

Để xác minh khả năng sử dụng thực tế, doanh nghiệp nên thực hiện End-to-end Test trên từng Core Channel.

Trong quá trình kiểm thử, cần xác minh cả chiều nhận và chiều gửi, khả năng tạo Conversation, việc ghi nhận lịch sử và cách hệ thống xử lý lỗi.

Nếu một Core Channel không đáp ứng được những nghiệp vụ bắt buộc, doanh nghiệp cần làm rõ giới hạn này trước khi đưa nền tảng vào danh sách lựa chọn.

2. Đánh giá Conversation Model

Conversation Model là một trong những tiêu chí quan trọng khi đánh giá hệ thống nhắn tin đa kênh.

Doanh nghiệp cần xác định nền tảng đang quản lý các Message riêng lẻ hay thực sự hỗ trợ Conversation như một đơn vị công việc có vòng đời, người phụ trách và trạng thái xử lý.

Một Conversation Model phù hợp có thể bao gồm những thuộc tính sau:

Những thuộc tính này giúp hệ thống hỗ trợ hoạt động của nhiều nhân viên và nhiều bộ phận thay vì chỉ hiển thị danh sách tin nhắn.

Phân biệt Message Management và Conversation Management

Một hệ thống chỉ tập trung vào Message có thể cung cấp những thao tác cơ bản như Read, Unread và Reply.

Tuy nhiên, nếu thiếu Conversation Lifecycle, doanh nghiệp có thể gặp khó khăn khi mở rộng sang những nghiệp vụ phức tạp hơn:

• Pending Management.
• Assignment.
• SLA.
• Handoff.
• Workload Management.
• Resolution Tracking.

Ví dụ, một tin nhắn đã được đọc không có nghĩa yêu cầu của khách hàng đã được giải quyết. Nhân viên có thể vẫn đang chờ xác nhận từ bộ phận giao hàng hoặc kiểm tra chính sách đổi trả.

Trong trường hợp đó, Conversation Status và Assignee cần được duy trì độc lập với trạng thái Read / Unread của Message.

Kiểm tra Conversation Model bằng tình huống thực tế

Thay vì chỉ xem giao diện quản lý conversation trong bản Demo, doanh nghiệp nên yêu cầu nhà cung cấp thực hiện một kịch bản có nhiều lượt tương tác.

Trong quá trình kiểm thử, cần làm rõ các câu hỏi:

• Conversation có giữ được toàn bộ History không?
• Pending Status có được duy trì không?
• Khi khách hàng quay lại, hệ thống tiếp tục conversation cũ hay tạo conversation mới?
• Nếu conversation đã Resolved, cơ chế Reopen hoạt động như thế nào?
• Assignee có được giữ lại sau khi khách hàng tiếp tục trao đổi không?
• Created Time, Last Message Time và những Timestamps liên quan có được ghi nhận chính xác không?

Kịch bản này giúp doanh nghiệp đánh giá khả năng quản lý Conversation Lifecycle thay vì chỉ kiểm tra chức năng gửi và nhận tin nhắn.

3. Đánh giá Unified Inbox

Unified Inbox không đơn thuần là giao diện đặt nhiều Channel cạnh nhau.

Một hệ thống có Facebook Tab, Zalo Tab và Website Tab trên cùng một màn hình có thể giúp nhân viên giảm thao tác chuyển đổi ứng dụng, nhưng chưa chắc đã tạo ra một quy trình quản lý conversation thống nhất.

Nếu mỗi Tab vẫn vận hành độc lập, doanh nghiệp thực chất chỉ đang sử dụng nhiều Inbox trong cùng một giao diện.

Multiple Inboxes Inside One UI không đồng nghĩa với Unified Operations.

Những khả năng cần kiểm tra trong Unified Inbox

Một Unified Inbox phục vụ Team Operations nên có các View hoặc chức năng tương đương:

Các View này giúp Agent biết những công việc đang chờ xử lý, đồng thời hỗ trợ Manager nhận diện Unassigned Conversations và Pending Backlog.

Ví dụ, khi bắt đầu ca làm việc, Agent có thể truy cập My Conversations để tiếp tục những yêu cầu đang phụ trách, sau đó kiểm tra Pending Queue để xác định các trường hợp cần Follow-up.

Manager có thể sử dụng All Conversations và Unassigned Queue để theo dõi khối lượng công việc và điều chỉnh Assignment khi cần.

Câu hỏi quan trọng khi đánh giá Unified Inbox

Thay vì chỉ hỏi “Tất cả tin nhắn có hiển thị trên cùng một màn hình không?”, doanh nghiệp cần kiểm tra liệu Inbox có hỗ trợ nhân viên xác định đúng công việc cần thực hiện tiếp theo hay không.

Một Unified Inbox phù hợp cần giúp Agent nhanh chóng nhận biết:

• Conversation nào cần phản hồi?
• Conversation nào chưa có Owner?
• Conversation nào đang Pending và cần Follow-up?
• Conversation nào có Priority cao?
• Conversation nào thuộc trách nhiệm của mình?

Một Unified Inbox hiệu quả không chỉ cho biết khách hàng đã nhắn gì, mà còn giúp Agent xác định cần làm gì tiếp theo.

4. Đánh giá Search và Filter

Khi doanh nghiệp chỉ có khoảng 100 conversation, khả năng tìm kiếm có thể chưa được chú ý nhiều. Tuy nhiên, khi dữ liệu tăng lên hàng chục nghìn hoặc 100.000 conversations, Search và Filter trở thành những capability quan trọng đối với hoạt động hằng ngày.

Một hệ thống có thể lưu trữ đầy đủ Conversation History nhưng vẫn gây khó khăn cho Agent nếu không thể nhanh chóng tìm thấy thông tin cần thiết.

Kiểm tra Search bằng những tình huống thực tế

Thay vì chỉ thử tìm kiếm một từ khóa đơn giản, doanh nghiệp nên sử dụng những yêu cầu thường xuất hiện trong quá trình vận hành:

• “Tìm conversation của Nguyễn An.”
• “Tìm khách hàng theo số điện thoại.”
• “Tìm những case phát sinh hôm qua.”
• “Tìm conversation liên quan đến đơn hàng #1024.”
• “Tìm tất cả Pending Conversations của Team CSKH.”

Các tình huống này giúp kiểm tra khả năng truy xuất thông tin theo Customer, thời gian, Order Context, Conversation Status và Team.

Bốn capability cần đánh giá

Ví dụ, một CSKH Manager có thể cần Saved View hiển thị toàn bộ Pending Conversations của Team, được sắp xếp theo thời điểm cập nhật gần nhất hoặc thời gian chờ xử lý.

Khi đánh giá Search và Filter, doanh nghiệp nên sử dụng bộ dữ liệu đủ lớn và những tình huống gần với thực tế. Một chức năng hoạt động tốt trong bản Demo với vài chục conversation chưa chắc đã đáp ứng được nhu cầu khi quy mô dữ liệu tăng đáng kể.

5. Đánh giá Conversation Status

Conversation Status giúp doanh nghiệp biểu diễn trạng thái công việc của từng conversation. Đây là thành phần quan trọng để quản lý những yêu cầu không thể hoàn tất ngay sau một lần phản hồi.

Một Conversation Lifecycle cơ bản có thể gồm bốn trạng thái:

New → In Progress → Pending → Resolved

Trong đó:

• New: Conversation mới được tiếp nhận và đang chờ xử lý.
• In Progress: Agent đang tiếp nhận và xử lý yêu cầu.
• Pending: Conversation đang chờ thông tin hoặc hành động tiếp theo.
• Resolved: Yêu cầu đã được xử lý và conversation được kết thúc theo quy trình.

Những câu hỏi cần kiểm tra

Doanh nghiệp nên yêu cầu Vendor trình diễn cách hệ thống quản lý Status trong những tình huống thực tế:

• Có thể cấu hình Status phù hợp với quy trình mà không làm hệ thống quá phức tạp không?
• Pending Conversations có Queue hoặc Saved View riêng không?
• Khi Resolve, hệ thống có ghi nhận Resolved Time không?
• Khi khách hàng tiếp tục nhắn tin, cơ chế Reopen hoạt động như thế nào?
• Status có thể được sử dụng làm Condition hoặc Trigger trong Automation không?
• Analytics có thể phân tích Conversation Volume theo Status không?

Read không đồng nghĩa với Resolved

Một Message được đánh dấu Read chỉ cho biết tin nhắn đã được đọc hoặc ghi nhận theo cơ chế của hệ thống. Điều đó không có nghĩa yêu cầu của khách hàng đã được giải quyết.

Ví dụ, Agent đọc yêu cầu đổi trả nhưng vẫn đang chờ bộ phận kho xác nhận tình trạng sản phẩm. Conversation cần tiếp tục được theo dõi dù tin nhắn không còn ở trạng thái Unread.

Read ≠ Resolved.

Nếu một nền tảng chủ yếu dựa vào Read / Unread, doanh nghiệp cần kiểm tra kỹ khả năng quản lý những case kéo dài nhiều giờ hoặc nhiều ngày.

6. Đánh giá Assignment và Ownership

Assignment xác định Agent hoặc Team chịu trách nhiệm xử lý một conversation. Đây là capability nền tảng đối với những doanh nghiệp có nhiều nhân viên cùng tiếp nhận tin nhắn từ các Channel.

Một hệ thống phục vụ Team Operations cần giúp Manager và Agent trả lời rõ ràng câu hỏi:

“Conversation này hiện thuộc trách nhiệm của ai?”

Kiểm thử Assignment bằng một quy trình chuyển giao

Qua quy trình này, doanh nghiệp cần kiểm tra những capability sau:

Đặc biệt, doanh nghiệp cần kiểm tra Conversation History và những thông tin liên quan có được giữ nguyên khi chuyển giao hay không.

Assignment quan trọng hơn những Automation không phục vụ nhu cầu cốt lõi

Một nền tảng có nhiều tính năng AI hoặc Automation nhưng không giúp Manager dễ dàng xác định người đang chịu trách nhiệm xử lý conversation sẽ gặp hạn chế trong Team Operations.

Một Active Conversation nên có Owner rõ ràng hoặc được hiển thị trong Unassigned Queue để chờ tiếp nhận.

Đây là điều kiện cơ bản giúp doanh nghiệp hạn chế tình trạng nhiều nhân viên cùng trả lời một khách hàng hoặc không ai tiếp tục xử lý những yêu cầu còn tồn đọng.

7. Đánh giá Routing

Routing quyết định conversation được chuyển đến Agent hoặc Team nào dựa trên những quy tắc vận hành.

Đối với doanh nghiệp nhỏ, Manual Assignment có thể đáp ứng đầy đủ nhu cầu. Khi số lượng nhân viên và Conversation Volume tăng, doanh nghiệp có thể cân nhắc những phương thức Routing phù hợp hơn.

Các phương thức Routing phổ biến

Doanh nghiệp không nên đánh giá Routing chỉ bằng số lượng thuật toán mà hệ thống hỗ trợ.

Câu hỏi quan trọng hơn là: Routing Model nào phù hợp với Workflow và cách phân chia trách nhiệm hiện tại?

Ví dụ, một doanh nghiệp chỉ cần hai quy tắc:

• Sales Inquiry → Sales Team.
• Complaint → CSKH Team.

Trong trường hợp này, một Rule Engine đơn giản, dễ kiểm soát và hoạt động ổn định có thể đáp ứng tốt nhu cầu mà không cần triển khai Routing phức tạp.

Khi đánh giá, doanh nghiệp cũng nên kiểm tra cách hệ thống xử lý khi không có Agent phù hợp, Team quá tải hoặc Rule không thể xác định nơi tiếp nhận conversation.

8. Đánh giá Customer Context

Customer Context giúp Agent hiểu người đang nhắn tin là ai, đã tương tác với doanh nghiệp như thế nào và có những thông tin liên quan nào cần sử dụng trong conversation hiện tại.

Một Customer Profile cơ bản có thể bao gồm:

• Name.
• Phone.
• Email.
• Channel Identities.
• Tags.
• Conversation History.
• Relevant Orders.

Tùy theo Use Case, doanh nghiệp có thể cần thêm những trường dữ liệu khác. Tuy nhiên, mục tiêu không phải là thu thập càng nhiều thông tin càng tốt, mà là cung cấp đúng Context tại thời điểm Agent cần sử dụng.

Những capability cần kiểm tra

Khi đánh giá Customer Context, doanh nghiệp nên xác minh:

• Conversation có được liên kết với Customer Profile không?
• Agent có thể xem Previous Conversations không?
• Các Channel Identities có thể được liên kết với cùng một Customer khi có căn cứ phù hợp không?
• Quy trình Merge Customer hoạt động như thế nào?
• Duplicate Profiles được phát hiện và xử lý ra sao?

Ví dụ, khi khách hàng hỏi về một đơn hàng đã mua, Agent cần có khả năng truy cập Conversation History và Relevant Order Context mà không phải tìm kiếm thủ công qua nhiều hệ thống.

Cẩn thận với lời hứa Customer 360

Customer 360 là thuật ngữ thường được sử dụng để mô tả góc nhìn tổng hợp về khách hàng. Tuy nhiên, doanh nghiệp không nên chỉ dựa vào tên gọi này để đánh giá chất lượng Customer Context.

Thay vì hỏi “Hệ thống có Customer 360 không?”, hãy kiểm tra:

“Agent có xem được những thông tin cần thiết ngay trong quá trình trả lời khách hàng không?”

Một Customer Profile có 100 trường dữ liệu nhưng yêu cầu Agent mở năm màn hình để tìm đơn hàng gần nhất có thể không đáp ứng tốt nhu cầu vận hành.

Ngược lại, một Profile đơn giản nhưng hiển thị đúng Conversation History, Customer Identity và Relevant Orders ngay tại Workspace có thể giúp Agent xử lý yêu cầu hiệu quả hơn.

9. Đánh giá Customer Identity

Customer Identity là tiêu chí dễ bị bỏ qua khi lựa chọn hệ thống nhắn tin đa kênh.

Một khách hàng có thể liên hệ qua Facebook, Zalo và Website bằng những tài khoản hoặc thông tin định danh khác nhau. Hệ thống cần có cách liên kết các Channel Identities khi có đủ căn cứ, đồng thời tránh hợp nhất nhầm hai người khác nhau.

Ví dụ, hệ thống ghi nhận:

• Facebook: Nguyễn An.
• Zalo: Nguyễn An.

Hai tài khoản có cùng tên không đủ để kết luận chúng thuộc về cùng một khách hàng.

Same Name ≠ Same Customer.

Kiểm tra Identity Resolution

Doanh nghiệp nên yêu cầu Vendor giải thích và trình diễn ba tình huống.

Automatic Merge: Nếu hệ thống tự động hợp nhất Customer Profiles, cần xác định những Identifier hoặc quy tắc nào được sử dụng.

Manual Merge: Nếu Agent thực hiện hợp nhất thủ công, cần kiểm tra quy trình thao tác và những thông tin được hiển thị để Agent xác minh.

Incorrect Merge: Nếu hai Customer Profiles bị hợp nhất nhầm, hệ thống có hỗ trợ Undo hoặc quy trình khôi phục phù hợp không?

Ngoài ra, doanh nghiệp nên kiểm tra quyền truy cập và lịch sử thay đổi đối với những thao tác liên quan đến Customer Identity.

Identity Resolution cần đủ an toàn để hạn chế nguy cơ trộn Conversation History hoặc Order Context của những khách hàng khác nhau.

10. Đánh giá Tag và Segmentation

Tag giúp doanh nghiệp phân loại Conversation hoặc Customer theo những tiêu chí phục vụ hoạt động giao tiếp và vận hành.

Một Tag Taxonomy phù hợp có thể hỗ trợ:

• Classification.
• Routing.
• Filter.
• Priority.
• Segmentation.
• Analytics.
• Automation.

Tuy nhiên, khi số lượng Tag tăng, doanh nghiệp cần có cơ chế quản lý để tránh trùng lặp và sử dụng không nhất quán giữa các Team.

Những capability cần kiểm tra

• Hệ thống có hỗ trợ quản lý Tag Taxonomy không?
• Có thể giới hạn quyền tạo hoặc chỉnh sửa Tag không?
• Duplicate Tags được xử lý như thế nào?
• Có thể Bulk Update Tag cho nhiều Conversation hoặc Customer không?
• Tag có thể được sử dụng trong Automation Rules không?

Phân biệt Tag và Structured Field

Không phải mọi thông tin đều nên được lưu dưới dạng Tag.

Ví dụ, nếu doanh nghiệp sử dụng:

• Tag = Hanoi.
• Tag = Agent A.
• Tag = Order1024.

Trong khi các giá trị này thực chất đại diện cho Store, Assignee và Order ID, việc dùng Tag có thể khiến dữ liệu khó quản lý và thiếu nhất quán.

Một Data Model phù hợp nên tách Classification khỏi Operational Data.

Tag nên phục vụ những mục đích phân loại linh hoạt, trong khi những thông tin có cấu trúc rõ ràng như Store, Assignee và Order ID nên được quản lý bằng Structured Attributes khi hệ thống hỗ trợ.

11. Đánh giá Workflow

Nhiều nền tảng giới thiệu tính năng Workflow, nhưng khả năng tạo một quy trình trong bản Demo không đảm bảo hệ thống có thể mô hình hóa đúng hoạt động thực tế của doanh nghiệp.

Vì vậy, doanh nghiệp nên xây dựng những kịch bản dựa trên Customer Communication Workflows hiện tại và yêu cầu Vendor trình diễn trực tiếp.

Workflow cho CSKH

New → Assign → Reply → Pending → Continue → Resolve

Quy trình này kiểm tra khả năng tiếp nhận, phân công, phản hồi, theo dõi yêu cầu đang chờ và hoàn tất conversation.

Workflow cho Sales

New Lead → Assign → Qualify → Follow-up → Handoff

Quy trình này kiểm tra cách hệ thống hỗ trợ tiếp nhận khách hàng tiềm năng, phân công Sales, ghi nhận nhu cầu và chuyển giao thông tin khi cần.

Workflow cho Retail

Product Inquiry → Purchase Intent → Order Context → CSKH

Quy trình này tập trung vào khả năng duy trì Product Context và kết nối hoạt động tư vấn trước mua với hỗ trợ sau mua.

Workflow cho doanh nghiệp dịch vụ

Service Inquiry → Qualify → Booking → Follow-up

Quy trình này kiểm tra khả năng quản lý nhu cầu dịch vụ, xác định mức độ phù hợp, kết nối thông tin đặt lịch và tiếp tục chăm sóc khách hàng.

Kiểm tra Workflow bằng hoạt động thực tế

Đối với mỗi Workflow, doanh nghiệp nên xác định rõ điểm bắt đầu, những trạng thái cần quản lý, người chịu trách nhiệm, điều kiện chuyển bước và kết quả mong đợi.

Trong quá trình Pilot, cần kiểm tra xem Agent có thể thực hiện toàn bộ quy trình mà không phải sử dụng quá nhiều thao tác thủ công hoặc chuyển đổi liên tục giữa các hệ thống hay không.

Hệ thống nên được đánh giá bằng Workflow thực tế của doanh nghiệp, không chỉ bằng những Workflow mẫu do Vendor chuẩn bị.

12. Đánh giá Automation

Automation giúp doanh nghiệp giảm những thao tác lặp lại trong quá trình tiếp nhận, phân loại và xử lý conversation. Tuy nhiên, khả năng tự động hóa cần được đánh giá dựa trên những Workflow thực tế thay vì chỉ dựa vào số lượng Automation Rules mà nền tảng hỗ trợ.

Một Automation Rule cơ bản thường có ba thành phần:

Trigger → Condition → Action

Trong đó:

• Trigger: Sự kiện kích hoạt Automation.
• Condition: Điều kiện cần thỏa mãn để Rule được thực thi.
• Action: Hành động mà hệ thống thực hiện khi điều kiện được đáp ứng.

Ví dụ, khi có New Conversation và Intent được xác định là Sales, hệ thống có thể tự động Assign conversation cho Sales Team.

Những capability cần kiểm tra

Một Rule Engine có nhiều khả năng cấu hình nhưng khó kiểm tra lỗi hoặc khó xác định nguyên nhân thực thi có thể tạo thêm rủi ro vận hành.

Không chỉ kiểm thử Automation bằng Positive Case

Ví dụ, doanh nghiệp thiết lập Rule: Khi Customer Type = VIP, conversation được gắn High Priority.

Không nên chỉ kiểm tra trường hợp VIP được gắn đúng Priority. Doanh nghiệp cần thử cả những tình huống ngoại lệ.

Trong quá trình Pilot, doanh nghiệp nên ghi nhận kết quả của từng Test Case, kiểm tra Execution Log và xác minh cách hệ thống xử lý khi Rule không thể thực thi.

13. Đánh giá Quick Reply, Knowledge Base và AI

Quick Reply, Knowledge Base và AI có thể giúp Agent xử lý conversation nhanh hơn. Tuy nhiên, những Capability này nên được đánh giá sau khi doanh nghiệp đã xác minh các thành phần nền tảng như Conversation Model, Assignment và Customer Context.

Quick Reply

Quick Reply giúp Agent sử dụng những mẫu trả lời đã được chuẩn hóa cho các câu hỏi thường gặp.

Khi đánh giá, doanh nghiệp cần kiểm tra:

• Agent có dễ dàng tìm thấy mẫu trả lời phù hợp không?
• Template có thể được phân loại theo Category không?
• Agent có thể cá nhân hóa nội dung trước khi gửi không?
• Ai có quyền tạo, chỉnh sửa và quản lý Template?

Một Quick Reply hữu ích không chỉ giúp giảm thao tác nhập liệu mà còn hỗ trợ duy trì tính nhất quán của thông tin được cung cấp cho khách hàng.

Knowledge Base

Knowledge Base là nguồn tham chiếu chung cho các chính sách, quy trình và thông tin nghiệp vụ.

Những capability cần kiểm tra bao gồm:

• Search: Khả năng tìm kiếm nội dung.
• Update: Quy trình cập nhật thông tin.
• Permissions: Quyền tạo, chỉnh sửa và phê duyệt.
• Version: Khả năng quản lý phiên bản.
• Agent Workspace: Khả năng truy cập Knowledge Base ngay trong giao diện xử lý conversation.

Doanh nghiệp nên thử một tình huống Agent cần tìm chính sách đổi trả hoặc quy trình xử lý khiếu nại trong lúc đang trả lời khách hàng.

AI

Thay vì chỉ hỏi “Hệ thống có AI không?”, doanh nghiệp cần xác định AI đang hỗ trợ những nghiệp vụ nào.

Mỗi ứng dụng cần được đánh giá bằng những tình huống riêng, dựa trên độ chính xác, khả năng kiểm soát và mức độ phù hợp với Workflow.

Đánh giá AI bằng Failure Handling

Một tiêu chí quan trọng là cách AI phản ứng khi không có đủ thông tin hoặc mức độ tin cậy thấp.

Ví dụ, doanh nghiệp có thể đưa ra câu hỏi không có câu trả lời trong Knowledge Base và quan sát hành vi của hệ thống.

Khi gặp Low Confidence, AI có hỗ trợ:

• Human Review.
• Human Handoff.
• Fallback Response.

Hay vẫn tiếp tục tạo câu trả lời dù thiếu căn cứ?

Đối với Customer Communication, khả năng nhận biết giới hạn và chuyển giao cho nhân viên khi cần thiết là một phần quan trọng của chất lượng AI.

14. Đánh giá SLA và Response Time

Nếu doanh nghiệp cần quản lý chất lượng dịch vụ, hệ thống phải hỗ trợ ghi nhận thời gian và theo dõi những chỉ số liên quan đến quá trình xử lý conversation.

Những dữ liệu cần kiểm tra bao gồm:

• Conversation Created Time.
• First Reply Time.
• Resolved Time.
• Business Hours.
• Priority.

Từ những dữ liệu này, hệ thống có thể hỗ trợ tính First Response Time và theo dõi việc đáp ứng SLA theo quy trình doanh nghiệp thiết lập.

Những capability cần xác minh

Kiểm tra định nghĩa của từng Metric

Hai nền tảng đều có thể giới thiệu tính năng Response Time nhưng sử dụng cách tính khác nhau.

Vì vậy, doanh nghiệp cần làm rõ:

• Start Timestamp được xác định tại thời điểm nào?
• End Timestamp được xác định tại thời điểm nào?
• Bot Reply có được tính là First Response không?
• Thời gian ngoài Business Hours được xử lý như thế nào?
• Reopened Conversation có được tính lại thời gian phản hồi không?

Ví dụ, một nền tảng có thể tính thời gian phản hồi từ khi khách hàng gửi tin nhắn, trong khi nền tảng khác bắt đầu tính khi conversation được Assign cho Agent.

Nếu không thống nhất định nghĩa, việc so sánh KPI giữa hai nền tảng có thể dẫn đến kết luận không chính xác.

Không nên so sánh KPI chỉ dựa trên tên Metric.

15. Đánh giá Analytics

Analytics giúp doanh nghiệp chuyển từ việc quan sát conversation riêng lẻ sang theo dõi hiệu suất của toàn bộ Team Operations.

Một bộ Analytics cơ bản nên hỗ trợ trả lời những câu hỏi:

• Có bao nhiêu Conversation trong kỳ?
• Bao nhiêu Conversation mới được tạo?
• Bao nhiêu Conversation đang Pending?
• Bao nhiêu Conversation chưa được Assign?
• Bao nhiêu Conversation đã Resolved?
• First Response Time đang ở mức nào?
• Có bao nhiêu Conversation vi phạm SLA?

Những Dimension cần hỗ trợ

Dữ liệu nên có khả năng được phân tích theo các Dimension liên quan đến mô hình vận hành:

Một hệ thống Analytics hữu ích cần giúp Manager chuyển từ nhận định chủ quan như “Tôi cảm giác Team đang quá tải” sang những câu hỏi dựa trên dữ liệu, chẳng hạn “Pending và Unassigned đang tăng ở Team nào, trên Channel nào và trong khoảng thời gian nào?”.

Dashboard đẹp không đồng nghĩa với Analytics chính xác

Giao diện Dashboard chỉ là lớp trình bày. Chất lượng Analytics phụ thuộc vào độ chính xác của dữ liệu vận hành và phương pháp tính toán.

Doanh nghiệp có thể thực hiện một bài kiểm thử đơn giản:

1. Chọn 10 Conversation thực tế trong bộ dữ liệu Pilot.
2. Ghi nhận thủ công Status, Assignee và những Timestamp liên quan.
3. Đối chiếu kết quả với Dashboard.
4. Kiểm tra cách hệ thống tính toán những Metric tương ứng.

Nếu Dashboard không phản ánh chính xác dữ liệu nguồn, doanh nghiệp cần xác định nguyên nhân trước khi sử dụng các báo cáo này để đánh giá hiệu suất.

16. Đánh giá Integration

Integration giúp hệ thống nhắn tin đa kênh kết nối với những công cụ và nguồn dữ liệu khác trong doanh nghiệp.

Tuy nhiên, không nên đánh giá khả năng tích hợp chỉ bằng tổng số Integration được nhà cung cấp công bố.

Câu hỏi quan trọng hơn là: Những Integration nào thực sự cần thiết để giảm thao tác và cung cấp Relevant Context cho Agent?

Tùy theo mô hình kinh doanh, doanh nghiệp có thể cần kết nối với:

• CRM.
• Order Management System.
• Booking System.
• ERP.
• API.
• Webhook.

Ví dụ, khi khách hàng hỏi về tình trạng đơn hàng, Agent có thể cần xem Relevant Order Context ngay trong Workspace thay vì chuyển sang một hệ thống riêng và tìm kiếm thủ công.

Một Integration phù hợp phải đưa được những dữ liệu cần thiết vào đúng Workflow, đúng thời điểm.

Có API không đồng nghĩa với API đáp ứng được nhu cầu

Nếu API là một Requirement quan trọng, doanh nghiệp cần kiểm tra:

Doanh nghiệp nên kiểm tra API hoặc Integration bằng một Use Case thực tế, thay vì chỉ xác nhận sự tồn tại của tính năng trong tài liệu giới thiệu.

17. Đánh giá Data Portability

Data Portability là khả năng truy xuất và chuyển dữ liệu ra khỏi nền tảng khi doanh nghiệp cần thay đổi hệ thống hoặc sử dụng dữ liệu cho những mục đích khác.

Đây là tiêu chí dễ bị bỏ qua trong giai đoạn lựa chọn phần mềm nhưng có thể ảnh hưởng đáng kể đến Switching Cost trong tương lai.

Một câu hỏi cần đặt ra trước khi ký hợp đồng là:

“Nếu sau ba năm doanh nghiệp muốn chuyển sang nền tảng khác, những dữ liệu quan trọng có thể được xuất ra như thế nào?”

Những nhóm dữ liệu cần kiểm tra

• Customers.
• Conversations.
• Messages.
• Tags.
• Assignments.
• Timestamps.
• Analytics.

Doanh nghiệp nên làm rõ định dạng Export, phạm vi dữ liệu có thể truy xuất, cách duy trì mối quan hệ giữa các Entity và những giới hạn liên quan.

Ví dụ, nếu hệ thống cho phép xuất Message nhưng không cung cấp Conversation ID, Customer Reference hoặc Timestamps liên quan, việc khôi phục Conversation History trên nền tảng mới có thể gặp khó khăn.

Khả năng Export cần được kiểm thử thực tế nếu Data Portability là Requirement quan trọng, thay vì chỉ dựa vào cam kết chung của Vendor.

18. Đánh giá Reliability

Một hệ thống Customer Communication cần được xem là một Operational System vì sự cố có thể ảnh hưởng trực tiếp đến khả năng tiếp nhận và phản hồi khách hàng.

Doanh nghiệp cần xác minh cách nền tảng hoạt động khi xảy ra những tình huống như:

• Channel bị ngắt kết nối.
• Message gửi thất bại.
• Automation không thực thi.
• Agent được phân công không còn hoạt động.
• Customer Data bị thiếu hoặc không khả dụng.

Những capability cần kiểm tra

Kiểm thử Failure thay vì chỉ kiểm thử Happy Path

Trong bản Demo, Vendor thường trình diễn một quy trình thuận lợi: khách hàng gửi Message, Agent phản hồi và hệ thống ghi nhận thành công.

Tuy nhiên, doanh nghiệp cần kiểm tra thêm những tình huống ngoại lệ.

Các tình huống cần thử gồm:

1. Message Failure: Tin nhắn gửi đi không thành công.
2. Channel Disconnect: Một Channel mất kết nối.
3. Inactive Agent: Conversation được phân công cho Agent không còn hoạt động.
4. Missing Customer Data: Dữ liệu khách hàng cần thiết bị thiếu.
5. Automation Failure: Automation Rule không thể thực thi.

Với mỗi tình huống, cần xác minh hệ thống có hiển thị lỗi, cảnh báo đúng người, duy trì dữ liệu cần thiết và hỗ trợ quy trình xử lý tiếp theo hay không.

Khả năng xử lý Exception là yếu tố quan trọng để đánh giá mức độ sẵn sàng của nền tảng khi triển khai trong môi trường Production.

19. Đánh giá Permission và Administration

Một hệ thống có thể mang lại trải nghiệm tốt cho Agent nhưng vẫn tạo ra chi phí vận hành lớn nếu việc quản trị người dùng, phân quyền và cấu hình quá phức tạp.

Vì vậy, doanh nghiệp cần đánh giá cả khả năng sử dụng hằng ngày lẫn khả năng quản trị hệ thống.

Kiểm tra phân quyền theo từng vai trò

Ba nhóm vai trò cơ bản thường gặp là Agent, Team Lead và Admin.

Doanh nghiệp nên sử dụng tài khoản thử nghiệm cho từng vai trò để xác minh những chức năng được phép truy cập và những thao tác bị giới hạn.

Áp dụng Principle of Least Privilege

Principle of Least Privilege là nguyên tắc chỉ cấp cho người dùng những quyền cần thiết để thực hiện công việc của họ.

Khi đánh giá hệ thống, hãy đặt ra những câu hỏi:

• Agent có thể xem và thay đổi những thông tin nào?
• Team Lead có thể Reassign conversation trong phạm vi Team không?
• Ai được phép thay đổi Automation Rules?
• Ai có quyền kết nối hoặc ngắt kết nối Channel?
• Những thay đổi quan trọng có được ghi nhận trong Audit Log không?

Doanh nghiệp không nên phải cấp quyền Admin cho mọi nhân viên chỉ vì hệ thống khó cấu hình Permissions.

Ngược lại, mô hình phân quyền cũng không nên phức tạp đến mức mỗi thay đổi nhỏ đều cần Developer can thiệp.

Mục tiêu là cân bằng giữa khả năng kiểm soát, bảo mật và tính thuận tiện trong quản trị.

20. Đánh giá Agent Experience

Một Capability dù mạnh đến đâu cũng khó tạo ra giá trị nếu Agent không thể sử dụng hiệu quả trong công việc hằng ngày.

Vì vậy, Agent Experience cần được đánh giá bằng những nhân viên thực sự sử dụng hệ thống, thay vì chỉ quan sát bản Demo do Vendor, Manager hoặc IT thực hiện.

Kiểm thử bằng Workflow thực tế

Hãy yêu cầu Agent hoàn thành một quy trình xử lý conversation từ đầu đến cuối:

Find New Conversation → Review Customer → Reply → Assign → Pending → Search History → Transfer → Resolve

Trong quá trình kiểm thử, doanh nghiệp cần quan sát:

• Số thao tác: Agent phải thực hiện bao nhiêu bước để hoàn tất Workflow?
• Độ dễ hiểu: Giao diện và các chức năng có dễ nhận biết không?
• Context Switching: Agent có phải liên tục chuyển đổi giữa nhiều màn hình hoặc hệ thống không?
• Training Time: Nhân viên mới cần bao lâu để thực hiện thành thạo các thao tác cơ bản?

Nên để Agent tự thực hiện quy trình sau phần hướng dẫn ban đầu, đồng thời ghi nhận những bước họ gặp khó khăn hoặc cần người hỗ trợ.

Usability ảnh hưởng trực tiếp đến chi phí vận hành

Giả sử Agent phải thực hiện 10 lần nhấp chuột cho một Workflow lặp lại hàng trăm lần mỗi ngày. Những thao tác tưởng chừng nhỏ này có thể tích lũy thành chi phí đáng kể khi quy mô Team tăng lên.

Do đó, Agent Experience không chỉ là yếu tố giao diện mà còn liên quan trực tiếp đến năng suất và chi phí vận hành.

21. Đánh giá Manager Experience

Manager cần có khả năng quan sát tình hình xử lý conversation của toàn bộ Team để kịp thời phân công, hỗ trợ và giải quyết những trường hợp tồn đọng.

Một Manager Workspace nên cung cấp khả năng theo dõi:

• Queue Visibility.
• Unassigned Conversations.
• Pending Conversations.
• SLA Risk.
• Agent Workload.
• Analytics.

Kiểm thử khả năng quan sát vận hành

Hãy đặt cho Manager một câu hỏi cụ thể:

“Hiện có bao nhiêu Customer Conversations vẫn cần Action?”

Manager có thể tìm được câu trả lời trong vòng một phút không?

Tiếp theo, yêu cầu Manager xác định những conversation chưa có Assignee, những case đang Pending và những yêu cầu có nguy cơ vi phạm SLA.

Nếu Manager phải hỏi từng Agent, mở nhiều báo cáo rồi Export dữ liệu sang Google Sheets để tổng hợp, khả năng quan sát vận hành của hệ thống còn hạn chế.

Một Manager Workspace hữu ích cần giúp người quản lý nhanh chóng nhận diện những vấn đề cần can thiệp, thay vì chỉ hiển thị số lượng Message hoặc Conversation.

22. Đánh giá khả năng mở rộng

Scalability không chỉ là khả năng xử lý một khối lượng Message lớn. Đối với hệ thống nhắn tin đa kênh, khả năng mở rộng còn liên quan đến mô hình tổ chức và mức độ phức tạp của hoạt động vận hành.

Doanh nghiệp cần xem xét khả năng hỗ trợ:

• More Channels.
• More Accounts.
• More Agents.
• More Teams.
• More Workflows.
• More Customers.

Ví dụ, nếu doanh nghiệp tăng từ 3 Agent lên 15 Agent, hệ thống có còn dễ quản lý Assignment, Permissions và Workload không?

Nếu bổ sung một Channel hoặc Team mới, doanh nghiệp có phải cấu hình lại phần lớn Workflow hiện tại không?

Đánh giá Complexity Scalability

Một hệ thống có thể mở rộng tốt về hạ tầng nhưng không mở rộng tốt về cấu hình.

Ví dụ:

5 Agents → Quy trình dễ quản lý

50 Agents → 200 Manual Rules

Nếu mỗi lần bổ sung nhân viên hoặc Team đều đòi hỏi thêm nhiều quy tắc thủ công, chi phí quản trị có thể tăng nhanh theo quy mô tổ chức.

Doanh nghiệp nên kiểm tra khả năng tái sử dụng Rule, quản lý cấu hình tập trung và tổ chức Permissions theo Team hoặc Role.

Khả năng mở rộng phù hợp không chỉ giúp hệ thống xử lý thêm dữ liệu mà còn cho phép độ phức tạp vận hành tăng một cách có kiểm soát.

23. Đánh giá Total Cost of Ownership

Subscription Price chỉ là một phần trong tổng chi phí sở hữu và vận hành hệ thống.

Total Cost of Ownership (TCO) cần tính đến cả những khoản chi phí phát sinh trong quá trình triển khai, sử dụng và bảo trì.

Các thành phần TCO có thể bao gồm:

Ví dụ, System A có License thấp nhưng Integration Cost cao và yêu cầu nhiều công sức quản trị. Trong khi đó, System B có License cao hơn nhưng quy trình triển khai và vận hành đơn giản hơn.

Do đó, doanh nghiệp cần so sánh TCO trong cùng một khoảng thời gian, thay vì chỉ đối chiếu mức phí thuê bao hằng tháng.

Tính cả chi phí của Workaround

Khi hệ thống thiếu một Capability quan trọng, doanh nghiệp có thể phải bổ sung những thao tác thủ công để bù đắp.

Ví dụ, nếu Agent phải cập nhật Google Sheets vì nền tảng không hỗ trợ một trường dữ liệu hoặc báo cáo cần thiết, thời gian thực hiện công việc này cũng là Operational Cost.

Giả sử:

5 Agents × 20 phút/ngày × 22 ngày làm việc = 36,7 giờ/tháng

Đây là lượng thời gian doanh nghiệp cần tính đến khi đánh giá Feature Gap.

Một hạn chế về tính năng không chỉ gây bất tiện mà còn có thể tạo ra chi phí lặp lại trong suốt quá trình sử dụng.

24. Đánh giá Time-to-Value

Time-to-Value là khoảng thời gian từ khi doanh nghiệp bắt đầu triển khai đến khi hệ thống tạo ra giá trị vận hành theo những mục tiêu đã xác định.

Đối với hệ thống nhắn tin đa kênh, doanh nghiệp nên xác định những công việc cần hoàn thành trước khi Core Workflow có thể hoạt động ổn định.

Các công việc thường bao gồm:

Setup → Channel Connection → Migration → Workflow Configuration → Training → Pilot

Khi đánh giá, cần làm rõ những Dependency có thể ảnh hưởng đến tiến độ:

• Ai chịu trách nhiệm kết nối các Channel?
• Có cần Migration dữ liệu lịch sử không?
• Workflow có thể cấu hình bằng công cụ sẵn có hay cần phát triển riêng?
• Agent và Manager cần được đào tạo trong bao lâu?
• Những điều kiện nào xác định Pilot đã hoàn thành?

Hệ thống có thời gian Setup ngắn nhất không nhất thiết là lựa chọn phù hợp với mọi doanh nghiệp.

Tuy nhiên, nếu một SME có 5 nhân viên phải mất sáu tháng chỉ để cấu hình một Core Workflow đơn giản, doanh nghiệp cần xem xét mức độ phù hợp giữa độ phức tạp của sản phẩm và nhu cầu thực tế.

25. Đánh giá Vendor và Product Support

Khi hệ thống nhắn tin đa kênh trở thành Operational Workspace, chất lượng hỗ trợ từ Vendor có thể ảnh hưởng trực tiếp đến khả năng duy trì hoạt động.

Điều này đặc biệt quan trọng đối với những thành phần như:

• Channel Integration.
• API.
• Automation.
• Message Delivery.

Những nội dung cần kiểm tra

Doanh nghiệp nên yêu cầu Vendor giải thích quy trình xử lý một sự cố cụ thể, chẳng hạn Channel mất kết nối hoặc Message Delivery bị gián đoạn.

Product Support không nên là tiêu chí duy nhất quyết định việc lựa chọn nền tảng, nhưng cũng không nên bị bỏ qua khi đánh giá khả năng vận hành lâu dài.

26. Xây dựng Scorecard đánh giá hệ thống nhắn tin đa kênh

Sau khi hoàn thành các bước kiểm thử, doanh nghiệp cần tổng hợp kết quả thành một Scorecard thống nhất để đối chiếu các nền tảng theo cùng một bộ yêu cầu.

Scorecard nên phản ánh mức độ đáp ứng những Use Case đã xác định từ đầu, thay vì chỉ ghi nhận số lượng tính năng mà Vendor giới thiệu.

Thang điểm đánh giá từng tiêu chí

Có thể sử dụng thang điểm từ 0 đến 5:

Điểm số cần được ghi nhận dựa trên kết quả Demo, Pilot hoặc những bằng chứng có thể xác minh.

Không phải tiêu chí nào cũng có mức độ quan trọng như nhau. Do đó, doanh nghiệp nên xác định Weight cho từng nhóm theo nhu cầu vận hành.

Scorecard tham khảo với tổng trọng số 100 điểm

Đây là bộ trọng số tham khảo. Doanh nghiệp cần điều chỉnh dựa trên những Use Case và Critical Requirements của mình.

Ví dụ:

• CSKH: Có thể tăng trọng số cho Assignment, Pending và SLA.
• Sales: Có thể tăng trọng số cho Lead Ownership, Customer Context và CRM Integration.
• Retail: Có thể tăng trọng số cho Product Context và Order Context.

Công thức tính điểm quy đổi

Với mỗi nhóm tiêu chí, điểm quy đổi được tính bằng:

Điểm quy đổi = (Điểm đánh giá / 5) × Trọng số

Ví dụ, một nhóm có Weight = 10 và Score = 4/5:

4 / 5 × 10 = 8 điểm

Điểm tổng của hệ thống bằng tổng điểm quy đổi của tất cả nhóm tiêu chí:

System Score = Σ Weighted Criteria

Doanh nghiệp có thể sử dụng cùng một bảng để đối chiếu nhiều nền tảng, đồng thời lưu lại ghi chú và bằng chứng cho từng điểm đánh giá.

Critical Gate quan trọng hơn điểm tổng

Điểm tổng không nên thay thế những Requirement bắt buộc.

Ví dụ, System A đạt 88/100 điểm nhưng không hỗ trợ Zalo, trong khi Zalo là Channel tiếp nhận phần lớn conversation của doanh nghiệp.

Trong trường hợp này, System A không đáp ứng một Requirement quan trọng, dù tổng điểm ở những tiêu chí khác cao.

Tương tự, một nền tảng đạt 90/100 điểm nhưng không có Assignment phù hợp sẽ không đáp ứng yêu cầu vận hành của doanh nghiệp có 20 Agents cùng xử lý conversation.

Vì vậy, doanh nghiệp cần xác định trước danh sách Critical Requirements và đánh dấu từng yêu cầu theo trạng thái:

Pass / Fail

Chỉ những nền tảng vượt qua tất cả Critical Gates mới được đưa vào bước so sánh điểm tổng.

Cách tiếp cận này giúp doanh nghiệp tránh lựa chọn một hệ thống có nhiều tính năng bổ sung nhưng thiếu Capability thiết yếu cho Workflow thực tế.

Template Critical Requirements: Xác định những yêu cầu không được thiếu

Trước khi so sánh điểm tổng, doanh nghiệp cần xác định những Requirement bắt buộc đối với hệ thống nhắn tin đa kênh.

Một nền tảng có thể đáp ứng rất tốt nhiều tiêu chí nhưng vẫn không phù hợp nếu thiếu Channel hoặc Capability cốt lõi của doanh nghiệp.

Ví dụ, bảng Critical Requirements dưới đây giúp kiểm tra hai hệ thống theo cùng một bộ yêu cầu:

Trong ví dụ này, System B không đáp ứng yêu cầu Zalo, dù đây là Channel bắt buộc. Vì vậy, hệ thống có thể bị loại ngay tại Critical Gate mà không cần tiếp tục so sánh những tính năng bổ sung.

Đối với các Requirement chưa được xác minh đầy đủ, chẳng hạn Pending Queue được đánh dấu ⚠️, doanh nghiệp nên yêu cầu Demo hoặc Pilot trước khi xác nhận Pass / Fail.

Đừng so sánh Vendor bằng bảng 200 Features

Một bảng tính gồm hàng trăm dòng tính năng có thể tạo cảm giác quá trình đánh giá rất chi tiết và khách quan.

Tuy nhiên, nếu mọi Feature đều được chấm điểm như nhau, một tính năng nhỏ có thể có ảnh hưởng tương đương một Capability bắt buộc đối với hoạt động kinh doanh.

Ví dụ, khả năng thay đổi giao diện và khả năng quản lý Assignment không nên mặc nhiên có trọng số bằng nhau nếu doanh nghiệp có nhiều Agent cùng xử lý conversation.

Thay vì bắt đầu bằng một danh sách tính năng dài, hãy xây dựng chuỗi đánh giá:

Business Requirement → Capability → Scenario → Evidence

Trong đó:

• Business Requirement: Doanh nghiệp cần giải quyết vấn đề gì?
• Capability: Hệ thống phải có khả năng nào để đáp ứng yêu cầu?
• Scenario: Tình huống nào có thể kiểm tra Capability đó?
• Evidence: Bằng chứng nào xác nhận hệ thống thực sự đáp ứng?

Cách tiếp cận này giúp mỗi điểm đánh giá gắn với một nhu cầu vận hành cụ thể thay vì chỉ dựa trên danh sách tính năng do Vendor cung cấp.

Scenario-based Evaluation và Feature-based Evaluation

Feature-based Evaluation thường bắt đầu bằng câu hỏi: “Hệ thống có Assignment không?”

Scenario-based Evaluation đi xa hơn bằng cách yêu cầu Vendor thực hiện một quy trình hoàn chỉnh.

Ví dụ:

1. Khách hàng gửi tin nhắn qua Facebook.
2. Conversation xuất hiện trong Unassigned Queue.
3. Team Lead Assign conversation cho Agent A.
4. Agent A nghỉ hoặc không thể tiếp tục xử lý.
5. Team Lead chuyển conversation sang Agent B.
6. Agent B tiếp nhận và xem được toàn bộ Conversation History.

Một Scenario như vậy đồng thời kiểm tra Channel, Conversation Model, Queue, Assignment, Permissions và Customer History.

Quan trọng hơn, nó cho biết các Capability có phối hợp được với nhau trong một Workflow thực tế hay không.

Doanh nghiệp nên sử dụng cùng một Scenario và cùng bộ Expected Results cho mọi Vendor để kết quả có thể đối chiếu.

Bộ 10 Scenario nên sử dụng khi Demo

Một Demo Script thống nhất giúp doanh nghiệp kiểm tra các hệ thống trên cùng điều kiện, hạn chế việc mỗi Vendor chỉ trình diễn những tính năng nổi bật của riêng mình.

Scenario 1 — New Conversation

Customer → Core Channel → New Conversation

Khách hàng gửi tin nhắn qua một Channel bắt buộc. Kiểm tra Message có được tiếp nhận và Conversation có xuất hiện trong Inbox hay không.

Scenario 2 — Unassigned

Tạo một Conversation mới chưa được phân công.

Kiểm tra Conversation có xuất hiện trong Unassigned Queue và Team Lead có thể nhìn thấy hay không.

Scenario 3 — Assignment

Unassigned → Agent A

Assign Conversation cho Agent A. Kiểm tra Agent có nhận được Conversation và có thể bắt đầu xử lý ngay không.

Scenario 4 — Pending

Agent Reply → Waiting Customer → Pending

Agent phản hồi rồi chuyển Conversation sang Pending. Kiểm tra Case có tiếp tục xuất hiện trong Pending Queue để được theo dõi hay không.

Scenario 5 — Customer History và Reopen

Khách hàng quay lại sau khi Conversation trước đã được xử lý.

Kiểm tra Agent có xem được lịch sử tương tác và hệ thống có xử lý Reopen đúng theo cấu hình không.

Scenario 6 — Team Handoff

Sales → CSKH

Chuyển một Conversation từ Sales sang CSKH. Kiểm tra Conversation History, Customer Context và những thông tin cần thiết có được giữ nguyên không.

Scenario 7 — Automation

Complaint → High Priority → CSKH

Kiểm tra Rule tự động phân loại và chuyển Conversation. Thực hiện cả Positive Case và Negative Case để xác minh Rule không kích hoạt sai.

Scenario 8 — SLA

Tạo một Case sắp vượt thời hạn xử lý hoặc mô phỏng tình huống SLA Breach.

Kiểm tra Alert, Timestamp và Report có phản ánh đúng cấu hình SLA không.

Scenario 9 — Failure

Mô phỏng Channel Disconnect hoặc Message Delivery Failure.

Kiểm tra Agent và Admin có nhận biết được sự cố, nhìn thấy trạng thái lỗi và có hướng xử lý tiếp theo không.

Scenario 10 — Analytics

Sau khi hoàn thành các Scenario trước, mở Dashboard và đối chiếu dữ liệu.

Kiểm tra số lượng Conversation, Status, Assignment, Response Time và những chỉ số liên quan có phản ánh chính xác những gì vừa diễn ra không.

Demo Script có thể sao chép sang Google Sheets

Doanh nghiệp có thể ghi Pass, Fail hoặc Needs Verification cho từng Scenario. Cột Evidence nên lưu kết quả kiểm thử, ảnh chụp màn hình hoặc ghi chú từ buổi Demo.

Demo chưa đủ: Cần kiểm chứng bằng Pilot

Demo thường diễn ra trong Controlled Environment với dữ liệu và tình huống đã được chuẩn bị trước.

Trong khi đó, Pilot cho phép doanh nghiệp quan sát hệ thống khi được sử dụng bởi Real Agents, với Real Customers và Real Workflows.

Một nền tảng hoạt động tốt trong Demo vẫn có thể phát sinh vấn đề khi gặp Traffic thực tế, Conversation History dài, nhiều Agent, Duplicate Customer Profiles hoặc Channel Disconnect.

Vì vậy, những hệ thống trong Shortlist cuối nên được kiểm chứng qua Pilot nếu điều kiện triển khai cho phép.

Xác định Pilot Scope vừa đủ

Doanh nghiệp không nhất thiết phải triển khai toàn bộ Channel, Team và Automation ngay từ đầu.

Ví dụ, một Pilot có thể giới hạn trong phạm vi:

Phạm vi này cho phép doanh nghiệp tập trung vào những Core Workflows và Critical Requirements trước khi mở rộng triển khai.

Những chỉ số cần đo trong Pilot

Bên cạnh các KPI liên quan đến khách hàng, doanh nghiệp nên theo dõi cả những vấn đề vận hành:

• Agent Adoption.
• Manual Workarounds.
• Assignment Errors.
• Pending Errors.
• Message Failures.
• Automation Errors.
• Time to Complete Tasks.

Ví dụ, nếu Agent vẫn phải sử dụng Google Sheets để xác định ai đang phụ trách từng Conversation, doanh nghiệp cần kiểm tra lại mức độ phù hợp của hệ thống hoặc cách cấu hình Assignment.

Kết quả Pilot nên được đối chiếu với Expected Results đã xác định trước, thay vì chỉ dựa trên cảm nhận chung của người tham gia.

Bảy Red Flags khi đánh giá hệ thống nhắn tin đa kênh

Những dấu hiệu dưới đây có thể giúp doanh nghiệp xác định các vấn đề cần kiểm tra kỹ hơn trong quá trình Demo và Pilot.

Một Red Flag không tự động đồng nghĩa hệ thống phải bị loại. Tuy nhiên, doanh nghiệp nên ghi nhận các dấu hiệu này trong Risk Assessment, xác định mức độ ảnh hưởng và yêu cầu thêm bằng chứng trước khi ra quyết định.

Điều chỉnh tiêu chí đánh giá theo từng Use Case

Không có một bộ trọng số phù hợp với mọi doanh nghiệp. Một SME có ba Agent sẽ có nhu cầu vận hành khác với một Team CSKH lớn hoặc một hệ thống Retail có nhiều cửa hàng.

Do đó, doanh nghiệp cần điều chỉnh Scorecard theo Use Case thực tế.

SME có 1–3 Agents

Những Capability cần xem xét gồm Ease of Use, Core Channels, Unified Inbox, Conversation Management, Manual Assignment, Customer History và Cost.

AI không nhất thiết phải có trọng số cao nếu những nhu cầu nền tảng vẫn chưa được đáp ứng.

Team Sales

Những Capability liên quan gồm Lead Conversation Visibility, Assignment, Unassigned Queue, Customer Context, Follow-up, CRM Integration và Response Time.

Trọng tâm là khả năng tiếp nhận, phân công và theo dõi Lead xuyên suốt quá trình tư vấn.

Team CSKH

Những Capability cần xem xét gồm Queue, Pending, Assignment, SLA, Handoff, Customer History, Escalation và Analytics.

Các tiêu chí này hỗ trợ quản lý những yêu cầu kéo dài, phân công trách nhiệm và theo dõi chất lượng dịch vụ.

Marketing

Những Capability liên quan gồm Customer Context, Tags, Segmentation, Automation, Source Context và Sales / CSKH Handoff.

Tuy nhiên, hệ thống nhắn tin đa kênh nên được đánh giá theo vai trò trong Customer Communication, thay vì mặc nhiên xem nó là một Advertising Platform tổng quát.

Retail

Những Capability cần xem xét gồm Product Context, Customer History, Assignment, Order Context và Sales-to-CSKH Handoff.

Mục tiêu là duy trì Context từ giai đoạn tư vấn sản phẩm đến mua hàng và hỗ trợ sau mua.

Service Business

Những Capability liên quan gồm Service Context, Assignment, Pending, Follow-up, Booking / Case Integration và Handoff.

Doanh nghiệp cần kiểm tra khả năng kết nối Conversation với quy trình cung cấp dịch vụ thực tế.

Feature Fit Matrix tham khảo

Các mức độ trong bảng chỉ là Framework tham khảo. Critical Requirements và Workflow thực tế của từng doanh nghiệp luôn cần được xác định riêng.

Mô hình hóa System Fit bằng EAV

Entity–Attribute–Value (EAV) là một cách biểu diễn các đặc điểm của hệ thống dưới dạng Entity, Attribute và Value.

Thay vì chỉ mô tả một hệ thống bằng tổng số tính năng, doanh nghiệp có thể ghi nhận những Attribute liên quan trực tiếp đến Use Case cần đánh giá.

Ví dụ:

Theo cách này, mỗi Requirement có thể được mô tả bằng:

Entity + Relevant Attributes + Required Values

Ví dụ, thay vì ghi chung chung “Hỗ trợ Automation”, doanh nghiệp có thể yêu cầu rõ:

• Automation hỗ trợ Trigger = New Conversation.
• Automation hỗ trợ Condition = Tag.
• Automation hỗ trợ Action = Assign Team.

Cách mô tả này giúp Requirement cụ thể hơn, dễ truy vết và dễ xác minh trong Demo hoặc Pilot.

Xây dựng bảng đánh giá hoàn chỉnh

Sau khi xác định Use Cases, Critical Requirements và những Capability cần kiểm tra, doanh nghiệp có thể tổng hợp tất cả vào một bảng đánh giá thống nhất.

Các cột gợi ý gồm:

Các giá trị Weight trong bảng là ví dụ ở cấp Requirement, không phải bộ trọng số 100 điểm đã trình bày ở phần Scorecard. Doanh nghiệp cần chuẩn hóa cách phân bổ trọng số trước khi tính điểm tổng.

Quy ước mã nhóm Requirement

Mã Requirement giúp doanh nghiệp liên kết một yêu cầu với Demo Scenario, Pilot Test, Evidence và kết quả đánh giá cuối cùng.

Quy trình 7 bước lựa chọn hệ thống nhắn tin đa kênh

Để quá trình đánh giá nhất quán, doanh nghiệp có thể triển khai theo bảy bước.

Bước 1 — Audit Current State

Xác định những vấn đề đang tồn tại trong hoạt động Customer Communication.

Ví dụ: nhiều Inbox rời rạc, Ownership không rõ ràng, Pending bị bỏ quên hoặc thiếu Customer History.

Bước 2 — Xây dựng Use Cases

Mô tả những Workflow quan trọng mà hệ thống cần hỗ trợ.

Không nên bắt đầu bằng một danh sách tính năng dài trước khi xác định nhu cầu vận hành.

Bước 3 — Xác định Critical Requirements

Liệt kê những Channel và Capability không thể thiếu.

Mỗi Critical Requirement cần có Expected Result và cách xác minh rõ ràng.

Bước 4 — Shortlist

Đối chiếu các nền tảng với Critical Requirements để xác định những hệ thống đủ điều kiện bước vào vòng đánh giá tiếp theo.

Bước 5 — Scenario Demo

Sử dụng cùng một Demo Script cho mọi Vendor.

Ghi nhận kết quả, bằng chứng và những vấn đề chưa được xác minh.

Bước 6 — Pilot

Cho Agent thực tế sử dụng hệ thống với những Core Workflows đã xác định.

Theo dõi cả kết quả phục vụ khách hàng lẫn các vấn đề vận hành phát sinh.

Bước 7 — Đánh giá Score, Risk và TCO

Tổng hợp điểm số, những rủi ro còn tồn tại, chi phí sở hữu và kết quả Pilot trước khi ra quyết định.

Những sai lầm cần tránh khi lựa chọn hệ thống

Không lựa chọn chỉ dựa trên Subscription Price

Giả sử System A có phí thuê bao 500 và System B có phí thuê bao 800 trong cùng một kỳ thanh toán.

Điều đó không tự động có nghĩa System A có tổng chi phí thấp hơn.

Nếu System A yêu cầu thêm Manual Sheets, nhiều công sức Administration hoặc Integration Work, TCO thực tế có thể cao hơn.

Doanh nghiệp cần so sánh các khoản chi phí trong cùng phạm vi và cùng khoảng thời gian.

Không lựa chọn chỉ vì có AI

Một AI Feature hữu ích không thay thế được những Capability nền tảng nếu doanh nghiệp đang gặp vấn đề về Assignment, Pending hoặc Customer History.

Có thể tổ chức quá trình đánh giá theo bốn lớp:

Foundation → Operations → Measurement → Intelligence

Trong đó, doanh nghiệp xác minh các Capability cốt lõi trước khi xem xét giá trị bổ sung từ AI và những tính năng nâng cao.

Không lựa chọn chỉ vì nhãn All-in-one

All-in-one chỉ có ý nghĩa khi những Capability tích hợp thực sự đáp ứng được Workflow của doanh nghiệp.

Nếu mỗi Module hoạt động riêng lẻ hoặc quá trình chuyển giao giữa các Module không duy trì được Context, hệ thống vẫn có thể tạo ra những điểm đứt gãy trong vận hành.

=> All-in-one không tự động đồng nghĩa với One Operating Model.

Không lựa chọn chỉ dựa trên Review

Review từ người dùng khác có thể giúp phát hiện những vấn đề cần kiểm tra, nhưng kết quả sử dụng phụ thuộc vào quy mô và Operating Model của từng doanh nghiệp.

Ví dụ, một Review từ doanh nghiệp có 2 Agents sử dụng Facebook và Instagram chưa chắc phản ánh được nhu cầu của một doanh nghiệp có 50 Agents, cần Zalo, Website Chat và Sales / CSKH Handoff.

Vì vậy, Review nên được sử dụng như một nguồn tham khảo để xây dựng câu hỏi kiểm thử. Mức độ phù hợp của hệ thống vẫn cần được xác minh bằng Use Cases, Demo và Pilot của chính doanh nghiệp.

Bộ câu hỏi nên hỏi Vendor khi đánh giá hệ thống nhắn tin đa kênh

Khi làm việc với Vendor, doanh nghiệp không nên chỉ hỏi hệ thống có hỗ trợ một tính năng hay không. Những câu hỏi hữu ích cần làm rõ phạm vi hỗ trợ, giới hạn, cách vận hành và khả năng xử lý các tình huống ngoại lệ.

Những câu hỏi về tình huống ngoại lệ

Những câu hỏi về Exception thường giúp doanh nghiệp hiểu rõ hơn chiều sâu của hệ thống so với việc chỉ xác nhận tính năng có tồn tại.

Với những câu hỏi quan trọng, doanh nghiệp nên yêu cầu Vendor thực hiện Demo, cung cấp tài liệu kỹ thuật hoặc xác minh trong Pilot. Câu trả lời bằng lời nói chưa nên được xem là bằng chứng hệ thống đáp ứng đầy đủ Requirement.

Checklist 60 giây trước khi ký hợp đồng

Checklist dưới đây tổng hợp 15 nội dung cần rà soát sau khi hoàn thành Demo và Pilot. Bạn có thể đánh dấu trực tiếp từng mục.

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

Tóm lại

Đánh giá một hệ thống nhắn tin đa kênh không nên đơn thuần là so sánh số lượng tính năng giữa các nền tảng.

Ví dụ:

System A: 100 Features

System B: 80 Features

Không thể chỉ dựa vào số lượng tính năng để kết luận System A phù hợp hơn System B.

Thay vào đó, doanh nghiệp cần bắt đầu từ nhu cầu kinh doanh, xác định những Use Case quan trọng và kiểm chứng khả năng đáp ứng của từng hệ thống thông qua một quy trình đánh giá có cấu trúc.

Quy trình đánh giá gồm tám bước:

Business Need → Use Case → Required Attributes → Critical Gate → Scenario Test → Pilot → TCO → Decision

Cách tiếp cận này giúp doanh nghiệp xác định hệ thống có thực sự hỗ trợ những Workflow cần thiết, đáp ứng các yêu cầu bắt buộc và phù hợp với chi phí vận hành hay không.

Những nhóm Capability quan trọng

Khi đánh giá hệ thống nhắn tin đa kênh, doanh nghiệp cần xem xét các nhóm Capability cốt lõi:

Các Capability này cần được đánh giá trong mối liên hệ với nhau, thay vì xem xét như những tính năng độc lập.

Một hệ thống có nhiều tính năng chưa chắc đã đáp ứng tốt những nhu cầu quan trọng nhất của doanh nghiệp.

Điều cần tìm kiếm là một nền tảng giúp doanh nghiệp vận hành các Customer Conversations quan trọng với ít Friction, rõ Ownership, đầy đủ Customer Context và dữ liệu đáng tin cậy.

Vì vậy, hai nguyên tắc cốt lõi khi lựa chọn hệ thống nhắn tin đa kênh là:

SYSTEM FIT > FEATURE COUNT

REAL WORKFLOW EVIDENCE > SALES DEMO

Quyết định lựa chọn nên dựa trên mức độ phù hợp với nhu cầu thực tế và những bằng chứng đã được xác minh thông qua Scenario Test và Pilot, thay vì chỉ dựa vào số lượng tính năng hoặc nội dung trình diễn của Vendor.