Trình theo dõi SLA: xây dựng thời hạn, thời gian tạm dừng và báo cáo theo đội ngũ

Vì sao các đội ngũ vận hành khách hàng thường bỏ lỡ thời hạn SLA

Các đội ngũ vận hành khách hàng hiếm khi bỏ lỡ SLA vì ai đó phớt lờ một ngày đến hạn. Thời hạn thay đổi, ticket được chuyển qua nhiều người và phản hồi của khách hàng có thể khiến công việc tạm dừng trong nhiều ngày. Một bảng tính chỉ có một cột thời hạn sẽ nhanh chóng mất tác dụng nếu không có người cập nhật sau mỗi thay đổi.

Vấn đề đầu tiên là xem mọi mục tiêu SLA như một thời hạn duy nhất. Mục tiêu phản hồi đầu tiên đo tốc độ nhân viên xác nhận một yêu cầu mới. Mục tiêu xử lý đo khoảng thời gian đội ngũ có để giải quyết yêu cầu. Một ticket có thể đáp ứng mục tiêu phản hồi trong 15 phút nhưng vẫn bỏ lỡ mục tiêu xử lý ba ngày sau đó. Một thời hạn duy nhất không cho biết cam kết nào đã bị vi phạm.

Quyền sở hữu tạo ra một vấn đề khác. Một nhân viên có thể phản hồi, chuyên gia có thể điều tra và quản lý có thể phê duyệt giải pháp. Nếu không ai sở hữu bộ đếm SLA đang hoạt động, mỗi người đều có thể nghĩ rằng người khác đang theo dõi. Ticket nằm trong hàng đợi cho đến khi hết thời gian.

Hãy xem xét một vấn đề truy cập tài khoản được báo cáo lúc 10:00. Nhân viên phản hồi lúc 10:12, đáp ứng mục tiêu phản hồi 30 phút, rồi yêu cầu ảnh chụp màn hình lúc 10:20. Khách hàng phản hồi vào chiều hôm sau. Nếu trình theo dõi tính thời gian chờ đó vào mục tiêu xử lý, hệ thống sẽ quy trách nhiệm cho bộ phận hỗ trợ về khoảng thời gian họ không thể sử dụng. Nếu tạm dừng bộ đếm nhưng không tiếp tục lại, kết quả cũng sai theo hướng ngược lại.

Trình theo dõi nên cung cấp cho mỗi ticket một hồ sơ vận hành chung gồm người phụ trách, đội ngũ, mức độ ưu tiên, thời hạn phản hồi và xử lý, trạng thái bộ đếm, lý do tạm dừng và lịch sử thay đổi. Khi đó, nhân viên có thể tập trung vào công việc sắp vi phạm, còn quản lý có thể xác định chậm trễ do nhân sự, bàn giao hoặc thời gian chờ khách hàng.

Bảng tính thủ công có thể phù hợp với một hàng đợi nhỏ và ổn định. Khi thời hạn phụ thuộc vào mức độ ưu tiên, giờ làm việc, việc phân công lại và thời gian tạm dừng, trình theo dõi cần các quy tắc nhất quán.

Xác định thông tin cần có trong mỗi bản ghi SLA

Mỗi ticket cần đủ chi tiết để giải thích ai sở hữu ticket, cam kết nào được áp dụng và bộ đếm có nên chạy hay không. Hãy bắt đầu với những thông tin cơ bản: khách hàng hoặc tài khoản, mức độ ưu tiên, đội ngũ được phân công, người phụ trách ticket và trạng thái hiện tại.

Sau đó thêm các trường kiểm soát thời hạn:

• Chính sách SLA, chẳng hạn «Hỗ trợ tiêu chuẩn» hoặc «Hỗ trợ ưu tiên»
• Thời điểm bắt đầu
• Thời hạn phản hồi đầu tiên và thời hạn xử lý
• Lý do tạm dừng và thời điểm bắt đầu tạm dừng
• Thời điểm tiếp tục hoặc tổng thời gian đã tạm dừng

Tách riêng phản hồi đầu tiên và xử lý hoàn tất. Một đội ngũ có thể cam kết phản hồi đầu tiên trong bốn giờ làm việc nhưng cần hai ngày làm việc để xử lý. Một thời hạn duy nhất sẽ khiến lời xác nhận nhanh che khuất một ticket chưa được giải quyết.

Không yêu cầu nhân viên tự chọn «đã vi phạm». Hãy tính trạng thái này từ thời điểm hiện tại, thời hạn, trạng thái ticket và các lần tạm dừng hợp lệ. Ví dụ, ticket vi phạm SLA xử lý khi thời hạn đã qua, ticket vẫn mở và bộ đếm đang hoạt động.

AppMaster có thể tập trung logic này tại một nơi. Data Designer giúp mô hình hóa các trường của ticket, còn Business Process trực quan có thể tính thời hạn và trạng thái vi phạm mỗi khi nhân viên tạo hoặc cập nhật ticket.

Thiết lập quy tắc SLA trước khi xây dựng trình theo dõi

Quy tắc rõ ràng giúp kết quả SLA công bằng. Hãy xác định mục tiêu cho từng loại ticket trước khi tạo công thức hoặc báo cáo. Nếu không, hai nhân viên có thể xử lý cùng một yêu cầu theo cách khác nhau và số liệu vi phạm sẽ mất ý nghĩa.

Hầu hết đội ngũ thay đổi mục tiêu theo mức độ ưu tiên, gói dịch vụ khách hàng và loại yêu cầu. Hãy giữ phiên bản đầu tiên ở quy mô nhỏ. Ví dụ, sự cố sản xuất khẩn cấp có thể yêu cầu phản hồi đầu tiên trong một giờ, vấn đề truy cập của khách hàng trả phí trong bốn giờ làm việc và câu hỏi thông thường trong hai ngày làm việc.

Viết mỗi quy tắc bằng ngôn ngữ đơn giản. Câu «Một vấn đề thanh toán mức ưu tiên cao của khách hàng cao cấp cần được phản hồi lần đầu trong vòng hai giờ làm việc» cho biết chính xác dữ liệu cần lưu: mức độ ưu tiên, gói dịch vụ, loại yêu cầu, thời điểm tạo và thời điểm phản hồi đầu tiên.

Xác định lịch làm việc

Quyết định mục tiêu chạy liên tục cả ngày hay chỉ trong giờ hỗ trợ. Nếu bộ phận hỗ trợ làm việc từ thứ Hai đến thứ Sáu, 9:00 đến 17:00, một ticket nhận lúc 16:30 thứ Sáu với mục tiêu hai giờ sẽ đến hạn lúc 10:30 thứ Hai, không phải vào tối thứ Sáu.

Ghi rõ ngày làm việc, giờ hỗ trợ, múi giờ, ngày lễ và mọi lịch sự cố riêng hoạt động 24/7. Khi có thể, hãy dùng một lịch được đặt tên cho mỗi chính sách. Đội ngũ phục vụ khách hàng ở nhiều quốc gia có thể cần lịch theo khu vực, nhưng tạo một lịch cho từng khách hàng sẽ làm tăng công việc bảo trì không cần thiết.

Xác định mốc bắt đầu và quyền sở hữu chính sách

Chọn chính xác thời điểm bộ đếm bắt đầu. Ticket mới thường bắt đầu khi hệ thống nhận được ticket. Ticket mở lại cần một quy tắc riêng: tiếp tục thời gian còn lại, khởi động lại bộ đếm ban đầu hoặc bắt đầu một mục tiêu mới. Chọn một phương pháp và áp dụng nhất quán.

Giao việc thay đổi chính sách cho một người hoặc một nhóm nhỏ. Nhân viên có thể sửa dữ liệu ticket, nhưng không nên thay đổi thời hạn để xóa vi phạm. Lưu phiên bản chính sách trên mỗi bản ghi và ghi lại các ngoại lệ đã được phê duyệt cùng lý do và ngày áp dụng.

Ứng dụng AppMaster có thể lưu chính sách trong một khu vực quản trị và áp dụng quy tắc phù hợp khi ticket đi vào hệ thống. Cách này thay thế các công thức bảng tính riêng lẻ bằng một bộ đếm nhất quán.

Mô hình hóa dữ liệu phía sau trình theo dõi

Giữ phiên bản đầu tiên đủ đơn giản để trưởng bộ phận vận hành có thể kiểm tra một ticket và hiểu vì sao thời hạn thay đổi.

Bắt đầu với bảng ticket gồm ID, tiêu đề, khách hàng, mức độ ưu tiên, trạng thái, thời điểm tạo, thời điểm phản hồi đầu tiên, thời điểm giải quyết, các thời hạn, người phụ trách được phân công và đội ngũ chịu trách nhiệm. Mỗi ticket nên có một người phụ trách hiện tại và một đội ngũ, ngay cả khi nhiều người cùng bình luận.

Tạo các bản ghi riêng cho đội ngũ và chính sách SLA. Bản ghi đội ngũ có thể chứa tên và lịch giờ làm việc. Mỗi chính sách cần nêu rõ loại ticket được áp dụng, mục tiêu phản hồi và xử lý, loại bộ đếm và việc thời gian chờ khách hàng có tạm dừng bộ đếm hay không.

Thêm bản ghi ngày lễ với ngày, đội ngũ hoặc địa điểm liên quan và nhãn ngắn. Lưu mọi mốc thời gian trong một múi giờ nhất quán, thường là UTC, sau đó hiển thị giờ địa phương trên giao diện khi cần. Việc trộn nhiều múi giờ gây lỗi vào cuối tuần và thời điểm chuyển sang hoặc rời giờ mùa hè.

Giữ lịch sử trạng thái thay vì ghi đè dữ liệu cũ. Mỗi mục cần ghi ID ticket, trạng thái cũ và mới, thời điểm sự kiện và người hoặc quy tắc thực hiện thay đổi. Ghi lại các sự kiện như «Đang chờ khách hàng», «Khách hàng đã phản hồi», «Đã phân công» và «Đã giải quyết».

Lịch sử này giải thích các thay đổi thời hạn. Nếu thời hạn chuyển từ sáng thứ Ba sang chiều thứ Ba, quản lý có thể thấy đội ngũ đã tạm dừng SLA ba giờ để chờ khách hàng. Data Designer trực quan của AppMaster có thể mô hình hóa các bản ghi liên quan, còn Business Process Editor có thể cập nhật thời hạn sau khi trạng thái thay đổi.

Tính thời hạn của ticket

Bắt đầu bộ đếm tại một sự kiện rõ ràng, chẳng hạn khi hệ thống nhận ticket hỗ trợ. Không bắt đầu khi ai đó tình cờ xem ticket. Lưu thời điểm bắt đầu để mọi phép tính sau đó dùng cùng một mốc tham chiếu.

Tiếp theo, chọn chính sách SLA phù hợp dựa trên gói dịch vụ, loại ticket, mức độ ưu tiên hoặc khu vực của khách hàng. Sau đó tính thời hạn:

1. Đọc mục tiêu của ticket, chẳng hạn thời gian phản hồi bốn giờ.
2. Chỉ cộng thời gian làm việc được chính sách cho phép.
3. Bỏ qua giờ đóng cửa, cuối tuần và ngày lễ nếu chính sách loại trừ các khoảng thời gian này.
4. Lưu thời hạn trên ticket.
5. Tính lại nếu thay đổi mức độ ưu tiên, gói dịch vụ hoặc danh mục khiến một chính sách khác được áp dụng.

Giờ làm việc khiến việc này phức tạp hơn tưởng tượng. Nếu SLA bốn giờ bắt đầu lúc 16:00 và bộ phận hỗ trợ làm việc từ 9:00 đến 17:00, ticket còn một giờ trong ngày hôm đó. Ticket đến hạn vào 12:00 ngày làm việc kế tiếp, không phải 20:00 cùng ngày.

Khi ticket thay đổi mức độ ưu tiên, hãy giữ thời điểm bắt đầu ban đầu và áp dụng quy tắc nâng cấp đã được ghi nhận. Một số đội ngũ áp dụng mục tiêu khẩn cấp từ thời điểm bắt đầu ban đầu, số khác bắt đầu mục tiêu mới khi ticket được nâng cấp. Cả hai cách đều có thể hiệu quả nếu mọi người tuân thủ cùng một quy tắc.

Hiển thị cả thời hạn chính xác và thời gian còn lại. Các nhãn như «còn 2 giờ 15 phút», «đến hạn sau 1 ngày» và «trễ 35 phút» giúp nhân viên quét hàng đợi nhanh hơn việc chỉ xem mốc thời gian. Dùng trạng thái trung tính cho ticket đang an toàn, cảnh báo khi gần đến hạn và trạng thái vi phạm rõ ràng sau khi thời hạn trôi qua.

Tạm dừng bộ đếm khi chờ khách hàng phản hồi

Chỉ tạm dừng bộ đếm khi đội ngũ không thể tiếp tục xử lý ticket nếu thiếu khách hàng. Các lý do phổ biến gồm chờ thông tin, xác nhận, quyền truy cập, phê duyệt hoặc tệp. Chậm trễ nội bộ, chẳng hạn chờ đồng nghiệp, không nên tạm dừng SLA.

Dùng một nhóm trạng thái ngắn gọn, rõ ràng:

• Đang chờ thông tin từ khách hàng
• Đang chờ khách hàng phê duyệt
• Đang chờ quyền truy cập của khách hàng
• Đang chờ tệp do khách hàng cung cấp

Khi nhân viên chọn một trong các trạng thái này, hãy lưu chính xác thời điểm và lý do tạm dừng. Đồng thời ghi lại tin nhắn hoặc sự kiện yêu cầu khách hàng phản hồi. Khi đó, người giám sát có thể xác minh việc tạm dừng là hợp lý.

Khi khách hàng phản hồi, tiếp tục bộ đếm từ thời điểm phản hồi. Cộng thời gian chờ vào total paused time, sau đó tính lại thời gian còn lại theo quy tắc giờ làm việc. Thời gian khách hàng chờ 90 phút sẽ đẩy thời hạn thêm 90 phút, tùy thuộc vào giờ đóng cửa.

Hiển thị thời gian tạm dừng trong giao diện ticket. Nhân viên cần biết ticket đã chờ 15 phút hay ba ngày, còn người giám sát cần nhận ra các ticket liên tục quay lại trạng thái chờ.

Giới hạn lý do tạm dừng theo những lý do được chính sách SLA cho phép. Yêu cầu có một sự kiện yêu cầu từ khách hàng trước khi chấp nhận tạm dừng. Trong AppMaster, Business Process có thể kiểm tra trạng thái mới, lưu thời điểm bắt đầu tạm dừng và từ chối thay đổi không hợp lệ trước khi cập nhật bản ghi SLA.

Email tự động «chúng tôi đã nhận được tin nhắn của bạn» không nên tiếp tục bộ đếm. Hãy dùng tin nhắn đến từ khách hàng hoặc phản hồi đã được nhân viên xác nhận, đồng thời giữ toàn bộ lịch sử tạm dừng cùng ticket.

Xử lý một ví dụ về hỗ trợ khách hàng

Một khách hàng gửi câu hỏi thanh toán lúc 10:00 thứ Ba: «Vì sao hóa đơn của tôi hiển thị hai khoản phí?» Trình theo dõi tạo ticket B-184, phân công cho bộ phận Hỗ trợ và áp dụng SLA thanh toán. Đội ngũ có bốn giờ làm việc để gửi phản hồi hữu ích đầu tiên và tám giờ làm việc để giải quyết.

Bộ phận Hỗ trợ làm việc từ 9:00 đến 17:00, thứ Hai đến thứ Sáu. Lúc 10:35, một nhân viên xác nhận đội ngũ đang kiểm tra tài khoản. Bộ đếm phản hồi đầu tiên dừng ở 35 phút, còn lại 3 giờ 25 phút. Ticket đáp ứng mục tiêu phản hồi đầu tiên.

Lúc 11:00, nhân viên cần số hóa đơn và đánh dấu ticket là «Đang chờ khách hàng». Bộ đếm xử lý tạm dừng sau một giờ làm việc thực tế. Trình theo dõi lưu thời điểm và lý do tạm dừng.

Khách hàng phản hồi lúc 15:30. Trình theo dõi cộng 4 giờ 30 phút tạm dừng vào thời hạn. Thời hạn xử lý ban đầu là 18:00 thứ Ba, nên thời hạn được điều chỉnh thành 14:30 thứ Tư sau khi thời gian còn lại được chuyển sang ngày làm việc kế tiếp.

Một nhân viên giải quyết vấn đề lúc 15:10 thứ Tư. Ticket trễ 40 phút. Ticket được tính là một lần xử lý quá hạn của bộ phận Hỗ trợ, trong khi phản hồi đầu tiên vẫn đúng hạn.

Báo cáo vi phạm nên thể hiện rõ phần tách này: bộ phận Hỗ trợ nhận một ticket thanh toán, đáp ứng mục tiêu phản hồi đầu tiên, bỏ lỡ mục tiêu xử lý 40 phút và dành 4 giờ 30 phút để chờ khách hàng. Chỉ nhìn vào tổng thời gian tồn tại của ticket sẽ dẫn đến kết luận sai.

Báo cáo vi phạm SLA theo đội ngũ

Ticket vi phạm SLA khi thời hạn trôi qua trước khi hành động bắt buộc được thực hiện. Hãy dùng thời hạn đã điều chỉnh sau các lần tạm dừng chờ khách hàng hợp lệ.

Tách ticket đang mở và quá hạn khỏi ticket đã giải quyết nhưng bị trễ. Ticket đang mở và quá hạn cần được xử lý ngay. Ticket đã giải quyết nhưng bị trễ thuộc về báo cáo hiệu suất. Gộp hai nhóm sẽ che khuất công việc khẩn cấp và khiến báo cáo khó sử dụng.

Trong mỗi kỳ, hãy nhóm kết quả theo đội ngũ sở hữu ticket tại thời điểm thời hạn trôi qua. Lọc theo chính sách, mức độ ưu tiên và khoảng thời gian. Không nên so sánh trực tiếp một đội ngũ thanh toán có chính sách phản hồi bốn giờ với đội ngũ xử lý sự cố kỹ thuật có chính sách xử lý hai ngày làm việc.

Dùng số lượng cùng với tỷ lệ:

• Tổng số ticket có SLA đang hoạt động
• Số ticket được giải quyết đúng mục tiêu
• Số ticket đang mở và quá hạn
• Số ticket được giải quyết sau thời hạn
• Tỷ lệ vi phạm, tính bằng số ticket vi phạm chia cho số ticket có SLA

Tỷ lệ vi phạm 50% mang ý nghĩa khác nhau nếu đến từ một ticket trễ trên tổng số hai ticket, thay vì 50 ticket trễ trên tổng số 100 ticket. Hãy xem xu hướng cùng với chi tiết ticket. Các vi phạm thường xuyên ở ticket ưu tiên cao có thể chỉ ra vấn đề về quy tắc nâng cấp hoặc bàn giao, thay vì khối lượng công việc tổng thể.

Một báo cáo hữu ích cho phép quản lý mở danh sách ticket trễ, xem chính sách và mức độ ưu tiên, đồng thời kiểm tra quyền sở hữu tại thời điểm vi phạm. Báo cáo nên hỗ trợ việc xem xét thực tế những công việc cần cải thiện, thay vì khuyến khích đội ngũ đóng ticket quá sớm.

Xây dựng giao diện cho nhân viên và quản lý

Nhân viên cần một danh sách làm việc ngắn gọn, không phải báo cáo đầy ticket cũ. Mỗi ticket đang mở nên hiển thị người phụ trách, đội ngũ, mức độ ưu tiên, thời hạn, trạng thái bộ đếm và thời gian còn lại. Ghi nhận ngay thay đổi quyền sở hữu khi ticket chuyển giữa các đội ngũ.

Dùng nhãn bộ đếm đơn giản. «Đang hoạt động» nghĩa là đội ngũ chịu trách nhiệm cho hành động tiếp theo. «Tạm dừng - chờ khách hàng» nghĩa là bộ đếm đã dừng. Hiển thị riêng thời gian hoạt động và thời gian tạm dừng để người dùng hiểu vì sao ticket đã mở trong nhiều ngày.

Giao diện nhân viên có thể bao gồm ticket đến hạn trong bốn giờ tới, ticket quá hạn, ticket đang chờ khách hàng phản hồi và ticket được phân công lại trong ngày. Gửi cảnh báo trước thời hạn. Mục tiêu phản hồi bốn giờ cần cảnh báo sớm hơn mục tiêu xử lý ba ngày.

Quản lý cần một giao diện khác. Báo cáo hàng tuần có thể nhóm ticket quá hạn theo đội ngũ và hiển thị số lần vi phạm, tỷ lệ đạt mục tiêu, thời gian quá hạn trung bình và ticket vẫn mở sau thời hạn. Đưa người phụ trách và lần cập nhật gần nhất vào từng mục quá hạn.

Giữ nhật ký kiểm toán cho các thay đổi chính sách. Nếu đội ngũ vận hành thay đổi mục tiêu từ tám giờ thành 12 giờ, hãy ghi rõ ai thay đổi, thời điểm thay đổi và ticket mới nào sử dụng quy tắc này. Kết quả lịch sử phải giữ lại quy tắc được áp dụng khi mỗi ticket bắt đầu.

AppMaster cho phép đội ngũ xây dựng các giao diện web riêng cho nhân viên và quản lý, trong khi vẫn dùng chung dữ liệu ticket và quy tắc nghiệp vụ phía sau.

Những sai lầm làm sai lệch kết quả SLA

Biểu đồ gọn gàng vẫn có thể kể sai câu chuyện nếu các quy tắc nền tảng không đúng.

Áp dụng máy móc các quy tắc thời gian

Không tính theo giờ lịch khi thỏa thuận cam kết giờ làm việc. Một ticket mở lúc 16:30 thứ Sáu với mục tiêu phản hồi tám giờ làm việc không vi phạm lúc 00:30 thứ Bảy. Chỉ tính giờ làm việc và ngày lễ được quy định trong chính sách.

Hãy cẩn thận tương tự với việc tạm dừng. Trạng thái «đang chờ khách hàng» chỉ nên tạm dừng SLA khi đội ngũ đã gửi một yêu cầu rõ ràng và không thể tiếp tục nếu thiếu phản hồi. Tạm dừng mọi ticket có nhãn này sẽ che giấu những chậm trễ thuộc về đội ngũ.

Giữ lại các mốc thời gian giải thích từng kết quả: thời hạn ban đầu, chính sách đã dùng, mọi thời điểm bắt đầu và kết thúc tạm dừng, lý do tạm dừng, thời hạn đã điều chỉnh, thời điểm xử lý và người đóng ticket. Không có lịch sử này, không ai có thể xác minh vì sao ticket được xem là đúng hạn.

Chỉ tính quyền sở hữu một lần

Dùng một quy tắc quyền sở hữu trong báo cáo đội ngũ. Nếu bộ phận Hỗ trợ chuyển ticket cho bộ phận Thanh toán, không tính cùng một vi phạm cho cả hai đội ngũ. Bạn có thể gán kết quả cho đội ngũ sở hữu ticket khi thời hạn trôi qua và báo cáo các lần bàn giao riêng.

Yêu cầu có thời điểm giải quyết trước khi đóng ticket. Trạng thái đã đóng không chứng minh công việc kết thúc lúc nào. Ví dụ, nếu ticket chuyển từ Hỗ trợ sang Thanh toán lúc 14:00 và vi phạm lúc 15:00, bộ phận Thanh toán sở hữu vi phạm theo quy tắc sở hữu tại thời điểm vi phạm. Báo cáo vẫn có thể hiển thị lần bàn giao trước đó mà không thêm một vi phạm thứ hai.

Kiểm tra trình theo dõi trước khi ra mắt

Xem xét mọi chính sách SLA trước khi nhân viên dựa vào trình theo dõi. Mỗi chính sách cần mục tiêu rõ ràng, chẳng hạn phản hồi đầu tiên trong bốn giờ hoặc xử lý trong hai ngày làm việc, cùng lịch áp dụng cho chính sách đó. Đặt chính sách mặc định cho những ticket không khớp quy tắc về khách hàng, gói dịch vụ hoặc mức độ ưu tiên.

Hãy kiểm thử các tình huống thời gian khó, không chỉ trường hợp thông thường:

• Tạo ticket ngay trước khi kết thúc ngày làm việc và xác nhận thời gian còn lại được chuyển sang ngày làm việc kế tiếp.
• Tạo ticket trước cuối tuần hoặc ngày lễ và xác nhận thời hạn bỏ qua khoảng thời gian đóng cửa.
• Tạm dừng ticket để chờ khách hàng, thêm phản hồi và xác nhận bộ đếm tiếp tục đúng cách.
• Chuyển ticket giữa các đội ngũ và kiểm tra đội ngũ nào sở hữu vi phạm xảy ra sau đó.
• Đóng ticket sau thời hạn và xác nhận trình theo dõi ghi nhận vi phạm.

So sánh tổng số trên dashboard với danh sách ticket phía sau. Nếu báo cáo cho biết Đội ngũ A có 12 vi phạm, hãy lọc các bản ghi và đếm lại. Việc này phát hiện ticket trùng, ticket thiếu đội ngũ và ticket mở lại bị tính hai lần.

Thiết lập quyền truy cập trước khi phát hành. Nhân viên nên cập nhật những ticket mình xử lý, quản lý cần báo cáo của đội ngũ và quản trị viên nên kiểm soát cài đặt chính sách. Trong AppMaster, hãy kiểm thử từng vai trò bằng một tài khoản riêng để quản lý không cần quyền quản trị viên khi xem báo cáo vi phạm SLA.

Bắt đầu nhỏ và cải thiện quy trình

Bắt đầu với một loại ticket và một chính sách SLA. Đội ngũ hỗ trợ có thể bắt đầu với các yêu cầu email tiêu chuẩn và mục tiêu phản hồi đầu tiên 24 giờ. Như vậy là đủ để kiểm thử thời hạn, các lần tạm dừng được phê duyệt và bản ghi vi phạm.

Mời một vài nhân viên vận hành khách hàng chạy ticket thực tế qua quy trình, gồm một trường hợp bình thường, một trường hợp chờ khách hàng và một trường hợp bỏ lỡ thời hạn. Thu thập phản hồi cụ thể. Nhân viên có thể cần trạng thái riêng cho việc chờ khách hàng và chờ đội ngũ khác. Quản lý có thể nhận thấy nhãn «tạm dừng» chung chung che giấu quá nhiều thông tin.

Khi bảng tính hạn chế quy trình, hãy xây dựng trình theo dõi dưới dạng ứng dụng no-code trong AppMaster. Bạn có thể tạo biểu mẫu ticket, xác định logic bộ đếm trong Business Process Editor trực quan và cung cấp dashboard riêng cho nhân viên và quản lý. AppMaster có thể tạo backend, ứng dụng web và ứng dụng di động native khi trình theo dõi cần hoạt động ngoài một bảng dùng chung.

Ban đầu, hãy giữ báo cáo ở mức vừa phải: ticket đang mở, ticket sắp vi phạm, ticket đang tạm dừng và vi phạm theo đội ngũ. So sánh các thời hạn mẫu với kiểm tra thủ công, xem xét ticket vi phạm và khoảng thời gian tạm dừng, rồi chỉ thay đổi một quy tắc mỗi lần trước khi kiểm thử lại. Khi nhân viên tin tưởng vào phép tính, hãy thêm một loại ticket hoặc chính sách mức độ ưu tiên khác và lặp lại các bước kiểm tra tương tự.