Cách tách vận hành hỗ trợ sự kiện khỏi phần mềm quản lý sự kiện, và thiết kế quy trình vận hành sự kiện cho các yêu cầu, ngoại lệ và escalation trực tiếp.
Phần mềm quản lý sự kiện có thể tổ chức đăng ký, chương trình, diễn giả, người tham dự và truyền thông. Nhưng điều đó không tự động vận hành được mảng hỗ trợ khi một người tham dự không vào được phiên, một phòng bị đổi hoặc một ngoại lệ có tác động lớn xuất hiện chỉ vài phút trước giờ quan trọng. Kế hoạch nằm trong một hệ thống. Những người đang cố giúp một người tham dự bối rối lại làm việc ở một hệ thống khác, thường với ít thông tin hơn mức họ cần.
Vận hành hỗ trợ sự kiện trong ngày diễn ra cần sáu thứ: kiến thức cập nhật, phủ kênh, triage, người sở hữu, escalation và khả năng quan sát. Bài viết này đi qua từng thứ như một yêu cầu mà đội vận hành có thể kiểm thử trước sự kiện, và kết thúc bằng một checklist sẵn sàng. Bài do GCT Solutions viết cho các đơn vị tổ chức sự kiện và trưởng nhóm hỗ trợ đã có nền tảng sự kiện và muốn lớp hỗ trợ xung quanh nó đứng vững dưới áp lực.
Lớp quản lý sự kiện ghi nhận và điều phối sự kiện đã lên kế hoạch: ai đã đăng ký, chương trình gồm những gì, diễn giả nào ở phòng nào. Lớp vận hành hỗ trợ xử lý các yêu cầu và ngoại lệ phát sinh so với kế hoạch đó: người tham dự làm mất link truy cập, phiên đã chuyển chỗ, nhu cầu tiếp cận mà không ai lường trước.
Sự phân biệt này hữu ích vì một đơn vị có thể đã có nền tảng sự kiện rất tốt mà vẫn vật lộn với hộp thư rời rạc, câu hỏi lặp lại và bàn giao thủ công. Mua phần mềm lập kế hoạch tốt hơn không giải quyết được những vấn đề đó, vì chúng nằm ở một lớp khác. Cvent, một trong những nhà cung cấp công nghệ sự kiện lớn nhất, nêu một ý liên quan trong hướng dẫn công nghệ sự kiện của họ: việc lập kế hoạch sự kiện trải qua nhiều đội, và hệ thống rời rạc hoặc cách tiếp cận một-cỡ-cho-tất-cả có thể làm tăng sự rối thay vì hiệu quả.
E-INNA, Trợ lý AI doanh nghiệp cho vận hành khách hàng của GCT, là một cách để vận hành lớp hỗ trợ này, như được mô tả trong bài của chúng tôi về E-INNA như một trợ lý AI doanh nghiệp cho vận hành khách hàng. Nó đứng cạnh nền tảng sự kiện và không thay thế đăng ký, bán vé hay các công cụ khác đang dùng. Trong ứng dụng này, một trợ lý có thể giúp kết nối kiến thức đã được duyệt, khả năng hiểu yêu cầu, định tuyến, escalation và các phản hồi có con người dẫn dắt.
Người tham dự và nhân sự cần câu trả lời dựa trên thông tin hiện hành, đã được duyệt. Một câu trả lời nhanh lấy từ thông tin lỗi thời là một thất bại vận hành, vì nó đưa người ta đến sai phòng một cách đầy tự tin. Vì vậy quy trình hỗ trợ cần biết nguồn nào sở hữu từng loại thông tin, lần rà soát gần nhất là khi nào, ai được cập nhật, các thay đổi khẩn được phân phối ra sao, và phải làm gì khi các nguồn mâu thuẫn nhau.
Điểm cuối thường bị bỏ ngỏ nhiều nhất. Chương trình trong ứng dụng sự kiện nói một đằng, chương trình in nói một nẻo, và một nhân sự trên sàn lại nghe một phiên bản thứ ba. Quyết định trước nguồn nào thắng, và một bản sửa đến được mọi kênh bằng cách nào, rẻ hơn nhiều so với việc phân xử ngay giữa một hàng người tham dự.
Một người tham dự có thể bắt đầu bằng email, tiếp tục trên chat và nói chuyện với một người tại chỗ. Hoạt động vận hành nên giữ lại câu hỏi, ngữ cảnh danh tính, hành động trước đó và người đang phụ trách hiện tại, ở mức mà quy tắc quyền riêng tư và thiết kế hệ thống cho phép. Thiếu ngữ cảnh đó, mỗi lần bàn giao đều là một lần bắt đầu lại. Người tham dự phải lặp lại vấn đề, và đội ngũ không thấy được liệu cùng một sự cố có đang lan ra nhiều người hay không.
Hãy xét một tình huống minh họa. Một người tham dự gửi email báo link phiên không hoạt động, rồi hỏi lại đúng điều đó trên chat hai mươi phút sau, rồi đi bộ tới bàn hỗ trợ. Nếu mỗi kênh giữ một bản ghi riêng, ba người đã mở ba cuộc điều tra. Nếu yêu cầu mang một mã định danh và một lịch sử duy nhất, người ở bàn hỗ trợ có thể thấy những gì đã thử và đi thẳng vào việc sửa.
Đến trước xử lý trước (FIFO) là chưa đủ vào lúc sự kiện lên đỉnh. Yêu cầu đến trước chưa chắc là yêu cầu quan trọng nhất, và người đang chờ mật khẩu Wi-Fi không nên chặn một mối lo về an toàn. Một mô hình hỗ trợ nên phân biệt ít nhất các loại yêu cầu sau, và quy tắc định tuyến cho từng loại phải được thống nhất với đơn vị tổ chức sự kiện.
Loại yêu cầu
Vì sao cần xử lý riêng
Người phụ trách điển hình (thống nhất theo từng sự kiện)
Yêu cầu thông tin thông thường
Trả lời được từ kiến thức đã duyệt; khối lượng lớn
Câu trả lời dựa trên kiến thức, luôn có người sẵn sàng
Vấn đề truy cập hoặc danh tính
Có thể chặn việc tham dự và liên quan dữ liệu cá nhân
Nhóm đăng ký hoặc truy cập
Thay đổi lịch và địa điểm
Gấp về thời gian và có thể ảnh hưởng nhiều người
Vận hành chương trình hoặc địa điểm
Nhu cầu tiếp cận (accessibility)
Thường cần phản hồi cá nhân hóa, cẩn thận
Đầu mối accessibility được chỉ định
Mối lo về an toàn hoặc an ninh
Phải đến tay một người ngay lập tức
An ninh hoặc quản lý tại chỗ
Ngoại lệ của diễn giả, nhà trưng bày hoặc VIP
Tác động lớn và nhạy cảm về quan hệ
Phụ trách tài khoản hoặc liên lạc diễn giả
Vấn đề ảnh hưởng nhiều người tham dự
Báo hiệu một vấn đề rộng hơn, không phải một ca đơn lẻ
Trưởng vận hành
AI có thể hỗ trợ phân loại, nhưng hoạt động vận hành cần quyền sở hữu và escalation rõ ràng cho từng nhóm. Một mô hình phân loại tốt chỉ hữu ích khi yêu cầu đã phân loại đến được người biết nó thuộc về mình.
Escalation nên chuyển đi nhiều hơn một thông báo. Người xử lý cần yêu cầu gốc, thông tin sự kiện liên quan, các hành động đã thực hiện và lý do ca được escalate. Một tin nhắn kiểu "người tham dự cần giúp đỡ" buộc người xử lý phải dựng lại tình huống trong lúc người tham dự đang chờ.
Quy trình cũng nên ghi lại hành động cuối cùng để các yêu cầu sau và báo cáo phản ánh đúng điều đã xảy ra. Nếu một lần đổi phòng được xử lý bởi một nhân sự đi dọc sàn thông báo, sự việc đó thuộc về bản ghi, vì người tiếp theo hỏi về cùng căn phòng sẽ được hưởng lợi từ nó. Văn phòng Ủy viên Thông tin Anh (ICO), trong hướng dẫn về AI và bảo vệ dữ liệu, coi trách nhiệm giải trình là điều các tổ chức nên có dù có dùng AI hay không. Quyền sở hữu rõ ràng của con người với các ca được escalate là một cách thực tế để thể hiện điều đó. Đây là thông tin chung, không phải tư vấn pháp lý.
Đội ngũ cần thấy được, khi sự kiện diễn ra, những yêu cầu nào đang mở và già đi, có ngoại lệ ưu tiên cao nào, chủ đề nào cứ lặp lại, khối lượng công việc chia theo kênh hay giai đoạn sự kiện ra sao, trạng thái escalation thế nào, và khoảng trống kiến thức nào đang tạo ra nhu cầu có thể tránh được. Góc nhìn này giúp hoạt động phản ứng trong lúc sự kiện và cải thiện trước sự kiện sau.
Mục cuối dễ bị đánh giá thấp. Khi cùng một câu hỏi đến bốn mươi lần, câu trả lời hiếm khi là thêm nhân sự. Thường đó là một biển chỉ dẫn rõ hơn, một câu viết tốt hơn trong ứng dụng người tham dự, hoặc một sửa đổi trên một trang. Khả năng quan sát biến một đống yêu cầu thành bằng chứng cho những cải tiến đó.
Công nghệ trong ngày diễn ra có thể hỏng. Mạng rớt, một tích hợp bị kẹt, một kênh nhắn tin bị giới hạn, một dịch vụ AI không khả dụng. Câu hỏi không phải là có gì đó hỏng hay không mà là đội ngũ làm gì khi nó hỏng. Một kế hoạch chế độ suy giảm (degraded-mode) xác định câu trả lời đó từ trước.
Kế hoạch có thể gồm thông tin quan trọng đã được cache, một hàng đợi thủ công, một đường liên lạc thay thế, escalation tại chỗ và một cách có kiểm soát để đối soát bản ghi sau khi hồi phục. Nó chỉ hữu ích nếu đã được diễn tập. Một kế hoạch chỉ tồn tại trong tài liệu, mà không ai từng luyện tập, thường thất bại đúng lúc nó lần đầu được cần đến.
Trước khi mở cửa, trưởng nhóm hỗ trợ có thể dùng các kiểm tra sau để xác nhận hoạt động đã sẵn sàng.
Kiến thức đã duyệt và người sở hữu của nó đã được xác nhận.
Các thay đổi khẩn có quy trình phân phối xác định.
Các nhóm yêu cầu và quy tắc escalation đã được kiểm thử.
Vai trò nhân sự và các điểm bàn giao đã được ghi lại.
Các kênh và tích hợp được giám sát.
Dữ liệu nhạy cảm chỉ được xử lý khi thật cần thiết.
Quy trình chế độ suy giảm đã được diễn tập.
Báo cáo và rà soát sau sự kiện đã có người phụ trách.
E-INNA là Trợ lý AI doanh nghiệp cho vận hành khách hàng của GCT. Nó giúp đưa một yêu cầu đi qua bốn giai đoạn: tương tác, hiểu yêu cầu, quyết định hoặc hành động, và kết quả. Hỗ trợ sự kiện là một ứng dụng phù hợp tự nhiên vì công việc trộn lẫn các câu hỏi lặp lại với những ngoại lệ gấp và các lần bàn giao giữa các đội.
Trên thực tế, E-INNA nhận ra cùng một người tham dự xuyên các kênh và giữ ngữ cảnh qua các phiên, điều giải quyết vấn đề bàn giao nêu ở Yêu cầu 2. Ý định được nhận diện bằng các quy tắc do đơn vị vận hành cấu hình. Lead và ticket được lưu trên dashboard E-INNA, nơi quản trị viên xây các luồng chuyển chúng đến đúng đội. Một người có thể duyệt câu trả lời trước khi gửi, tiếp quản cuộc trò chuyện rồi trả lại, giữ được sự kiểm soát của con người nêu ở Yêu cầu 4. Đơn vị vận hành vẫn quyết định ai sở hữu kiến thức, ca nào cần phán đoán của con người và các ngoại lệ khẩn được escalate ra sao. Chi tiết cho từng sự kiện cụ thể được thống nhất trong giai đoạn xác định phạm vi.
Bước đầu đúng đắn là lập bản đồ khối lượng hỗ trợ sự kiện và trách nhiệm vận hành trước khi chọn tính năng hay tích hợp. Nếu bạn muốn được hỗ trợ làm việc đó, hãy xem tổng quan của GCT Solutions về E-INNA hoặc trao đổi với đội ngũ GCT về E-INNA. Cách nghĩ tương tự về sự kiểm soát của con người cũng xuất hiện trong bài của chúng tôi về xây dựng quản trị AI vào trong hệ thống.
Hỗ trợ trong ngày sự kiện hiếm khi hỏng vì một sự cố kịch tính. Nó hỏng ở những khoảnh khắc nhỏ không có người phụ trách rõ ràng: một câu hỏi không ai chắc cách trả lời, một ngoại lệ nằm nhầm hàng đợi, một thay đổi đến một số kênh mà không đến kênh khác. Sáu yêu cầu trong bài chung một ý tưởng: đưa ra những quyết định đó từ trước, một cách bình tĩnh, thay vì ứng biến trước một hàng người tham dự.
Ý tưởng đó đúng với bất kỳ công cụ nào đứng sau bàn hỗ trợ. Công nghệ, kể cả AI, có thể làm một hoạt động đã được xác định rõ nhanh hơn và dễ nhìn thấy hơn, nhưng không thể tạo ra quyền sở hữu hay phán đoán chưa từng được giao. Những đội xử lý tốt nhất ngày diễn ra thường là những đội đã luyện tập sẵn cho tình huống mình bị sai.
E-INNA: Trợ lý AI doanh nghiệp cho vận hành khách hàng
Xây dựng quản trị AI vào trong hệ thống, không chỉ trong tài liệu chính sách
Khám phá thêm từ GCT Solutions tại trang chủ GCT Solutions, hoặc xem cách chúng tôi tiếp cận dịch vụ AI (AI services).
Quản lý sự kiện lập kế hoạch và ghi nhận sự kiện: đăng ký, chương trình, diễn giả và truyền thông. Vận hành hỗ trợ sự kiện xử lý các yêu cầu và ngoại lệ trực tiếp phát sinh so với kế hoạch đó, như vấn đề truy cập, thay đổi và các vấn đề gấp.
Vì mức độ khẩn và hậu quả không đi theo thứ tự đến. Một mối lo về an toàn hay một vấn đề ảnh hưởng nhiều người tham dự phải đến tay một người ngay lập tức, kể cả khi các yêu cầu đơn giản hơn đã đến trước.
Thông tin quan trọng đã cache, một hàng đợi thủ công, một đường liên lạc thay thế, escalation tại chỗ và một cách có kiểm soát để đối soát bản ghi sau đó. Kế hoạch cần được diễn tập trước sự kiện.
AI có thể giúp phân loại yêu cầu, truy xuất câu trả lời đã duyệt và soạn phản hồi, nhưng các ca nhạy cảm hoặc tác động lớn nên thuộc về những người chịu trách nhiệm. Quy tắc sở hữu và escalation phải do đơn vị vận hành xác định.
Cvent, Event technology timeline and day-of preparation (Dòng thời gian công nghệ sự kiện và chuẩn bị cho ngày diễn ra): https://www.cvent.com/en/resource/hospitality/event-tech-timeline
Văn phòng Ủy viên Thông tin Anh (ICO), Guidance on AI and data protection (Hướng dẫn về AI và bảo vệ dữ liệu): https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/