# Dẫn workshop discovery với khách: vẽ quy trình từ hai đầu, chấm điểm từng việc rồi mới hứa

> Phần lớn deployment thắng hay thua ngay từ discovery, nên đừng để câu "làm thêm cái này nữa nhé" chiếm hết chín mươi phút bạn có trong phòng họp của khách.

Bản gốc: https://fdetimes.net/vi/bach-khoa/dan-workshop-discovery-voi-khach-hang/

Thử hình dung chín giờ sáng ở văn phòng khách. Trong phòng có mười hai người. Giám đốc vận hành mở đầu: "Chúng tôi muốn AI cho toàn bộ bộ phận xử lý khiếu nại". Trưởng IT ngồi cuối bàn, khoanh tay. Ba nhân viên ngày nào cũng trả lời khiếu nại thì chưa được ai hỏi câu nào. Bạn có chín mươi phút.

Tình huống kiểu này là chuyện thường ngày của một FDE, và cách bạn dẫn buổi đó quyết định phần lớn những gì xảy ra sau. Playbook về FDE của Scaler viết thẳng rằng discovery là nơi phần lớn deployment thắng hoặc thua.

Mục tiêu của nó là một problem statement và một định nghĩa thành công mà cả hai bên cùng đồng ý, chứ không phải một danh sách mong muốn.

Dưới đây là một ví dụ đi từ đầu đến cuối: một công ty logistics giả định và quy trình xử lý khiếu nại hoá đơn của họ.

## Trước giờ họp: một câu hỏi, hai điểm mốc, dưới mười người

Hướng dẫn tổ chức workshop discovery của Koji khuyên viết ra trước tiên một câu hỏi duy nhất mà buổi họp phải trả lời. Với công ty logistics kia, câu đó không nên là "AI giúp được gì cho chăm sóc khách hàng". Một câu tốt hơn: "Trong quy trình xử lý khiếu nại hoá đơn, bước nào nên tự động hoá trước, và đo thành công bằng gì?"

Triaster, một công ty chuyên về bản đồ quy trình, khuyên chốt phạm vi trước buổi họp, rồi mở đầu bằng điểm bắt đầu và điểm kết thúc của phạm vi đó. Ở ví dụ này, điểm bắt đầu là lúc email khiếu nại rơi vào hộp thư chung. Điểm kết thúc là lúc credit note được phát hành, hoặc khiếu nại bị từ chối kèm lý do.

Danh sách người tham dự quan trọng không kém. Triaster coi các chuyên gia nghiệp vụ, tức người trực tiếp làm việc đó, là thành phần bắt buộc. Họ giữ số người dưới mười, muốn có một người hiểu quy trình nối sang các bộ phận khác thế nào, và cần người sở hữu quy trình ủng hộ.

Scaler nói cùng ý: đừng chỉ nói chuyện với lãnh đạo, hãy ngồi cùng những người sẽ thật sự dùng hệ thống. Vậy với mười hai người kia, việc đầu tiên là cắt danh sách.

Giữ người sở hữu quy trình, ba nhân viên xử lý khiếu nại, một người bên kế toán phụ trách phát hành credit note, trưởng IT và người quản lý kho. Giám đốc vận hành có thể chỉ cần dự mười lăm phút cuối, lúc chốt ưu tiên.

## Vẽ bản đồ từ hai đầu vào giữa

Khi đã có hai điểm mốc trên bảng, hãy để nhân viên kể lại một khiếu nại có thật mà họ xử lý tuần trước.

Mỗi bước là một tờ giấy dán: tiếp nhận email, phân loại, tra hoá đơn trong ERP, đối chiếu với bằng chứng giao hàng, xin duyệt, phát hành credit note.

Dưới mỗi tờ, ghi bốn thứ: ai làm, trên hệ thống nào, dùng dữ liệu gì, và hồ sơ hay phải chờ ở đâu.

Sẽ có những câu hỏi chưa ai trong phòng trả lời được, chẳng hạn bằng chứng giao hàng nằm trong hệ thống nào. Đừng dừng lại để đào bằng được. Sổ tay FDE của PostHog khuyên dùng công việc thật của khách để lộ ra các vấn đề thực, thay vì cố mô hình hoá mọi thứ ngay từ đầu.

Đánh dấu "?" lên tờ giấy, giao một người kiểm tra, rồi đi tiếp.

## Mười việc hợp lý, chỉ chọn một

Đến cuối phần vẽ, trên bảng thường có cả chục ý tưởng đều nghe hợp lý. PostHog mô tả kỹ năng phán đoán cốt lõi của FDE đúng ở chỗ này: biết trong mười việc hợp lý thì việc nào làm trước, và việc nào không làm luôn.

Ma trận ưu tiên của OpenAI Academy đặt hai câu hỏi cho từng workflow. Nếu chạy được thì nó đem lại bao nhiêu giá trị? Cần bao nhiêu công sức và độ phức tạp để triển khai được?

Để ước lượng giá trị, họ chỉ ra ba tín hiệu mạnh: tần suất, độ lặp lại và độ phủ. Dưới đây là cách chấm giả định cho ví dụ logistics, theo thang 1-5:

| Workflow ứng viên | Tần suất | Lặp lại | Độ phủ | Công sức | Quyết định |
|---|---|---|---|---|---|
| Phân loại email khiếu nại | 5 | 4 | 3 | 2 | Làm trước |
| Đối chiếu hoá đơn với bằng chứng giao hàng | 4 | 5 | 3 | 4 | Làm sau, khi đã rõ dữ liệu |
| Báo cáo khiếu nại hằng tháng cho CFO | 1 | 4 | 1 | 2 | Không làm |
| Dự báo khách nào sắp khiếu nại | 2 | 2 | 2 | 5 | Không làm |

Bảng này không phải một công thức. Giá trị của nó là buộc cả phòng nói thành lời vì sao chọn việc này mà không chọn việc kia. Báo cáo cho CFO dễ làm, nhưng mỗi tháng chỉ chạy một lần và chỉ một người đọc. Dự báo khiếu nại nghe hấp dẫn nhất, nhưng tốn công nhất và giá trị chưa rõ.

Ngay lúc đó sẽ có người hỏi: "Tiện thể mình làm luôn phần dự báo được không?" Lời khuyên của PostHog là phản biện mọi câu "có nên làm thêm…". Hãy ghi ý đó vào một cột "để sau" trên bảng, cho người đề xuất thấy ý của họ không bị vứt đi. Nhưng đừng để nó lọt vào phạm vi hôm nay.

## Những câu không được bỏ qua

Câu đầu tiên dành cho trưởng IT, người vẫn đang khoanh tay. Scaler nhấn mạnh rằng nếu dữ liệu của khách không được phép rời khỏi mạng nội bộ, bạn phải biết điều đó trước khi thiết kế bất cứ thứ gì. Hãy hỏi thẳng: email khiếu nại và dữ liệu ERP có được gửi tới một model bên ngoài không, và ai là người ký duyệt?

Câu thứ hai là câu PostHog đưa vào danh sách khi scoping: vấn đề được mô tả có đang chỉ tới một mẫu sâu hơn không? Giả sử khi kể chuyện, nhân viên nhắc rằng phần lớn khiếu nại đến từ cùng một kho.

Có thể gốc rễ là lỗi quét bằng chứng giao hàng ở kho đó, và một agent đọc email chỉ đang dọn hậu quả. Vì người quản lý kho đang ngồi trong phòng, bạn hỏi được ngay giả thuyết này có đáng đem đi kiểm tra không.

Câu thứ ba quay về đúng mục tiêu Scaler đặt ra: thành công trông như thế nào? Đừng rời phòng khi chưa có một câu cả hai bên gật đầu, chẳng hạn "thời gian từ lúc nhận email đến lúc khiếu nại vào đúng hàng đợi giảm từ X xuống Y", với X đo bằng dữ liệu thật trong tuần tới.

**Điểm mấu chốt:** Workshop discovery cho bạn giả thuyết để kiểm chứng, chưa phải bằng chứng.

## Sau giờ họp: những gì trên bảng vẫn chỉ là giả thuyết

Koji nói rõ rằng workshop không tạo ra bằng chứng. Những tờ giấy dán, điểm số và cả câu "phần lớn khiếu nại đến từ một kho" đều là giả thuyết.

Koji cũng khuyên xếp các giả định theo tác động và mức độ chưa chắc chắn. Áp vào ví dụ logistics, "email khiếu nại đủ rõ để phân loại tự động" có tác động lớn vì việc làm trước dựa cả vào nó, mà chưa ai đo. "Phần lớn khiếu nại đến từ một kho" cũng tác động lớn và cũng chưa chắc.

Vì thế việc đầu tiên sau buổi họp là kiểm hai giả định đó: lấy một mẫu khiếu nại thật, chẳng hạn một tuần email, chạy thử bước phân loại trên đó và đếm khiếu nại theo kho. Đó chính là tinh thần dùng công việc thật để lộ vấn đề mà PostHog khuyên.

Bạn nên gửi bản tóm tắt trong vòng một ngày, gồm câu hỏi trung tâm, bản đồ quy trình, bảng chấm điểm, cột "để sau", câu trả lời về dữ liệu và định nghĩa thành công.

Một bản như vậy cũng là thứ bạn mang vào phỏng vấn được, sau khi xoá tên khách. Trong CV, dòng "dẫn workshop discovery, chốt phạm vi từ mười ý tưởng xuống một và đo kết quả bằng chỉ số đã thống nhất" nói nhiều hơn chữ "giao tiếp tốt".

## Những lỗi khiến workshop thành buổi họp vô ích

Lỗi thứ hai là vẽ cả công ty, vì không chốt điểm đầu và điểm cuối, nên hết chín mươi phút vẫn chưa tới bước nào đáng tự động hoá.

Lỗi thứ ba là hứa ngay trong phòng, trước khi hỏi về giới hạn dữ liệu. Lời hứa đó có thể sụp chỉ sau một email của bộ phận bảo mật. Lỗi cuối là coi những gì cả phòng đồng thuận là sự thật đã được kiểm chứng, rồi xây ngay trên nó.

Một workshop tốt không kết thúc bằng tràng vỗ tay. Nó kết thúc khi bạn có một việc để làm vào sáng thứ Hai, một con số để đo, và danh sách những việc đã khéo léo nói "chưa".

**Thử ngay tuần này:**

- Chọn một quy trình bạn hiểu rõ (ở công ty hiện tại hoặc ở một khách hàng), ghi ra một câu hỏi trung tâm, điểm bắt đầu, điểm kết thúc và 5-7 bước ở giữa.
- Liệt kê bốn việc có thể tự động hoá trong quy trình đó, chấm 1-5 cho giá trị và công sức, rồi viết một câu giải thích vì sao bạn bỏ hẳn việc có điểm thấp nhất.
- Soạn sẵn ba câu hỏi bạn sẽ hỏi trong mọi workshop: về giới hạn dữ liệu, về mẫu sâu hơn và về định nghĩa thành công.

## Nguồn

- [How forward deployed engineers work - Handbook](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)

- [The Forward-Deployed Engineer Playbook: How the Role Actually Runs a Deployment](https://www.scaler.com/topics/the-forward-deployed-engineer-playbook/)

- [Capturing a Business Process: 3 Tips for Process Discovery Workshops](https://triaster.co.uk/blog/capturing-a-business-process-tips-for-process-discovery-workshops)

- [Prioritize AI workflow opportunities (OpenAI Academy)](https://academy.openai.com/public/clubs/champions-ecqup/resources/workflow-discovery-and-prioritization-matrix-2026-05-05)

- [Customer Discovery Workshop: The Step-by-Step Playbook with Templates (2026)](https://www.koji.so/docs/customer-discovery-workshop-guide)