Nếu Sales Cloud tập trung vào việc biến Prospect thành Customer, thì Service Cloud giải quyết bài toán ngược lại:

Sau khi khách hàng mua hàng, doanh nghiệp sẽ tiếp nhận, phân loại, xử lý và theo dõi vấn đề của họ như thế nào?

Trong kỳ thi Salesforce Platform Administrator 2026, nhóm kiến thức Service Cloud chiếm khoảng 10%. Con số không lớn, nhưng đây là nhóm câu hỏi khá "thực chiến" vì Salesforce thường không hỏi định nghĩa đơn thuần mà đưa ra một Business Scenario, sau đó yêu cầu chọn đúng tính năng.

Muốn ăn trọn phần này, hãy nắm chắc 4 mảnh ghép:

Case → Routing → SLA → Support Process

---

1. Case Management – Vòng đời của Case

Case là gì?

Case đại diện cho một yêu cầu hỗ trợ từ khách hàng.

Ví dụ:

• Khách hàng báo sản phẩm bị lỗi.
• Khách hàng hỏi tình trạng giao hàng.
• Khách hàng yêu cầu đổi sản phẩm.
• Khách hàng cần hỗ trợ kỹ thuật.

Thay vì để nhân viên xử lý email một cách thủ công, Service Cloud biến yêu cầu đó thành một Case để doanh nghiệp có thể theo dõi toàn bộ lifecycle:

Customer → Case → Assignment → Agent xử lý → Resolution → Closed

Điểm quan trọng trong bài thi là: Case không nhất thiết phải được tạo thủ công.

Web-to-Case

Web-to-Case cho phép khách hàng gửi yêu cầu hỗ trợ thông qua một Web Form.

Ví dụ:

Customer
   ↓
Support Web Form
   ↓
Web-to-Case
   ↓
Case được tạo trong Salesforce

Các thông tin như Subject, Description, Email, Product... có thể được khách hàng nhập trực tiếp trên form.

Use Case điển hình:

Công ty muốn khách hàng điền form "Contact Support" trên website và tự động tạo Case trong Salesforce.

→ Web-to-Case

---

Email-to-Case

Email-to-Case giải quyết một tình huống khác: khách hàng gửi email đến địa chỉ hỗ trợ.

customer@example.com
        ↓
support@company.com
        ↓
Email-to-Case
        ↓
Case được tạo trong Salesforce

Ví dụ:

Customer gửi email "Sản phẩm tôi nhận được bị hỏng" đến support@company.com.

Salesforce có thể tự động biến email đó thành Case.

Đây là một điểm cực kỳ quan trọng:

Web-to-Case = Form → Case

Email-to-Case = Email → Case

---

2. Routing & Assignment – Case đi về đâu?

Tạo Case mới chỉ là bước đầu.

Câu hỏi tiếp theo là:

Case này phải được xử lý bởi ai?

Đây là nơi rất nhiều Admin nhầm lẫn giữa Queue và Case Assignment Rules.

Queue – "Nơi chứa Case"

Có thể hiểu Queue như một hàng đợi công việc.

Ví dụ:

Technical Support Queue
        ↓
Case A
Case B
Case C

Các thành viên trong Queue có thể lấy Case ra để xử lý.

Queue trả lời câu hỏi:

Case đang nằm ở đâu / nhóm nào đang chịu trách nhiệm tiếp nhận?

---

Case Assignment Rule – "Bộ não định tuyến"

Assignment Rule không phải là nơi chứa Case.

Nó là tập hợp các rule xác định Case nên được assign cho Queue hoặc User nào dựa trên điều kiện.

Ví dụ:

IF Case Origin = Web
AND Product = Elevator
        ↓
Assign → Technical Support Queue

Hoặc:

IF Priority = High
AND Region = Vietnam
        ↓
Assign → Vietnam Support Queue

Business Scenario thực tế

Một công ty bán thiết bị điện có 3 nhóm:

• General Support
• Technical Support
• VIP Support

Khách hàng gửi Case qua website.

Doanh nghiệp muốn:

Nếu Case có Product = Elevator và Type = Technical Issue → tự động đưa Case vào Technical Support Queue.

Thiết kế hợp lý:

Web-to-Case → tạo Case

Case Assignment Rule → kiểm tra điều kiện

Technical Support Queue → nhận Case

Hãy nhớ:

Assignment Rule quyết định "đẩy đi đâu". Queue là "nơi Case chờ được xử lý".

---

3. SLA & Automation – Auto-Response vs Escalation

Đây là một trong những khu vực dễ xuất hiện bẫy phòng thi nhất.

Hai tính năng có vẻ giống nhau vì đều liên quan đến tự động hóa Case, nhưng mục đích hoàn toàn khác nhau.

---

Case Auto-Response Rules

Auto-Response Rule dùng để gửi email phản hồi tự động khi Case được tạo.

Ví dụ:

Khách hàng gửi Case lúc 10:00. Ngay lập tức nhận email: "Chúng tôi đã nhận được yêu cầu của bạn. Case #000123 đang được xử lý."

Flow:

Case Created
     ↓
Auto-Response Rule
     ↓
Email Customer

Mục tiêu chính:

Xác nhận đã nhận được yêu cầu.

Nó không có nghĩa là Case đã được xử lý.

---

Case Escalation Rules

Escalation Rule giải quyết một vấn đề khác:

Case bị "ngâm" quá lâu thì phải làm gì?

Ví dụ SLA của công ty quy định:

• Priority High → phải được xử lý trong 4 giờ.
• Nếu quá thời gian mà Case chưa được giải quyết → escalate.

Có thể thực hiện các hành động như:

• Reassign Case cho người khác.
• Reassign Case cho Queue.
• Gửi email thông báo.
• Escalate đến manager.

Flow:

Case Created
     ↓
Case chưa được xử lý
     ↓
Quá thời gian quy định
     ↓
Escalation Rule
     ↓
Alert / Reassign / Escalate

Bẫy phòng thi kinh điển

"Customer creates a Case and should immediately receive an email confirming that Salesforce has received the request."

Đáp án là:

Case Auto-Response Rule

Không phải Escalation Rule.

Ngược lại:

"High-priority Cases that remain unresolved for 4 hours should be escalated to a manager."

→ Case Escalation Rule

Hãy ghi nhớ bằng một câu:

Auto-Response = phản hồi ngay. Escalation = xử lý khi bị trễ.

Đừng thấy từ "email" rồi chọn Auto-Response một cách máy móc. Escalation Rule cũng có thể gửi email; điểm khác biệt nằm ở điều kiện và mục đích của automation.

---

4. Support Process – Case được phép có Status nào?

Một khái niệm rất dễ hiểu nếu bạn đã nắm Sales Process.

Với Opportunity:

Sales Process quyết định những Stage nào được phép sử dụng.

Ví dụ:

Prospecting
Qualification
Proposal
Closed Won
Closed Lost

Với Case cũng tương tự.

Support Process quyết định những Status nào được phép sử dụng cho Case.

Ví dụ doanh nghiệp A chỉ muốn:

New
Working
Escalated
Closed

Trong khi doanh nghiệp B muốn:

New
In Progress
Waiting for Customer
Waiting for Vendor
Resolved
Closed

Support Process giúp giới hạn các giá trị Status được sử dụng cho từng quy trình hỗ trợ.

Sau đó, Record Type có thể được sử dụng để gắn Support Process phù hợp với từng loại Case.

Ví dụ:

Technical Case
   ↓
Technical Support Process
   ↓
New → Investigating → Waiting for Customer → Resolved → Closed

Trong khi:

Billing Case
   ↓
Billing Support Process
   ↓
New → In Progress → Resolved → Closed

Đây chính là tư duy kiến trúc mà Admin cần nhớ:

Sales Process kiểm soát Opportunity Stage. Support Process kiểm soát Case Status.

---

Tổng kết – Công thức ăn trọn 10%

Nếu gặp câu hỏi Service Cloud trong phòng thi, hãy tư duy theo chuỗi:

CUSTOMER
   ↓
Web-to-Case / Email-to-Case
   ↓
CASE
   ↓
Assignment Rule
   ↓
Queue / User
   ↓
Agent xử lý
   ↓
Support Process → Status
   ↓
Escalation nếu quá SLA
   ↓
Closed

Và hãy thuộc lòng 6 keyword:

Requirement	Salesforce Feature
Khách hàng gửi Form	Web-to-Case
Khách hàng gửi Email	Email-to-Case
Xác định Case sẽ được assign đi đâu	Case Assignment Rule
Nơi chứa/chờ Case	Queue
Email xác nhận ngay khi Case được tạo	Auto-Response Rule
Case quá lâu chưa xử lý	Escalation Rule
Kiểm soát Case Status	Support Process

---

Và đây mới là cú twist...

Chúng ta vừa xây dựng một hệ thống mà Case có thể tự sinh, tự phân loại, tự định tuyến, tự phản hồi và tự escalation.

Nhưng tất cả những thứ trên vẫn có một giới hạn:

Cuối cùng vẫn cần con người đọc Case và quyết định phải làm gì.

Vậy nếu Salesforce có thể tiến thêm một bước?

Nếu thay vì:

"Case này thuộc Queue nào?"

chúng ta có thể hỏi:

"AI, hãy đọc Case này, hiểu vấn đề của khách hàng, tìm thông tin liên quan, đề xuất cách xử lý và thậm chí thực hiện action giúp tôi."

Đó chính là lúc Agentforce AI bước vào sân khấu.

🔥 Bài cuối cùng sẽ là "trùm cuối" của series: Agentforce AI – 8% điểm số nhưng là nơi Salesforce Admin 2026 bắt đầu bước sang kỷ nguyên AI Agent.

Nếu bạn đã đi cùng series đến đây, thì Phần 9 chính là boss cuối.

Let's meet Agentforce.