Xây dựng hệ thống ưu tiên yêu cầu mà mọi người có thể hiểu

Vì sao yêu cầu dễ tạo cảm giác thiếu công bằng khi không có quy tắc rõ ràng

Yêu cầu hiếm khi đến từ một nơi duy nhất. Quản lý gửi email, ai đó đăng tin nhắn trong nhóm, còn đồng nghiệp thì nhắc đến một «việc sửa nhanh» sau cuộc họp. Ngay lúc đó, yêu cầu nào cũng có thể nghe như rất khẩn cấp. Khi không có quy trình tiếp nhận chung, thông điệp lớn tiếng nhất hoặc người gửi kiên trì nhất thường được xử lý trước.

Điều này nhanh chóng gây ra nhầm lẫn. Đội ngũ bán hàng có thể phải chờ hai tuần để cập nhật cổng khách hàng, trong khi đội ngũ lại hoàn thành một báo cáo nội bộ nhỏ ngay trong ngày. Những người đang chờ công việc không nhìn thấy các đánh đổi phía sau quyết định đó. Họ chỉ thấy sự im lặng, rồi một kết quả dường như ưu ái người khác.

Các quyết định không được giải thích khiến những lần chậm trễ thông thường trở nên giống chuyện cá nhân. Người gửi có thể nghĩ rằng đội ngũ đã bỏ sót tin nhắn, hiểu sai vấn đề hoặc đối xử đặc biệt với người có ảnh hưởng. Ngay cả một quyết định hợp lý cũng khó được tin tưởng nếu không ai có thể xem lại cách quyết định được đưa ra.

Hệ thống ưu tiên yêu cầu cho mọi yêu cầu một điểm xuất phát như nhau. Hệ thống thu thập những thông tin cần để so sánh công việc: ai bị ảnh hưởng, điều gì xảy ra nếu chờ xử lý, cần bao nhiêu công sức và có thời hạn thực sự hay không. Mục tiêu không phải là tạo một biểu mẫu dài hay một công thức tự động quyết định mọi thứ. Mục tiêu là có một cách lựa chọn nhất quán và dễ nhìn thấy.

Ví dụ, trưởng nhóm hỗ trợ báo rằng khách hàng không thể đặt lại mật khẩu. Một đồng nghiệp marketing đề nghị thêm bộ lọc mới vào bảng điều khiển trước tháng tới. Cả hai yêu cầu đều quan trọng, nhưng yêu cầu đầu tiên ảnh hưởng đến những người không thể truy cập tài khoản. Các quy tắc chấm điểm yêu cầu rõ ràng sẽ cho mọi người thấy lý do đó.

Quy trình tiếp nhận yêu cầu minh bạch cũng giúp đội ngũ xử lý bất đồng bình tĩnh hơn. Người gửi có thể bổ sung thông tin còn thiếu hoặc giải thích vì sao thời hạn đã thay đổi. Họ không cần đuổi theo các cuộc trao đổi riêng hay tranh luận rằng công việc của mình «cảm thấy» khẩn cấp hơn.

Mỗi yêu cầu nên trả lời ba câu hỏi:

• Yêu cầu này giải quyết vấn đề gì và ai đang chịu ảnh hưởng?
• Điều gì xảy ra nếu đội ngũ chờ xử lý?
• Vì sao yêu cầu này đứng trước hoặc sau những công việc khác?

Đội ngũ vẫn cần phán đoán. Sự cố nghiêm trọng, vấn đề pháp lý hoặc cam kết bất ngờ với khách hàng có thể cần một ngoại lệ. Hãy ghi lại lý do và chia sẻ với những người gửi bị ảnh hưởng. Mọi người thường chấp nhận mức ưu tiên thấp hơn khi nhìn thấy quy tắc, bằng chứng và lý do của ngoại lệ.

Với công cụ nội bộ và cổng khách hàng, một cổng yêu cầu no-code giữ các thông tin này ở cùng một nơi dễ xem thay vì rải rác trong hộp thư. Người dùng nên có thể gửi yêu cầu, xem trạng thái và hiểu cách đội ngũ đưa ra quyết định.

Chọn bốn yếu tố mà mọi người đều hiểu

Hệ thống ưu tiên yêu cầu hoạt động tốt nhất khi ai cũng có thể giải thích tiêu chí bằng ngôn ngữ đời thường. Hầu hết các đội có thể dùng bốn yếu tố: mức độ khẩn cấp, tác động, công sức và thời hạn. Hãy tách riêng chúng, nếu không mọi người sẽ chấm mọi thứ là khẩn cấp.

Mức độ khẩn cấp cho biết một người cần hành động sớm đến đâu. Lỗi tính lương khiến nhân viên không được thanh toán là việc khẩn cấp vì nó đang gây hại ngay lúc này. Một yêu cầu tạo báo cáo mới trước quý sau có thể rất đáng quan tâm, nhưng chưa khẩn cấp hôm nay.

Tác động cho biết điều gì thay đổi nếu đội ngũ hoàn thành yêu cầu hoặc để yêu cầu chưa được xử lý. Tác động có thể bao gồm số khách hàng hay nhân viên bị ảnh hưởng, khoản tiền tăng hoặc mất đi, rủi ro pháp lý hay bảo mật và số giờ làm thủ công được cắt giảm.

Hãy dùng một thang điểm ngắn mà mọi người có thể áp dụng mà không phải đoán:

• Tác động thấp ảnh hưởng đến một người hoặc một tiện ích nhỏ.
• Tác động trung bình ảnh hưởng đến một đội, một nhóm khách hàng hoặc nhiều giờ công việc lặp lại.
• Tác động cao ảnh hưởng đến nhiều khách hàng, doanh thu đáng kể, tuân thủ, bảo mật hoặc một quy trình kinh doanh cốt lõi.

Công sức có mục đích khác. Một công việc lớn không nên tự động bị xếp sau chỉ vì mất nhiều thời gian hơn. Công sức giúp đội ngũ lập kế hoạch năng lực và so sánh các lựa chọn. Sửa vấn đề truy cập tài khoản có thể mất một giờ và giúp 20 người dùng. Xây dựng lại quy trình phê duyệt có thể mất hai tuần và giúp 200 người dùng. Cả hai đều có thể đáng được quan tâm, nhưng đội ngũ có thể lên lịch cho chúng theo cách khác nhau.

Hãy yêu cầu ước tính gần đúng, không cần độ chính xác giả tạo. Trước khi xem xét, chỉ cần các mức nhỏ, vừa và lớn. Người gửi có thể mô tả công việc dự kiến, còn đội ngũ thực hiện sẽ xác nhận ước tính.

Thời hạn cần có bằng chứng. Một thời hạn thực sự phải có ngày cụ thể và hậu quả rõ ràng: «Quy định thuế mới bắt đầu có hiệu lực từ ngày 1 tháng 7 và chúng ta không thể nộp tờ khai nếu thiếu trường này». «Vui lòng hoàn thành trước thứ Sáu» chỉ là mong muốn, trừ khi người gửi giải thích điều gì xảy ra sau thứ Sáu.

Điều này ngăn việc thổi phồng thời hạn. Nếu mọi yêu cầu đều có ngày khẩn cấp, ngày tháng sẽ không còn giúp đội ngũ ưu tiên các yêu cầu đến. Biểu mẫu tiếp nhận yêu cầu minh bạch có thể hỏi ngày, hậu quả nếu bỏ lỡ ngày đó và liệu có phương án tạm thời hay không.

Xây dựng mô hình chấm điểm dễ giải thích

Hệ thống ưu tiên yêu cầu dễ được tin tưởng hơn khi người gửi có thể phần nào đoán được kết quả trước khi xem xét. Dùng thang điểm từ 1 đến 5 cho từng yếu tố. Khoảng điểm rộng hơn dễ tạo ra tranh luận về những khác biệt nhỏ mà không ai có thể bảo vệ.

Dùng tác động, mức độ khẩn cấp, áp lực thời hạn và công sức. Định nghĩa từng con số bằng ngôn ngữ đơn giản và đặt các định nghĩa đó ngay trong biểu mẫu yêu cầu.

Hãy để cách tính hiện rõ:

Điểm ưu tiên = (Tác động x 2) + Mức độ khẩn cấp + Áp lực thời hạn + (6 - Công sức)

Cách tính này dành trọng số cao hơn cho tác động. Công việc ngắn hơn được cộng một lợi thế nhỏ khi hai yêu cầu đem lại lợi ích tương đương. Điểm dao động từ 5 đến 25. Một thành viên trong đội có thể giải thích kết quả một cách đơn giản: «Chúng tôi đặt việc này lên trước vì nó ảnh hưởng đến nhiều người, có ngày cố định và cần ít công sức hơn phương án còn lại».

Đừng giấu ngoại lệ bên trong công thức. Cam kết với khách hàng, vấn đề bảo mật hoặc sự phụ thuộc vào dự án khác có thể làm thay đổi thứ tự. Thêm một trường ngắn «bối cảnh để xem xét» và yêu cầu người duyệt ghi lại lý do khi ghi đè điểm số.

Ví dụ, đội bán hàng yêu cầu một báo cáo và nhận điểm 18. Một vấn đề hỗ trợ nhận điểm 16, nhưng có một khách hàng không thể hoàn tất đơn hàng đã thanh toán. Người duyệt có thể đưa vấn đề hỗ trợ lên trước và ghi chú: «Đang chặn một đơn hàng đã thanh toán của khách hàng». Nhờ vậy, quyết định có thể được xem xét lại thay vì mang tính cá nhân.

AppMaster có thể hỗ trợ loại cổng yêu cầu no-code này bằng biểu mẫu và logic nghiệp vụ để tính tổng điểm. Đặt mô tả các yếu tố ngay cạnh từng trường để người gửi và người duyệt cùng áp dụng một quy tắc.

Thu thập thông tin cần thiết cho từng yêu cầu

Hệ thống ưu tiên yêu cầu cần những thông tin cơ bản giống nhau cho mọi mục. Một biểu mẫu tiếp nhận ngắn sẽ ngăn những tin nhắn mơ hồ như «hãy làm việc này sớm» vượt lên trước công việc có nhu cầu kinh doanh được ghi nhận đầy đủ.

Hầu hết các đội cần năm trường bắt buộc:

• Mô tả vấn đề hoặc thay đổi được yêu cầu bằng ngôn ngữ đơn giản
• Những người hoặc nhóm sẽ sử dụng kết quả
• Tần suất họ sử dụng kết quả
• Điều gì xảy ra nếu đội ngũ trì hoãn công việc
• Ngày đến hạn mong muốn, nếu có

Hãy hỏi về hậu quả của việc chờ đợi bằng những thông tin cụ thể. «Việc này sẽ hữu ích» không giải thích được mức độ khẩn cấp. Người gửi có thể cho biết nhân viên hỗ trợ phải sao chép dữ liệu giữa hai hệ thống cho từng trường hợp, hoặc khách hàng không thể hoàn tất đơn hàng cho đến khi một trường xuất hiện trên cổng. Những chi tiết đó cho đội ngũ cơ sở công bằng để chấm điểm.

Tần suất sử dụng cũng làm thay đổi mức ưu tiên. Một báo cáo được 40 nhân viên bán hàng dùng mỗi sáng có tác động rộng hơn một báo cáo tương tự được một quản lý dùng mỗi quý. Hãy yêu cầu mọi người cung cấp thông tin thực tế thay vì tự chấm điểm cho yêu cầu của mình. Sau đó, các quy tắc có thể biến những thông tin đó thành một kết quả nhất quán.

Xem ngày đến hạn như một tuyên bố cần có bối cảnh

Một ngày cụ thể không tự chứng minh mức độ khẩn cấp. Bất kỳ ai chọn ngày đến hạn cũng nên nêu lý do. Những lý do hữu ích gồm cam kết đã ký với khách hàng, ngày pháp lý hoặc ngày tuân thủ, sự kiện đã lên kế hoạch hay sự phụ thuộc vào một đội khác.

Người nhập «thứ Sáu» vì họ thích ngày đó không nên nhận cùng một điểm với người có quy trình thanh toán sẽ dừng vào thứ Sáu. Hãy hỏi: «Điều gì sẽ xảy ra nếu việc này chưa sẵn sàng vào ngày đó?» Câu trả lời rõ ràng giúp đánh giá thời hạn dễ hơn. Câu trả lời yếu cho đội ngũ lý do để điều chỉnh thời hạn.

Trả lại nhanh các yêu cầu chưa đầy đủ

Đừng để một yêu cầu làm dở nằm trong hàng đợi. Hãy trả lại cùng một ghi chú cụ thể, chẳng hạn: «Vui lòng nêu nhóm người dùng và mô tả ảnh hưởng của việc chậm hai tuần». Cách này giữ cho quy trình công bằng và ngăn đội ngũ tự suy đoán.

Cổng yêu cầu no-code có thể bắt buộc điền các trường và chỉ hiển thị câu hỏi tiếp theo khi cần. Ví dụ, câu hỏi về thời hạn có thể xuất hiện sau khi ai đó nhập ngày đến hạn. Đội ngũ dùng AppMaster có thể tạo ứng dụng tiếp nhận với biểu mẫu, quy tắc nghiệp vụ và trạng thái «Cần bổ sung thông tin», để người gửi hoàn thiện thông tin còn thiếu mà không phải trao đổi qua một chuỗi email dài.

Tiếp nhận rõ ràng không phải là thủ tục rườm rà. Nó cung cấp đủ bằng chứng cho cùng một bộ quy tắc chấm điểm yêu cầu, kể cả yêu cầu của những người ít lên tiếng và những người có khả năng thuyết phục.

So sánh các yêu cầu cạnh tranh bằng cùng một quy tắc

Đội bán hàng yêu cầu thay đổi cổng khách hàng. Một số khách hàng đang hoạt động không thể xem trạng thái dịch vụ hiện tại, và đội bán hàng nói rằng thay đổi này có thể ảnh hưởng đến cuộc trao đổi gia hạn vào thứ Sáu. Cùng lúc đó, đội vận hành yêu cầu một báo cáo nội bộ kết hợp số liệu hỗ trợ và bán hàng hằng tuần.

Dùng cùng một công thức cho cả hai yêu cầu: (Tác động x 2) + Mức độ khẩn cấp + Áp lực thời hạn + (6 - Công sức).

Lúc này, báo cáo được làm trước. Báo cáo có thời hạn đã được xác nhận vì quản lý vận hành cần nó cho buổi xem xét vào thứ Hai đã lên lịch. Yêu cầu về cổng ảnh hưởng đến khách hàng, nhưng đội bán hàng mới chỉ nói rằng thứ Sáu quan trọng. Nhân viên vẫn có thể gửi trạng thái dịch vụ qua email, và chưa ai chứng minh rằng việc gia hạn phụ thuộc vào thay đổi này.

Một ngày sau, đội bán hàng bổ sung bằng chứng: một khách hàng có cuộc họp gia hạn vào thứ Sáu, quản lý khách hàng đính kèm lời mời họp, và khách hàng yêu cầu được truy cập cổng trước cuộc gọi đó. Điểm thời hạn tăng từ 1 lên 5.

Lúc này, yêu cầu về cổng đạt 17 điểm và được đưa lên trước báo cáo. Báo cáo không trở nên kém hữu ích hơn. Thay đổi cổng hiện có thời hạn khách hàng đã được xác nhận và đến trước.

Đó là lý do bằng chứng về thời hạn cần có quy tắc riêng. Viết «khẩn cấp» hoặc nêu một ngày tùy ý không nên được cộng điểm. Chỉ chấp nhận bằng chứng mà người khác có thể kiểm tra, chẳng hạn cam kết với khách hàng, ngày đến hạn pháp lý, cuộc họp đã đặt lịch hoặc vấn đề dịch vụ ảnh hưởng đến người dùng đang hoạt động.

Giữ ghi chú bên cạnh điểm số thật ngắn: «Đã xác nhận cuộc họp gia hạn vào thứ Sáu; 18 khách hàng đang hoạt động sử dụng cổng này». Bất kỳ ai xem hàng đợi cũng có thể thấy vì sao thứ tự thay đổi, còn đội vận hành có thể lập kế hoạch dựa trên một quyết định rõ ràng.

Cho người gửi thấy cách quyết định được đưa ra

Mọi người dễ chấp nhận mức ưu tiên thấp hơn khi nhìn thấy các quy tắc áp dụng cho tất cả. Hãy công khai những yếu tố tạo nên điểm số: mức độ khẩn cấp, tác động, công sức và áp lực thời hạn. Định nghĩa ý nghĩa của từng con số. Chẳng hạn, mức khẩn cấp 5 có thể có nghĩa là công việc của nhiều người đã dừng lại, còn mức 2 có nghĩa là yêu cầu sẽ giúp một công việc thường ngày dễ hơn.

Quy trình cũng cần lịch xem xét có thể dự đoán. Nêu rõ khi nào đội ngũ xem xét yêu cầu mới, chẳng hạn vào thứ Ba và thứ Năm hằng tuần, cũng như khi nào xem xét toàn bộ hàng đợi. Một yêu cầu đang chờ xem xét sẽ bớt cảm giác bị bỏ quên khi người gửi biết ngày cụ thể.

Hiển thị hàng đợi

Mỗi người gửi nên thấy trạng thái hiện tại và ngày dự kiến xem xét. Các nhãn đơn giản hoạt động tốt: Mới, Cần bổ sung thông tin, Đang xem xét, Đã lên kế hoạch, Đang thực hiện và Không lên kế hoạch. Tránh các nhãn như «đang chờ» khi không ai biết bước tiếp theo là gì.

Ví dụ, quản lý bán hàng gửi yêu cầu thêm một trường vào cổng khách hàng. Cổng có thể hiển thị rằng yêu cầu đang được xem xét, có điểm 11 và sẽ được thảo luận vào ngày 14 tháng 5. Quản lý có thể vẫn không thích kết quả, nhưng họ có thông tin cụ thể thay vì sự im lặng.

Khi điểm số thay đổi, hãy thêm một bình luận ngắn bằng ngôn ngữ đời thường:

• «Thời hạn chuyển sang quý sau, nên mức độ khẩn cấp giảm từ 4 xuống 2».
• «Đội hỗ trợ xác nhận 60 khách hàng gặp vấn đề này, nên tác động tăng từ 2 lên 5».
• «Đội ngũ tìm thấy một API có sẵn, nên công sức giảm từ 4 xuống 2».

Những ghi chú này giúp đội ngũ giải thích các lựa chọn trước đây. Chúng cho thấy điểm số phản ánh thông tin hiện tại, không phụ thuộc vào việc ai lên tiếng lớn nhất.

Cho phép mọi người sửa lại thông tin

Người gửi cần có cách sửa thông tin còn thiếu hoặc không chính xác. Thêm trường bình luận hoặc thao tác «Cung cấp thêm thông tin» vào biểu mẫu tiếp nhận yêu cầu minh bạch. Hãy yêu cầu bằng chứng có ảnh hưởng đến điểm số, chẳng hạn số người dùng, ngày đến hạn theo hợp đồng hoặc phương án tạm thời.

Người gửi có thể cung cấp thông tin, nhưng không nên tự sửa điểm số của mình. Người hoặc đội chịu trách nhiệm ưu tiên sẽ cập nhật điểm và giải thích thay đổi. Cách này giữ cho quy trình công bằng mà vẫn cho mọi người tiếng nói thực sự.

Những sai lầm làm mất niềm tin

Hệ thống ưu tiên yêu cầu mất uy tín khi thưởng cho người nói lớn nhất trong phòng. Người gửi có thể gọi một mục là khẩn cấp vì nó ảnh hưởng đến thời hạn của chính họ, nhưng mức độ khẩn cấp cần có bằng chứng: ngày cố định, cam kết với khách hàng, vấn đề tuân thủ hoặc sự cố dịch vụ. Hãy yêu cầu bằng chứng đó thay vì chấp nhận nhãn «khẩn cấp» màu đỏ.

Đừng dùng công sức như một hình phạt cho công việc khó nhưng cần thiết. Một bản sửa bảo mật lớn hoặc thay đổi phức tạp trên cổng khách hàng có thể mất nhiều thời gian hơn một báo cáo đơn giản, nhưng lợi ích của nó có thể xứng đáng. Công sức giúp so sánh các lựa chọn. Nó không nên đẩy công việc phức tạp sang một bên mãi mãi.

Những tuyên bố mơ hồ về tác động cũng tạo ra vấn đề tương tự. «Việc này sẽ giúp tất cả mọi người» không cho người duyệt thông tin nào để chấm điểm. Hãy yêu cầu người gửi mô tả ai được hưởng lợi và điều gì thay đổi. «Nhân viên hỗ trợ mất 15 phút sao chép dữ liệu cho mỗi một trong 40 trường hợp hằng tuần» cho đội ngũ cơ sở thực tế để ước tính tác động.

Những yếu tố thường làm mất niềm tin gồm:

• Cho phép đánh dấu mọi yêu cầu là khẩn cấp mà không có thời hạn hoặc thiệt hại rõ ràng
• Chấm điểm thấp cho yêu cầu phức tạp chỉ vì chúng cần nhiều công sức hơn
• Chấp nhận tuyên bố tác động rộng mà không có nhóm người dùng, con số hoặc ví dụ
• Đưa yêu cầu của lãnh đạo lên trước mà không ghi nhận trong cùng một quy trình
• Không cập nhật điểm số sau khi thời hạn, nhu cầu khách hàng hoặc mục tiêu kinh doanh thay đổi

Công việc của lãnh đạo không cần phải bí mật. Một lãnh đạo có thể có lý do chính đáng để đẩy một mục lên trước, chẳng hạn cam kết đã ký với khách hàng hoặc thời hạn pháp lý. Hãy đưa yêu cầu đó vào cùng danh sách tiếp nhận, nêu lý do và cho thấy lý do đã ảnh hưởng đến điểm số hoặc thứ tự như thế nào.

Điểm số cũng có thể hết hiệu lực. Chiến dịch có thể kết thúc, khách hàng có thể giải quyết vấn đề theo cách khác hoặc thời hạn có thể trôi qua. Hãy xem xét các yêu cầu đang hoạt động hai tuần một lần hoặc bất cứ khi nào người gửi thay đổi thông tin. Người phụ trách hàng đợi nên cập nhật điểm số và để lại ghi chú ngắn giải thích thay đổi.

Hành vi nhất quán quan trọng hơn một công thức phức tạp. Khi đội ngũ áp dụng cùng quy tắc cho công việc khẩn cấp, khó và của lãnh đạo, người gửi sẽ hiểu rằng điểm số có ý nghĩa.

Thử nghiệm quy trình trước khi triển khai

Hãy chạy thử trong thời gian ngắn trước khi biến hệ thống ưu tiên yêu cầu thành quy trình mặc định của đội. Nhờ ba người không tham gia thiết kế gửi các yêu cầu thực tế. Nếu họ không thể hoàn thành biểu mẫu và ước tính điểm mà không cần hướng dẫn, hãy viết lại cho đơn giản hơn hoặc bỏ bớt một trường.

Cho hai người duyệt cùng xem một nhóm yêu cầu mẫu và chỉ cung cấp những thông tin mà người gửi bình thường sẽ đưa ra. Tổng điểm của họ không nhất thiết phải giống hệt nhau, nhưng khoảng cách lớn cho thấy quy tắc còn mơ hồ. Hãy thay các thuật ngữ như «tác động cao» bằng mô tả cụ thể như «ảnh hưởng đến hơn 50 khách hàng» hoặc «khiến đội tài chính không thể hoàn tất sổ sách tháng».

Kiểm tra mọi ngày được cam kết. Một thời hạn cần nêu rõ hậu quả: ngày nộp hồ sơ pháp lý, hợp đồng sắp hết hạn, cam kết với khách hàng hoặc sự kiện đã lên kế hoạch. «Tôi cần việc này sớm» là mong muốn, không phải thời hạn.

Trước khi triển khai, hãy xác nhận rằng:

• Người gửi có thể xem điểm số, trạng thái và lý do thay đổi
• Người duyệt ghi chú khi ghi đè điểm số được tính tự động
• Đội ngũ xem xét các yêu cầu đang chờ theo một lịch cố định
• Biểu mẫu thu thập đủ thông tin để đánh giá tác động, công sức, mức độ khẩn cấp và thời hạn
• Một người phụ trách hàng đợi và trả lời câu hỏi về điểm số

Nếu một yêu cầu bị hạ xuống vì có vấn đề lớn hơn xuất hiện, hãy giải thích bằng một cập nhật ngắn. «Được chuyển xuống vì yêu cầu bảo mật mới đang chặn quyền truy cập của khách hàng» tạo nhiều niềm tin hơn một thay đổi trạng thái không lời giải thích.

AppMaster phù hợp để xây dựng loại cổng yêu cầu no-code này. Đội ngũ có thể tạo biểu mẫu tiếp nhận, tính điểm từ câu trả lời, hiển thị trạng thái cho người gửi và lưu ghi chú của người duyệt ngay cạnh từng yêu cầu thay vì để chúng thất lạc trong các chuỗi email.

Bắt đầu nhỏ và giữ quy trình minh bạch

Hãy triển khai với một đội và một nhóm nhỏ các loại yêu cầu, chẳng hạn sửa lỗi, yêu cầu quyền truy cập và thay đổi báo cáo. Thử nghiệm trong phạm vi hẹp giúp phát hiện các câu hỏi gây nhầm lẫn trước khi mọi phòng ban phụ thuộc vào chúng.

Giữ phiên bản đầu tiên đơn giản. Thu thập thông tin cần để áp dụng quy tắc chấm điểm, tính điểm và hiển thị trạng thái hiện tại. Chỉ thêm phê duyệt, lời nhắc và luồng chuyển phức tạp khi một vấn đề thực tế đòi hỏi.

Trong tháng đầu tiên, hãy xem xét các yêu cầu thực tế mỗi tuần. Chú ý xem mọi người có chọn các câu trả lời khác nhau cho cùng một tình huống hay không, cũng như liệu điểm số có vẻ bất hợp lý dù mọi người đã làm đúng quy tắc. Cả hai vấn đề đều cho thấy định nghĩa cần được viết bằng ngôn ngữ dễ hiểu hơn.

Nếu nhiều người gửi gọi một bất tiện nhỏ là «khẩn cấp», hãy thay đổi định nghĩa. Khẩn cấp có thể có nghĩa là dịch vụ không hoạt động, khách hàng không thể hoàn tất một tác vụ đã thanh toán hoặc thời hạn cố định còn trong vòng hai ngày làm việc. Mọi người phải có thể chọn câu trả lời mà không cần biết đội ngũ tranh luận riêng về ưu tiên như thế nào.

Sau khi gửi, người gửi nên thấy:

• Điểm số hoặc mức ưu tiên
• Các yếu tố tạo nên điểm số
• Trạng thái hiện tại và người phụ trách
• Ngày xem xét tiếp theo nếu đội ngũ chưa lên lịch thực hiện

Minh bạch không có nghĩa là mọi yêu cầu được xử lý ngay. Điều đó có nghĩa là mọi người có thể thấy đội ngũ đã nhận yêu cầu, áp dụng cùng một quy tắc và sẽ xem xét vào thời điểm đã nêu. Khi mức ưu tiên thay đổi, hãy ghi lại lý do bằng ngôn ngữ đơn giản.

Sau giai đoạn thử nghiệm, hãy giữ lại những phần mọi người hiểu và bỏ các trường không ai dùng. Một quy trình đơn giản mà mọi người có thể làm theo sẽ tạo được nhiều niềm tin hơn một quy trình chi tiết chỉ người xây dựng mới hiểu.