Thử nghiệm mở rộng Sơ đồ dịch vụ - Service Blueprint

Một sơ đồ dịch vụ, nếu nó bao hàm nhiều thông tin hơn, liệu nó có giải quyết nhiều vấn đề hơn?

Liệu mọi thứ trên sơ đồ này có diễn ra như dự kiến? Chắc chắn là không. Khi chúng ta vạch nó ra như vậy, mọi người thường cho rằng “như vậy là xong”, nhưng không.

• Thứ gì trong đó đã không như dự kiến? Nó đã như thế nào?
• Nếu các thành viên xem những tài liệu này, thấy được bức tranh lớn về hành trình của người dùng thì sao?
• Điều gì sẽ xảy ra khi những thông tin chi tiết ấy giúp chúng ta hiểu rằng hành trình này cần những cải tiến lớn?

Dưới đây là mẫu sơ đồ dịch vụ tôi mới làm. Chút tôi sẽ giải thích về nó.

Mở rộng Sơ đồ dịch vụ - Service Blueprint

Chia mục cho các khía cạnh của Sơ đồ dịch vụ - Service Blueprint

• Số liệu: Chúng ta đang có những số liệu nào? Chúng có khớp với nhu cầu người dùng và mục tiêu kinh doanh? Đây cũng có thể là bước chúng ta đo lường hiệu quả. KPI và OKR.
• Rủi ro, chính sách và cân nhắc: Rủi ro đối với người dùng, sản phẩm và công ty là gì? Có chính sách hay điều luật nào chúng ta cần lưu ý tại bước này không?
• Cơ hội và đề xuất: Sơ đồ thường bao gồm những insight, cơ hội và ý tưởng.

Tôi thêm những mục ấy vào sơ đồ dịch vụ, bên dưới “quy trình hỗ trợ”

Nếu quy trình không quá rườm rà, UXPressia có một mục “quy trình” riêng. Tôi nghĩ tôi cũng sẽ thử làm như vậy. Ngoài ra, tôi thêm mục “kênh” để cho biết nơi hoặc điểm chạm tương ứng. Cửa hàng, điện thoại, máy tính,...có thể có nhiều kênh nên thêm vào là vậy, còn tôi cũng sẽ xem xét tính hữu ích của nó sau.

Sử dụng Task Analysis và Optimized Task Flow

Từ khi tôi học Task Analysis và Optimized Task Flow, tôi đã ưu tiên dùng nó hơn sơ đồ hành trình khách hàng và Jobs To Be Done. Khi ứng dụng Task Analysis đúng, nó sẽ cho chúng ta thấy chi tiết về toàn bộ trải nghiệm người dùng.

Nó gồm:

• Câu hỏi, vấn đề và khó khăn: Điều gì đã xảy ra gây trở ngại cho người dùng, Những câu hỏi mà họ có thể có? Bước ấy có thể được thực hiện như thế nào để loại bỏ trở ngại.
• Công cụ, hiểu biết, cách giải pháp: Đây là phần quan trọng trong Task Analysis. Trong khi thực hiện nghiên cứu quan sát, để ý khi nào người dùng sử dụng công cụ bên ngoài sản phẩm, tự tạo giải pháp, hoặc có hiểu biết về sản phẩm nào chúng ta kỳ vọng người dùng có nhưng họ đã không có. Ví dụ: Người dùng máy tính (công cụ) để tính toán, hoặc dùng bảng ghi chú (giải pháp). Họ phải tìm số điện thoại của nhà cung cấp vì hệ thống yêu cầu nhưng họ không nhớ hoặc không biết (hiểu biết).
• MI, EO, CD, KD: Trong đó chúng là viết tắt của Manually Intensive (công việc cần thực hiện), Error-prone (lỗi thường gặp), Cognitively Demanding (nhận thức người dùng cần có) và Knowledge Dependent (giả định về hiểu biết của người dùng). Chúng là những vấn đề, pain point có thể gặp và cần có hướng giải quyết.

Đôi khi, các thành viên, lãnh đạo hoặc khách hàng nhìn vào sơ đồ hành trình khách hàng có thế cho rằng những bước ấy đã được hoàn thiện và chúng ta không cần sửa gì thêm. Tuy nhiên, nếu chúng ta đưa những pain point, trở ngại của người dùng vào sơ đồ dịch vụ, chúng sẽ cho chúng ta thấy được những chi tiết quan trọng của hành trình.

Mặt khác, Task Analysis và Optimized Task Flow cũng hữu ích cho team CX và UX, tuy nhiên, chúng thường phức tạp khiến họ không biết phải bắt đầu từ đâu.

Vậy nên, việc đưa ra hướng dẫn cho team là điều quan trọng. Tôi hy vọng việc đưa chúng vào sơ đồ dịch vụ sẽ khiến thông trở nên dễ hiểu hơn cho team và lãnh đạo. Về Task Analysis và Optimized Task Flow, chúng ta vẫn nên thực hiện nhưng hãy xếp vào tài liệu lưu hành nội bộ.

Tìm hiểu cảm nhận và cấp độ cảm xúc của người dùng

Chúng ta thường có nhiều giả định về cảm xúc của người dùng, tuy nhiên, giả định vẫn chỉ là giả định. Tôi thường sẽ muốn lấy thông tin thực bằng cách hỏi trực tiếp người dùng.

Và nếu thông tin trong những mục của sơ đồ dịch vụ không đưa ra thông tin trực quan về cảm xúc của người dùng, hãy đặt icon cảm xúc bên cạnh chúng.

Thêm trích dẫn của người dùng từ những nghiên cứu cũng là một cách hữu ích để chúng ta hình dung cảm xúc người dùng. Tuy nhiên, tuyệt đối không dùng trích dẫn giả định, mọi thứ cần được rút ra từ nghiên cứu.

Trình bày sơ đồ

Sơ đồ dịch vụ sẽ giúp chúng ta giải quyết những vấn đề trong quy trình nội bộ và trải nghiệm của khách hàng. Tuy nhiên, mục tiêu của chúng ta là khiến sơ đồ hữu ích cho công việc, vậy nên, hãy xem xét cách trình bày theo những yêu cầu cần có cho sơ đồ, đừng khiến nó quá phức tạp hay quá sơ sài. Bởi sơ đồ dịch vụ bao hàm nhiều thông tin, vậy nên, tùy vào khán giả của chúng ta là ai mà chúng ta sẽ chọn cách trình bày sơ đồ. Có một số người không cần xem toàn bộ tất thảy những thông tin ấy và ngược lại.

Kết luận

Trong quá trình thực hiện sơ đồ dịch vụ, chúng ta cần chắc chắn không hy sinh trải nghiệm người dùng hay trải nghiệm khách hàng. Team marketing hay sale có thể muốn muốn số tính năng mà họ nghĩ sẽ thu hút khách hàng, nhưng chúng ta vẫn cần cân nhắc tính phụ hợp cũng như nhu cầu của khách hàng. Như chúng ta vẫn nói rằng lấy khách hàng làm trung tâm, quyết định về sản phẩm cần được dựa trên chân dung khách hàng, nhiệm vụ và mục tiêu của họ.

Đồng thời, các thành viên cần tin tưởng vào điều ấy, tin rằng chúng ta đang tạo ra sản phẩm với dịch vụ và tính năng tốt hơn. Khách hàng sẽ hài lòng và chúng ta sẽ đạt được mục tiêu kinh doanh.