Chào mọi người,

Nếu Day 15 mình kể về pha “bị khách phản dame” ngay trong họp, thì sang Day 16 này, mình muốn chia sẻ một bài học khác: nghệ thuật follow-up.
Nghe tưởng đơn giản, nhưng chính nó đã giúp mình thoát khỏi cái mác bị khách hàng cười cợt là “họp cho vui”.

 

🎾 Bối cảnh

Trong một dự án tennis court booking, khách yêu cầu thêm chính sách hủy (cancel policy).
Nghe qua tưởng chỉ là rule đơn giản:

  • Cancel trước 24h → refund 100%

  • Cancel trong vòng 24h → refund 0%

Nghe có vẻ rất dễ và có thể báo team dev làm ngay luôn được đúng không?

Nhưng không, đến buổi review tiếp theo, khách lại “quăng” thêm hàng loạt dimension:

  1. Loại sân

    • Outdoor → hủy trước 24h refund 100%.

    • Indoor → chi phí vận hành cao, hủy trước 24h chỉ refund 50%.

  2. Loại user

    • Booking lẻ → áp dụng rule cơ bản.

    • Subscription (thành viên tháng) → không refund, mà đổi thành credit.

  3. Nguyên nhân hủy

    • User hủy → theo rule trên.

    • Sân hủy (bảo trì, sự cố điện, thời tiết cực đoan) → luôn refund 100% hoặc trừ vào credit.

  4. User VIP

    • Luôn được cộng thêm benefit 20%.

Và cú twist: khách hỏi mình thẳng trong meeting bằng tiếng Nhật:

「もしVIPユーザーで、サブスクリプション契約をしていて、インドアコートを予約し、ちょうど24時間前にキャンセルした場合、どう処理されますか?」

Mình đứng hình ngay trong cuộc họp. Vì spec mình viết chỉ cover từng rule riêng lẻ, không hề define priority khi các dimension chồng chéo.

(※ Dimension: chiều phân tích, khía cạnh, yếu tố phân tích)

 

Khách quay sang nói một câu khá đau:

「仕様がこのままだと、開発チームはどう解釈してもいい状態ですよね。じゃあ前回のミーティングは何のためにしたんでしょうか?」

 

📚 Đào sâu vào issue

Cái mình thiếu không phải ở nghe hiểu, mà là tư duy follow-up sau họp.

  • Chỉ assume rule đơn giản → không gửi lại confirmation detail.

  • Bỏ lỡ việc phát hiện ra requirement thực chất có nhiều chiều (multi-dimension).

👉 Thực tế, business case này phức tạp vì có ít nhất 4 dimension chồng chéo:

  • Dimension sân (indoor/outdoor)

  • Dimension user (normal/subscription/VIP)

  • Dimension lý do hủy (user cancel/system cancel)

  • Dimension thời gian (trước 24h, trong 24h, sát giờ)

Khi những dimension này giao nhau → phải có business matrix để chỉ rõ rule nào ưu tiên.

Ví dụ case khách nêu:
VIP + subscription + indoor + cancel đúng 24h → refund, credit, hay % nào?

Với spec cũ, mình không có câu trả lời.

 

👩‍💻 Cách xử lý

Ngay sau buổi họp, mình follow-up bằng mail xác nhận rõ ràng:

  1. Tóm tắt lại ý khách:

「本日の打ち合わせでいただいたキャンセルポリシーに関するご要望は、コートの種類、ユーザー種別、キャンセル理由、キャンセルタイミングの4つの条件が組み合わさる可能性がある、という理解です。」

  1. Đưa ra business matrix để confirm thay vì chỉ list rule.
    Ví dụ:

 

Normal

Subscription

VIP

Outdoor – cancel >24h

Refund 100%

Credit 100%

Refund 120%

Indoor – cancel >24h

Refund 50%

Credit 50%

Refund 70% / Credit 70%

System cancel (any case)

Refund 100%

Credit 100%

Refund 120% / Credit 120%

 

  1. Chủ động hỏi edge case thay vì để khách nêu:

「もしVIPユーザーでサブスクリプションを利用し、インドアコートを24時間前にキャンセルした場合、返金とクレジットのどちらを優先すべきでしょうか?」

👉 Nhờ vậy, khách hàng cảm thấy mình được “dẫn dắt” thay vì chỉ “ghi chép”.

 

🌱 Bài học mình rút ra

1: Follow-up không chỉ là courtesy, mà là công cụ bắt bug từ sớm

- Meeting xong phải luôn có follow-up note lại rule chi tiết, edge case, và các dimension.

📧 Mail sample follow-up

件名:キャンセルポリシーに関する要件確認のお願い

[お客様名] 様

いつもお世話になっております。

本日の打ち合わせにてご説明いただきましたキャンセルポリシーについて、私の理解を整理し、下記の通りまとめさせていただきました。
ご確認の上、相違や不足がございましたらご指摘いただけますと幸いです。

1. ご要望の理解

キャンセルポリシーは以下の4つの条件が組み合わさると理解しております。

  • コート種別(アウトドア/インドア)

  • ユーザー種別(通常/サブスクリプション会員/VIP)

  • キャンセル理由(ユーザーによるキャンセル/システム側キャンセル)

  • キャンセルタイミング(24時間前以前/24時間以内/直前)

 

2. 初期整理したルール例(ドラフト)

 

通常ユーザー

サブスクリプション

VIP

アウトドア – 24h前以前

返金100%

クレジット100%

返金120%

インドア – 24h前以前

返金50%

クレジット50%

返金70%/クレジット70%

システム都合キャンセル(全てのケース)

返金100%

クレジット100%

返金120%/クレジット120%

※上記は一旦私の理解に基づく例示です。実際のルールとして確定ではありません。

 

3. 確認させていただきたい点

  • VIPユーザーかつサブスクリプション契約で、インドアコートをちょうど24時間前にキャンセルした場合、返金とクレジットのどちらを優先すべきでしょうか。

  • インドアのサブスクリプションユーザーに対して「返金なし・クレジット付与あり」という理解でよろしいでしょうか。

  • 上記以外にも優先順位や特別ルールがあればご教示いただけますでしょうか。

 

以上、ご確認よろしくお願いいたします。

 

2: Phải confirm bằng business matrix, không chỉ gạch đầu dòng

- Với requirement nhiều chiều, chỉ liệt kê rule là chưa đủ.

- Cần build bảng matrix (hoặc diagram timeline) để thấy khi các rule giao nhau thì outcome là gì.

 

3: Không assume “rule đơn giản”

- Requirement càng nghe có vẻ đơn giản → càng dễ có trap.

- Rule nhỏ nhưng nhiều dimension sẽ biến thành một bài toán phức tạp.

 

4: Follow-up là cơ hội để dẫn dắt khách

- Thay vì ngồi chờ khách nêu ra case, mình có thể proactive hỏi:

“Nếu VIP user có subscription mà hủy sân indoor trước 24h thì muốn refund, credit, hay hybrid rule nào?”

👉 Làm vậy, khách sẽ thấy BA/BrSE không chỉ nghe-gõ, mà còn tư duy trước một bước.

 

 

Checklist chống "họp cho vui"

  • Sau họp, luôn viết follow-up mail/slack recap: rule + edge case.

  • Confirm không chỉ điều kiện đơn, mà cả khi nhiều điều kiện chồng chéo.

  • Với business rule nhiều dimension → làm business matrix.

  • Paraphrase lại rule theo ví dụ cụ thể, nhờ khách confirm.

 

🥀 Đúc kết

Follow-up không phải “thủ tục hành chính”, mà là nghệ thuật giúp BrSE tránh hiểu sai, tránh bị nói “họp cho vui”.

Giống như trong tennis, một cú bóng đơn giản nhìn tưởng dễ trả, nhưng khi nó xoáy kép, nảy ở góc sân, nếu không có chiến thuật follow-up, bạn sẽ bỏ lỡ ngay.

👉 Nghệ thuật follow-up chính là: không chỉ trả lại quả bóng, mà còn phải dẫn dắt nhịp trận, để mình và khách cùng chơi trên một mặt sân rõ ràng 🎾.