title: "Bộ kịch bản giao tiếp (Part 2): Cách xử lý "Save-call" khi khách hàng đòi rời bỏ"
series: "CSM Masterclass: Từ Người Mới đến CSM Chiến nhất"
part: "Phần 2 — Action Kit Thực thi"
order: 11
content_type: "Action Kit / Template"
audience: "Customer Success Manager (CSM) mới vào nghề & đang phát triển"
reading_time: "12 phút"
tags:

• customer-success
• save-call
• churn
• kich-ban-giao-tiep
• de-escalation
• action-kit

Bộ kịch bản giao tiếp (Part 2): Cách xử lý "Save-call" khi khách hàng đòi rời bỏ

Save-call là cuộc gọi bạn thực hiện khi khách hàng đã nói ra (hoặc gần như chắc chắn) họ sẽ hủy hợp đồng, không gia hạn, hoặc rời bỏ sản phẩm. Đây là một trong những cuộc gọi áp lực nhất trong nghề CS — nhưng cũng là cuộc gọi có kịch bản rõ ràng nhất, nếu bạn biết cây quyết định bên dưới.

Cách dùng: đọc lướt cây kịch bản một lần trước khi gọi để nắm cấu trúc 4 bước, không học thuộc lòng từng chữ — hãy nói bằng giọng của bạn, giữ đúng tinh thần và trình tự. In bài này ra hoặc mở song song màn hình trong lúc gọi lần đầu, vài lần sau bạn sẽ tự nhiên.

Bước 0 — Chuẩn bị trước cuộc gọi (2 phút)

Trước khi bấm gọi, xác nhận nhanh 3 điều:

Bước 1 — Mở đầu: Thừa nhận cảm xúc trước

Đây chính là ứng dụng trực tiếp nguyên tắc "thừa nhận cảm xúc trước khi giải thích" từ bài De-escalation. Đừng mở đầu bằng câu hỏi khai thác lý do ngay — hãy dành 15-20 giây đầu để khách cảm thấy được nghe.

Nguyên văn:

"Chào anh/chị [Tên], em là [Tên bạn] bên [Tên công ty]. Trước tiên, em hiểu tình huống này thực sự gây khó chịu cho anh/chị, và em thật sự cảm ơn anh/chị đã dành thời gian nói chuyện với em trước khi quyết định. Em gọi không phải để thuyết phục anh/chị đổi ý ngay lập tức, mà để hiểu đúng chuyện gì đang xảy ra — vì em nghĩ anh/chị xứng đáng có một cuộc trò chuyện thẳng thắn trước khi mọi thứ khép lại."

Lưu ý: Câu cuối "không phải để thuyết phục đổi ý ngay lập tức" rất quan trọng — nó hạ vũ khí phòng thủ của khách hàng ngay từ đầu. Khách hàng đã lường trước bạn sẽ "chiến đấu" để giữ họ; khi bạn không làm vậy, họ thường mở lòng hơn.

Bước 2 — Câu hỏi khai thác lý do THẬT

Đừng hỏi "Anh/chị có chắc không?" hay "Có gì em có thể giúp không?" — những câu này quá chung chung và dễ nhận câu trả lời xã giao "Thôi, quyết định rồi". Hãy hỏi cụ thể, đưa khách vào chế độ giải thích thay vì phòng thủ:

Nguyên văn:

"Anh/chị có thể chia sẻ cụ thể điều gì khiến mình đi đến quyết định này không? Em muốn hiểu đúng vấn đề trước khi đề xuất bất cứ điều gì — chứ không muốn đoán mò rồi đưa ra giải pháp sai chỗ."

Sau khi khách trả lời, dùng kỹ thuật paraphrase (nhắc lại bằng lời của bạn) để xác nhận bạn hiểu đúng, đồng thời câu giờ để phân loại lý do vào một trong 3 nhánh bên dưới:

"Để em chắc là em hiểu đúng: vấn đề chính là [nhắc lại ý khách vừa nói], đúng không ạ?"

Từ đây, dựa vào câu trả lời, rẽ vào 1 trong 3 nhánh kịch bản.

🌳 CÂY KỊCH BẢN THEO 3 NHÁNH LÝ DO

Khách xác nhận lý do
        │
        ├── (a) VÌ GIÁ / CHI PHÍ ──────────► Nhánh A
        │
        ├── (b) VÌ THIẾU TÍNH NĂNG ────────► Nhánh B
        │
        └── (c) VÌ KHÔNG DÙNG TỚI /
              KHÔNG THẤY GIÁ TRỊ ─────────► Nhánh C

Nhánh A — Lý do: Giá / Chi phí

Dấu hiệu nhận biết: khách nói "đắt quá", "cắt ngân sách", "tìm được chỗ rẻ hơn", "công ty đang thắt chi tiêu".

Bước A1 — Xác nhận và không phán xét:

"Em hiểu, bài toán ngân sách là chuyện rất thực tế, đặc biệt trong giai đoạn này. Em không nghĩ đây là chuyện anh/chị cần giải thích thêm — vấn đề là làm sao để giá trị anh/chị nhận được xứng đáng với chi phí bỏ ra, đúng không ạ?"

Bước A2 — Hỏi để phân biệt "hết tiền" và "thấy không đáng tiền":

"Cho em hỏi thêm một chút: vấn đề là ngân sách hiện tại không còn khoản này nữa, hay là anh/chị thấy mức giá hiện tại chưa tương xứng với những gì team đang dùng?"

(Câu trả lời quyết định bạn đi tiếp theo hướng nào — downgrade hay renegotiate giá trị.)

Bước A3a — Nếu là vấn đề ngân sách thực sự → đề xuất downgrade:

"Vậy em có một phương án: mình có gói [Tên gói thấp hơn] vẫn giữ được [2-3 tính năng cốt lõi khách đang dùng nhiều nhất], chỉ cắt bớt [tính năng ít dùng], với chi phí thấp hơn khoảng [X]%. Anh/chị có muốn em gửi bảng so sánh chi tiết để cân nhắc không? Mình vẫn giữ được kết quả công việc, chỉ tối ưu lại chi phí thôi."

Bước A3b — Nếu là vấn đề "chưa thấy đáng tiền" → đề xuất ưu đãi gia hạn có điều kiện:

"Vậy để em đề xuất thế này: nếu anh/chị gia hạn thêm [3/6 tháng], em có thể xin duyệt mức giá ưu đãi [X]% cho giai đoạn này, đổi lại team em sẽ đồng hành sát hơn — có buổi check-in hàng tháng để đảm bảo anh/chị thấy rõ giá trị trước khi quyết định dài hạn. Anh/chị thấy phương án này có hợp lý để thử thêm một giai đoạn không?"

Lưu ý quan trọng: Chỉ đề xuất mức discount/downgrade nằm trong thẩm quyền đã xác nhận ở Bước 0. Nếu khách yêu cầu mức vượt thẩm quyền, dùng câu: "Mức này em cần xin duyệt từ quản lý, em xin phép trong 24h sẽ phản hồi anh/chị nhé" — không tự ý hứa.

Nhánh B — Lý do: Thiếu tính năng

Dấu hiệu nhận biết: khách nói "sản phẩm không có [tính năng X]", "đối thủ có tính năng đó", "team em cần [tính năng] mà chờ mãi chưa thấy".

Bước B1 — Xác nhận cụ thể tính năng đang thiếu, tránh chung chung:

"Anh/chị có thể nói rõ hơn tính năng [X] cụ thể cần giải quyết bài toán gì không? Đôi khi có cách dùng tạm những gì hiện có để giải quyết một phần, trong lúc team sản phẩm xử lý phần còn lại."

Bước B2 — Kiểm tra roadmap thật (không hứa suông):

"Để em kiểm tra chính xác: tính năng này [đã có trong roadmap quý [X] / đang được đội sản phẩm đánh giá / hiện chưa nằm trong kế hoạch]. Em sẽ không hứa ngày cụ thể nếu chưa chắc chắn, nhưng em có thể kết nối trực tiếp phản hồi của anh/chị với đội sản phẩm — thực tế nhiều tính năng bọn em ưu tiên phát triển đến từ đúng những phản hồi như thế này."

Bước B3a — Nếu tính năng đã có trong roadmap gần:

"Tin vui là tính năng này dự kiến ra mắt trong [khung thời gian cụ thể]. Nếu anh/chị đồng ý, em có thể đưa team vào nhóm early-access để dùng thử ngay khi có bản beta, và mình tạm dùng [giải pháp thay thế/workaround] trong lúc chờ. Anh/chị thấy phương án chờ thêm [X tuần/tháng] với early-access có ổn không?"

Bước B3b — Nếu tính năng chưa có trong roadmap gần:

"Thành thật là tính năng này chưa nằm trong kế hoạch gần, nên em không muốn hứa hẹn thiếu chắc chắn. Nhưng em có thể đề xuất cách làm tạm: [mô tả workaround cụ thể — dùng tính năng khác kết hợp, tích hợp qua API/Zapier, quy trình thủ công tạm thời]. Cách này có giải quyết được phần lớn nhu cầu trước mắt của team không ạ, trong lúc em đưa đề xuất chính thức lên đội sản phẩm?"

Nhánh C — Lý do: Không dùng tới / Không thấy giá trị

Dấu hiệu nhận biết: khách nói "team ít dùng", "không thấy hiệu quả rõ ràng", "mua về nhưng không ai đụng tới".

Đây là nhánh quan trọng nhất để cứu, vì gốc rễ thường không phải sản phẩm dở mà là onboarding chưa chạm được Aha Moment ban đầu. Quay lại đúng JTBD (Jobs-to-be-Done — công việc khách hàng thực sự cần hoàn thành) mà khách đã đặt ra lúc mua.

Bước C1 — Quay lại JTBD gốc:

"Cho em hỏi lại một chút để hiểu rõ: lúc anh/chị quyết định dùng [Tên sản phẩm], mục tiêu ban đầu team mình muốn giải quyết là gì? Em muốn xem lại xem mình có đang đi lệch khỏi mục tiêu đó không."

Bước C2 — Xác định điểm nghẽn cụ thể (không phải "sản phẩm không tốt" chung chung):

"Vậy nếu mục tiêu ban đầu là [nhắc lại JTBD], điều gì đang cản trở team đạt được nó — là do chưa ai được đào tạo dùng đúng cách, do quy trình nội bộ chưa gắn sản phẩm vào công việc hàng ngày, hay do bản thân sản phẩm chưa đáp ứng được nhu cầu đó?"

Bước C3a — Nếu điểm nghẽn là do onboarding/đào tạo chưa tới nơi:

"Vậy đây là tin tốt — vấn đề không nằm ở việc sản phẩm không phù hợp, mà là team chưa được set up đúng cách để thấy giá trị. Em đề xuất mình dành 1 buổi 30 phút, em ngồi trực tiếp với [người dùng chính] để rà lại đúng use case ban đầu và chỉnh lại cách dùng cho khớp với công việc hàng ngày của team. Nếu sau buổi đó và [2-4 tuần] dùng thử mà vẫn chưa thấy rõ giá trị, mình ngồi lại nói chuyện tiếp, công bằng không ạ?"

Bước C3b — Nếu điểm nghẽn thực sự là sản phẩm không phù hợp với nhu cầu:

"Em ghi nhận thẳng thắn: nếu đúng là [Tên sản phẩm] không giải quyết được bài toán [JTBD] của team, thì việc tiếp tục trả phí cũng không công bằng cho anh/chị. Em sẽ không cố thuyết phục dùng tiếp trong trường hợp này — nhưng em rất mong được ghi nhận lại phản hồi này để đội sản phẩm hiểu rõ khoảng cách, và nếu sau này mình có cải tiến phù hợp hơn, em rất mong được kết nối lại."

(Nhánh C3b dẫn thẳng sang Bước 4 — chốt "chia tay đẹp" bên dưới.)

Bước 4 — Chốt khi khách vẫn quyết định rời đi: "Chia tay đẹp"

Nếu sau tất cả các nhánh trên, khách hàng vẫn giữ quyết định rời đi, đây là lúc dừng thuyết phục và chuyển sang giữ mối quan hệ cho tương lai. Cố nài nỉ thêm ở giai đoạn này chỉ khiến khách hàng nhớ về công ty bạn như một trải nghiệm khó chịu ở phút cuối — điều ngược lại hoàn toàn với mục tiêu.

Nguyên văn:

"Em tôn trọng quyết định của anh/chị, và cảm ơn anh/chị đã thẳng thắn chia sẻ trong suốt cuộc trò chuyện này — điều đó giúp em và team hiểu rõ hơn rất nhiều. Trước khi mình khép lại, em có 2 việc muốn làm: một là đảm bảo quá trình chuyển đổi/kết thúc hợp đồng diễn ra suôn sẻ nhất cho team anh/chị, không có gì bị gián đoạn giữa chừng; hai là nếu tiện, em rất mong được nghe thêm góp ý ngắn gọn để tụi em làm tốt hơn cho những khách hàng sau. Và nếu sau này tình hình hoặc nhu cầu của team thay đổi, cánh cửa luôn mở — em rất vui được đón anh/chị quay lại bất cứ lúc nào, không cần khách sáo gì cả."

Checklist các việc cần làm ngay sau cuộc gọi (dù kết quả thế nào):

📝 Cách tuỳ biến cho tình huống của bạn

1. Xác định trước thẩm quyền discount/downgrade của bạn trước khi dùng kịch bản Nhánh A — đừng để đến giữa cuộc gọi mới hỏi quản lý, sẽ mất nhịp và giảm uy tín.
2. Chuẩn bị sẵn danh sách workaround cho 3-5 tính năng hay bị khách yêu cầu nhất (Nhánh B) — đừng để phải nghĩ ứng biến ngay trong cuộc gọi.
3. Ôn lại JTBD của từng nhóm khách hàng chính (xem lại Bài 2) trước khi gọi Nhánh C — câu hỏi "mục tiêu ban đầu của anh/chị là gì" sẽ hời hợt nếu bạn không có ngữ cảnh sẵn trong đầu.
4. Nếu công ty bạn có quy trình "win-back" (giành lại khách đã rời) chính thức, thêm một dòng vào email cảm ơn ở Bước 4 để khách biết cách quay lại dễ dàng, thay vì phải liên hệ từ đầu.

🔗 Quay lại tư duy nền tảng

Toàn bộ Bước 1 (thừa nhận cảm xúc trước) và tinh thần "không ép buộc" ở Bước 4 của kịch bản này là ứng dụng trực tiếp nguyên tắc đã học ở Kỹ năng De-escalation: Nghệ thuật biến khách hàng giận dữ thành khách hàng trung thành. Nếu bạn thấy mình vẫn muốn "nhảy" thẳng vào giải pháp mà bỏ qua bước thừa nhận cảm xúc, hãy đọc lại bài đó để hiểu vì sao thứ tự này không phải là hình thức xã giao, mà là cơ chế tâm lý bắt buộc để khách hàng thực sự nghe được đề xuất của bạn.

🔗 Bài viết liên quan

• Bộ kịch bản giao tiếp (Part 1): Welcome call & Discovery call — kịch bản cho đầu hành trình khách hàng, để đối chiếu phong cách giao tiếp nhất quán xuyên suốt vòng đời khách hàng.
• Checklist Onboarding 10 bước — nếu Nhánh C của bài này chỉ ra vấn đề nằm ở onboarding, đây là công cụ để rà soát và sửa tận gốc cho những khách hàng mới, tránh lặp lại tình huống save-call.

Bài trước: Bộ kịch bản giao tiếp (Part 1) · Bài tiếp theo: Checklist Onboarding