LB
Ly Byn Cosmetics
SOP Preview · CRM/CSKH Retail 360

SOP CRM/CSKH Retail 360 trên Lark

Bản SOP này chuẩn hóa luồng CRM/CSKH cho mô hình retail: Pancake gom hội thoại Facebook/Zalo, Lark quản lý hồ sơ khách hàng, cơ hội bán hàng, đơn hàng, giao hàng, chăm sóc sau bán, hoàn hàng và khiếu nại. Mục tiêu là để team sale/CSKH không sót lead, không quên follow-up và quản lý được toàn bộ vòng đời khách hàng từ lần đầu quan tâm đến mua lại.

Project Ly Byn Cosmetics
Phạm vi CRM/CSKH Retail 360
Phiên bản Draft v3
Cập nhật 06/06/2026

1Tổng quan

Nguyên tắc chốt: Sale chat và xử lý hội thoại hằng ngày trên Pancake; Lark chỉ dùng để quản lý hồ sơ 360, cơ hội, mốc follow-up, nút tạo hóa đơn, ticket và báo cáo; KiotViet là engine hóa đơn/tồn kho/trả hàng. Không bắt sale nhập song song cùng một nội dung ở nhiều app. Cơ hội không đóng ngay sau khi chốt đơn mà chuyển sang Đã mua hàng và tiếp tục qua CSKH sau bán.

Mục tiêu

  • Không sót lead từ Facebook, Zalo, giới thiệu và data cũ nhờ gom hội thoại về Pancake.
  • Mỗi cơ hội, đơn hàng và ticket có owner rõ ràng.
  • Theo dõi xuyên suốt từ lead đến mua lại và CSKH sau bán.

Phạm vi

  • Tiếp nhận khách từ Zalo, Fanpage qua Pancake, thêm nguồn giới thiệu và data cũ.
  • Tạo cơ hội, ghi nhận chăm sóc và theo dõi giai đoạn mua hàng.
  • Liên kết lịch sử đơn hàng, giao hàng, hoàn hàng, khiếu nại và CSKH sau bán.

Liên kết hệ thống

  • Kiến trúc tích hợp chuẩn: Facebook + Zalo → Pancake → Lark.
  • Pancake là nơi gom inbox Facebook/Zalo và xử lý hội thoại hằng ngày.
  • Lark là nơi quản lý khách hàng, cơ hội, follow-up, CSKH, ticket, báo cáo và nút tạo hóa đơn Kiot.
  • KiotViet vẫn là engine hóa đơn, tồn kho, doanh thu và trả hàng.
  • Hoàn hàng/đổi hàng liên kết với workflow hoàn hàng đang triển khai.
Không kết nối trực tiếp Facebook/Zalo vào Lark. Lead và hội thoại từ Facebook/Zalo đi vào Pancake trước, sau đó Pancake/n8n chỉ đồng bộ các dữ liệu quan trọng sang Lark như lead, nguồn kênh, trạng thái, nhân viên phụ trách, lịch sử CSKH và thông tin cần báo cáo. Cách này tận dụng Pancake cho nghiệp vụ inbox/chat, còn Lark tập trung vào quy trình, KPI và Customer 360.

2Vai trò và bảng sử dụng

Bảng sử dụng

  • Khách hàng: hồ sơ gốc 360, chống trùng, thông tin liên hệ, nguồn khách, health status.
  • Cơ hội: nơi sale theo dõi nhu cầu, follow-up, chốt mua và CSKH sau bán.
  • Pancake Lead/Hội thoại: nguồn hội thoại Facebook/Zalo, dùng để đồng bộ khách, nguồn kênh, owner và nội dung cần chăm sang Lark.
  • Yêu cầu tạo hóa đơn Kiot: nơi sale bấm tạo hóa đơn sau khi chốt đơn trên Lark; n8n gọi API KiotViet để tạo hóa đơn thật.
  • Đơn hàng: lịch sử giao dịch đồng bộ từ KiotViet/Lark để xem trong Customer Profile.
  • Lịch sử chăm sóc: bảng nhật ký tóm tắt các mốc chăm sóc quan trọng, không thay thế lịch sử chat chi tiết trên Pancake.
  • Ticket/Khiếu nại: nơi ghi nhận phản ánh, assign bộ phận xử lý và theo dõi đến khi đóng case.
  • Hoàn hàng/Đổi hàng: lịch sử hoàn, đổi, hủy đơn liên kết với workflow hoàn hàng.

Vai trò

  • Sale phụ trách: chăm sóc khách trên Pancake, cập nhật mốc quan trọng trên Lark, đặt lịch nhắc, chuyển stage sau khi khách mua.
  • Sale trực Pancake: phản hồi inbox/comment, xác nhận nhu cầu, đảm bảo khách có hồ sơ trên Lark và cơ hội được assign đúng người.
  • CSKH sau bán: theo dõi khách đã nhận hàng, ghi nhận phản hồi, tạo ticket nếu có vấn đề.
  • Bộ phận xử lý ticket: xử lý khiếu nại, đổi hàng, hoàn hàng hoặc vấn đề vận chuyển theo phân công.
  • Quản lý: xem view CSKH - Khách sếp cung cấp chưa chia, chia khách cho người chăm sóc, theo dõi khách cần chia lại, SLA quá hạn và ticket chưa đóng.

Nguyên tắc vận hành

  • Mỗi khách chỉ có 1 hồ sơ gốc trong bảng Khách hàng.
  • Mỗi nhu cầu cụ thể của khách được theo dõi bằng 1 Cơ hội.
  • Mỗi Cơ hội chỉ có 1 sale phụ trách chính, nhưng có thể bàn giao cho CSKH sau bán sau khi khách mua.
  • Chỉ Khách sếp cung cấp mới áp dụng cơ chế chia khách; Khách tự kiếm do người tự kiếm tự chăm.
  • Không nhập lại toàn bộ lịch sử chat vào Lark; chỉ nhập tóm tắt kết quả chăm sóc khi đổi stage, đặt lịch nhắc, chốt đơn, phát sinh ticket hoặc có thông tin quan trọng.
  • Sau mỗi mốc chăm sóc quan trọng trên Lark phải có Việc cần làm tiếp theoNgày nhắc tiếp theo.
  • Lead từ Facebook/Zalo đi qua Pancake trước, sau đó đồng bộ hoặc tạo hồ sơ Khách hàngCơ hội trên Lark.
  • Phần lên đơn có 2 phương án: tạo hóa đơn trên KiotViet rồi sync về Lark, hoặc tạo yêu cầu hóa đơn trên Lark rồi đẩy lên KiotViet qua API.
  • Phương án mục tiêu là sale chốt đơn trên Lark và bấm Tạo hóa đơn Kiot; giai đoạn chuyển tiếp vẫn có thể cho sale tạo hóa đơn trên KiotViet rồi webhook sync về Lark.
  • KiotViet vẫn là nơi ghi nhận hóa đơn thật, trừ kho, doanh thu và thao tác trả hàng khi phát sinh hoàn/trả.
  • Sau khi khách chốt đơn, không đóng cơ hội ngay; chuyển sang Đã mua hàng, liên kết đơn hàng và theo dõi giao/nhận.
  • Khi khách đã nhận hàng, chuyển sang CSKH sau bán để nhắc chăm lại, ghi phản hồi và kích hoạt mua lại.

3SOP theo từng app

Mục tiêu vận hành là sale thao tác ít nhất có thể. Sale không phải nhảy qua lại liên tục giữa Pancake, Lark và KiotViet. Mỗi app có một vai trò rõ ràng; dữ liệu được đồng bộ tự động qua n8n/workflow tại các mốc quan trọng.

Pancake · App làm việc hằng ngày của sale

  • Sale trực inbox/comment Facebook/Zalo trên Pancake.
  • Pancake giữ lịch sử chat đầy đủ, phân nhân viên phụ trách và hỗ trợ AI chatbot/automation.
  • Sale chỉ cần cập nhật trạng thái hội thoại/lead trên Pancake theo rule nội bộ.
  • Khi khách có nhu cầu rõ hoặc đủ thông tin liên hệ, Pancake/n8n đồng bộ khách và cơ hội sang Lark.
  • Không copy toàn bộ nội dung chat sang Lark; Lark chỉ lưu tóm tắt, trạng thái, owner và link trace về Pancake.

Lark · App quản trị quy trình và Customer 360

  • Lark lưu hồ sơ Khách hàng, Cơ hội, Đơn hàng, Ticket, Hoàn hàng và KPI.
  • Sale chỉ mở Lark khi cần kiểm tra Customer 360, tạo/chốt cơ hội, đặt ngày nhắc, bấm tạo hóa đơn Kiot hoặc tạo ticket.
  • Không yêu cầu sale nhập lại từng đoạn chat; chỉ nhập tóm tắt kết quả chăm sóc tại các mốc quan trọng.
  • Lark tự nhắc follow-up, SLA, CSKH sau bán và ticket quá hạn.
  • Quản lý dùng Lark để xem pipeline, chất lượng chăm sóc, đơn hàng, khiếu nại và hiệu quả từng sale.

KiotViet · App kho, hóa đơn và trả hàng

  • Giai đoạn chuyển tiếp: sale có thể tạo hóa đơn trên KiotViet, sau đó webhook/sync đơn về Lark.
  • Giai đoạn mục tiêu: sale không cần vào KiotViet để tạo khách hoặc tạo hóa đơn thủ công; nút Tạo hóa đơn Kiot trên Lark gọi API KiotViet để tạo hóa đơn thật.
  • KiotViet chịu trách nhiệm trừ tồn, ghi nhận doanh thu, thanh toán và nghiệp vụ trả hàng.
  • Kho/kế toán/người có quyền mới vào KiotViet để xử lý trả hàng khi phát sinh hoàn/trả.
  • Hóa đơn KiotViet được webhook/sync ngược về Lark để tiếp tục đóng đơn, giao hàng và CSKH sau bán.

Quy tắc chống chồng chéo

  • Chat ở đâu thì xử lý ở đó: Facebook/Zalo chat trên Pancake, không chat lại trên Lark.
  • Lark không thay Pancake làm inbox; Lark chỉ lưu dữ liệu quản trị cần báo cáo và nhắc việc.
  • Sale không nhập khách/đơn trên Kiot; Kiot chỉ nhận hóa đơn qua API từ Lark.
  • Một tương tác không nhập hai lần: Pancake giữ chi tiết chat, Lark giữ tóm tắt và mốc xử lý.
  • Muốn xem toàn bộ chân dung khách thì mở Customer 360 trên Lark; muốn tiếp tục chat thì quay về Pancake bằng link hội thoại.
Tình huống Sale thao tác ở đâu? Lark ghi nhận gì?
Khách mới nhắn Facebook/ZaloPancakeTạo/cập nhật Khách hàng, nguồn, owner, link hội thoại
Khách hỏi sản phẩm, cần tư vấnPancakeTạo/gợi ý Cơ hội nếu đủ điều kiện
Sale follow-up hằng ngàyPancakeCập nhật mốc follow-up/tóm tắt nếu có kết quả quan trọng
Khách chốt muaLarkChuyển Cơ hội = Đã mua hàng, tạo yêu cầu hóa đơn Kiot
Cần tạo hóa đơn - phương án 1KiotVietWebhook/sync hóa đơn về Lark để xử lý đóng/giao/CSKH
Cần tạo hóa đơn - phương án 2LarkBấm Tạo hóa đơn Kiot; n8n gọi API Kiot để trừ kho và ghi nhận doanh thu
Đóng đơn/giao hàngLark/KhoTheo dõi Đơn hàng, ảnh đóng đơn, ảnh giao hàng
Khách khiếu nạiPancake để tiếp nhận, Lark để tạo ticketTicket, SLA, người xử lý, kết quả cuối
Trả hàng/hoàn hàngKiotViet bởi người có quyền, Lark để theo dõi caseCase hoàn hàng, trạng thái xử lý, lịch sử trong Customer 360
Khách sếp cung cấpLarkQuản lý chia khách, sale nhận danh sách, Pancake chỉ dùng nếu có hội thoại online

Quy trình lên đơn

Phương án 1 · Lên đơn trên KiotViet rồi bắn về Lark

  • Sale tạo hóa đơn trực tiếp trên KiotViet.
  • KiotViet là nơi phát sinh hóa đơn gốc, trừ kho và ghi nhận doanh thu.
  • Webhook/sync KiotViet bắn đơn về Lark để quản lý đóng đơn, giao hàng và CSKH sau bán.
  • Lark không đẩy trạng thái giao hàng ngược về KiotViet.
  • Phù hợp trong giai đoạn chuyển tiếp khi sale vẫn quen thao tác KiotViet hoặc khi API tạo hóa đơn từ Lark chưa hoàn thiện.

Phương án 2 · Lên đơn trên Lark rồi bắn lên KiotViet

  • Sale chốt đơn trong Lark từ Customer/Cơ hội và bấm Tạo hóa đơn Kiot.
  • n8n/API tạo hóa đơn thật trên KiotViet để KiotViet trừ kho, ghi nhận doanh thu và thanh toán.
  • Lark lưu Kiot invoice IDMã hóa đơn Kiot để trace, không cần sync ngược các trạng thái giao hàng lên Kiot.
  • Chỉ cần sync/cập nhật ngược KiotViet khi phát sinh trạng thái hủy/hoàn/trả hàng hoặc nghiệp vụ ảnh hưởng tồn kho/công nợ.
  • Đây là phương án mục tiêu để sale không phải nhảy qua KiotViet khi chốt đơn.
Khuyến nghị triển khai: giữ phương án 1 làm fallback an toàn trong giai đoạn đầu, đồng thời build phương án 2 làm luồng chính cho sale. Khi phương án 2 ổn định, sale chỉ cần làm việc trên Pancake và Lark; KiotViet vẫn xử lý hóa đơn, tồn kho, doanh thu và trả hàng ở phía sau.

4Cơ chế chia khách

Khách được chia ngay trên bảng Khách hàng. Cơ chế này chỉ áp dụng cho nhóm Khách sếp cung cấp; không áp dụng cho Khách tự kiếm và không thay thế cơ chế assign hội thoại online trên Pancake.

Nguyên tắc: Khách sếp cung cấp là data nội bộ do sếp/quản lý đưa xuống, nên chia trên Lark. Pancake chỉ dùng sau đó nếu sale cần nhắn/chat hoặc khách phát sinh hội thoại Facebook/Zalo. Owner chính để tính KPI vẫn là Người chăm sóc trên Lark.

B1. Phân loại khách

  1. Khách mới được gắn Phân loại khách: Khách tự kiếm hoặc Khách sếp cung cấp.
  2. Với data sếp cung cấp, nhập/import vào Lark trước, làm sạch và chống trùng theo SĐT trước khi chia.
  3. Khách sếp cung cấp chưa có Người chăm sóc sẽ nằm ở view CSKH - Khách sếp cung cấp chưa chia.

B2. Quản lý chia khách

  1. Gán field Người chăm sóc trên bảng Khách hàng.
  2. Nếu cần, điền Ghi chú chia khách để người chăm sóc biết bối cảnh.
  3. Có thể chia thủ công theo mức độ ưu tiên, khu vực, nhóm sản phẩm quan tâm, quan hệ với sếp hoặc năng lực từng sale.
  4. Khách tự kiếm không cần chia, chỉ cần giữ đúng Phân loại khách = Khách tự kiếm.

B3. Người chăm sóc nhận khách

  1. Người chăm sóc mở view CSKH - Khách sếp cung cấp đã chia.
  2. Sale xác nhận đã nhận khách bằng cách cập nhật Trạng thái chia khách = Sale đã nhận.
  3. Liên hệ khách trong SLA cấu hình, ví dụ 24 giờ làm việc.
  4. Nếu phát sinh nhu cầu cụ thể thì tạo Cơ hội để bắt đầu luồng chăm sóc theo cơ hội.

B4. Chia lại nếu cần

  1. Nếu người chăm sóc không phù hợp hoặc quá tải, đổi Trạng thái chia khách = Cần chia lại.
  2. Quản lý xử lý lại trong view CSKH - Khách cần chia lại.
Workflow chia khách: khi khách có Phân loại khách = Khách sếp cung cấp và được gán Người chăm sóc, hệ thống sẽ đánh dấu Trạng thái chia khách = Đã chia, ghi Người chia khách, Thời gian chia khách và nhắn cho người chăm sóc. Workflow đã tạo nhưng cần owner bật nếu đang ở trạng thái disabled.
View Người dùng Mục đích
Khách sếp cung cấp chưa chiaQuản lýLọc khách chưa có Người chăm sóc để chia
Khách sếp cung cấp đã chiaSaleDanh sách khách được giao cần nhận và chăm
Khách sếp cung cấp cần follow-up hôm naySaleKhách đã đến hạn chăm lại
Khách sếp cung cấp quá hạnQuản lýKhách đã chia nhưng sale chưa nhận/chưa chăm đúng SLA
Khách cần chia lạiQuản lýKhách không phù hợp owner hiện tại hoặc sale quá tải

5Quy trình thao tác chuẩn

B1. Tiếp nhận khách

  1. Khách nhắn Facebook/Zalo được gom về Pancake; sale trực Pancake phản hồi bước đầu và lấy số điện thoại nếu chưa có.
  2. Pancake/n8n tự đồng bộ lead sang Lark, check trùng theo SĐT và Pancake ID.
  3. Sale chỉ mở Lark nếu hệ thống báo thiếu SĐT, thiếu owner, hoặc cần kiểm tra Customer 360 trước khi tư vấn sâu.

B2. Tạo Cơ hội

  1. Cơ hội nên được tạo tự động từ lead Pancake khi khách có nhu cầu rõ hoặc đủ thông tin liên hệ.
  2. Workflow tự link Khách hàng, gán Sale phụ trách, set Giai đoạn = Mới nhậnNguồn cơ hội = Pancake Facebook/Pancake Zalo.
  3. Sale chỉ tạo thủ công trên Lark khi khách đến từ nguồn ngoài Pancake như referral, data cũ hoặc khách tại cửa hàng.

B3. Liên hệ và tư vấn

  1. Sale tiếp tục chat/gọi/inbox trên Pancake, không phải copy từng đoạn chat sang Lark.
  2. Pancake lưu lịch sử hội thoại chi tiết; Lark chỉ lưu link hội thoại và tóm tắt mốc quan trọng.
  3. Khi có kết quả rõ như khách quan tâm mạnh, hẹn gọi lại, báo giá, chờ phản hồi hoặc chốt mua, sale cập nhật trạng thái/tóm tắt một lần trên Lark.

B4. Follow-up

  1. Sale follow-up trên Pancake theo hội thoại đang phụ trách.
  2. Lark tự nhắc việc dựa trên Ngày nhắc tiếp theo; sale chỉ cần cập nhật lại ngày nhắc khi thay đổi kế hoạch chăm sóc.
  3. Không bắt buộc nhập lịch sử chăm sóc cho mọi tin nhắn; chỉ ghi tóm tắt khi thay đổi stage, có cam kết của khách, hoặc có việc cần quản lý theo dõi.

B5. Chờ phản hồi

  1. Sau khi gửi tư vấn/báo giá trên Pancake và cần chờ khách, sale chuyển cơ hội trên Lark sang Chờ phản hồi.
  2. Bắt buộc có Ngày nhắc tiếp theo; đến hạn Lark nhắc sale quay lại Pancake để follow-up.

B6. Khách mua hàng

  1. Nếu khách chốt đơn, chuyển Giai đoạn = Đã mua hàng, không đóng cơ hội ngay.
  2. Phương án 1: sale tạo hóa đơn trên KiotViet; webhook/sync đơn về bảng Đơn hàng trên Lark.
  3. Phương án 2: sale mở Lark một lần để kiểm tra Customer 360, sản phẩm, thanh toán và bấm nút Tạo hóa đơn Kiot từ cơ hội.
  4. Với phương án 2, n8n kiểm tra khách, sản phẩm, chi nhánh, sale Kiot, thanh toán và gọi API KiotViet để tạo hóa đơn thật.
  5. Lark link cơ hội với đơn hàng hoặc mã đơn KiotViet để xem trong Customer Profile; không sync trạng thái giao hàng ngược về KiotViet.
  6. Chỉ xử lý ngược sang KiotViet khi có nghiệp vụ hủy/hoàn/trả hàng ảnh hưởng tồn kho, thanh toán hoặc công nợ.

B7. Theo dõi giao hàng

  1. Kho/vận hành theo dõi trạng thái xử lý đơn trên Lark: đóng đơn, phân người giao, đang giao, đã giao.
  2. Sale không cần theo dõi thủ công từng bước giao hàng, chỉ nhận thông báo khi đơn đã giao, giao thất bại hoặc phát sinh vấn đề.
  3. Khi đơn đã giao, workflow chuyển cơ hội sang CSKH sau bán và đặt Ngày nhắc CSKH sau bán theo cấu hình.

B8. CSKH sau bán

  1. Đến ngày nhắc sau bán, Lark gửi thông báo; sale/CSKH quay lại Pancake để nhắn hỏi tình trạng sử dụng.
  2. Chỉ ghi vào Lark phần Phản hồi sau bán, Customer Health Status và nhu cầu mua lại nếu có.
  3. Nếu khách có nhu cầu mua tiếp, tạo cơ hội mới hoặc workflow tự gợi ý cơ hội mua lại.

B9. Khiếu nại / hoàn hàng

  1. Khách phản ánh ở Pancake; sale tiếp nhận và chỉ tạo Ticket/Khiếu nại trên Lark khi cần bộ phận khác xử lý hoặc cần SLA.
  2. Ticket assign cho bộ phận liên quan: sale, CSKH, kho, vận chuyển hoặc quản lý.
  3. Nếu phát sinh đổi/trả/hoàn, ticket link với workflow Hoàn hàng/Đổi hàng; người có quyền xử lý trả hàng trên KiotViet rồi cập nhật kết quả về Lark.

B10. Tạm dừng hoặc Thất bại

  1. Nếu khách hẹn xa thì chuyển Tạm dừng.
  2. Nếu dừng theo dõi hẳn trước khi mua thì chuyển Thất bại.
  3. Cần ghi rõ lý do thất bại hoặc lý do tạm dừng.

6Giai đoạn Cơ hội

Đề xuất bộ trạng thái mở rộng cho retail, để không dừng ở bước chốt sale mà theo dõi tiếp giao hàng, sau bán và mua lại.

Mới nhận

Vừa tạo cơ hội, chưa có tương tác chăm sóc đầu tiên.

Cần liên hệ trong 24h

Đã liên hệ

Đã có lần chạm đầu tiên, đang tiếp tục tìm hiểu nhu cầu.

Đã có tương tác đầu tiên

Đang chăm sóc

Đang follow-up bình thường, cần có lịch nhắc tiếp theo.

Trạng thái mặc định khi đang theo

Chờ phản hồi

Đã gửi thông tin, đang chờ khách phản hồi lại.

Phải có ngày nhắc

Đã mua hàng

Khách đã chốt đơn hoặc đã phát sinh đơn hàng. Cơ hội vẫn mở để theo dõi giao hàng và bàn giao CSKH sau bán.

Link với đơn hàng

CSKH sau bán

Khách đã nhận hàng hoặc đơn đã hoàn tất, cần chăm sóc lại sau X ngày và ghi nhận phản hồi sử dụng.

Nhắc chăm sau bán

Tạm dừng

Khách hẹn lại sau, chưa cần theo sát trong ngắn hạn.

Cần có lý do

Thất bại

Cơ hội dừng hẳn trước khi mua, không theo tiếp nữa.

Bắt buộc ghi lý do

7Customer 360 Profile

Mỗi hồ sơ khách hàng cần là màn hình tổng hợp để sale, CSKH và quản lý nhìn được toàn bộ vòng đời khách hàng.

Thông tin gốc

  • Tên khách, SĐT, kênh liên hệ, nguồn khách hàng.
  • Phân loại khách, người chăm sóc, ghi chú nội bộ.
  • Customer Health Status: New / Active / VIP / Risk / Complaint.

Lịch sử bán hàng

  • Lịch sử Opportunity theo từng nhu cầu.
  • Lịch sử đơn hàng và giá trị mua.
  • Lịch sử hoàn hàng, đổi hàng hoặc hủy đơn.

Lịch sử CSKH

  • Lịch sử chăm sóc trước bán và sau bán.
  • Ticket/khiếu nại đang mở và đã đóng.
  • Ngày nhắc tiếp theo và việc cần làm tiếp theo.
Quy tắc Health Status: New là khách mới chưa mua; Active là khách đã mua hoặc đang tương tác tốt; VIP là khách giá trị cao/mua nhiều; Risk là khách có dấu hiệu không hài lòng, lâu không phản hồi hoặc có công nợ/vấn đề giao hàng; Complaint là khách đang có ticket khiếu nại chưa đóng.

8Ticket, khiếu nại và hoàn hàng

Complaint / Ticket Flow

  1. Khách phản ánh qua Facebook, Zalo, điện thoại hoặc tại cửa hàng.
  2. Sale/CSKH mở Customer Profile và tạo Ticket/Khiếu nại.
  3. Ticket được assign cho bộ phận liên quan và có Deadline SLA.
  4. Người phụ trách cập nhật trạng thái đến khi Đã xử lý hoặc Đóng.

Return / Hoàn hàng

  1. Nếu case liên quan đổi/trả/hoàn, ticket phải link với đơn hàng liên quan.
  2. Tạo hoặc link sang workflow hoàn hàng đang triển khai.
  3. Customer Profile hiển thị được lịch sử hoàn hàng, đổi hàng và khiếu nại liên quan.
  4. Chỉ đóng ticket khi đã có kết quả xử lý cuối cùng và khách được thông báo.

9SLA, reminder và Pancake lead flow

SLA và Reminder

  • Lead mới phải được xử lý trong thời gian cấu hình được, ví dụ 15 phút, 30 phút hoặc 24 giờ làm việc.
  • Quá hạn xử lý lead thì tự động notify sale phụ trách và quản lý.
  • Follow-up đến hạn thì tự động nhắc sale phụ trách.
  • Ticket quá SLA thì tự động nhắc người phụ trách và escalate cho quản lý.

Pancake · Facebook/Zalo Integration

  1. Lead/hội thoại từ Facebook Fanpage và Zalo OA đi vào Pancake trước.
  2. Pancake/n8n đồng bộ thông tin khách, kênh, page/OA, owner và hội thoại cần chăm sang Lark.
  3. Hệ thống kiểm tra trùng theo SĐT; nếu chưa có SĐT thì giữ ở hàng chờ cần bổ sung thông tin.
  4. Tạo hoặc gợi ý tạo Cơ hội với Nguồn cơ hội = Pancake Facebook/Pancake Zalo.
  5. Assign NVKD/Sale phụ trách theo rule chia khách.
  6. Sale follow-up trên Pancake; Lark chỉ ghi tóm tắt khi có kết quả quan trọng và tự động notify nếu quá hạn.

Vì sao dùng Pancake làm lớp đầu vào?

  • Gom inbox Facebook, Zalo về một nơi để sale không phải mở nhiều kênh riêng lẻ.
  • Giữ lịch sử chat và bối cảnh hội thoại trước khi đồng bộ sang Lark.
  • Phân chia nhân viên phụ trách ngay tại nơi phát sinh hội thoại.
  • Hỗ trợ AI chatbot và automation để phản hồi nhanh, giảm bỏ sót khách.
  • Phù hợp hơn Lark cho nghiệp vụ inbox/comment thời gian thực.

Lark nhận dữ liệu gì từ Pancake?

  • Lead/khách hàng mới và thông tin định danh như SĐT, tên, kênh nguồn.
  • Trạng thái lead hoặc trạng thái hội thoại cần theo dõi.
  • Nhân viên phụ trách/owner để tính SLA và KPI.
  • Lịch sử CSKH tóm tắt hoặc link trace về hội thoại Pancake.
  • Dữ liệu cần cho báo cáo tập trung: nguồn khách, tỷ lệ xử lý, cơ hội, đơn hàng, ticket.

10Form Lark dùng tại các mốc quan trọng

Form 1: Tạo Cơ hội

  • Tên cơ hội
  • Khách hàng
  • Sale phụ trách
  • Giai đoạn
  • Ưu tiên
  • Nguồn cơ hội
  • Nhu cầu / Ghi chú
  • Ngày nhắc tiếp theo

Form 2: Ghi nhận tương tác nhanh

  • Cơ hội
  • Tóm tắt tương tác quan trọng
  • Ngày nhắc lại

Để giảm thao tác, sale không copy chat từ Pancake sang Lark. Chỉ ghi gọn khi có mốc quan trọng: kết quả chính, việc cần làm tiếp theo và ngày nhắc lại.

Form 3: CSKH sau bán

  • Khách hàng
  • Cơ hội / Đơn hàng liên quan
  • Ngày nhận hàng
  • Phản hồi sau bán
  • Ngày nhắc CSKH sau bán
  • Customer Health Status

Form 4: Tạo yêu cầu hóa đơn Kiot

  • Khách hàng
  • Cơ hội
  • Chi tiết sản phẩm
  • Chi nhánh Kiot
  • Sale Kiot
  • Phương thức thanh toán
  • Đã thanh toán / COD

Form 5: Tạo Ticket/Khiếu nại

  • Khách hàng
  • Đơn hàng liên quan
  • Loại ticket
  • Mức độ ưu tiên
  • Bộ phận xử lý
  • Nội dung phản ánh
  • Deadline SLA

11Workflow nên setup ngay

Workflow Điều kiện kích hoạt
Chia khách sếp cung cấpKhách hàng có `Phân loại khách = Khách sếp cung cấp` và được gán `Người chăm sóc`
Pancake lead intakeCó lead/hội thoại mới từ Pancake hoặc import lead mới
Tạo cơ hội mớiTạo record mới ở bảng `Cơ hội`
Ghi tóm tắt chăm sóc`Tóm tắt tương tác quan trọng` có nội dung mới hoặc Pancake đồng bộ trạng thái quan trọng
Nhắc follow-upĐến `Ngày nhắc tiếp theo` và cơ hội chưa `Thất bại` / `Tạm dừng`
Lead quá hạn xử lýQuá `Deadline xử lý lead` nhưng cơ hội vẫn `Mới nhận` hoặc chưa có chăm sóc đầu tiên
CSKH sau bánCơ hội `Đã mua hàng` và đơn hàng đã giao/hoàn tất
Ticket mớiTạo ticket/khiếu nại mới từ Customer Profile
Ticket quá SLAQuá `Deadline SLA` nhưng ticket chưa `Đã xử lý` / `Đóng`
Link hoàn hàngTicket có loại `Đổi trả` hoặc `Hoàn hàng`
Lên đơn KiotPhương án 1: KiotViet tạo hóa đơn và webhook về Lark; Phương án 2: sale bấm `Tạo hóa đơn Kiot` trên Lark
Daily digestHằng ngày theo giờ cấu hình, ví dụ 8:00

12Checklist cho sale/CSKH

Việc phải nhớ

  • Khách mới vào thì tìm khách cũ trước.
  • Lead Facebook/Zalo phải được xử lý từ Pancake và đồng bộ/ghi nhận về Lark.
  • Nếu có nhu cầu cụ thể thì tạo Cơ hội.
  • Chat/follow-up trên Pancake; chỉ nhập tóm tắt vào Lark khi có mốc quan trọng.
  • Luôn điền Việc cần làm tiếp theo.
  • Luôn đặt Ngày nhắc lại.
  • Khách chốt mua thì dùng một trong hai luồng lên đơn đã chốt: KiotViet → Lark hoặc Lark → KiotViet.
  • Nếu dùng luồng mục tiêu Lark → KiotViet, sale bấm Tạo hóa đơn Kiot từ Lark, không nhập khách/đơn thủ công trên Kiot.
  • Khách đã mua thì chuyển Đã mua hàng, link đơn hàng và theo dõi nhận hàng.
  • Khách nhận hàng xong thì chuyển CSKH sau bán và ghi phản hồi.
  • Có phản ánh/khiếu nại thì tạo Ticket, không chỉ ghi chú trong chat.

View nên mở mỗi ngày

Cơ hội mới nhận Lead Pancake chưa có SĐT Khách sếp cung cấp chưa chia Khách sếp cung cấp đã chia Khách cần chia lại Khách tự kiếm Cơ hội cần chăm hôm nay Cơ hội quá hạn Cơ hội chờ phản hồi Cơ hội đã mua hàng Yêu cầu hóa đơn lỗi CSKH sau bán đến hạn Ticket mới Ticket quá SLA Khách Risk/Complaint Cơ hội của tôi