Vòng đời yêu cầu khách hàng: lập sơ đồ trước khi thiết kế màn hình

Vì sao màn hình dễ thất bại nếu không có sơ đồ yêu cầu

Một biểu mẫu yêu cầu được thiết kế đẹp vẫn có thể tạo ra một quy trình lộn xộn. Các đội nhóm thường chọn trường thông tin, nút bấm và bảng điều khiển trước, rồi mới phát hiện rằng chưa ai thống nhất chuyện gì xảy ra sau khi khách hàng nhấp vào «Gửi».

Màn hình chỉ thể hiện từng thời điểm riêng lẻ. Vòng đời yêu cầu của khách hàng cho thấy toàn bộ hành trình: yêu cầu đến đâu, ai xem xét, họ quyết định gì, công việc bắt đầu khi nào và điều gì được xem là hoàn tất. Không có sơ đồ này, từng màn hình có thể vẫn hợp lý khi đứng riêng, nhưng công việc giữa các màn hình lại không rõ ràng.

Hãy hình dung một biểu mẫu hỗ trợ có trạng thái «Đang xử lý». Trạng thái đó có nghĩa là ai đó đã đọc yêu cầu, đã phân công, đã liên hệ với khách hàng hay đã bắt đầu công việc thực tế? Nhân viên có thể dùng cùng một nhãn theo những cách khác nhau. Khách hàng thấy rất ít tiến triển, còn quản lý không biết yêu cầu đang bị kẹt ở đâu.

Bắt đầu từ màn hình cũng che khuất các bước bàn giao. Một yêu cầu có thể đi từ bộ phận hỗ trợ sang bộ phận thanh toán rồi đến quản lý tài khoản. Nếu đội ngũ chưa xác định người phụ trách ở từng bước, ai cũng có thể nghĩ rằng người khác sẽ xử lý. Yêu cầu cứ nằm trong hàng đợi chung cho đến khi khách hàng phải hỏi lại.

Lập sơ đồ quy trình yêu cầu giúp phát hiện những khoảng trống này trước khi bắt đầu thiết kế giao diện. Đội ngũ cần quyết định:

• Thông tin nào khởi tạo yêu cầu?
• Ai phụ trách hành động tiếp theo?
• Sau mỗi quyết định, yêu cầu có thể chuyển sang những trạng thái nào?
• Thời hạn bắt đầu, tạm dừng hoặc kết thúc khi nào?
• Ai cần nhận thông báo khi yêu cầu thay đổi?

Sơ đồ cũng giúp tránh các bảng điều khiển gây hiểu nhầm. Một con số về yêu cầu «đang mở» không nói lên nhiều điều nếu trong đó gồm cả yêu cầu mới, yêu cầu đang chờ khách hàng bổ sung thông tin và công việc bị đội khác chặn lại. Các trạng thái riêng biệt tạo ra ngôn ngữ chung cho nhân viên và giúp khách hàng nhận được cập nhật chính xác hơn.

Sơ đồ không cần phức tạp. Nó cần mô tả công việc mọi người thực sự làm, bao gồm thông tin còn thiếu, yêu cầu bị từ chối và trường hợp được mở lại. Khi hành trình đã rõ, việc thiết kế màn hình trở nên dễ dàng hơn vì mỗi trang có một nhiệm vụ cụ thể: thu thập thông tin, giúp người phụ trách hành động hoặc cho khách hàng biết yêu cầu đang ở đâu.

Bắt đầu với một yêu cầu và kết quả rõ ràng

Hãy bắt đầu với loại yêu cầu mà đội ngũ thường gặp nhất. Đó có thể là yêu cầu hoàn tiền, báo cáo giao hàng hư hỏng hoặc yêu cầu thay đổi thông tin tài khoản. Đừng cố lập sơ đồ cho mọi nhu cầu của khách hàng trong một biểu đồ. Sơ đồ quá rộng sẽ nhanh chóng trở nên mơ hồ.

Hãy viết sự kiện bắt đầu bằng ngôn ngữ đời thường. Ví dụ: «Khách hàng gửi yêu cầu hoàn tiền cho một đơn hàng qua biểu mẫu hỗ trợ». Cách viết này xác định thời điểm vòng đời bắt đầu. Nó cũng tránh một bất đồng thường xuất hiện sau đó: yêu cầu bắt đầu khi khách hàng gửi đi, khi bộ phận hỗ trợ đọc yêu cầu hay khi ai đó tạo phiếu?

Sau đó, xác định điểm kết thúc từ cả hai phía. Một yêu cầu hoàn tiền hoàn tất khi khách hàng nhận được quyết định rõ ràng và, nếu được chấp thuận, đội ngũ thanh toán đã thực hiện hoàn tiền. Đội hỗ trợ cũng cần lưu lại quyết định, lý do, số tiền và ngày thực hiện. Những chi tiết đó quan trọng hơn một màn hình chỉ hiển thị «Đã hoàn tất».

Hãy tách kết quả khỏi giao diện. «Hiển thị thông báo thành công màu xanh» mô tả một màn hình. «Khách hàng nhận được xác nhận về số tiền hoàn và ngày dự kiến tiền về» mô tả công việc cần được thực hiện. Màn hình có thể thay đổi khi thiết kế lại. Công việc bên dưới cần nhất quán dù khách hàng dùng cổng thông tin web, ứng dụng di động hay email.

Một định nghĩa ngắn thường giúp phát hiện các quy tắc còn thiếu trước khi bắt đầu thiết kế:

• Loại yêu cầu: hoàn tiền cho một đơn hàng đã thanh toán
• Bắt đầu: khách hàng gửi biểu mẫu hoặc liên hệ với bộ phận hỗ trợ
• Kết thúc: khách hàng nhận được quyết định chấp thuận hoặc từ chối, đồng thời đội ngũ lưu lại quyết định đó
• Ngoại lệ: bộ phận hỗ trợ yêu cầu bổ sung thông tin đơn hàng trước khi đưa ra quyết định

Giả sử khách hàng báo bị tính phí trùng vào thứ Hai. Yêu cầu chỉ nên kết thúc sau khi đội ngũ xác nhận khoản phí có bị trùng hay không, gửi quyết định và ghi nhận khoản hoàn tiền nếu có. Đóng phiếu ngay sau phản hồi đầu tiên sẽ khiến công việc thực tế vẫn chưa được giải quyết.

Khi hành trình đã có điểm bắt đầu và kết thúc chính xác, đội ngũ có thể thêm trạng thái, người phụ trách, thời hạn và thông báo mà không cần phỏng đoán. AppMaster có thể chuyển sơ đồ đó thành các quy trình nghiệp vụ và màn hình, nhưng trước hết sơ đồ phải xác định công việc.

Liệt kê các trạng thái mà yêu cầu có thể chuyển vào

Trạng thái cho mọi người biết một yêu cầu khách hàng đang ở đâu. Hãy tập trung vào những điểm có ý nghĩa trong công việc thay vì ghi lại từng hành động nhỏ. Nhân viên cần đọc trạng thái là biết việc gì phải làm tiếp theo.

Một yêu cầu hỗ trợ hoặc dịch vụ thường có thể gồm các trạng thái sau:

• Mới: hệ thống đã nhận yêu cầu nhưng chưa ai xem xét.
• Đang xem xét: một thành viên trong đội kiểm tra thông tin và quyết định cách xử lý.
• Chờ khách hàng: đội ngũ cần khách hàng cung cấp câu trả lời, tệp hoặc xác nhận.
• Đang xử lý: một người đã nhận việc và đang thực hiện.
• Chờ phê duyệt hoặc công việc bên ngoài: tiến độ phụ thuộc vào quản lý, nhà cung cấp, đơn vị thanh toán hoặc bên khác.
• Đã giải quyết: đội ngũ đã hoàn tất công việc được yêu cầu.
• Đã đóng: khách hàng chấp nhận kết quả hoặc đội ngũ đóng yêu cầu sau một khoảng thời gian đã quy định.

Hãy dùng những tên gọi phù hợp với cách mọi người vẫn nói. «Chờ khách hàng» rõ ràng hơn «Đang chờ thông tin». «Đang xử lý» thường dễ hiểu hơn «Đang hoạt động». Khách hàng không nên cần một bảng thuật ngữ nội bộ để hiểu trạng thái hiển thị trên cổng thông tin.

Các trạng thái chờ cần được cân nhắc kỹ. Chúng phân biệt công việc đội ngũ có thể làm ngay với công việc phụ thuộc vào người khác. Một yêu cầu hoàn tiền có thể chuyển từ «Đang xem xét» sang «Chờ khách hàng» khi khách hàng cần cung cấp biên lai. Nếu quản lý tài chính phải phê duyệt số tiền, yêu cầu chuyển sang «Chờ phê duyệt». Hai kiểu chờ này cần lời nhắc và quy tắc thời hạn khác nhau.

Tránh các nhãn trùng nghĩa. «Đang mở», «Đã phân công» và «Đang được xử lý» thường mô tả cùng một tình huống chung. Chỉ giữ một trạng thái, trừ khi mỗi nhãn làm thay đổi người phụ trách, hành động của nhân viên hoặc thời hạn áp dụng. Ít trạng thái và bước chuyển đổi rõ ràng hơn cũng giúp báo cáo đáng tin cậy hơn.

Hãy kiểm tra mọi yêu cầu bằng một câu hỏi đơn giản: yêu cầu có thể đồng thời ở hai trạng thái không? Nếu có, các tên gọi có thể đang chồng lấn. Hãy sửa lại cho đến khi mỗi trạng thái chỉ mô tả một điều kiện rõ ràng.

Vẽ các bước chuyển đổi và xác định ai kích hoạt chúng

Tên trạng thái không tự giải thích được quy trình. Hãy ghi lại cách yêu cầu chuyển trạng thái, ai có quyền chuyển và điều kiện nào phải được đáp ứng trước đó. Cách này giúp tránh việc một nút trên màn hình thay đổi yêu cầu sai thời điểm.

Hãy viết mỗi bước chuyển đổi thành một câu đơn giản. Ví dụ: «Nhân viên hỗ trợ chuyển yêu cầu từ Mới sang Đang xem xét sau khi kiểm tra khách hàng đã cung cấp mã đơn hàng». Câu này nêu rõ hành động, người thực hiện và điều kiện.

Một sơ đồ đơn giản có thể gồm các bước sau:

• Khách hàng gửi yêu cầu, hệ thống tạo một yêu cầu ở trạng thái Mới.
• Nhân viên hỗ trợ phân công yêu cầu cho chuyên viên và chuyển sang Đang xem xét.
• Chuyên viên chuyển sang Chờ khách hàng khi thông tin còn thiếu.
• Khi khách hàng trả lời, yêu cầu quay lại Đang xem xét.
• Chuyên viên chuyển sang Đã giải quyết sau khi hoàn tất công việc.
• Khách hàng hoặc trưởng nhóm hỗ trợ đóng yêu cầu sau khi xác nhận.

Hãy xác định vai trò được phép thực hiện cho từng mũi tên. «Đội ngũ» là quá mơ hồ. Hãy dùng những vai trò như khách hàng, nhân viên hỗ trợ, chuyên viên thanh toán, trưởng nhóm hoặc hệ thống tự động. Một quy tắc hệ thống cũng có thể kích hoạt thay đổi. Chẳng hạn, hệ thống tự động có thể chuyển yêu cầu từ Chờ khách hàng sang Đã đóng sau 14 ngày không có phản hồi, nếu đó là chính sách của bạn.

Các ngoại lệ cần có bước chuyển đổi riêng. Khách hàng có thể hủy một yêu cầu Mới nhưng không thể hủy yêu cầu đã hoàn tất. Trưởng nhóm có thể mở lại yêu cầu Đã đóng nếu vấn đề quay trở lại. Nhân viên có thể chuyển Đang xem xét về Mới chỉ khi yêu cầu bị phân công nhầm. Những quy tắc này bảo vệ quyền sở hữu yêu cầu và giải thích vì sao một số thay đổi trạng thái không khả dụng.

Hãy vẽ hành trình bằng các ô và mũi tên trước khi thiết kế màn hình. Tìm những vòng lặp không bao giờ kết thúc, chẳng hạn hai vai trò liên tục chuyển yêu cầu qua lại. Đồng thời kiểm tra các điểm cụt. Nếu yêu cầu chuyển sang Chờ phê duyệt, hãy xác định người phê duyệt và điều gì xảy ra sau khi chấp thuận hoặc từ chối.

Trong AppMaster, sau này sơ đồ có thể trở thành logic của quy trình nghiệp vụ, còn vai trò quyết định mỗi người dùng nhìn thấy những hành động nào. Hãy giữ sơ đồ đủ dễ đọc để một thành viên mới có thể theo dõi một yêu cầu từ lúc gửi đến khi đóng.

Gán người phụ trách cho mọi bước bàn giao

Một yêu cầu cần có một người phụ trách cụ thể bất cứ khi nào công việc đang diễn ra. Người đó không nhất thiết phải tự hoàn thành mọi nhiệm vụ. Họ cần biết trạng thái hiện tại, đưa yêu cầu tiến lên và trả lời khi có người hỏi cập nhật. Việc cùng phụ trách thường dẫn đến tình trạng không ai hành động.

Người phụ trách có thể thay đổi khi yêu cầu tiến triển. Nhân viên hỗ trợ có thể phụ trách yêu cầu mới, chuyên viên phụ trách việc điều tra và quản lý tài khoản phụ trách phản hồi cuối cùng cho khách hàng. Hãy đưa từng thay đổi vào sơ đồ để nhân viên không phải tự đoán ai nên hành động.

Hãy tách người phụ trách yêu cầu khỏi người xem xét và người phê duyệt. Trưởng nhóm tài chính có thể phê duyệt khoản hoàn tiền, nhưng nhân viên hỗ trợ vẫn có thể là người phụ trách yêu cầu. Nhân viên đó yêu cầu phê duyệt, theo dõi phản hồi và thông báo kết quả cho khách hàng. Trưởng nhóm tài chính không nên phải tiếp nhận mọi việc theo sau chỉ vì họ đã nhấp vào nút phê duyệt.

Ở mỗi bước bàn giao, hãy ghi lại người và đội ngũ đang phụ trách, lý do thay đổi người phụ trách, công việc cần hoàn tất trước bước chuyển tiếp theo và người tiếp nhận nếu người phụ trách vắng mặt.

Hãy chuẩn bị cho trường hợp nghỉ phép trước khi nó gây chậm trễ. Bạn có thể dùng hàng đợi của đội, chỉ định người thay thế hoặc đặt quy tắc tự phân công lại yêu cầu sau một khoảng thời gian. Nếu chuyên viên nghỉ, người khác phải nhìn thấy yêu cầu trong hàng đợi của mình thay vì để nó gắn với một người không thể phản hồi.

Hãy hiển thị rõ quyền sở hữu trong ứng dụng. Tin nhắn riêng và chuỗi email có thể hỗ trợ công việc, nhưng không nên là nơi định nghĩa quy trình. Mỗi bản ghi yêu cầu cần hiển thị người phụ trách hiện tại, lần bàn giao trước, thời điểm phân công và lý do phân công lại. Quản lý có thể phát hiện yêu cầu đã chờ quá lâu, còn nhân viên làm việc với khách hàng có thể cập nhật mà không phải tìm trong các tin nhắn.

Ví dụ, khi khách hàng báo lỗi thanh toán, nhân viên hỗ trợ phụ trách yêu cầu cho đến khi xác nhận bộ phận tài chính cần xem xét. Sau đó chuyên viên tài chính phụ trách việc điều tra. Khi tài chính ghi nhận quyết định, quyền phụ trách quay lại bộ phận hỗ trợ để phản hồi và đóng yêu cầu. Cách này giúp tránh việc hai người gửi những câu trả lời khác nhau hoặc cùng nghĩ rằng người kia đã phản hồi.

Khi xây dựng quy trình trong ứng dụng, hãy đưa thay đổi người phụ trách vào chính bước chuyển trạng thái. AppMaster có thể kết nối thay đổi trạng thái, quy tắc phân công và bản ghi kiểm tra trong cùng một quy trình nghiệp vụ. Điều đó giúp quyền sở hữu luôn rõ ràng khi đội ngũ phát triển.

Đặt thời hạn phù hợp với công việc

Một yêu cầu thường cần hai loại thời hạn. Thời hạn phản hồi bao phủ phản hồi có ý nghĩa đầu tiên, chẳng hạn xác nhận nhân viên hỗ trợ đã đọc yêu cầu và cần thêm thông tin. Thời hạn hoàn tất bao phủ thời điểm đội ngũ giải quyết yêu cầu hoặc cung cấp kết quả đã thống nhất.

Tách riêng hai mốc này giúp tránh một vấn đề phổ biến: khách hàng nhận được xác nhận nhanh nhưng yêu cầu sau đó nằm im nhiều ngày. Một yêu cầu cấp quyền có thể cần phản hồi trong bốn giờ làm việc và hoàn tất trong hai ngày làm việc. Một tranh chấp thanh toán phức tạp có thể cần phản hồi trong một ngày làm việc và có thời hạn hoàn tất dài hơn.

Hãy ghi rõ chính xác khi nào mỗi đồng hồ bắt đầu. Nhiều đội ngũ bắt đầu tính thời hạn phản hồi ngay khi hệ thống nhận yêu cầu. Thời hạn hoàn tất có thể bắt đầu cùng lúc hoặc chỉ bắt đầu khi đội ngũ có đủ thông tin để xử lý. Hãy chọn một quy tắc và áp dụng nhất quán.

Hãy xác định việc tạm dừng cũng cẩn thận như vậy. Đồng hồ có thể tạm dừng khi yêu cầu chờ khách hàng trả lời, chờ bên thứ ba được phê duyệt hoặc chờ một đợt bảo trì đã lên lịch. Đồng hồ tiếp tục chạy khi thông tin còn thiếu được bổ sung hoặc trở ngại kết thúc. Đừng tạm dừng thời hạn chỉ vì người được phân công đang bận hoặc vắng mặt. Người phụ trách hoặc quản lý cần phân công lại công việc.

Hãy thêm bước báo cáo trước khi thời hạn đến gần. Lời nhắc gửi cho người phụ trách khi đã dùng 75% thời gian cho phép giúp họ còn thời gian hành động. Ở mốc 90%, hãy thông báo cho quản lý của họ hoặc đội tiếp theo chịu trách nhiệm. Nếu quá hạn, hãy đánh dấu yêu cầu là quá hạn và nêu hành động tiếp theo.

Một chính sách đơn giản có thể như sau:

• Đồng hồ phản hồi bắt đầu khi khách hàng gửi yêu cầu.
• Đồng hồ hoàn tất tạm dừng sau khi đội ngũ đặt một câu hỏi cụ thể và yêu cầu chuyển sang Chờ khách hàng.
• Khi khách hàng trả lời, đồng hồ tiếp tục chạy và yêu cầu quay lại người phụ trách hiện tại.
• Khi gần đến hạn, người phụ trách nhận lời nhắc, sau đó quản lý nhận thông báo báo cáo.
• Với yêu cầu quá hạn, quản lý lập kế hoạch khắc phục và cập nhật cho khách hàng.

Chỉ dùng giờ làm việc nếu mọi người thống nhất về lịch phía sau quy tắc đó. Một đội cam kết hỗ trợ bảy ngày một tuần không nên âm thầm dừng đồng hồ vào mỗi buổi tối. Nếu bộ phận hỗ trợ làm việc từ thứ Hai đến thứ Sáu, hãy xác định giờ làm việc, ngày nghỉ và múi giờ trong quy tắc quy trình. Quy tắc rõ ràng giúp thông báo thời hạn công bằng cho cả khách hàng và nhân viên.

Lập kế hoạch thông báo để tránh gây nhiễu

Thông báo nên trả lời một câu hỏi thực tế: có ai cần biết hoặc cần làm gì ngay bây giờ không? Nếu không, hãy giữ cập nhật trong bản ghi yêu cầu. Hộp thư quá nhiều thông báo sẽ khiến khách hàng và nhân viên bỏ qua cả những tin quan trọng.

Hãy gửi khách hàng thông báo khi yêu cầu thay đổi theo cách ảnh hưởng đến họ. Những thời điểm thường gặp gồm xác nhận đã nhận yêu cầu, yêu cầu bổ sung thông tin, chấp thuận hoặc từ chối yêu cầu, thay đổi ngày hoàn tất dự kiến và hoàn tất công việc. Đừng thông báo cho khách hàng chỉ vì nhân viên sửa lỗi đánh máy, thêm ghi chú nội bộ hoặc phân công lại nhiệm vụ mà không thay đổi kết quả dự kiến.

Thông báo nội bộ cũng cần có người nhận và lý do hành động. Khi yêu cầu chuyển sang «Cần xem xét», hãy báo cho người xem xét. Khi khách hàng trả lời câu hỏi, hãy báo cho người được phân công theo dõi. Toàn bộ đội ngũ không cần nhận thông báo cho cả hai sự kiện.

Hãy viết thông điệp ngắn gọn và cụ thể. Nêu tên yêu cầu, trạng thái hiện tại và việc gì sẽ xảy ra tiếp theo. Ví dụ:

• Khách hàng: «Chúng tôi đã nhận yêu cầu thiết bị số 1842 của bạn. Chúng tôi sẽ xem xét trước thứ Ba.»
• Người xem xét: «Yêu cầu số 1842 cần bạn phê duyệt trước 15:00 thứ Ba.»
• Khách hàng: «Yêu cầu số 1842 của bạn đã được chấp thuận. Đội ngũ sẽ lên lịch giao hàng và cập nhật cho bạn trước thứ Sáu.»

Thời điểm gửi quan trọng không kém cách viết. Lời nhắc thời hạn cần đến người được phân công đủ sớm để họ hành động, không phải năm phút trước khi hết hạn. Với khoảng thời gian xem xét hai ngày, một lời nhắc vào ngày trước hạn và một lời nhắc sau khi quá hạn thường là đủ. Khi người phụ trách hoàn tất công việc, ứng dụng nên dừng các lời nhắc đang chờ.

Hãy ghi quy tắc thông báo bên cạnh từng bước chuyển đổi trên sơ đồ. Nêu người nhận, sự kiện kích hoạt, kênh gửi và việc ứng dụng có cần nhắc lại hay không. Nhờ vậy, hành vi của quy trình rõ ràng trước khi có người xây dựng màn hình hoặc viết tính năng tự động.

Theo dõi một yêu cầu khách hàng đơn giản

Một khách hàng báo bị tính phí trùng qua biểu mẫu hỗ trợ. Biểu mẫu tạo yêu cầu số 4821 với trạng thái «Mới» và phân công vào hàng đợi hỗ trợ. Khách hàng nhận được xác nhận ngay lập tức, kèm số yêu cầu và thông báo rằng đội ngũ sẽ xem xét trong một ngày làm việc.

Nhân viên hỗ trợ mở yêu cầu, kiểm tra bản ghi đơn hàng và thanh toán, rồi chuyển trạng thái sang «Đang xem xét». Nhân viên đó là người phụ trách yêu cầu. Nếu bản ghi thanh toán chưa đủ chi tiết, nhân viên chọn «Chờ khách hàng» và yêu cầu ảnh chụp sao kê ngân hàng hoặc bốn số cuối của thẻ.

Trạng thái này cần có thời hạn. Ứng dụng có thể nhắc khách hàng sau ba ngày và đóng yêu cầu sau bảy ngày nếu không có phản hồi. Nhân viên cần nhận thông báo khi khách hàng bổ sung thông tin còn thiếu để yêu cầu không bị bỏ quên trong hàng đợi.

Khi khách hàng trả lời, yêu cầu quay lại «Đang xem xét» và nếu có thể thì trở về với chính nhân viên trước đó. Tính liên tục rất quan trọng vì nhân viên mới không phải hỏi lại những câu đã được hỏi.

Nếu xác nhận khoản phí bị trùng, nhân viên chuyển yêu cầu sang «Quyết định hoàn tiền» và phân công cho người xem xét bên tài chính. Tài chính có hai ngày làm việc để chấp thuận hoặc từ chối khoản hoàn. Lời nhắc trước hạn một ngày giúp người xem xét có thời gian hành động trước khi khách hàng phải hỏi lại.

Người xem xét bên tài chính ghi nhận quyết định. Yêu cầu được chấp thuận chuyển sang «Đang xử lý hoàn tiền», nơi đội thanh toán thực hiện hoàn tiền và nhập mã tham chiếu. Yêu cầu bị từ chối quay lại bộ phận hỗ trợ cùng lý do để nhân viên có thể giải thích rõ ràng.

Bộ phận hỗ trợ chỉ gửi thông báo cuối cùng sau khi đội ngũ đã hoàn tiền hoặc giải thích lý do từ chối. Sau đó nhân viên chuyển trạng thái sang «Đã đóng». Khách hàng nhận được thông báo kết thúc nêu rõ kết quả, còn đội ngũ lưu lại người phụ trách, quyết định, thời hạn và từng thông báo.

Sơ đồ này ngăn một khoảng trống phổ biến: yêu cầu trông như đã hoàn tất trên một màn hình nhưng vẫn đang chờ xử lý trong hàng đợi của đội khác.

Những lỗi phổ biến khiến quy trình trở nên khó hiểu

Hầu hết quy trình yêu cầu trở nên khó hiểu vì các nhãn nghe có vẻ rõ ràng với người thiết kế nhưng lại không rõ với người dùng hằng ngày. Trạng thái «Đang chờ» có thể nghĩa là khách hàng chưa trả lời, quản lý cần phê duyệt công việc hoặc kỹ thuật viên đang chờ linh kiện. Mỗi tình huống cần một bước tiếp theo khác nhau.

Hãy thay các nhãn mơ hồ bằng trạng thái mô tả rõ lý do chờ. «Chờ khách hàng bổ sung thông tin» cho người yêu cầu biết họ cần làm gì. «Chờ quản lý phê duyệt» cho quản lý biết điều gì đang chặn tiến độ. Nếu đội ngũ không thể nói ai cần hành động tiếp theo, hãy đổi tên hoặc xóa trạng thái đó.

Quyền sở hữu là một vấn đề thường gặp khác. Một yêu cầu có thể liên quan đến hỗ trợ, tài chính và vận hành, nhưng nhiều cái tên không tạo ra trách nhiệm chung. Hãy chỉ định một người phụ trách cho mỗi trạng thái đang hoạt động. Người đó có thể hỏi ý kiến người khác nhưng vẫn chịu trách nhiệm đưa yêu cầu tiến lên hoặc giải thích sự chậm trễ.

Một thời hạn cần gắn với một hành động. Ngày đến hạn chỉ gửi lời nhắc sẽ không giúp được nhiều nếu không ai phản hồi. Hãy xác định điều gì xảy ra khi hết thời gian: cảnh báo người phụ trách, báo cáo cho quản lý hoặc chuyển yêu cầu vào hàng đợi xem xét. Hãy chọn hành động phù hợp với tác động của sự chậm trễ.

Đừng xây dựng màn hình chỉ vì một trạng thái nghe có vẻ hữu ích. Mỗi màn hình cần hỗ trợ một nhiệm vụ, quyết định hoặc bước bàn giao rõ ràng. Màn hình «Kiểm tra chất lượng» chỉ hợp lý khi ai đó kiểm tra theo các tiêu chí đã xác định rồi phê duyệt yêu cầu hoặc trả lại cùng lý do. Nếu đội ngũ không thể giải thích hành động đó một cách rõ ràng, hãy xóa trạng thái thay vì che giấu sự chưa chắc chắn phía sau một trang khác.

Trước khi thiết kế màn hình, hãy kiểm tra từng phần của vòng đời bằng bốn câu hỏi:

• Trạng thái này chính xác có nghĩa gì?
• Ai phụ trách yêu cầu khi nó ở đây?
• Sự kiện nào chuyển yêu cầu sang trạng thái tiếp theo?
• Điều gì xảy ra nếu quá hạn?

Việc kiểm tra này giúp phát hiện khoảng trống sớm. Nó cũng giúp chuyển sơ đồ quy trình yêu cầu thành ứng dụng dễ hơn vì mỗi trạng thái đều có mục đích, người phụ trách và hành động xác định.

Kiểm tra nhanh trước khi thiết kế màn hình

Sơ đồ yêu cầu cần vượt qua một lần xem xét đơn giản trước khi bất kỳ ai mở công cụ xây dựng giao diện. Hãy đọc nó như một nhân viên đang xử lý yêu cầu thực tế vào một ngày thứ Ba bận rộn. Nếu bạn không biết việc gì xảy ra tiếp theo, màn hình cũng không thể sửa được khoảng trống đó.

Mỗi trạng thái cần có một nhiệm vụ rõ ràng và ít nhất một đường thoát. «Chờ khách hàng» nghĩa là đội ngũ cần thông tin, vì vậy trạng thái này phải chuyển tiếp khi khách hàng trả lời, hủy yêu cầu hoặc không phản hồi trong thời hạn đã thống nhất. Tránh các trạng thái chỉ mô tả cảm giác chung, như «Đang xử lý», trừ khi đội ngũ biết chính xác công việc nào diễn ra ở đó.

Hãy xem xét từng bước chuyển đổi bằng cách hỏi điều gì kích hoạt nó và ai được phép thực hiện. Nhân viên hỗ trợ có thể đánh dấu yêu cầu đã giải quyết sau khi gửi câu trả lời. Khách hàng có thể mở lại yêu cầu. Một quy tắc hệ thống có thể đóng yêu cầu sau 14 ngày không có phản hồi. Hãy ghi lại các quyền này để mọi người không vô tình thay đổi yêu cầu.

Hãy dùng danh sách kiểm tra sau:

• Mọi trạng thái đều có mục đích, đường thoát và trạng thái tiếp theo hợp lý.
• Mọi bước chuyển đổi đều nêu rõ yếu tố kích hoạt và người hoặc quy tắc được phép bắt đầu.
• Mọi yêu cầu đang mở đều có một người phụ trách và ngày đến hạn hoặc thời hạn phản hồi.
• Mọi cập nhật cho khách hàng đều diễn ra khi thay đổi trạng thái ảnh hưởng đến họ.
• Mọi hướng xử lý quá hạn đều nêu rõ ai nhận cảnh báo và họ cần làm gì.

Hãy kiểm tra quyền sở hữu tại các bước bàn giao, nơi sự nhầm lẫn thường bắt đầu. Nếu nhân viên hỗ trợ chuyển một vấn đề kỹ thuật sang bộ phận kỹ thuật, yêu cầu cần có người phụ trách mới cụ thể. Nhân viên ban đầu có thể tiếp tục theo dõi, nhưng hai người không nên cùng nghĩ rằng người kia sẽ phản hồi.

Giữ thông báo thời hạn ở mức thực tế. Gửi lời nhắc nội bộ trước hạn, sau đó chỉ báo cáo khi yêu cầu vẫn còn mở. Hãy cho khách hàng biết khi bạn cần họ cung cấp thông tin, khi yêu cầu chuyển sang đội khác và khi đội ngũ giải quyết hoặc đóng yêu cầu. Đừng thông báo cho khách hàng về mọi ghi chú nội bộ.

Khi sơ đồ đã rõ ràng trên giấy, màn hình sẽ có nhiệm vụ cụ thể: hiển thị đúng trạng thái, hành động, người phụ trách và thời hạn cho đúng người.

Biến sơ đồ thành ứng dụng

Khi vòng đời yêu cầu khách hàng đã rõ, mỗi phần của sơ đồ đều có vị trí trực tiếp trong ứng dụng. Trạng thái trở thành trường trạng thái. Người phụ trách trở thành người dùng hoặc đội nhóm được phân công. Thời hạn trở thành các trường ngày giờ. Bước chuyển đổi trở thành những hành động như «Phân công», «Yêu cầu bổ sung thông tin», «Giải quyết» và «Mở lại».

Hãy giữ phiên bản đầu tiên đơn giản. Màn hình yêu cầu thường cần khách hàng, loại yêu cầu, mô tả, trạng thái hiện tại, người phụ trách, ngày đến hạn, lịch sử hoạt động và tệp đính kèm. Một hàng đợi riêng có thể hiển thị cho mỗi người những yêu cầu cần họ chú ý.

Quy trình nên kiểm soát các hành động thay vì chỉ hiển thị một nhãn. Nhân viên hỗ trợ có thể chuyển yêu cầu từ «Mới» sang «Đang xem xét». Chỉ người được phân công giải quyết mới có thể đánh dấu yêu cầu là «Đã giải quyết». Nếu khách hàng trả lời sau khi yêu cầu đã được giải quyết, ứng dụng có thể mở lại yêu cầu và đưa về hàng đợi phù hợp.

Trước khi xây dựng mọi màn hình, hãy thử một bản nháp có thể vận hành với những người thực sự tiếp nhận và giải quyết yêu cầu. Yêu cầu họ xử lý các trường hợp thông thường, một trường hợp khẩn cấp và một yêu cầu thiếu thông tin. Quan sát những lúc họ không tìm thấy hành động, không biết ai phụ trách hoặc phải rời ứng dụng để hỏi người khác.

Hãy dùng phản hồi đó để sửa cả sơ đồ lẫn màn hình. Một bước bàn giao khiến hai đội nhầm lẫn có thể cần trạng thái «Chờ phê duyệt». Một yêu cầu nằm quá lâu có thể cần ngày đến hạn rõ hơn hoặc lời nhắc cho người phụ trách. Đừng thêm trạng thái để mô tả từng hoạt động nhỏ. Quá nhiều lựa chọn khiến quy trình khó theo dõi hơn.

AppMaster có thể biến thiết kế này thành một ứng dụng yêu cầu no-code. Data Designer của nền tảng có thể mô hình hóa yêu cầu, người dùng, đội nhóm, thời hạn và lịch sử trạng thái. Business Process Editor có thể xác định việc phân công, thay đổi trạng thái, lời nhắc và báo cáo, trong khi màn hình web hoặc di động gốc hỗ trợ hàng đợi yêu cầu, trang chi tiết và báo cáo quản lý.

Hãy bắt đầu với một loại yêu cầu và một nhóm người dùng nhỏ. Khi họ có thể tạo, phân công, cập nhật và đóng yêu cầu mà không cần cách xử lý tạm thời, hãy thêm loại yêu cầu tiếp theo. Kết quả sẽ là một ứng dụng hỗ trợ công việc thực tế trong ngày bận rộn, thay vì những màn hình đẹp mắt nhưng khiến mọi người không biết phải làm gì.