Theo dõi yêu cầu qua email: xây dựng bộ phận hỗ trợ đơn giản

Vì sao yêu cầu qua email khó quản lý

Email vẫn hiệu quả khi có ít yêu cầu và một người xử lý tất cả. Mọi việc bắt đầu rối lên khi nhiều người cùng dùng một hộp thư hoặc yêu cầu xuất hiện xen giữa các cuộc trò chuyện thông thường.

Hộp thư che khuất khối lượng công việc thực tế. Mười email mới có thể là mười việc nhỏ cần xử lý, hoặc một vấn đề khẩn cấp cùng chín câu hỏi thông thường. Người quản lý không thể biết ai phụ trách từng yêu cầu nếu phải mở từng chuỗi email.

Trách nhiệm cũng dễ bị bỏ sót. Một người có thể nghĩ đồng nghiệp sẽ trả lời vì lần trước họ đã xử lý yêu cầu tương tự. Sau một ngày bận rộn, tin nhắn có thể nằm im trong một chuỗi trả lời dài mà chưa ai đọc. Người gửi thấy không có phản hồi, trong khi đội ngũ lại nghĩ công việc đã có người lo.

Việc trả lời trùng lặp tạo ra một vấn đề khác. Hai người có thể trả lời cùng một câu hỏi với thông tin hơi khác nhau, khiến người gửi không biết nên làm theo câu trả lời nào. Cờ đánh dấu trong hộp thư hiếm khi giải quyết được việc này vì chúng thuộc về từng người dùng, không phải toàn đội.

Mức độ ưu tiên cũng dễ bị bỏ quên. Việc đặt lại mật khẩu có thể cần xử lý hôm nay, trong khi đề xuất cho một báo cáo trong tương lai có thể chờ. Trong hộp thư, cả hai email có thể trông cấp bách như nhau. Người nhắc nhiều nhất thường được chú ý trước, dù một yêu cầu khác có thời hạn gấp hơn.

Theo dõi yêu cầu qua email biến mỗi yêu cầu thành một hồ sơ công việc dùng chung. Mỗi hồ sơ cần có mô tả rõ ràng, một người phụ trách cụ thể, trạng thái hiện tại và thời hạn phản hồi hoặc hoàn tất.

Email không cần biến mất. Mọi người vẫn có thể dùng email khi phù hợp. Điểm thay đổi là đội ngũ ghi nhận các yêu cầu lặp lại ở một nơi và quản lý chúng như công việc thay vì những cuộc trò chuyện rời rạc. Một bộ phận hỗ trợ nội bộ đơn giản giúp hàng đợi trở nên rõ ràng, giảm việc trả lời trùng lặp và cho người gửi biết bước tiếp theo sẽ là gì.

Chọn những yêu cầu cần chuyển đổi trước

Hãy bắt đầu với những yêu cầu xuất hiện thường xuyên và đi theo một quy trình quen thuộc. Những email này dễ biến mất trong các chuỗi trao đổi dài, bị chuyển tiếp nhiều lần hoặc bị chờ xử lý vì không ai biết ai phụ trách.

Xem lại lưu lượng hộp thư trong vài tuần. Những nhóm phù hợp thường gồm yêu cầu cấp quyền truy cập vào công cụ dùng chung hoặc tài khoản khách hàng, yêu cầu thiết bị và giấy phép phần mềm, vấn đề của khách hàng cần đội ngũ khác hỗ trợ, phê duyệt mua sắm và các thay đổi định kỳ như cập nhật thông tin liên hệ hoặc thêm thành viên vào đội ngũ.

Với mỗi loại yêu cầu, hãy quyết định ai xử lý và họ cần hành động trong bao lâu. Yêu cầu cấp quyền có thể được chuyển đến bộ phận CNTT và cần phản hồi trong ngày. Phê duyệt mua sắm có thể chuyển cho quản lý và cần vài ngày làm việc. Cách này ngăn mọi yêu cầu dồn vào một hàng đợi không có người phụ trách.

Giữ phiên bản đầu tiên ở quy mô nhỏ. Chọn từ hai đến bốn loại yêu cầu có người phụ trách rõ ràng, các bước lặp lại và đủ số lượng để đáng tạo biểu mẫu. Một đội hỗ trợ có thể bắt đầu với việc chuyển cấp vấn đề của khách hàng, cấp quyền tài khoản và phê duyệt hoàn tiền thay vì cố đưa mọi email của công ty vào hệ thống.

Ban đầu, hãy để các trường hợp hiếm gặp, bất thường hoặc nhạy cảm trong email. Một câu hỏi pháp lý chỉ phát sinh một lần hoặc yêu cầu cần thảo luận dài không phù hợp với quy trình cố định. Hãy thêm loại yêu cầu mới khi cùng một mô hình xuất hiện thường xuyên.

Viết quy trình bằng ngôn ngữ đơn giản trước khi xây dựng. Nêu rõ đội ngũ tiếp nhận, mức độ khẩn cấp dự kiến và hành động đầu tiên. Câu «CNTT xem xét yêu cầu cấp quyền trong vòng một ngày làm việc» giúp mọi người biết phải làm gì. Câu «CNTT xử lý việc cấp quyền» thì không.

AppMaster có thể giúp các đội ngũ biến những yêu cầu lặp lại thành biểu mẫu nội bộ và hồ sơ được theo dõi mà không yêu cầu nhân viên không chuyên về kỹ thuật tự xây dựng ứng dụng từ đầu. Hãy bắt đầu với những công việc vốn đã tạo ra nhiều email lặp lại, sau đó mở rộng khi các quy trình đầu tiên hoạt động ổn định.

Biến email thành biểu mẫu hữu ích

Một biểu mẫu ngắn thu thập những thông tin đội ngũ cần trước khi bắt đầu xử lý. Biểu mẫu không nên giống một hồ sơ đăng ký dài. Nếu một yêu cầu đơn giản mất mười phút để gửi, mọi người sẽ quay lại dùng email.

Hãy bắt đầu với những thông tin nhân viên thường xuyên phải hỏi thêm qua email. Một yêu cầu thiết bị có thể cần tên người yêu cầu, phòng ban, loại thiết bị, địa điểm giao và ngày cần. Bỏ qua những trường không ảnh hưởng đến công việc. Số điện thoại không mang lại nhiều giá trị nếu người gửi đã nhận cập nhật qua bộ phận hỗ trợ.

Dùng danh sách lựa chọn cho những câu trả lời lặp lại, chẳng hạn loại yêu cầu, đội ngũ phụ trách, mức độ khẩn cấp và địa điểm. Các lựa chọn giúp yêu cầu nhất quán và dễ sắp xếp hơn. Hãy dùng tên gọi giống với cách mọi người giao tiếp tại nơi làm việc. Nếu không biết nên chọn «hỗ trợ hệ thống» hay «sự cố kỹ thuật», người dùng sẽ lại gặp đúng vấn đề của hộp thư.

Chỉ hiển thị câu hỏi bổ sung khi cần

Các loại yêu cầu khác nhau cần những thông tin khác nhau. Trường có điều kiện giúp biểu mẫu ngắn gọn mà không buộc mọi người trả lời những câu hỏi không liên quan.

Yêu cầu cấp quyền có thể hỏi tên ứng dụng, cấp độ truy cập, phê duyệt của quản lý và ngày kết thúc quyền truy cập. Yêu cầu cơ sở vật chất có thể hỏi số phòng, loại sự cố và sự cố có ảnh hưởng đến an toàn hay không.

Chỉ bắt buộc những thông tin cần thiết để bắt đầu công việc. Hãy làm rõ trường không bắt buộc. Trường văn bản tự do sẽ hữu ích nếu có câu hỏi cụ thể như «Điều gì đã xảy ra và sự cố bắt đầu từ khi nào?». Một trường trống có tên «Mô tả» thì không giúp người dùng biết cần viết gì.

Xác nhận yêu cầu rõ ràng

Sau khi gửi, hãy cho người gửi biết yêu cầu đã được tiếp nhận như thế nào. Hiển thị mã yêu cầu, loại yêu cầu, đội ngũ tiếp nhận và thời gian phản hồi đầu tiên dự kiến nếu đội ngũ có quy định.

Ví dụ: «Yêu cầu SR-1042 đã được gửi đến bộ phận Cấp quyền CNTT. Đội ngũ sẽ xem xét trong vòng một ngày làm việc. Hãy thêm thông tin mới vào yêu cầu này thay vì gửi email riêng.»

Ứng dụng no-code có thể tập hợp các biểu mẫu tiếp nhận trong một cổng thông tin dùng chung và chuyển từng yêu cầu đến đúng hàng đợi. Nhờ đó, nhân viên có nhiều thời gian giải quyết yêu cầu hơn thay vì phải giải mã email.

Thiết lập quy tắc phân công dễ thực hiện

Một yêu cầu khó bị bỏ qua hơn khi có một hồ sơ và một người phụ trách cụ thể. Hãy tạo hồ sơ cho mọi lần gửi biểu mẫu, kể cả khi hai người báo cáo cùng một vấn đề. Mỗi hồ sơ cần có lịch sử, trạng thái và thời hạn riêng.

Đừng chỉ giao việc cho một hộp thư chung như «đội CNTT» hoặc «Vận hành». Mọi người có thể nhìn thấy yêu cầu, nhưng không ai biết mình phải hành động. Hãy giao cho một người cụ thể. Người đó có thể nhờ hỗ trợ, nhưng vẫn chịu trách nhiệm đưa yêu cầu tiến lên hoặc bàn giao rõ ràng.

Ví dụ, yêu cầu cấp quyền có thể được giao cho Priya ở bộ phận CNTT. Nếu Priya cần quản lý phê duyệt, cô ấy vẫn phải theo dõi việc phê duyệt được gửi đến và cập nhật cho người yêu cầu.

Mỗi hồ sơ nên có tên và thông tin liên hệ của người gửi, loại yêu cầu, ngày giờ gửi, người phụ trách, người thay thế và trạng thái hiện tại. Hãy đặt người thay thế khi tạo loại yêu cầu, thay vì chờ đến lúc có người vắng mặt. Người thay thế cần đủ quyền truy cập và thông tin để trả lời, phân công lại hoặc đóng yêu cầu.

Việc bàn giao cũng cần rõ ràng như vậy. Nếu yêu cầu chuyển từ Nhân sự sang CNTT, người phụ trách đầu tiên phải giao cho một người cụ thể, thêm ghi chú ngắn về những việc đã diễn ra và cập nhật trạng thái. Người nhận mới phải xác nhận bàn giao. Chỉ thay đổi trạng thái không cho thấy đã có ai nhìn thấy công việc.

AppMaster có thể mô hình hóa hồ sơ với các trường về người phụ trách, người thay thế, thời gian gửi, loại yêu cầu và trạng thái. Công cụ quy trình trực quan của nền tảng có thể chuyển biểu mẫu đến đúng nơi theo các quy tắc đội ngũ đặt ra. Hãy xem các yêu cầu chưa được phân công mỗi ngày làm việc để khoảng trống trong quy trình không khiến công việc bị chờ qua đêm.

Dùng trạng thái cho thấy công việc đang diễn ra thế nào

Giữ danh sách trạng thái ban đầu ngắn gọn: mới, đang xử lý, đang chờ, đã giải quyết và đã đóng. Các nhãn này cho người gửi biết tình hình và giúp đội ngũ nhận ra công việc cần chú ý.

Yêu cầu mới đã vào bộ phận hỗ trợ nhưng chưa có ai tiếp nhận. Chuyển sang đang xử lý khi một người nhận trách nhiệm và bắt đầu làm việc. Đánh dấu đã giải quyết khi đội ngũ hoàn tất công việc và thông báo cho người gửi. Đóng yêu cầu sau khi người gửi xác nhận kết quả hoặc khi thời gian xem xét do đội ngũ công bố đã kết thúc.

Làm rõ trạng thái đang chờ

«Đang chờ» cần cho biết vì sao công việc tạm dừng và ai phải hành động tiếp theo. Ban đầu, một trạng thái đang chờ có thể đủ nếu hồ sơ ghi rõ lý do, chẳng hạn «đang chờ người gửi» hoặc «đang chờ bộ phận an ninh CNTT».

Khi số lượng tăng, hãy tách trạng thái chờ người gửi và chờ đội ngũ khác. Người phụ trách cần nhắc người gửi chưa cung cấp tên, phê duyệt, ảnh chụp màn hình hoặc thông tin còn thiếu. Yêu cầu chờ đội ngũ khác có thể cần được đẩy cấp nội bộ. Không yêu cầu nào nên biến mất khỏi tầm nhìn.

Viết một quy tắc ngắn cho từng trạng thái. Thành viên đội ngũ chuyển yêu cầu từ mới sang đang xử lý khi nhận việc. Họ chuyển sang đang chờ khi cần câu trả lời hoặc hành động từ bên ngoài. Họ chuyển sang đã giải quyết khi hoàn tất công việc và giải thích kết quả.

Tránh thêm các nhãn như «đang xếp hàng», «đã giao» hoặc «đang điều tra» trừ khi chúng dẫn đến một quyết định hằng ngày khác. Quá nhiều lựa chọn tạo ra các cập nhật thiếu nhất quán và khiến người gửi bối rối.

Tạo mục tiêu thời gian phản hồi phù hợp với công việc

Mục tiêu thời gian phản hồi cho người gửi biết khi nào họ có thể mong đợi câu trả lời. Mục tiêu cũng giúp đội ngũ sắp xếp công việc trước khi hàng đợi biến thành một đống email được cho là khẩn cấp.

Đặt mục tiêu khác nhau cho từng loại yêu cầu. Tài khoản bị khóa có thể cần phản hồi trong một giờ, trong khi yêu cầu tạo báo cáo mới có thể chờ đến ngày làm việc tiếp theo. Đặt cùng một thời hạn cho mọi yêu cầu khiến việc thường ngày trông có vẻ khẩn cấp và khiến vấn đề thực sự cấp bách phải chờ.

Tách phản hồi đầu tiên khỏi việc hoàn tất yêu cầu

Hãy theo dõi hai mốc thời gian. Phản hồi đầu tiên đo tốc độ một người xác nhận đã nhận trách nhiệm hoặc hỏi thông tin còn thiếu. Thời gian giải quyết đo khoảng thời gian đội ngũ cần để hoàn thành công việc.

Phản hồi nhanh không có nghĩa là yêu cầu đã hoàn tất. Người yêu cầu quyền truy cập phần mềm có thể nhận được phản hồi trong vòng hai giờ: «Tôi đã nhận yêu cầu này và cần phê duyệt của quản lý.» Toàn bộ yêu cầu có thể mất hai ngày làm việc vì việc phê duyệt và tạo tài khoản cần các bước riêng.

Hãy đặt mục tiêu mà đội ngũ có thể đáp ứng. Ví dụ:

• Cấp quyền hoặc tài khoản bị khóa: phản hồi đầu tiên trong 1 giờ làm việc, giải quyết trong 8 giờ làm việc
• Vấn đề về lương hoặc khách hàng: phản hồi đầu tiên trong 4 giờ làm việc, giải quyết trong 2 ngày làm việc
• Yêu cầu thiết bị hoặc báo cáo tiêu chuẩn: phản hồi đầu tiên trong 1 ngày làm việc, giải quyết trong 5 ngày làm việc
• Yêu cầu thay đổi theo kế hoạch: phản hồi đầu tiên trong 2 ngày làm việc, thống nhất ngày giải quyết sau khi xem xét

Xác định rõ giờ làm việc, gồm ngày làm việc, giờ văn phòng và ngày nghỉ. Yêu cầu gửi vào cuối ngày thứ Sáu không nên bị xem là quá hạn vào thứ Bảy khi không có ai làm việc cuối tuần.

Hãy cảnh báo người phụ trách trước khi thời hạn kết thúc. Lời nhắc khi đã sử dụng 75% hoặc 80% thời gian cho phép giúp họ có cơ hội cập nhật cho người gửi, nhờ hỗ trợ hoặc phân công lại công việc. Cập nhật rõ ràng thường ngăn những email hỏi lại không cần thiết.

Trong AppMaster, đội ngũ có thể lưu loại yêu cầu, mức độ khẩn cấp, người phụ trách, trạng thái và thời hạn mục tiêu trong một ứng dụng no-code. Quy trình nghiệp vụ có thể tính thời hạn dựa trên loại yêu cầu đã chọn và cảnh báo người phụ trách khi thời hạn sắp đến. Hãy điều chỉnh mục tiêu sau vài tuần dựa trên dữ liệu yêu cầu thực tế.

Ví dụ: xử lý yêu cầu cấp quyền

Một điều phối viên kinh doanh mới cần quyền truy cập công cụ bán hàng của đội ngũ trước thứ Hai. Thay vì gửi email đến hộp thư chung, họ điền biểu mẫu của bộ phận hỗ trợ nội bộ. Yêu cầu nhận được một mã tham chiếu để cả nhân viên và đội hỗ trợ có thể tìm lại sau này.

Biểu mẫu hỏi tên nhân viên và email công việc, công cụ bán hàng và cấp độ truy cập, phòng ban, tên quản lý và ngày cần quyền truy cập.

Bộ phận hỗ trợ chuyển yêu cầu đến đội hỗ trợ vận hành và giao cho một người phụ trách cụ thể. Nếu vai trò nhạy cảm, quy trình sẽ gửi nhiệm vụ phê duyệt đến quản lý của nhân viên.

Người phụ trách xác nhận yêu cầu trong vòng bốn giờ làm việc: «Yêu cầu của bạn đang chờ quản lý phê duyệt. Chúng tôi sẽ cập nhật khi nhận được phản hồi.» Trạng thái chuyển thành đang chờ, với lý do được ghi là chờ phê duyệt. Bộ phận hỗ trợ có thể nhắc quản lý sau một khoảng thời gian nhất định, còn người phụ trách vẫn chịu trách nhiệm về yêu cầu.

Sau khi được phê duyệt, người phụ trách cấp đúng vai trò và đưa yêu cầu về trạng thái đang xử lý để nhân viên kiểm tra quyền truy cập. Khi nhân viên xác nhận có thể đăng nhập và nhìn thấy đúng quyền, người phụ trách giải quyết rồi đóng yêu cầu. Nếu có vấn đề, hồ sơ đó vẫn được mở. Không ai cần tìm lại các chuỗi email cũ.

Những sai lầm khiến yêu cầu bị bỏ sót

Bộ phận hỗ trợ vẫn có thể làm mất công việc nếu các quy tắc tạo ra nhiều nỗ lực hơn hộp thư cũ. Biểu mẫu dài, trách nhiệm không rõ ràng và đóng yêu cầu quá sớm là những nguyên nhân phổ biến.

Đừng đưa mọi chi tiết email vào biểu mẫu. Với yêu cầu cấp quyền, đội ngũ thường chỉ cần tên hệ thống, cấp độ truy cập, người cần quyền và lý do. Trường tiêu đề email dài hoặc địa chỉ liên hệ trùng lặp không mang lại nhiều giá trị. Chỉ hiển thị câu hỏi bổ sung khi loại yêu cầu cần chúng.

Một nhóm có thể nhận yêu cầu, nhưng một người phải chịu trách nhiệm cho hành động tiếp theo. Nếu cần hỗ trợ, họ có thể phân công lại. Không nên để yêu cầu chưa được giao trong khi chờ câu trả lời. Chế độ xem hằng ngày về công việc chưa phân công và quá hạn sẽ phát hiện vấn đề trước khi người gửi phải đuổi theo đội ngũ qua email.

Đừng giải quyết yêu cầu khi đội ngũ mới chỉ hoàn tất một nhiệm vụ nội bộ. Quản trị viên có thể đã tạo tài khoản, nhưng yêu cầu vẫn phải mở cho đến khi người dùng nhận được hướng dẫn truy cập hoặc xác nhận có thể đăng nhập.

Mục tiêu thời gian cũng thất bại khi phản ánh khối lượng công việc lý tưởng thay vì nhân lực thực tế. Lời hứa phản hồi trong một giờ cho mọi yêu cầu sẽ tạo ra các thời hạn bị bỏ lỡ nếu một đội hỗ trợ nhỏ còn phải xử lý những nhiệm vụ khác. Hãy dựa mục tiêu vào nhu cầu gần đây và số giờ có thể làm việc, sau đó xem xét các trường hợp trễ trong vài tuần đầu. Khắc phục việc chậm trễ lặp lại bằng cách đơn giản hóa biểu mẫu, bổ sung người hỗ trợ hoặc thay đổi mục tiêu thành mức đội ngũ có thể đáp ứng ổn định.

Kiểm tra nhanh trước khi triển khai

Hãy thử nghiệm quy trình với một nhóm nhỏ trước khi biến nó thành cách tiếp nhận yêu cầu thông thường. Kiểm tra các yêu cầu thực tế từ đầu đến cuối.

Mỗi hồ sơ mới cần có một người cụ thể chịu trách nhiệm cho hành động tiếp theo. Nếu yêu cầu chờ phê duyệt, hãy giữ người phụ trách ban đầu ở trạng thái hiển thị và ghi rõ ai phải phản hồi. Sau vài ngày, bạn cần trả lời được ba câu hỏi mà không phải mở một chuỗi email dài: ai phụ trách, yêu cầu đang ở trạng thái nào và khi nào cần hành động?

Viết định nghĩa ngắn bên cạnh từng trạng thái. Nhờ hai hoặc ba nhân viên phân loại cùng một nhóm yêu cầu mẫu. Nếu họ chọn các trạng thái khác nhau, hãy sửa lại định nghĩa thay vì mong mọi người tự đoán.

Mỗi tuần, xem xét các yêu cầu quá hạn và đang chờ. Tìm trường thông tin mọi người thường bỏ trống, nhiệm vụ luôn cần phê duyệt hoặc đội ngũ đang nhận nhiều việc hơn khả năng xử lý. Lời nhắc hiếm khi tự giải quyết được một sự chậm trễ lặp lại.

Hỏi người gửi xem biểu mẫu có rõ ràng không. Nếu họ liên tục gửi email bổ sung tên ứng dụng, cấp độ truy cập, quản lý hoặc ngày cần, hãy thêm hoặc làm rõ các trường đó.

Đưa bộ phận hỗ trợ vào sử dụng hằng ngày

Hãy bắt đầu với một đội ngũ và một loại yêu cầu thường xuyên, chẳng hạn quyền truy cập phần mềm, thiết bị hoặc vấn đề cơ sở vật chất. Bản phát hành đầu tiên có phạm vi giới hạn giúp mọi người có thời gian làm quen với biểu mẫu và giúp đội ngũ tìm ra khoảng trống trong thực tế.

Cho người gửi biết nơi gửi yêu cầu và cần cung cấp thông tin gì. Giữ hộp thư chung cũ trong một thời gian chuyển tiếp ngắn, nhưng yêu cầu nhân viên thêm các yêu cầu qua email vào bộ phận hỗ trợ để mọi việc đều có người phụ trách và trạng thái. Sau đó, đưa biểu mẫu thành kênh chính thức.

Xem lại hồ sơ của tháng đầu tiên. Xóa những trường mọi người không dùng, tìm hiểu các danh mục thường dẫn đến việc phân công lại và điều chỉnh những mục tiêu không phù hợp với nỗ lực thực tế. Chỉ thêm câu hỏi khi câu trả lời làm thay đổi người xử lý hoặc việc họ cần làm.

Một bảng điều khiển đơn giản giúp quản lý hằng ngày. Theo dõi yêu cầu mới theo loại, thời gian phản hồi đầu tiên và hoàn tất, công việc đang mở theo người phụ trách và trạng thái, các mục quá hạn và yêu cầu được mở lại. Trao đổi về các số liệu trong một buổi xem xét ngắn mỗi tuần. Nếu yêu cầu cấp quyền thường trễ vì chỉ một quản lý phê duyệt tất cả, hãy thêm người phê duyệt thay thế hoặc thay đổi quy trình.

AppMaster hỗ trợ bộ phận hỗ trợ nội bộ no-code với biểu mẫu tiếp nhận, quy trình phân công, quy tắc trạng thái và bảng điều khiển trong cùng một ứng dụng. Đội ngũ có thể cung cấp quyền truy cập trên web và xây dựng ứng dụng di động native khi nhân viên cần gửi hoặc cập nhật yêu cầu ngoài bàn làm việc.

Tiếp tục cải thiện quy trình sau khi triển khai. Hỏi người gửi xem biểu mẫu có dễ hiểu không, đồng thời hỏi những người xử lý yêu cầu xem công việc còn bị mắc ở đâu. Những thay đổi nhỏ dựa trên hồ sơ thực tế sẽ giúp bộ phận hỗ trợ luôn hữu ích thay vì biến thành một hộp thư khác.