Xây dựng mô hình vận hành CX có khả năng mở rộng

Một ngân hàng tôi từng tư vấn có một chi nhánh mẫu vận hành CX xuất sắc: nhân viên chủ động xin lỗi khi giao dịch chậm, quy trình khiếu nại được xử lý trong 24 giờ, điểm hài lòng cao hơn trung bình mạng lưới gần 20 điểm. Ban điều hành quyết định nhân rộng mô hình ra 60 chi nhánh trong vòng một năm. Mười tám tháng sau, chi nhánh mẫu vẫn xuất sắc — còn 59 chi nhánh còn lại quay về đúng như trước khi dự án bắt đầu. Không ai làm sai quy trình. Vấn đề là chưa từng có quy trình nào để họ làm theo cho đúng. Đó là thất bại kinh điển của CX: nhầm một sáng kiến tốt với một mô hình vận hành có thể scale. Mô hình vận hành CX là tập hợp các cơ chế — quản trị, quy trình, vai trò, dữ liệu và ngân sách — biến trải nghiệm khách hàng từ nỗ lực cá nhân của một vài người xuất sắc thành một năng lực tổ chức lặp lại được ở mọi đơn vị, mọi ca làm việc, mọi thời điểm. Không có nó, CX mãi là dự án; có nó, CX trở thành chức năng.

Vì sao hầu hết chương trình CX "chết" khi mở rộng quy mô?

Vì chúng được thiết kế cho quy mô nhỏ. Một trưởng phòng CX tâm huyết có thể tự tay theo sát 5 chi nhánh, đọc từng phản hồi khách hàng, gọi điện nhắc từng quản lý. Ở quy mô 50 chi nhánh, cơ chế đó sụp đổ về mặt toán học — không phải vì con người kém đi, mà vì băng thông quản lý không co giãn theo cùng tốc độ với số điểm chạm cần giám sát.

Nghiên cứu "The Truth About Customer Experience" của Rawson, Duncan và Jones (Harvard Business Review, tháng 9/2013) chỉ ra một điểm then chốt: các công ty thường quản trị CX theo từng điểm chạm riêng lẻ trong khi khách hàng trải nghiệm nó như một hành trình liên tục. Khi tổ chức mở rộng, khoảng cách giữa cách CX được thiết kế (theo hành trình) và cách nó được vận hành (theo phòng ban) càng lộ rõ — và đó chính xác là nơi mô hình vận hành phải can thiệp.

Mô hình vận hành CX khác gì với chiến lược CX?

Chiến lược trả lời câu hỏi "chúng ta muốn trở thành công ty như thế nào với khách hàng?". Mô hình vận hành trả lời câu hỏi khó hơn: "ai làm gì, quyết định gì, với ngân sách nào, và điều gì xảy ra khi có xung đột giữa tốc độ và chất lượng trải nghiệm?". Rất nhiều tổ chức có một bản chiến lược CX đẹp trên slide nhưng không có cơ chế nào buộc một trưởng phòng vận hành phải ưu tiên trải nghiệm khách hàng hơn KPI chi phí ngắn hạn của mình.

Nói cách khác: chiến lược là điểm đến, mô hình vận hành là hệ thống đường ray. Không có đường ray, đoàn tàu chiến lược chỉ chạy được ở đúng đoạn đường đã trải sẵn — tức là nơi có một cá nhân xuất sắc đang đẩy nó bằng tay.

Một mô hình vận hành CX có thể scale gồm những lớp nào?

Từ những chương trình tôi đã trực tiếp dựng và sửa lại, tôi luôn quy về ba lớp bắt buộc. Thiếu một lớp, hai lớp còn lại sẽ tự sụp:

• Lớp quản trị (governance): ai có quyền quyết định gì, ở tầng nào — từ việc phê duyệt một thay đổi quy trình nhỏ đến việc đánh đổi trải nghiệm lấy tốc độ triển khai. Không có lớp này, mọi cải tiến CX phụ thuộc vào việc "ai đang có mặt trong phòng họp hôm đó".
• Lớp quy trình và dữ liệu: cách hành trình khách hàng được ánh xạ, đo lường và cập nhật một cách nhất quán, không phụ thuộc vào việc ai là người vẽ bản đồ hành trình lần gần nhất.
• Lớp năng lực và văn hoá: liệu tuyến đầu có được huấn luyện, có công cụ, và có động lực đúng để hành xử theo thiết kế — hay họ chỉ đang diễn lại đúng những gì được kiểm tra trong buổi đào tạo rồi quay lại thói quen cũ ngay sau đó.

Ba lớp này không tách rời. Một quy trình tốt không có quản trị rõ ràng sẽ bị bẻ cong ngay khi gặp áp lực doanh số quý. Một cơ chế quản trị chặt nhưng thiếu năng lực tuyến đầu chỉ tạo ra tuân thủ hình thức. Đây cũng là lý do các dự án service design đẹp trên giấy thường chết trong triển khai — chúng dừng lại ở lớp quy trình mà không đi đến lớp quản trị và năng lực.

Làm sao thiết kế quản trị CX mà không tạo ra bộ máy quan liêu?

Câu trả lời ngắn: phân tầng quyết định theo mức độ rủi ro, không theo cấp bậc. Rất nhiều tổ chức mắc lỗi ngược — mọi thay đổi trải nghiệm, dù nhỏ, đều phải đi qua ủy ban cấp cao, khiến tốc độ cải tiến chậm đến mức tuyến đầu bỏ cuộc và tự xử lý theo cách riêng.

Một cấu trúc tôi thường khuyến nghị có ba tầng:

1. Tầng vận hành hàng ngày — quản lý chi nhánh hoặc trưởng nhóm được quyền tự quyết những điều chỉnh trải nghiệm không ảnh hưởng đến rủi ro tài chính hay pháp lý (ví dụ: cách chào khách, thứ tự xử lý hàng chờ).
2. Tầng điều phối chức năng — CX Program Office giữ vai trò trọng tài giữa các phòng ban khi một cải tiến trải nghiệm đòi hỏi thay đổi ở nhiều bộ phận (ví dụ: rút ngắn thời gian phê duyệt hồ sơ đòi cả IT và tín dụng cùng tham gia).
3. Tầng quyết định chiến lược — ban điều hành chỉ can thiệp vào những đánh đổi có tính nguyên tắc: ngân sách lớn, thay đổi mô hình định giá, hoặc rủi ro thương hiệu.

Việc phân tầng này cần được viết thành văn bản — một khung quản trị CX rõ ràng — chứ không để ngầm hiểu. Ngầm hiểu là nơi văn hoá công ty âm thầm quay lại nguyên trạng cũ mỗi khi có sức ép.

CX Program Office nên vận hành như thế nào để không biến thành phòng "báo cáo"?

Rủi ro lớn nhất của một CX Program Office là trở thành nơi tổng hợp dashboard mà không có thẩm quyền thay đổi bất cứ điều gì. Để tránh điều đó, nó cần ba loại thẩm quyền cụ thể, không chỉ vai trò "điều phối":

• Thẩm quyền dữ liệu: quyền yêu cầu các phòng ban báo cáo theo cùng một định nghĩa chỉ số, cùng một chu kỳ — chấm dứt tình trạng mỗi vùng miền tính NPS theo cách riêng.
• Thẩm quyền ưu tiên hoá: quyền xếp hạng danh mục sáng kiến CX theo tác động thực tế, không theo ai la lớn nhất trong cuộc họp. Đây là nơi một khung ưu tiên hoá danh mục sáng kiến CX có kỷ luật trở nên quan trọng hơn bất kỳ công cụ công nghệ nào.
• Thẩm quyền ngân sách tối thiểu: một khoản dự phòng nhỏ để tài trợ các cải tiến nhanh (quick wins) mà không phải xin phê duyệt từng lần — nếu không, động lực (momentum) chết trước khi kết quả kịp xuất hiện.

Behavioral economics đóng vai trò gì trong việc scale một mô hình vận hành?

Hai cơ chế hành vi giải thích vì sao mô hình vận hành thường thất bại ở đúng giai đoạn mở rộng — chứ không phải ở giai đoạn thiết kế.

Thứ nhất là ranh giới giữa friction và sludge, khái niệm được Richard Thaler phổ biến rộng trong lý thuyết về "nudge" (thúc đẩy hành vi). Friction là ma sát cần thiết để đảm bảo chất lượng — ví dụ, một bước xác nhận trước khi hoàn tất khiếu nại. Sludge là ma sát vô ích chỉ tồn tại vì quy trình cũ chưa được dọn dẹp — ví dụ, ba lớp phê duyệt cho một thay đổi không có rủi ro. Khi một tổ chức scale mô hình vận hành, họ thường vô tình nhân bản cả sludge cùng với friction hữu ích, vì không ai dừng lại để phân loại trước khi nhân rộng. Kết quả là mô hình vận hành ở quy mô lớn chậm hơn, không nhanh hơn, so với phiên bản thí điểm.

Thứ hai là hiệu ứng độ dốc mục tiêu (goal-gradient effect): con người và tổ chức tăng nỗ lực khi cảm thấy đang gần đến đích. Ở giai đoạn thí điểm, một nhóm nhỏ nhìn thấy rõ vạch đích — con số khách hàng hài lòng tăng lên hàng tuần. Ở quy mô 60 chi nhánh, đích quá xa và quá mờ để tạo ra cùng động lực đó. Đây là lý do một mô hình vận hành cần chia lộ trình scale thành các mốc trung gian rõ ràng — theo cụm khu vực, theo quý — thay vì một mục tiêu duy nhất cách 18 tháng, để mỗi nhóm luôn cảm nhận được mình đang tiến gần một vạch đích cụ thể.

Làm sao biết mô hình vận hành đang thực sự hoạt động, không chỉ tồn tại trên giấy?

Đo bằng độ lệch chuẩn giữa các đơn vị, không chỉ bằng điểm trung bình toàn hệ thống. Một điểm CSAT trung bình 78 có thể ẩn giấu việc 10 chi nhánh đạt 95 và 10 chi nhánh khác đạt 55. Điểm trung bình che giấu chính xác điều mà mô hình vận hành được thiết kế để giải quyết: tính nhất quán.

Một số dấu hiệu cụ thể cho thấy mô hình đang hoạt động thật:

• Khoảng cách hiệu suất CX giữa đơn vị tốt nhất và kém nhất đang thu hẹp theo thời gian, không mở rộng.
• Các quyết định cải tiến trải nghiệm được đưa ra ở đúng tầng thẩm quyền đã thiết kế, không bị đẩy lên cấp cao vì thiếu rõ ràng.
• Tuyến đầu có thể giải thích vì sao một quy trình tồn tại, không chỉ tuân thủ nó một cách máy móc.
• Khi một chỉ số CX xấu đi, tổ chức biết chính xác ai chịu trách nhiệm điều tra — không cần họp để "xác định người phụ trách" trước.

Việc chấm điểm khách quan các năng lực này — chứ không dựa vào cảm nhận chủ quan của ban điều hành — là lý do một đánh giá độ trưởng thành CX có cấu trúc thường hữu ích hơn một cuộc khảo sát nội bộ không chính thức. Nếu muốn có điểm khởi đầu định lượng, công cụ CX Maturity Assessment chấm điểm bằng AI trên 12 nhóm năng lực nền tảng có thể cho một bức tranh nhanh trước khi đầu tư vào tái thiết kế mô hình vận hành đầy đủ.

Điều gì thường đổ vỡ đầu tiên khi một tổ chức bắt đầu scale?

Theo kinh nghiệm trực tiếp của tôi, thứ tự đổ vỡ khá dự đoán được:

1. Định nghĩa chỉ số phân rã trước tiên. Mỗi vùng bắt đầu tự điều chỉnh cách tính CSAT hay cách phân loại khiếu nại để báo cáo "đẹp" hơn — không ai nói dối, nhưng không còn ai đang đo cùng một thứ.
2. Quyền quyết định trở nên mơ hồ. Khi một cải tiến đòi hỏi hai phòng ban cùng thay đổi, không ai biết ai có quyền ép bên kia hành động, và sáng kiến nằm im trong hộp thư chờ vô thời hạn.
3. Đào tạo trở thành nghi lễ một lần. Nhân viên mới không được onboard theo đúng chuẩn CX ban đầu; họ học từ đồng nghiệp cũ, và mỗi lần "học từ đồng nghiệp" là một lần chuẩn bị bị pha loãng thêm.
4. Ngân sách cải tiến cạn trước ngân sách vận hành. Khoản dự phòng cho quick win bị cắt đầu tiên khi có sức ép chi phí, vì nó không "thiết yếu" trên giấy — trong khi thực chất đó chính là cơ chế duy trì động lực CX ở quy mô lớn.

Biết trước thứ tự này cho phép một chương trình quản trị thay đổi can thiệp đúng lúc: củng cố định nghĩa chỉ số và quyền quyết định trước khi chúng lệch, thay vì sửa chữa sau khi 60 chi nhánh đã hình thành 60 cách hiểu khác nhau về "trải nghiệm tốt".

Nên bắt đầu xây mô hình vận hành từ đâu nếu chưa có gì?

Đừng bắt đầu từ việc viết chính sách. Bắt đầu từ việc ánh xạ một hành trình khách hàng thực tế, xác định đúng những điểm chạm nơi các phòng ban va vào nhau, rồi thiết kế quản trị quanh đúng những điểm ma sát đó. Cấu trúc hành trình khách hàng (CX Journeys) được ánh xạ tốt sẽ tự nó lộ ra nơi mô hình vận hành cần tồn tại — thường không phải nơi ban điều hành nghĩ.

Một lộ trình triển khai theo giai đoạn — chứ không phải "big bang" toàn hệ thống — cũng giảm rủi ro đáng kể. Đây là lý do các lộ trình triển khai CX theo từng cụm đơn vị, với mốc đánh giá rõ ràng sau mỗi giai đoạn, thường thành công hơn việc công bố một mô hình vận hành hoàn chỉnh cho toàn tổ chức trong một lần.

Về hạ tầng đo lường và ánh xạ hành trình, cạm bẫy phổ biến là chồng thêm công cụ mới cho mỗi vấn đề mới phát sinh, khiến dữ liệu CX phân tán trên chục hệ thống không nói chuyện với nhau — điều tôi đã phân tích kỹ trong bài viết về tại sao càng nhiều công cụ CX lại tạo ra càng nhiều ma sát. Một mô hình vận hành tốt thường cần ít công cụ hơn tổ chức nghĩ, nhưng cần chúng được kết nối và có chủ sở hữu rõ ràng.

Về mặt thiết kế dịch vụ, khung service blueprint mà Nielsen Norman Group hệ thống hoá vẫn là công cụ nền tảng để nhìn thấy đồng thời trải nghiệm khách hàng (front-stage) và các quy trình nội bộ hỗ trợ nó (back-stage) — chính là ranh giới nơi mô hình vận hành phải neo vào.

Kết luận: mô hình vận hành là bài kiểm tra thật của cam kết CX

Bất kỳ ai cũng có thể nói "khách hàng là trung tâm" trong một bài phát biểu. Rất ít tổ chức chịu ngồi lại để viết ra ai được quyền quyết định gì khi tốc độ và trải nghiệm xung đột, và chịu bảo vệ quyết định đó khi áp lực doanh số tới. Đó chính là điểm phân định giữa một công ty có văn hoá CX và một công ty chỉ có một vài anh hùng CX đang gồng gánh cả hệ thống.

Chi nhánh mẫu trong câu chuyện đầu bài vẫn xuất sắc, nhiều năm sau. Nhưng xuất sắc một mình không phải là chiến thắng — nó là bằng chứng cho thấy tổ chức chưa từng thực sự thử scale điều gì cả, chỉ mới thử chứng minh rằng điều đó khả thi. Xây một mô hình vận hành đúng nghĩa là bước tiếp theo, khó hơn nhiều, và cũng là bước duy nhất biến một câu chuyện thành công đơn lẻ thành một năng lực tổ chức thật sự.

Nếu tổ chức của bạn đang ở đúng thời điểm chuyển từ thí điểm sang quy mô lớn, đội ngũ Customer Experience (CX) của Renascence có thể cùng bạn thiết kế lại lớp quản trị, quy trình và năng lực cần thiết để trải nghiệm khách hàng không phụ thuộc vào một vài cá nhân xuất sắc nữa.