Cách thiết kế hệ thống giao tiếp đa kênh cho SME

Cách thiết kế hệ thống giao tiếp đa kênh cho SME

Một hệ thống giao tiếp đa kênh cho SME nên xoay quanh Conversation và Customer, thay vì từng ứng dụng riêng lẻ. Channel là nguồn tiếp nhận; phía sau cần một mô hình thống nhất để quản lý conversation, ownership, trạng thái, customer context, workflow và analytics.

Mục tiêu không phải xây kiến trúc phức tạp nhất, mà là tạo một operating model đủ rõ để doanh nghiệp luôn biết khách đến từ đâu, conversation nào cần xử lý, khách là ai, ai phụ trách, trạng thái hiện tại và bước tiếp theo.

Nguyên tắc đầu tiên: đừng bắt đầu thiết kế từ danh sách phần mềm

Cách tiếp cận tool-first dễ dẫn tới nhiều Channel, Tool, Inbox và Workflow nhưng thiếu operating model thống nhất.

CUSTOMER → CONVERSATION → BUSINESS PROCESS → AGENT / TEAM → CHANNEL

Hãy xác định khách liên hệ để làm gì và conversation cần được xử lý thế nào trước khi chọn phần mềm. Với các nhóm như Hỏi sản phẩm, Đặt hàng và Hỗ trợ sau mua, workflow nên được xác định trước; Channel chỉ là nguồn vào.

Nếu chưa rõ failure mode cần xử lý, xem Những vấn đề khi quản lý nhiều kênh riêng biệt.

Một hệ thống SME cần những lớp nào?

Về mặt thiết kế, có thể nhìn hệ thống qua 8 lớp:

1. Channel — khách liên hệ từ đâu?
2. Message — khách vừa gửi gì?
3. Conversation — những message nào thuộc cùng một cuộc trao đổi?
4. Customer Context — người đang nói chuyện là ai?
5. Operations — conversation đang ở trạng thái nào và ai phụ trách?
6. Workflow — cần xử lý theo logic nào?
7. Automation — phần nào có thể tự động hóa?
8. Analytics — hệ thống đang vận hành ra sao?

Không phải SME nào cũng cần đủ capability ngay từ đầu; quan trọng là các lớp phải có vai trò rõ để tránh mua nhiều tính năng nhưng thiếu operating model.

Thiết kế phạm vi Channel trước

Không nên kết nối mọi Channel chỉ vì chúng tồn tại. Hãy phân biệt channel khách đang dùng với channel doanh nghiệp có thể kết nối.

• Ưu tiên channel có volume hoặc giá trị cao.
• Bắt đầu từ phạm vi thực tế, rồi mở rộng khi operating model ổn định.
• Tránh over-engineering ngay từ đầu.

Nguyên tắc: thiết kế architecture cho nhu cầu hiện tại và khả năng mở rộng gần nhất, không theo danh sách channel tối đa.

Channel nên được xem là Source, không phải toàn bộ workflow

CHANNEL → CONVERSATION → BUSINESS CONTEXT → WORKFLOW

Ví dụ một conversation có Channel = Facebook, Intent = Complaint, Priority = High, Team = CSKH. Workflow nên phụ thuộc nhiều hơn vào loại yêu cầu, customer type, priority và business process; ít phụ thuộc hơn vào ứng dụng gửi message.

Thiết kế Conversation làm đơn vị vận hành chính

Message là đơn vị giao tiếp; Conversation nên là đơn vị công việc. Nhiều message của cùng một khách nên được gom vào một conversation thay vì tạo nhiều task rời.

MESSAGE 1 + MESSAGE 2 + MESSAGE 3 → CONVERSATION

Conversation tối thiểu cần gắn với Channel, Customer, Status, Assignee, Team, Priority, Tags, Created Time và SLA. Nếu chỉ quản lý Message, doanh nghiệp sẽ khó triển khai assignment, pending, handoff, SLA, workload và resolution.

Một Conversation tối thiểu nên có những thuộc tính gì?

• Conversation ID
• Channel
• Customer
• Status
• Assignee
• Team
• Priority
• Tags
• Created At / Updated At
• Last Message At
• First Reply At
• Resolved At

Không nhất thiết dùng mọi field ngay; cần xác định rõ attribute nào tạo thành operational state.

Thiết kế một Unified Inbox hoặc Queue vận hành chung

Khi Conversation là đơn vị công việc, doanh nghiệp cần một nơi để nhìn và xử lý chúng. Không nhất thiết mọi người phải thấy mọi conversation.

• All Conversations
• My Conversations
• Unassigned
• New
• Pending
• VIP
• Complaint
• SLA Risk

Một workspace tốt trả lời đồng thời ba câu hỏi: cần xử lý conversation nào, khách đang nói gì và người đang nói là ai.

Thiết kế Conversation Status trước khi nghĩ đến Automation

Read/Unread không phải state vận hành. Một state model đơn giản nên đủ rõ để agent biết conversation đang ở đâu.

NEW → IN PROGRESS → PENDING → RESOLVED

Có thể thêm REOPENED nếu khách nhắn lại sau khi conversation đã hoàn tất.

Một state model đơn giản nên trả lời điều gì?

New

Conversation mới, chưa bắt đầu xử lý.

In Progress

Đã có agent chịu trách nhiệm và đang xử lý.

Pending

Chưa thể hoàn tất vì đang chờ khách, kho, kế toán, kỹ thuật hoặc bộ phận khác.

Resolved

Không còn hành động hiện tại cần thực hiện.

Status phải biểu diễn “còn việc hay không”

Status phải giúp agent biết bước tiếp theo. Chỉ tách Pending thành các trạng thái nhỏ hơn khi chúng thực sự tạo khác biệt trong vận hành; nếu không, dùng Pending kết hợp Reason/Tag.

Nguyên tắc: state model càng đơn giản càng tốt, miễn vẫn biểu diễn đúng trạng thái công việc.

Thiết kế Ownership và Assignment

CONVERSATION → TEAM → ASSIGNEE

Hệ thống phải luôn trả lời được ai chịu trách nhiệm chính. Conversation chưa được nhận cần xuất hiện trong Unassigned Queue.

SME nên phân công theo cách nào?

Theo channel

Phù hợp khi team thực sự chuyên môn hóa theo channel.

Facebook → Team A

Zalo → Team B

Theo chức năng

Thường phù hợp hơn khi business process quan trọng hơn channel.

Sales Inquiry → Sales

Complaint → CSKH

Theo agent

Phù hợp với đội nhỏ.

Tự động

New Conversation → Rule → Agent / Team

Chỉ tự động khi logic Assignment đã rõ và được team thống nhất.

Thiết kế Customer Context

CUSTOMER → CONVERSATIONS → MESSAGES

Customer Profile cơ bản có thể gồm:

• Name
• Phone
• Email
• Channel Identities
• Tags
• Customer Type
• Conversation History
• Order Information
• Notes

Mục tiêu không phải xây Customer 360 ngay, mà cung cấp đủ context để agent không phải hỏi lại thông tin doanh nghiệp đã biết.

Customer Context nên xuất hiện ngay cạnh Conversation

Agent nên có thể nhìn nhanh WHO + WHAT + HISTORY thay vì chỉ thấy CURRENT MESSAGE. Ví dụ cạnh conversation có thể hiển thị tên, phone, tags, số conversation trước và trạng thái đơn hàng.

Không nên cố hợp nhất Customer khi chưa đủ dữ liệu

Same Name ≠ Same Customer. Identity Resolution nên dựa trên dữ liệu đáng tin cậy như số điện thoại, email, account linkage, xác nhận của agent hoặc identifier phù hợp.

Thiết kế hệ thống Tag nhỏ và có taxonomy

Tag nên có nhóm rõ thay vì tạo nhiều synonym như VIP, Khách VIP, Quan trọng, VIP khách cũ.

Customer Type

• VIP
• Returning
• New

Intent

• Product Inquiry
• Price Inquiry
• Order
• Complaint
• Support

Product

• Product A
• Product B
• Product C

Tag phải phục vụ một mục đích vận hành

Trước khi tạo Tag, hãy hỏi nó được dùng để làm gì. Một Tag tốt có thể phục vụ Classification, Routing, Priority, Segmentation, Analytics hoặc Automation.

Nếu một field xứng đáng trở thành dữ liệu cấu trúc riêng, đừng biến nó thành tag chỉ vì tiện.

Thiết kế Priority riêng với Status

Status trả lời conversation đang ở đâu trong vòng đời; Priority trả lời cần được chú ý ở mức nào.

• Low
• Normal
• High
• Urgent

Với SME nhỏ, Normal và High có thể đã đủ. Priority nên dựa trên business context, ví dụ Complaint + VIP hoặc case vượt SLA threshold.

Nếu mọi conversation đều High Priority thì thực tế không còn Priority.

Priority nên dựa trên business context

Complaint + VIP → High Priority

Waiting > SLA threshold → High Priority

Thiết kế workflow trước khi tự động hóa

Workflow mô tả conversation đi từ lúc xuất hiện đến khi hoàn tất.

NEW CONVERSATION → CLASSIFY → ASSIGN → AGENT REVIEW → REPLY → PENDING / RESOLVED

Sales có thể có flow riêng: NEW LEAD → QUALIFY → ASSIGN SALES → CONSULT → FOLLOW-UP → CONVERT / CLOSE. Workflow nên theo business process, không phải mỗi channel một workflow hoàn toàn khác.

Một workflow cần xác định bốn thứ

Trigger

Điều gì bắt đầu workflow? Ví dụ: New Conversation.

Classification

Conversation thuộc loại nào? Ví dụ: Sales, Support, Complaint.

Ownership

Team hoặc Agent nào xử lý?

Exit Condition

Khi nào công việc được xem là hoàn tất? Ví dụ: Resolved.

Thiết kế SLA sau khi State và Ownership đã rõ

Conversation → Status → Assignment → Timestamps → SLA

First Response Time cần Created → First Agent Reply. Resolution Time cần Created → Resolved. SLA nên được xây sau khi State và Ownership đã rõ, không phải mua dashboard SLA trước.

SME nên bắt đầu SLA đơn giản thế nào?

• First Response Time
• Resolution / Follow-up Control

Ví dụ target: Normal = 30 phút; High = 10 phút. Con số thực tế phải dựa trên ngành, staffing, giờ hoạt động, kỳ vọng khách hàng và năng lực team.

Thiết kế Quick Reply và Knowledge ở nơi phù hợp

Các câu hỏi lặp lại như giá, tồn kho, thời gian giao, đổi trả hoặc địa chỉ có thể dùng Quick Reply.

KNOWLEDGE → QUICK REPLY → AGENT REVIEW → PERSONALIZE → SEND

Knowledge Base, Quick Reply và AI nên là lớp hỗ trợ agent. Nếu câu trả lời phụ thuộc context, agent cần điều chỉnh trước khi gửi.

Chỉ thêm Automation sau khi manual workflow đã ổn định

Automation có thể gồm Auto Reply, Auto Tag, Auto Assign, Auto Priority, Auto Notify và AI Bot. Nhưng trước hết phải trả lời được: con người xử lý thủ công theo rule nào?

CLEAR MANUAL RULE → STABLE WORKFLOW → AUTOMATION CANDIDATE

Automation nên ưu tiên những rule đơn giản, lặp lại

• New Conversation + Channel = Website + Intent = Sales → Assign Sales Team.
• New Conversation + Tag = VIP → Priority = High.
• Waiting > X minutes + Status = New → Notify Supervisor.

Một vài automation đáng tin cậy thường tốt hơn hệ thống nhiều nhánh mà không ai hiểu.

Thiết kế Analytics từ câu hỏi quản trị

Đừng bắt đầu từ việc dashboard có biểu đồ gì. Hãy bắt đầu từ quyết định manager cần đưa ra.

• Bao nhiêu conversation mới?
• Bao nhiêu chưa có owner?
• Bao nhiêu Pending?
• Channel nào quá tải?
• Agent nào có workload cao?
• Response Time và SLA có đạt không?

Bộ metric SME tối thiểu

• Conversation Volume
• New Conversations
• Resolved Conversations
• Pending Conversations
• Unassigned Conversations
• First Response Time
• Resolution Time
• SLA Compliance

Có thể phân tích theo Channel, Team, Agent, Time, Tag và Priority. Không cần 50 KPI nếu 8 KPI cơ bản vẫn chưa được dùng để ra quyết định.

Thiết kế Team Structure gắn với workflow

Team structure nên phản ánh Responsibility + Skill + Workload.

• SME nhỏ: Sales và CSKH.
• Đội 2–3 người: có thể dùng All Agents.
• Quy mô lớn hơn: tách New Lead / Existing Customer hoặc General Support / Complaint khi thực sự cần.

Team, Agent và Channel là ba entity khác nhau

Không đồng nhất Facebook Team với Facebook Channel.

CHANNEL → ≠ → TEAM → ≠ → AGENT

Channel cho biết nguồn; Team cho biết chức năng xử lý; Agent cho biết người chịu trách nhiệm.

Thiết kế quyền truy cập phù hợp với SME

Agent

• Xem conversation được phép
• Reply
• Cập nhật status
• Tag
• Chuyển conversation

Team Lead

• Xem queue team
• Reassign
• Kiểm tra backlog
• Theo dõi SLA

Manager/Admin

• Cấu hình channel
• Quản lý user
• Thiết kế workflow
• Xem analytics toàn hệ thống

Mục tiêu là tránh cả hai cực: Everyone can do everything và Nobody can do anything.

Thiết kế Customer Data vừa đủ

Đừng biến dự án Inbox thành CRM khổng lồ. Có thể bắt đầu với Customer ID, Name, Phone, Email, Channel Identity, Tags và Conversation History; sau đó mới mở rộng Orders, Segment, Lifetime Value, Assigned Sales hoặc Custom Attributes.

Chỉ đưa attribute vào operational model khi nó hỗ trợ decision, personalization, routing, analytics hoặc workflow thực tế.

Bảng Entity–Attribute–Value tối thiểu cho hệ thống SME

Một data model tối thiểu có thể gồm:

• Conversation: Channel = Facebook; Status = Pending; Assignee = Agent A; Team = CSKH; Priority = High; Tag = Complaint; Created At = 09:02.
• Customer: Name, Phone, Type = Returning, Tag = VIP.
• Agent: Team = CSKH, Status = Available.
• Channel: Type = Zalo, Account = Zalo OA A.

CUSTOMER → has → CONVERSATION

CONVERSATION → originates from → CHANNEL

CONVERSATION → assigned to → AGENT

AGENT → belongs to → TEAM

Data model rõ giúp workflow, analytics và automation dùng chung một ngôn ngữ.

Thiết kế integration boundary rõ ràng

OMNICHANNEL SYSTEM → CRM → ORDER SYSTEM → ERP

Chỉ đưa vào conversation phần dữ liệu agent cần để ra quyết định. Ví dụ Order Status thường hữu ích hơn việc bắt agent mở toàn bộ ERP.

Hãy tích hợp theo Context, không phải theo “có API hay không”

Integration tốt là integration giảm friction trong workflow. Ưu tiên Customer Phone, Order Status, Recent Orders hoặc Customer Tier nếu agent dùng thường xuyên.

Nguyên tắc: Operational Relevance > Data Availability.

Thiết kế cho failure và exception

Architecture phải tính cả trường hợp bất thường:

• Channel disconnect
• Agent offline
• No assignee
• SLA breach
• Customer replies after resolved
• Automation fails

Không có agent

New Conversation → No Available Agent → Unassigned Queue → Supervisor Visibility

Khách nhắn lại

Resolved → New Customer Message → Reopen

Channel mất kết nối

Connection Error → Alert → Admin Action

Chỉ thiết kế happy path sẽ khiến hệ thống yếu khi volume tăng hoặc có exception.

Thiết kế một Minimum Viable Omnichannel System cho SME

Một phiên bản tối thiểu có thể gồm:

3 Core Channels → Unified Inbox → Conversation → Status → Assignment → Customer Profile cơ bản → Tags → Basic Reporting

Bắt buộc

• Channel connection
• Conversation
• Unified Inbox
• Status
• Assignment
• Search
• Customer identity cơ bản

Nên có

• Tags
• Priority
• Customer history
• Quick Reply
• Basic analytics

Có thể bổ sung sau

• SLA nâng cao
• Auto routing
• Complex automation
• AI Bot
• Advanced segmentation
• Advanced analytics

Nguyên tắc: xây operating model trước, thêm intelligence sau.

Kiến trúc tối thiểu không có nghĩa workflow sơ sài

Ngay cả SME chỉ có Facebook, Zalo, Website và vài agent vẫn cần biết conversation mới đi đâu, ai nhận, Pending nghĩa là gì, khi nào Resolve và ai kiểm tra Unassigned.

Một hệ thống nhỏ nhưng rõ ràng tốt hơn hệ thống nhiều feature nhưng thiếu ownership.

Ví dụ thiết kế cho SME 3 nhân viên

Giả sử Facebook + Zalo + Website, 3 agents và khoảng 80 conversations/ngày.

Facebook / Zalo / Website → Unified Inbox → All Conversations → Manual Assignment → Agent A/B/C

• Status: New, In Progress, Pending, Resolved.
• Priority: Normal, High.
• Tags: Sales, Support, Complaint, VIP.
• Analytics: Volume, Pending, Response Time, Resolved.
• Automation: Minimal / None initially.

Ví dụ thiết kế cho SME 8–10 nhân viên

Với 5 Channels, Sales Team = 4, CSKH Team = 5 và khoảng 500 conversations/ngày, có thể thêm Classification, Team Routing, Assignment, Unassigned Queue, Priority, SLA, Auto Assignment, Pending Reminder và Team Analytics.

CHANNELS → UNIFIED MESSAGING → CONVERSATIONS → CLASSIFICATION → TEAM ROUTING → ASSIGNMENT → AGENT

Ví dụ thiết kế cho SME có Sales và CSKH tách biệt

Facebook → Product Inquiry → Sales Team

Zalo → Order Issue → CSKH Team

Customer Profile vẫn nên nối hai context: Sales Conversation và CSKH Conversation. Team khác nhau có thể có workflow khác nhau mà không tách customer history thành các silo.

Đừng copy architecture của doanh nghiệp lớn

Enterprise có thể cần nhiều team, skill routing, nhiều SLA, regional queues, QA, workforce management và AI phức tạp. SME nhỏ không nhất thiết cần.

Mỗi layer chỉ nên phức tạp đến mức cần thiết để giải quyết complexity đang tồn tại.

Dùng nguyên tắc “một nguồn sự thật cho mỗi operational state”

Không nên để Inbox ghi Pending, Sheet ghi Done và chat nội bộ nói “đang chờ kho”. Mỗi loại dữ liệu cần một nguồn authoritative rõ ràng.

Ownership

Một nơi chính thức.

Status

Một nơi chính thức.

Customer Identity

Một nguồn chính hoặc logic đồng bộ rõ.

SLA

Một logic đo chính thức.

Đây là nguyên tắc single source of operational truth; không có nghĩa doanh nghiệp chỉ được dùng một phần mềm.

Thiết kế hệ thống sao cho manager không phải hỏi nhân viên để biết state

Manager nên xem trực tiếp các chỉ số như New, Unassigned, In Progress, Pending và SLA Risk; đồng thời biết Assignee của từng case.

Nếu phải hỏi nhiều agent, mở nhiều channel và kiểm tra spreadsheet để biết backlog, operational visibility chưa tốt.

Một blueprint hoàn chỉnh cho SME

CHANNEL SOURCES → MESSAGING → CONVERSATION → CUSTOMER CONTEXT → OPERATIONS → WORKFLOW → AUTOMATION → AGENT / TEAM ACTION → RESOLUTION → ANALYTICS → PROCESS IMPROVEMENT

Đây là logical architecture, không phải danh sách tính năng để mua. SME có thể dùng một hoặc nhiều công cụ để triển khai architecture này.

Bảng thiết kế hệ thống có thể copy sang Google Sheet

Checklist kiểm tra thiết kế trước khi triển khai

Channel

• Xác định channel cần đưa vào scope
• Biết account/page thuộc từng channel
• Có owner quản trị kết nối

Conversation

• Conversation là đơn vị vận hành
• Có Conversation ID
• Có history
• Có logic reopen

Inbox

• Có All Conversations hoặc queue phù hợp
• Có My Conversations
• Có Unassigned
• Có Pending
• Có Search và Filter

Status

• Có state model rõ
• Agent hiểu Pending
• Agent hiểu khi nào Resolve

Ownership

• Mỗi conversation có Assignee
• Có Team
• Có Unassigned queue
• Có quy tắc chuyển ownership

Customer

• Có Customer Profile cơ bản
• Có identifiers
• Có conversation history
• Không merge khách dựa trên dữ liệu yếu

Classification

• Tag có taxonomy
• Mỗi Tag có use case rõ
• Tránh duplicate synonym tags

Priority

• Priority khác Status
• Có rule xác định High Priority
• Không biến mọi conversation thành High

Workflow

• Biết conversation bắt đầu ở đâu
• Biết ai xử lý
• Biết khi nào Pending
• Biết khi nào Escalate
• Biết khi nào Resolve

SLA

• Có định nghĩa thời gian phản hồi
• Target phù hợp nguồn lực SME
• Có timestamp cần thiết để đo

Automation

• Workflow thủ công đã rõ
• Rule đủ lặp lại
• Giải thích được Trigger → Condition → Action

Analytics

• Có Conversation Volume
• Có Unassigned
• Có Pending
• Có Response Time
• Có workload theo agent/team

Nếu còn nhiều câu chưa trả lời được, chưa nên vội cấu hình automation phức tạp.

Những sai lầm khi thiết kế hệ thống đa kênh cho SME

Thiết kế theo phần mềm thay vì workflow

Problem → Process → Capability, thay vì Feature → Tool.

Kết nối quá nhiều Channel ngay từ đầu

Tăng scope nhưng chưa chắc tăng giá trị.

Tạo quá nhiều Status

Agent khó biết dùng trạng thái nào.

Không có Assignee

Shared Inbox nhưng thiếu ownership.

Dùng Tag thay cho mọi loại dữ liệu

Taxonomy nhanh chóng hỗn loạn.

Automation trước Process

Tự động hóa một logic chưa ổn định.

Dashboard trước Data Model

Nhiều chart nhưng metric thiếu nhất quán.

Cố xây Customer 360 ngay lập tức

Dự án phình to trước khi Inbox cơ bản ổn.

Copy mô hình enterprise

Quá phức tạp so với nguồn lực SME.

Những lỗi triển khai cụ thể hơn xem Những sai lầm khi triển khai Omnichannel.

Thiết kế khác triển khai như thế nào?

Thiết kế hệ thống trả lời architecture phải có gì, entity liên kết ra sao, state model thế nào, Team/Assignment hoạt động ra sao, workflow logic và metric cần đo. Triển khai trả lời làm gì trước, ai phụ trách, cấu hình theo thứ tự nào, test/pilot và khi nào rollout.

Bài này tập trung vào TARGET OPERATING MODEL. Bài tiếp theo tập trung vào IMPLEMENTATION SEQUENCE.

Xem tiếp Các bước triển khai hệ thống nhắn tin đa kênh.

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

SME nên bắt đầu hệ thống đa kênh từ đâu?

Bắt đầu từ conversation và workflow thực tế: mục đích liên hệ, người xử lý, trạng thái và dữ liệu agent cần; sau đó mới chọn channel và capability.

SME có cần kết nối tất cả channel không?

Không. Ưu tiên channel tạo volume hoặc giá trị đáng kể; bổ sung channel ít dùng sau.

Thành phần quan trọng nhất của hệ thống là gì?

Conversation, Status và Ownership là nền tảng vì chúng xác định công việc, trạng thái và người chịu trách nhiệm.

Unified Inbox có đủ để tạo hệ thống Omnichannel không?

Không. Cần thêm Conversation Model, Customer Context, Assignment, Status, Workflow và dữ liệu đo lường.

Có nên triển khai Automation ngay từ đầu?

Chỉ tự động hóa workflow đã rõ và thống nhất; automation quá sớm có thể làm quy trình chưa tốt chạy nhanh hơn.

SME có cần CRM để triển khai nhắn tin đa kênh không?

Không nhất thiết. Có thể bắt đầu với Customer Profile và Conversation History; CRM bổ sung khi cần quản lý lead, pipeline hoặc customer data sâu hơn.

Có cần Customer 360 ngay từ đầu không?

Không. Bắt đầu bằng các attribute hỗ trợ trực tiếp cho conversation như name, phone, history, tag hoặc order context.

Có nên phân nhân viên theo từng channel?

Có thể, nhưng không nên là mặc định. Assignment theo team, intent hoặc workload có thể phù hợp hơn.

Hệ thống SME nên có bao nhiêu status?

Không có con số cố định. New → In Progress → Pending → Resolved thường đủ để bắt đầu nếu phản ánh đúng workflow.

Khi nào SME nên thêm AI Bot?

Sau khi đã rõ intent, knowledge, escalation logic và human handoff. AI không nên là lớp đầu tiên của architecture.

Tóm lại

Một hệ thống giao tiếp đa kênh cho SME không nên là tập hợp Facebook Tool + Zalo Tool + Website Tool + TikTok Tool. Hãy thiết kế như một operating system:

CHANNEL → MESSAGE → CONVERSATION → CUSTOMER CONTEXT → STATUS + OWNERSHIP → WORKFLOW → AGENT / TEAM → RESOLUTION → ANALYTICS

• Channel là nơi conversation bắt đầu.
• Conversation là đơn vị vận hành.
• Customer Context giúp hiểu người đang nói chuyện.
• Status cho biết công việc đang ở đâu.
• Assignment cho biết ai chịu trách nhiệm.
• Workflow cho biết phải làm gì.
• SLA cho biết cần xử lý trong bao lâu.
• Analytics cho biết hệ thống vận hành ra sao.
• Automation chỉ nên đặt trên một workflow đã rõ.

Kiến trúc tốt nhất cho SME không phải kiến trúc nhiều tính năng nhất, mà là kiến trúc đơn giản nhất vẫn giúp doanh nghiệp nhìn thấy, phân công, xử lý, theo dõi và đo lường các conversation quan trọng.

Sau khi target architecture rõ, bước tiếp theo là chuyển thiết kế thành kế hoạch rollout thực tế.

Đọc tiếp:

9. Vì sao doanh nghiệp cần hợp nhất các kênh nhắn tin?
10. Lợi ích của quản lý tin nhắn tập trung
11. Những vấn đề khi quản lý nhiều kênh riêng biệt
12. Cách thiết kế hệ thống giao tiếp đa kênh cho SME
13. Các bước triển khai hệ thống nhắn tin đa kênh
14. Checklist triển khai nhắn tin đa kênh
15. Khi nào doanh nghiệp nên dùng hệ thống đa kênh?
16. Những sai lầm khi triển khai Omnichannel