5 SLA cơ bản cho Service Desk

Các nhà quản lý Service Desk luôn muốn mang đến sự hài lòng cho khách hàng khi giải quyết các yêu cầu của họ nhanh gọn và đúng thời điểm. Nếu chúng ta muốn giải quyết các yêu cầu từ khách hàng một cách chính xác (được hỗ trợ từ các chuyên gia) và kịp thời, liệu chúng ta có cần đo lường cho 2 số liệu đó? Tất nhiên rồi.

Trong bài post này, tôi sẽ liệt kê và mô tả 5 SLA (service level agreement) metrics hay còn gọi là thoả thuận cấp độ dịch vụ để đo lường hiệu suất của một service desk. Lưu ý: đây không phải một danh sách SLA hoàn hảo nhưng là cơ bản nhất cho mọi service desk hiện nay. Và thật tuyệt vời nếu các bạn cũng chia sẻ những SLA mà các bạn đang áp dụng thông qua các bình luận bên dưới.

Các thuật ngữ tắt trong bài viết:

-Ticket: vé yêu cầu

-Agent: nhân viên hỗ trợ

Một trong những tiêu chí quan trọng của service desk đó chính là response. Khách hàng luôn mong đợi sẽ được đáp ứng nhanh cho các yêu cầu của họ, dù họ hiểu rằng đôi khi để hoàn thành một yêu cầu cần có vài ngày. SLA phù hợp với tiêu chí này là Time to First Response. Time to First Response được tính từ thời điểm khách hàng tạo một yêu cầu cho đến khi agent thấy ticket đó và bắt đầu đọc nó. Điều này có nghĩa khi một agent bắt đầu nhận lấy ticket, họ sẽ đọc yêu cầu đó và chuyển nó sang trạng thái tiếp theo (ví dụ: In progress) trong quy trình công việc, đương nhiên khách hàng cũng nhận được thông báo về điều đó.

Thông báo đến khách hàng là một phần của SLA này. Khách hàng có thể xem được hiện trạng của yêu cầu, và khi yêu cầu được chuyển sang trạng thái tiến hành (in progress), họ sẽ biết được agent nào đang thực hiện. Khách hàng sẽ cảm thấy hài lòng khi biết ít nhất có ai đó đã đọc và đang xử lý yêu cầu của họ. Một service desk tối ưu là luôn cập nhật và thông báo tiến độ xử lý yêu cầu đến cho khách hàng.

Đồng ý rằng bạn nên hồi đáp khách hàng nhanh chóng. Nhưng liệu khách hàng có quan tâm bạn hồi đáp và giao tiếp với họ nhanh ra sao. Điều họ muốn biết chính là sự hiệu quả trong việc giải quyết yêu cầu của họ. Service desk nên đo lường được thời gian xử lý yêu cầu và SLA Time to Resolution phù hợp với tiêu chí này. Nghe có vẻ đơn giản nhưng có vài vấn đề cần xem xét như: Điều gì sẽ xảy ra khi yêu cầu cần bổ sung thêm thông tin từ khách hàng? ước tính thời gian chờ khách hàng phản hồi? hoặc khi một agent yêu cầu thông tin từ khách hàng và phải đợi 4 ngày để được hồi đáp. Liệu 4 ngày đó có được tính vào thời gian xử lý vấn đề?

Thật không dễ trả lời bởi vì bạn sẽ không muốn đếm thời gian phải chời đợi khách hàng phản hồi. Tuy nhiên, các nhà quản lý tin rằng không quan trọng việc ai đang đợi ai. Nếu có 1 yêu cầu đang “Open”, điều này không có nghĩa nó đã được “Resolved”. Và tất cả những gì diễn ra giữa ” Created” và “Resolved” phụ thuộc vào việc yêu cầu được giải quyết trong bao lâu. Điều quan trọng để xác định thời gian xử lý yêu cầu là nó cần phải phù hợp với văn hóa làm việc của tổ chức và tìm một công cụ đủ linh hoạt để bạn có thể xác định và đo Time to Resolution.

Thay vì quyết định theo dõi (hoặc loại trừ) thời gian chờ đợi khách hàng, chúng ta có thể theo dõi thời gian mà agent xử lý ticket. Time Wating for Support là thời gian mà ticket được agent xử lý bắt đầu từ trạng thái “open”, nhưng không tính thời gian ở trạng thái “time waiting for customer”. Các nhà quản lý service desk luôn muốn kiểm soát thời gian xử lý ticket sao cho hợp lý. Họ có thể không cần kiểm soát việc hồi đáp từ khách hàng, nhưng chắc chắn muốn biết sự hồi đáp từ các agent và mất bao lâu cho việc xử lý ticket đó. Bằng cách đo lường Time Waiting for Support, người quản lý service desk sẽ xác định được đội nào hoặc agent nào chịu trách nhiệm xử lý cho yêu cầu của khách hàng.

Đôi khi có những khách hàng đòi hỏi có 1 bên thứ 3 (không phải thành viên của đội service desk) để đánh giá, phê duyệt, hoặc cung cấp thông tin trên yêu cầu của khách hàng. Ví dụ, một khách hàng có thể báo cáo đến service desk là keyboard họ không hoạt động. Nếu giải pháp là mua sắm một keyboard mới, thì cần có sự phê duyệt của người quản lý, phòng mua sắm hoặc tài chính. Nếu đây trường hợp là công ty bạn, chuyện gì xảy ra nếu quá trình phê duyệt mất 48-72 giờ? Điều đó liệu có đáp ứng được thoả thuận dịch vụ? Nếu không cách để đặt ticket vào trạng thái “chờ phê duyệt” và dừng thời gian tính, một số service desk có thể tự động đóng issue này vì đã xong tác vụ của họ, và có tắt các yêu cầu để mua sắm. Đây là một ví dụ thực tế và vì những lý do trên, luồng công việc sẽ bị gãy, theo dõi bị dừng lại, và không còn tính minh bạch trong quá trình này.

Để xử lý vấn đề này cần phải có một giai đoạn chờ đợi bên thứ 3 và dừng tính thời gian trong khi có một ticket về tình trạng công việc này (tất nhiên, JIRA Service Desk cho phép bạn xác định điều này). Để bắt đầu, bạn có thể đo mức độ dịch vụ đúng đối với đội của bạn, nhưng bạn cũng có thể đo lường mức độ dịch vụ cho bộ phận khác và cung cấp dữ liệu đó cho phòng mua sắm.

Cuối cùng, chúng ta sẽ nói về một đo lường tuyệt vời khác. Bất cứ ai đang cung cấp service desk (hoặc bất kỳ chức năng hỗ trợ) đều thích việc khách hàng có thể tự giải quyết các yêu cầu riêng của họ thông qua sử dụng bài viết trong cơ sở kiến thức hơn là gửi một yêu cầu đến các agent. Nhưng làm thế nào để bạn biết ai đó đã đọc bài viết “Reset Password” trong cơ sở kiến thức và sau đó sẽ không gửi một yêu cầu tương tự đến service desk? Làm thế nào để bạn biết rằng kể từ khi bạn thêm các bài viết mới vào cơ sở kiến thức (ví dụ thêm 10 bài viết mới), các yêu cầu đến service desk sẽ giảm 25%? Và làm thế nào bạn có thể chứng minh rằng việc các yêu cầu giảm đến 25% là do tác động của những bài viết hỗ trợ mới.

Không có câu trả lời đơn giản cho những câu hỏi trên.

Thay vì theo dõi liên kết trực tiếp giữa các bài viết trên cơ sở kiến thức với những ticket có liên quan thì chúng ta có thể cung cấp cho khách hàng self-service nhằm giúp họ có thể giải đáp những thắc mắc nhanh chóng hơn mà không cần phải đợi các agent.

Trực giác của chúng ta hiểu rằng nếu khách hàng có thể dễ dàng tìm thấy câu trả lời cho câu hỏi của họ trong khi đang làm việc hoặc trực tiếp trên cổng thông tin yêu cầu (JIRA Service Desk là một ví dụ), họ sẽ không cần phải tạo ra ticket để gửi đến agent. Đó cũng là lý do mà khách hàng sẽ hài lòng hơn khi biết rằng rất dễ để tìm kiếm các bài viết giúp họ giải quyết những yêu cầu riêng của họ ngay tại chỗ chứ không phải chờ đợi các agent trợ giúp.

Đây là một chủ đề rất thú vị để tranh luận. Làm thế nào để đo lường sự hiệu quả của tính năng self-service? Bạn có áp dụng nó? Tại sao hoặc tại sao không? Xin hãy chia sẻ quan điểm của bạn qua các bình luận trong bài viết này.

Bằng cách tìm hiểu 5 SLA cơ bản ở trên, bạn có thể bắt đầu định nghĩa nó như thế nào trong service desk của tổ chức bạn.