Một lần, bộ phận Hỗ trợ Kinh doanh tại Social Discovery Group phải đối mặt với thách thức khó khăn là giải quyết 1500 yêu cầu tồn đọng đã tích lũy trong hơn bốn năm. Quản lý một lượng lớn vấn đề như vậy là một công việc nghiêm túc và chúng tôi liên tục thấy mình phải vật lộn để theo kịp KPI. Bất chấp những nỗ lực tốt nhất của chúng tôi, các vé vẫn bị xáo trộn từ nước rút này sang nước rút khác, khiến khách hàng thất vọng và chúng tôi cảm thấy quá tải. Trong bài viết này, chúng tôi xin chia sẻ kinh nghiệm giải quyết nhiệm vụ tưởng chừng như bất khả thi này, gợi nhắc chúng ta về kỳ công thứ sáu huyền thoại của Hercules. Chúng tôi sẽ đưa bạn qua những thách thức mà nhóm SDGroup phải đối mặt và các bước chúng tôi đã thực hiện để xây dựng lại các quy trình của bộ phận. Chúng tôi đã áp dụng phương pháp STATIK, phương pháp này tỏ ra vô cùng hiệu quả trong việc giúp chúng tôi giải quyết công việc tồn đọng và mang lại sự cứu trợ rất cần thiết cho nhóm của chúng tôi. Vì vậy, nếu bạn đang tìm kiếm thông tin chi tiết thiết thực để giải quyết tình trạng tồn đọng yêu cầu, hãy tiếp tục đọc! Làm thế nào chúng tôi kết thúc với hàng đợi 1.500 vé Với tư cách là bộ phận Hỗ trợ Kinh doanh, chúng tôi chịu trách nhiệm xử lý các yêu cầu có chứa các khiếu nại và đề xuất của khách hàng về các dịch vụ của chúng tôi. Ví dụ: nếu khách hàng gặp khó khăn với hệ thống thanh toán trên trang web của chúng tôi, họ có thể nêu vấn đề với nhóm hỗ trợ kỹ thuật của SDG. Các đồng nghiệp thu thập tất cả thông tin liên quan, bao gồm các bước sao chép sự cố và ảnh chụp màn hình, đồng thời tạo một phiếu yêu cầu trong Jira, giao nó cho bộ phận của chúng tôi. Sau đó, chúng tôi tiến hành các thử nghiệm bổ sung để đảm bảo rằng sự cố không phải là trục trặc tạm thời của khách hàng mà là sự cố thực sự từ phía chúng tôi. Nếu được xác nhận, chúng tôi sẽ tạo báo cáo lỗi, sắp xếp thứ tự ưu tiên và chuyển tiếp báo cáo đó cho nhóm phát triển để giải quyết. Trung bình mỗi ngày chúng tôi nhận được 20-30 vé. Chúng tôi đã dành 2-3 giờ để tái tạo sự cố, nhưng bất cứ khi nào chúng tôi cần hỗ trợ từ các bộ phận khác, chẳng hạn như chi tiết trường hợp, khởi động lại dịch vụ, dữ liệu từ cơ sở dữ liệu hoặc phân tích từ nhóm nhà phát triển, nhiệm vụ của chúng tôi có xu hướng bị đình trệ. Các đồng nghiệp của chúng tôi thường không thể phản hồi kịp thời và không có nhóm nhà phát triển riêng biệt nào được chỉ định phụ trách các báo cáo lỗi của chúng tôi. Hơn nữa, vé phát triển của chúng tôi có mức độ ưu tiên thấp hơn so với các nhiệm vụ kinh doanh. Kết quả là, ngay cả những yêu cầu có mức độ ưu tiên cao cũng có thể không được giải quyết trong vài tháng, trong khi các nhiệm vụ có mức độ ưu tiên thấp hơn vẫn nằm trong bảng trong nhiều năm. Như bạn có thể thấy, quy trình này dẫn đến quá nhiều sự không chắc chắn trong việc đáp ứng thời hạn, điều này gây ra sự không hài lòng cho cả chúng tôi và khách hàng của chúng tôi. Tình hình dẫn đến một số vấn đề: Khách hàng căng thẳng và thất vọng khi vấn đề của họ không được giải quyết đủ nhanh và chúng tôi không thể đưa ra thời hạn rõ ràng. Nhóm hỗ trợ của chúng tôi đã rất thất vọng vì hầu như ngày nào khách hàng cũng yêu cầu cập nhật các vấn đề chưa được giải quyết. Nhóm hỗ trợ đã viết thư cho chúng tôi và nhận được phản hồi tương tự: "Vấn đề vẫn chưa được giải quyết." Nhóm của chúng tôi đã quá tải và không thể nhận các nhiệm vụ cũ và liên kết chúng thành các trường hợp định kỳ. Chúng tôi cảm thấy tuyệt vọng khi nhìn vào con số đáng sợ là 1.500 nhiệm vụ chưa được giải quyết trên bảng của chúng tôi. Chúng tôi biết rằng chúng tôi cần phải thay đổi cách tiếp cận của mình để đạt được bất kỳ bước tiến nào. Đây là vòng đời của vé trông như thế nào trong thời kỳ đó. Hãy xem xét một số vấn đề chúng tôi gặp phải khi quản lý vấn đề tồn đọng: Nhóm hỗ trợ thiếu tập lệnh để lập tài liệu và lọc các vấn đề kịp thời. Các nhiệm vụ ở trạng thái "Mới" thường bị mắc kẹt trong tình trạng lấp lửng. Khi chúng tôi không có đủ thông tin hoặc quyền truy cập để giải quyết vấn đề, vấn đề sẽ chuyển sang trạng thái "Đã báo cáo" và chúng tôi sẽ tìm kiếm sự trợ giúp từ các đồng nghiệp ở các bộ phận khác. Thật không may, có thể mất vài tuần hoặc thậm chí vài tháng để họ phản hồi. Và đôi khi, chúng tôi đã bỏ lỡ các nhận xét do có quá nhiều tác vụ sắp tới. Sau khi xác minh xong sự cố, chúng tôi đã chuyển sự cố sang trạng thái "Đang chờ khắc phục". Do tình trạng thiếu tài nguyên nhà phát triển thường xuyên, những yêu cầu này có thể vẫn chưa được giải quyết trong nhiều năm. Khách hàng đã không đóng vé, hy vọng rằng chúng tôi sẽ nhận được nhiều tài nguyên hơn trong tương lai. Công việc tồn đọng đáng kể dẫn đến trùng lặp. Thật khó để hợp nhất và đóng chúng vì chúng tôi thường phải cố gắng nhớ những nhiệm vụ nào đã được bắt đầu trong những năm trước. Cách tiếp cận được tổ chức kém này đã dẫn đến tồn đọng . 1.500 phiếu yêu cầu chưa được giải quyết trong hơn bốn năm Phương pháp STATIK và Kỳ công thứ sáu của Hercules Chúng tôi nhận ra rằng bộ phận của chúng tôi đã quá tập trung vào việc xử lý yêu cầu thay vì giải quyết mục đích cốt lõi là giải quyết các vấn đề của khách hàng: cải thiện lòng trung thành của họ đối với các sản phẩm của Social Discovery Group và phát hiện các lỗ hổng trong các dịch vụ và trang web của chúng tôi. Bạn có thể thắc mắc, "Tại sao không thuê thêm nhân viên nếu bạn không thể xử lý khối lượng công việc?" Tuy nhiên, kinh nghiệm đã chỉ ra rằng bằng cách thiết lập các quy trình hiệu quả, chúng ta có thể thực hiện mà không cần thêm nguồn lực. Tương tự như vậy, Hercules đã hoàn thành công việc của mình một mình bằng cách chuyển hướng dòng chảy của sông về phía chuồng ngựa của người Augean, nơi đã dọn sạch chúng chỉ trong một ngày. Để hợp lý hóa bảng yêu cầu của chúng tôi, chúng tôi đã tham khảo cuốn sách của Mike Burrows và triển khai phương pháp STATIK, một chiến lược có hệ thống để thực hiện phương pháp Kanban. "Kanban từ bên trong" Trong khi thực hiện phương pháp STATIK, chúng tôi đã làm theo sau: năm bước và kết luận rằng khách hàng cần hài lòng với sự hỗ trợ được cung cấp. Để làm được điều này, chúng ta cần đảm bảo những điều sau: 1. Chúng tôi đã xác định được kỳ vọng của khách hàng từ bộ phận Hỗ trợ Kinh doanh của mình Tính minh bạch trong công việc của chúng tôi đối với nhiệm vụ cho phép khách hàng hiểu điều gì đang xảy ra với các yêu cầu của họ tại bất kỳ thời điểm nào. Sự nhanh chóng trong công việc của chúng tôi đối với các nhiệm vụ, cung cấp thời gian dứt khoát để phản hồi trong bất kỳ trạng thái nào của vấn đề. Nguồn gốc bên trong là thứ cản trở chúng tôi và gây ra sự thất vọng trong công việc của chính chúng tôi. 2. Chúng tôi đã xác định cả nguồn gốc bên trong và bên ngoài của sự không hài lòng. Nguồn bên ngoài là thứ gây ra sự thất vọng cho khách hàng của chúng tôi và cản trở trải nghiệm của họ. Chúng tôi đã kiểm tra các yêu cầu được gửi đến bộ phận của chúng tôi và phân loại chúng theo bộ phận mà họ đến, tần suất của họ và kỳ vọng của khách hàng về thời gian phản hồi và giải pháp. 3. Chúng tôi đã phân tích nguồn gốc và bản chất khối lượng công việc của mình. Ở giai đoạn này, chúng tôi đã đánh giá mức độ hiệu quả của việc xử lý các yêu cầu và xác định số lượng nhiệm vụ mà chúng tôi có thể quản lý thực tế trong một tuần. 4. Chúng tôi đã đánh giá khả năng hiện tại của mình. Ngoài ra, chúng tôi đã tính toán thời gian trung bình cần thiết để bắt đầu bán vé cho đến khi phát hành bản sửa lỗi trong quá trình sản xuất. 5. Chúng tôi đã xây dựng lại vòng đời của vé và tạo một quy trình mới. Vòng đời vé ban đầu của chúng tôi Sử dụng những hiểu biết thu được, chúng tôi đã phát triển một vòng đời nhiệm vụ mới. Tiếp theo, chúng tôi đã triển khai một cách tiếp cận toàn diện để giải quyết tất cả các vấn đề đã đề cập trước đó. Chúng tôi đã thực hiện các bước sau: Chúng tôi đã tạo tập lệnh cho nhóm hỗ trợ của mình để lọc các tác vụ ở cấp độ ban đầu. Chúng tôi đã giới thiệu trạng thái "Quay lại trình báo cáo" tạm thời cho các nhiệm vụ yêu cầu thông tin đầu vào của khách hàng để điều tra sự cố. Nếu thông tin cần thiết không được cung cấp trong vòng ba ngày, nhiệm vụ sẽ tự động bị đóng. Chúng tôi đã xóa trạng thái "Đã báo cáo" và thay thế bằng trạng thái "Xác nhận sự cố" cụ thể hơn. Chúng tôi đã dành hơn hai tháng để xem xét và đóng các nhiệm vụ trùng lặp, khiến chúng tôi chỉ còn lại 800 vé duy nhất trong số 1.500 vé mà chúng tôi đã bắt đầu. Chúng tôi đã triển khai Thỏa thuận cấp độ dịch vụ (SLA) và đặt bộ hẹn giờ cho từng trạng thái. Trạng thái "Xác nhận sự cố" có bộ hẹn giờ là 7 ngày, trong khi trạng thái "Phát triển" có bộ hẹn giờ là 30 ngày. Việc có các nhiệm vụ ở trạng thái "Xác nhận sự cố" đã thúc đẩy chúng tôi gửi phản hồi cho đồng nghiệp của mình. Chúng tôi đã thay đổi phương pháp liên lạc của mình, sử dụng tin nhắn riêng tư hoặc chuỗi Slack thay vì bình luận trong Jira. Điều này làm giảm thời gian phản hồi xuống còn một ngày so với vài tuần trước đây. Mặc dù chúng tôi không đặt hẹn giờ ở trạng thái "Đang chờ khắc phục", nhưng chúng tôi đã phân bổ nhiều thời gian hơn cho việc trao đổi và thảo luận với khách hàng. Nếu một nhiệm vụ được coi là không khả thi, chúng tôi sẽ thông báo cho khách hàng và ưu tiên các nhiệm vụ quan trọng hơn. Điều này dẫn đến giảm 50% các tác vụ đang chờ xử lý. Ngoài ra, chúng tôi bắt đầu tổ chức các cuộc họp để khách hàng có thể giải thích tầm quan trọng của một nhiệm vụ, giúp chúng tôi ưu tiên khối lượng công việc của mình tốt hơn. Đối với trạng thái "Phát triển", chúng tôi đặt bộ hẹn giờ trong 30 ngày và giới hạn số nhiệm vụ ở trạng thái này là bốn. Điều này giúp chúng tôi tập trung vào việc sửa lỗi trong khung thời gian đã đặt và tránh bị choáng ngợp bởi tiếng ồn hình ảnh không cần thiết của 20-40 tác vụ ở trạng thái "Phát triển" trên bảng. Để đảm bảo các hoạt động của chúng tôi bền vững, chúng tôi đã áp dụng nguyên tắc phân vị thứ 90, nghĩa là 90% nhiệm vụ phải được hoàn thành đúng hạn, như được xác định bởi bộ hẹn giờ cho từng trạng thái. Chúng tôi đã theo dõi điều này bằng cách sử dụng Biểu đồ điều khiển của Jira và plugin Jira-helper để xây dựng phân vị thứ 90. Cuối cùng, chúng tôi đã giới thiệu thêm động lực cho đội, hứa hẹn một khoản tiền thưởng nếu nguyên tắc phần trăm thứ 90 được tuân theo, giống như Augeas đã hứa với Hercules một phần mười số ngựa của anh ấy như một phần thưởng. Bằng cách thực hiện cách tiếp cận mới này và xây dựng lại các quy trình của bộ phận, cuối cùng chúng tôi đã có thể giải quyết vấn đề đã đeo bám chúng tôi trong bốn năm dài. Giải pháp không yêu cầu thêm thời gian, công sức hay ngân sách, nhưng chúng tôi đã giảm đáng kể số lượng nhiệm vụ chồng chất. Chỉ trong năm tháng, với một nhóm chỉ gồm hai nhân viên thông minh, chúng tôi đã giảm được số lượng hàng đợi từ 1.500 vé xuống chỉ còn 150. Kinh nghiệm này đã dạy chúng tôi tầm quan trọng của việc xác định nguyên nhân cốt lõi của một vấn đề để giải quyết nó một cách hiệu quả. Nó cũng nhấn mạnh tầm quan trọng của việc có sẵn các quy trình được thiết kế tốt, vì các quy trình kém chắc chắn sẽ dẫn đến sự tích tụ của các vấn đề, như chúng tôi đã trực tiếp phát hiện ra. Viết bởi Dimitri Andrews, Kỹ sư kiểm thử phần mềm tại Social Discovery Group

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Developers: Build Less. Deliver More. [Learn how]	

Giải quyết vấn đề hỗ trợ khách hàng ổn định của Augean: Câu chuyện thành công của chúng tôi

dài quá đọc không nổi

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

Giải quyết vấn đề hỗ trợ khách hàng ổn định của Augean: Câu chuyện thành công của chúng tôi

dài quá đọc không nổi

Social Discovery Group

STORY’S CREDIBILITY

Guide

About Author

chuyên mục

Languages

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI...

NHỮNG BÀI VIẾT LIÊN QUAN