Họp business review với khách: FDE chuẩn bị số liệu, rủi ro và bước tiếp theo thế nào

Ba tuần sau khi hệ thống lên production, quản lý tài khoản nhắn cho bạn: thứ Năm tuần sau có buổi rà soát quý với khách, phó giám đốc vận hành sẽ dự, nhờ bạn chuẩn bị phần kỹ thuật.

Phản xạ của nhiều kỹ sư là mở Jira và liệt kê mọi thứ đã ship. Đó là cách nhanh nhất để lãng phí một giờ của người quyền lực nhất trong phòng.

Buổi business review là nơi khách quyết định mở rộng, gia hạn, hay để dự án lặng lẽ chìm xuống. Với FDE, đó cũng chính là thước đo công việc của bạn: pilot có thành production, khách có ký tiếp hay mở rộng phạm vi, hay mọi thứ dừng lại ở bản thử.

Vì thế, chuẩn bị business review là một kỹ năng FDE thực thụ, không phải việc hành chính để dành cho quản lý tài khoản. Bạn là người hiểu hệ thống rõ nhất, và cũng là người có thể dịch nó sang ngôn ngữ của người ký hợp đồng.

Báo cáo tiến độ không phải là business review

Buổi rà soát không phải nơi cập nhật trạng thái, cũng không phải một buổi gỡ lỗi kỹ thuật. Agenda nên xoay quanh kết quả khách nhận được, không phải danh sách các bản cập nhật.

Bạn cũng không cần kể hết. Chỉ chọn 2-3 thành quả thể hiện giá trị kinh doanh thật, đo được, thay vì trình bày mọi hoạt động của đội.

Phép thử đơn giản nhất: buổi rà soát phải dẫn tới ít nhất một quyết định, một cam kết, hoặc một bước tiếp theo rõ ràng. Không có cái nào, nó chỉ là một buổi trình chiếu.

Vậy nên việc chuẩn bị bắt đầu ở chỗ khác hẳn. Trước khi mở bảng tính, hãy viết ra một câu: cuối buổi họp, bạn muốn khách đồng ý điều gì? Mọi con số, mọi rủi ro trên slide đều phải phục vụ câu đó.

Một ví dụ: agent xử lý hồ sơ bồi thường

Thử hình dung bạn đã triển khai một agent đọc và phân loại hồ sơ bồi thường cho một công ty bảo hiểm. Quyết định bạn cần là: khách đồng ý mở rộng từ nhóm xử lý thí điểm sang các nhóm còn lại trong quý tới.

Bản nháp đầu của bạn có độ trễ p95, số token mỗi hồ sơ, độ chính xác trích xuất trên tập eval. Đó là số của bạn, không phải của họ. Thứ cần lên slide là những chỉ số quan trọng nhất với hoạt động kinh doanh của khách, nên bạn đổi sang thời gian xử lý trung bình mỗi hồ sơ và tỷ lệ hồ sơ phải làm lại.

Tiếp theo là so sánh với mốc của quý trước để thấy xu hướng. Giả sử dashboard của bạn cho thấy thời gian xử lý giảm từ 32 phút quý trước xuống 25 phút quý này: một câu chuyện rõ ràng.

Rồi bạn hỏi trưởng nhóm vận hành phía khách và phát hiện báo cáo nội bộ của họ ghi 29 phút, vì họ tính cả thời gian hồ sơ nằm chờ trong hàng đợi.

Nếu bạn đưa 25 lên slide trong khi phó giám đốc cầm tờ giấy ghi 29, cả buổi họp sẽ xoay quanh việc ai đúng. Chỉ một con số lệch là đủ để khách bắt đầu nghi mọi con số còn lại, và câu chuyện chính bị bỏ dở. Vì vậy số liệu phải được đối chiếu giữa các nguồn trước khi bước vào phòng.

Cách xử lý là thống nhất định nghĩa trước buổi họp, rồi ghi rõ trên slide chỉ số được tính từ đâu đến đâu. Có thể bạn trình bày cả hai con số, kèm một dòng giải thích phần chênh lệch nằm ở hàng đợi. Phần chênh lệch đó thậm chí có thể trở thành đề xuất cho quý sau.

Rủi ro phải đi kèm cách xử lý

Trong ví dụ trên, giả sử có hai vấn đề bạn biết rõ: chỉ một phần nhân viên nhóm thí điểm dùng agent hằng ngày, và agent đọc kém các hồ sơ viết tay. Bản năng là giấu đi để buổi họp đẹp hơn. Đó là sai lầm.

Rủi ro nên được nêu sớm, trước khi nó đe dọa việc gia hạn, và mỗi rủi ro đi cùng một biện pháp đề xuất. Rủi ro về mức độ sử dụng đi kèm đề xuất mở hai buổi hướng dẫn ngay tại chỗ.

Rủi ro về hồ sơ viết tay đi kèm đề xuất chuyển loại hồ sơ này sang luồng người duyệt trong lúc bạn thu thập mẫu để cải thiện.

Khi rủi ro được trình bày như vậy, khách thấy bạn kiểm soát được tình hình. Khi họ tự phát hiện ra, họ sẽ tự hỏi bạn còn giấu gì nữa.

Bản pre-read một trang

Gửi tài liệu đọc trước khoảng 48 giờ, để buổi họp không phải mất thời gian giải thích lại bối cảnh. Thời gian ngồi cùng nhau nên dành cho tranh luận và quyết định. Đây là khung bạn có thể dùng cho ví dụ bồi thường:

Phần	Nội dung	Ví dụ (giả định)
Quyết định cần chốt	Một câu, đặt lên đầu	Mở rộng sang các nhóm xử lý còn lại trong quý tới
2-3 kết quả	Chỉ số của khách, so với quý trước, ghi rõ định nghĩa	Thời gian xử lý mỗi hồ sơ, tỷ lệ làm lại
Time-to-value	Từ lúc bắt đầu engagement đến khi hệ thống chạy và được dùng thật	Số tuần từ kickoff đến khi nhóm thí điểm dùng hằng ngày
Rủi ro	Mỗi rủi ro một dòng, kèm cách xử lý	Mức sử dụng thấp, kèm buổi hướng dẫn tại chỗ
90 ngày tới	Ưu tiên, người phụ trách, mốc thời gian ở cả hai phía	Bên khách cử đầu mối cho mỗi nhóm mới

Dòng time-to-value là một thước đo dùng để đánh giá FDE: tính từ lúc engagement bắt đầu đến khi có một hệ thống chạy được và được sử dụng. Chữ “được sử dụng” quan trọng. Một hệ thống đã deploy nhưng không ai dùng chưa tạo ra giá trị.

Kết thúc buổi họp bằng cam kết của cả hai bên

Phần cuối buổi họp là để thống nhất 90 ngày tới: ưu tiên, người phụ trách và mốc thời gian, cho cả hai phía chứ không chỉ phía bạn. Tốt nhất hai bên cùng mang tới một mutual success plan, ghi lại mục tiêu chung, các mốc đo và rủi ro.

Khép lại bằng kế hoạch hành động chung, và đặt luôn lịch buổi rà soát tiếp theo trước khi mọi người đứng dậy.

Nếu việc mở rộng cần khách cấp quyền truy cập dữ liệu của các nhóm mới, đó phải là một dòng có tên người bên khách và có ngày cụ thể.

Những lỗi khiến buổi rà soát đổ vỡ

Gần như phổ biến không kém là mang số liệu nội bộ như độ trễ hay điểm eval lên slide chính, trong khi người nghe quan tâm đến chi phí và thời gian của đội họ. Những số đó nên nằm ở phụ lục, để dùng khi có người hỏi.

Rồi đến việc không đối chiếu số với khách trước, như chuyện 25 phút và 29 phút ở trên, hoặc giấu rủi ro, hoặc nêu rủi ro mà không kèm cách xử lý. Và tệ nhất là ra về với câu “chúng ta sẽ trao đổi thêm”, nghĩa là buổi họp không chốt được gì.

Biến buổi rà soát thành một dòng CV

Ví dụ bồi thường cũng là khuôn mẫu cho một dòng CV tốt. Thay vì “giao tiếp tốt với khách hàng”, hãy viết rằng bạn đã chuẩn bị và trình bày buổi rà soát quý cho cấp lãnh đạo phía khách, thống nhất định nghĩa chỉ số với đội vận hành, và buổi họp chốt việc mở rộng sang các nhóm còn lại.

Khi phỏng vấn, câu chuyện về con số 25 và 29 phút đáng kể lại chi tiết. Nó cho thấy bạn vừa hiểu dữ liệu, vừa hiểu người đang cầm dữ liệu ở phía bên kia bàn.

Bài tập: lập bảng 90 ngày cho dự án của bạn

Lấy dự án bạn đang làm và kẻ một bảng bốn cột: việc cần làm, người phụ trách, phía nào, ngày hoàn thành. Viết ít nhất ba dòng cho phía bạn và ba dòng cho phía khách, mỗi dòng có tên người thật và ngày cụ thể.

Nếu bạn không điền nổi tên người bên khách cho dòng nào, đó chính là rủi ro đầu tiên cần đưa vào buổi rà soát tới, kèm đề xuất cách xử lý.

Lần tới khi quản lý tài khoản nhờ bạn “chuẩn bị phần kỹ thuật”, đừng mở Jira trước. Hãy hỏi lại họ: chúng ta cần khách quyết định điều gì?