Basic và Professional một cách chi tiết. Professional bao gồm mọi thứ có trong Basic – và không giới hạn. Bảng dưới đây trình bày từng tính năng của cả hai giấy phép trong một cái nhìn.
Tính năng
Basic
Professional
Tùy chỉnh & quản trị
Đa ngôn ngữ: bật được 30 ngôn ngữ; việc dịch chạy qua xuất và nhập một tệp JSON – nhờ vậy bạn có đúng cách dùng từ mà công ty mình hiểuHướng dẫn
Thương hiệu riêng: logo, favicon, bảng màuHướng dẫn
Chế độ tối / chế độ sáng, thiết kế co giãn theo màn hìnhHướng dẫn
Định dạng ngày và giờ của bản cài đặt là do bạn chọn – thứ tự, ký tự ngăn cách và cách xem giờ 24 hay 12 tiếngHướng dẫn
Thông báo bảo trì và sự cố cho tất cả mọi người – trên trang đăng nhập, tùy ý gửi thêm qua e-mailHướng dẫn
chỉ trang đăng nhập
trang đăng nhập + e-mail
Cảnh báo sớm trước khi đĩa đầy: một thông báo từ 90%, một cảnh báo từ 95% – ai lo việc cập nhật thì thấy các con số và thấy phải làm gì, người đang đăng nhập nhận một câu ngắn; không có gì trong số đó hiện trên trang đăng nhậpHướng dẫn
Lưu trữ những ticket đã đóng (kèm khôi phục) – giữ cho khối dữ liệu đang làm việc nhỏ lại, ví dụ bằng cách đưa một năm cũ vào kho lưu trữHướng dẫn
Cập nhật chỉ bằng một nút bấm – hệ thống tạo một bản sao lưu trước (dữ liệu, tệp đính kèm, kho lưu trữ) và kiểm tra xem còn đủ dung lượng đĩa hay không; nếu không đủ, nó từ chối cập nhật kèm lý do thay vì hỏng giữa chừngHướng dẫn
Xuất và nhập các danh sách dữ liệu gốc của bạn dưới dạng JSON – bộ phận, chức danh, địa điểm và danh mục; điền một lượt thay vì gõ từng dòngHướng dẫn
Gửi qua SMTP (thông báo, thư trả lời tự động)Hướng dẫn
Quy trình e-mail với điều kiện & thao tácHướng dẫn
Mỗi nhóm có thể có hộp thư riêng. Thư gửi tới hộp thư đó tạo một ticket trong nhóm ấyHướng dẫn
Danh sách chặn e-mail: chặn từng địa chỉ hoặc cả tên miền – người gửi bị chặn thì không tạo ticket, và cũng không có thư trả lời nào gửi tới họHướng dẫn
Thư trả lời tự động và mẫu e-mail đa ngôn ngữHướng dẫn
Xác thực & bảo mật, gồm cả Single sign-on
Đăng nhập cục bộ (tên người dùng/mật khẩu) + JWT; đăng nhập hai yếu tố (TOTP kèm mã khôi phục) là tùy chọn – tắt, bắt buộc chỉ với người dùng nội bộ, hoặc bắt buộc với tất cả mọi ngườiHướng dẫn
Single sign-on qua OIDC (OpenID Connect) / OAuth2 và SAML 2.0 – kết nối những nhà cung cấp như Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 hay ADFS – cùng LDAP / Active Directory và LINE, Kakao, Naver, WeChat, WeCom và DingTalkHướng dẫn
Ở lần đăng nhập Single sign-on đầu tiên, tài khoản được tạo tự động (với vai trò khách hàng, không dùng chỗ người dùng nội bộ nào); mọi lần đăng nhập Single sign-on đều được ghi lạiHướng dẫn
Quản lý ticket
Tạo và sửa ticket; việc xóa chỉ diễn ra qua kho lưu trữHướng dẫn
Trình soạn văn bản định dạng: hiện hình ảnh chèn trong nội dung và liên kết (phần mô tả & bình luận)Hướng dẫn
Tệp đính kèm kèm phần xem trước (trình đọc PDF, phóng to hình ảnh, tối đa 50 MB mỗi tệp)Hướng dẫn
Quy trình trạng thái với trạng thái và bước chuyển cấu hình đượcHướng dẫn
Mức ưu tiên, trạng thái, vai trò, địa điểm, chức danh và bộ phận đều cấu hình đượcHướng dẫn
Danh mục chính và danh mục con cấu hình được tự do cho từng nhómHướng dẫn
Ticket đã vào bằng đường nào: hệ thống tự nhận ra cổng thông tin khách hàng và e-mail (e-mail cần Professional). Điện thoại và do nhân viên xử lý tạo thì nhân viên xử lý nhập vàoHướng dẫn
Ticket chuyển cấp được sang nhóm khác – dù vậy nhân viên xử lý vẫn nắm được toàn cảnhHướng dẫn
Trường tùy chỉnh tạo được theo từng nhóm (chữ, số, ngày, có/không …) và đánh dấu được là bắt buộc – tùy ý chỉ áp cho từng mẫu ticket riêngHướng dẫn
Người theo dõi: nhận e-mail mỗi khi một ticket được cập nhậtHướng dẫn
Trạng thái nhân viên xử lý (tình trạng sẵn sàng)
Sẵn sàng / Bận / Vắng mặt – nhân viên xử lý tự đặt, và khi giao ticket thì mọi người thấy ai đang không sẵn sàngHướng dẫn
Quản trị viên ghi nhận nghỉ ốm hay nghỉ phép, kèm một ngày “vắng mặt tới”Hướng dẫn
“Bận” tự đặt lại thành sẵn sàng sau một giờHướng dẫn
Không có lịch sử tình trạng sẵn sàng, không có đánh giá theo từng ngườiHướng dẫn
Tự động giao ticket
Khi bật lên: ticket mới được giao tự động cho một thành viên của nhóm ngay khi được tạo – nhân viên xử lý hoặc quản trị viênHướng dẫn
Luân phiên hay ít việc nhất – theo từng nhóm, mặc định tắtHướng dẫn
Những nhân viên xử lý đang bận hoặc vắng mặt thì bị bỏ quaHướng dẫn
Cũng áp cho ticket từ hộp thư đến; ticket do một con người giao thì không bao giờ bị đụng tới, và mọi lần giao tự động đều được ghi vào lịch sử ticketHướng dẫn
Báo cáo: ai đã nhận bao nhiêu ticket – và bao nhiêu lần không ai sẵn sàngHướng dẫn
Yêu cầu kèm công việc & phê duyệt
Một yêu cầu là một ticket tự tạo ra các công việc của nó – mỗi mục một ticket, trong nhóm phụ trách nó; phê duyệt thì có thể có, nhưng không bắt buộcHướng dẫn
Người yêu cầu đánh dấu cái mình cần ngay khi tạo yêu cầuHướng dẫn
Tiến độ của yêu cầu: “3 trên 5 đã xong” – mỗi công việc kèm nhóm, người được giao và một cú nhấp vào ticket của nóHướng dẫn
Một lần phê duyệt cho cả yêu cầu – một bức thư thay vì nhiều lần duyệt từng phầnHướng dẫn
Một bước phê duyệt thêm cho từng công việc nhạy cảmHướng dẫn
Người phê duyệt quyết định qua một liên kết có thời hạn gửi bằng e-mail. Họ không cần tài khoản trong hệ thống ticketHướng dẫn
Các công việc vẫn bị khóa cho tới khi có phê duyệtHướng dẫn
Lời nhắc cho những lần phê duyệt còn treo – không bao giờ có chuyện quá hạn thì coi như đã duyệtHướng dẫn
Một lời từ chối tới tay người yêu cầu, kèm lý do đã nêuHướng dẫn
Dấu vết kiểm toán trên ticket: ai quyết định khi nào, với bình luận nàoHướng dẫn
Người phê duyệt đang nghỉ phép? Một quản trị viên chuyển yêu cầu sang người khác – mọi thay đổi đều được ghi lạiHướng dẫn
Mẫu trả lời & mẫu ticket
Mẫu trả lời: phần chữ + thao tác trên trường (trạng thái, việc giao, mức ưu tiên …) trong một lần chọnHướng dẫn
Các thao tác được gợi ý có thể bỏ chọn từng cái trước khi gửiHướng dẫn
Chỗ giữ chỗ (người yêu cầu, số ticket, tiêu đề …) – chèn mẫu vào là các giá trị thật đi vào phần chữ, trước khi có gì được gửi điHướng dẫn
Câu trả lời có thể được gửi thêm dưới dạng e-mail tới người yêu cầu – chỉ việc gửi mới cần kênh thư; tệp đính kèm của mẫu thì được thêm vào ticket ở mọi phiên bảnHướng dẫn
Mẫu ticket mở được cho khách hàng theo từng mẫu — một ticket tới nơi đã đủ thông tin có thể rút ngắn thời gian xử lýHướng dẫn
Mỗi lần dùng đều truy vết được trong lịch sử ticketHướng dẫn
Tự động hóa & nhắc việc
Nhắc việc trên một ticket bằng tay (ngày + ghi chú, bộ lọc Hôm nay/Tuần này/Quá hạn)Hướng dẫn
Quy tắc theo thời gian – phản ứng với sự VẮNG MẶT của một hành độngHướng dẫn
Trình dựng quy tắc KHI/NẾU/THÌ với một câu lời thường chạy theoHướng dẫn
Có sẵn bốn quy tắc ví dụ (tắt khi cài đặt, bạn thích cái nào thì bật cái đó)Hướng dẫn
Xem trước trước khi bật: hiện ra ngay lúc này quy tắc sẽ ảnh hưởng tới những ticket nào – mà không đổi gì cảHướng dẫn
Thao tác: e-mail, trạng thái, mức ưu tiên, giao việc, chuyển sang nhóm khác, đặt nhắc việcHướng dẫn
Khoảng thời gian chọn được theo từng điều kiện: theo giờ làm việc và ngày làm việc lấy từ lịch của nhóm – hoặc chạy suốt ngày đêmHướng dẫn
Nhật ký cho từng quy tắc + tên quy tắc làm tác giả trong lịch sử ticketHướng dẫn
Hạn mức lượt chạy hằng tháng
không giới hạn
không giới hạn
Thao tác hàng loạt trên danh sách ticket
Đổi trạng thái của nhiều ticket cùng lúc – những trường khác thì qua một mẫu trả lờiHướng dẫn
Nhiều ticket giao được cho một nhân viên xử lý cùng lúcHướng dẫn
Mẫu trả lời áp dụng được cho nhiều ticket cùng lúc – chỗ giữ chỗ được thay theo từng ticketHướng dẫn
Xem trước trước khi chạy và một kết quả sau đó: thao tác áp cho bao nhiêu ticket trong số đã chọn và vì sao từng ticket bị bỏ qua – những ticket bị bỏ qua vẫn ở lại trong lựa chọnHướng dẫn
Thư gửi những người yêu cầu mặc định là tắt; bật lên thì hộp thoại nêu nó sẽ tới bao nhiêu người nhậnHướng dẫn
Mọi thay đổi hàng loạt đều xuất hiện trong lịch sử của từng ticket – kèm tên nhân viên xử lý đã kích hoạt nóHướng dẫn
Báo nhiều lần & sự cố diện rộng
Gộp hai lượt báo của cùng một người vào một ticket – bình luận, tệp đính kèm và phần mô tả đi theo, không có gì bị xóaHướng dẫn
Nếu có người trả lời qua e-mail theo số ticket cũ thì thư trả lời rơi vào cái ticket đã gộpHướng dẫn
Chốt chặn: ticket của những người khác nhau thì không gộp đượcHướng dẫn
Gom nhiều lượt báo về một sự cố diện rộng dưới một ticket sự cố duy nhất – mỗi lượt báo giữ người yêu cầu, trạng thái và thời hạn của mình, và một câu trả lời tới với tất cả mọi người bị ảnh hưởng bằng e-mail riêng của họHướng dẫn
Sự cố hiện dưới dạng biểu ngữ và được ghi trong thư trả lời tự động – biểu ngữ tự biến mất khi sự cố được xử lý xongHướng dẫn
SLA, lịch & chuyển cấp
Chính sách SLA với thời hạn cho phản hồi đầu tiên và cho việc xử lý xongHướng dẫn
Lịch giờ làm việc cho từng nhóm (múi giờ riêng, nhiều khung mỗi ngày)Hướng dẫn
Ngày lễ qua nhập tệp .ics hoặc nhập thủ côngHướng dẫn
Đồng hồ tạm dừng trong lúc chờ người yêu cầu (cấu hình được cho từng thời hạn)Hướng dẫn
Thời gian còn lại trong danh sách ticket – sắp xếp được, kèm bộ lọc cho những thời hạn bị vi phạmHướng dẫn
Khi bị vi phạm: báo tin, hoặc tự động chuyển ticket sang nhóm khácHướng dẫn
Số liệu SLA trong báo cáo (tỷ lệ đạt được, số lần vi phạm, thời gian trung bình đã dùng)Hướng dẫn
Ghi nhận thời gian theo từng ticket
Bật hay tắt được theo từng nhóm; mặc định tắtHướng dẫn
Ghi công sức theo từng ticket – các nút nhanh cấu hình được (ví dụ 15m, 30m, 1.5h) hoặc nhập tự do (được làm tròn theo quy tắc làm tròn ở nơi có bật quy tắc đó)Hướng dẫn
Đồng hồ bấm giờ trên ticket – nó đề xuất khoảng thời gian đã trôi qua và mục chỉ được tạo khi một con người xác nhận; mở một ticket khác thì nó tạm dừngHướng dẫn
Nhiều nhân viên xử lý cùng ghi thời gian được trên một ticket – mỗi mục mang ngày, ghi chú và tên của nhân viên xử lýHướng dẫn
Có tính phí / không tính phí theo từng mục – thời gian được ghi một lần; ticket hiện cả hai tổng: mọi thứ đã ghi và tổng có tính phí (chỉ những mục đã tích, sau khi làm tròn)Hướng dẫn
Tính tiền chính xác tới từng phút hay làm tròn lên – cấu hình được (bước nhảy và mức tối thiểu cho mỗi mục, ví dụ khối 15 phút), mặc định là chính xác tới từng phútHướng dẫn
Thời gian đã ghi và thời gian tính tiền là hai chuyện tách bạch – đổi cách làm tròn không bao giờ làm sai lệch dữ liệu đã quaHướng dẫn
Bắt buộc có một mục thời gian trước khi đóng – mặc định tắt; nó chỉ áp dụng khi một con người đổi trạng thái, không bao giờ áp cho việc đóng tự động, việc gộp hay các thao tác hàng loạtHướng dẫn
Một cột “Time” trong danh sách ticket – nó xuất hiện ngay khi một ticket trong danh sách đã có ghi thời gianHướng dẫn
Báo cáo theo người yêu cầu, nhóm, danh mục và trường tùy chỉnh – tính tiền theo công ty hay theo trung tâm chi phíHướng dẫn
Xuất từng mục riêng lẻ: CSV và Excel cho kế toán (cả hai đều đầy đủ) và PDF để chuyển tay, ví dụ cho khách hàngHướng dẫn
Khách hàng không bao giờ thấy thời gian đã ghi – bản ghi đi cùng hóa đơn dưới dạng một bản xuất (khuyến nghị PDF), chứ không lên ticket trong cổng thông tin khách hàngHướng dẫn
Phần tách theo từng nhân viên xử lý có thể tắt đi – mặc định tắt, được máy chủ bắt buộc chứ không chỉ bị ẩn điHướng dẫn
Báo cáo & bảng điều khiển
Bảng điều khiển với bức tranh hiện tại: ticket theo từng trạng thái, ba vụ việc đang mở lâu nhất, phân bố theo nhân viên xử lý và theo danh mụcHướng dẫn
Mỗi nhóm một bảng điều khiển riêng – mỗi nhóm thấy bức tranh của mình, với quyền riêng của mìnhHướng dẫn
Báo cáo lọc được tự do – khoảng thời gian, nhóm, trạng thái, nhân viên xử lý, người yêu cầu, địa điểm, mức ưu tiên, danh mục chính và danh mục con, kênh, toàn văn; các bộ lọc kết hợp với nhauHướng dẫn
Lọc và gộp theo cả những trường của riêng bạn – công ty, trung tâm chi phí, hợp đồngHướng dẫn
Báo cáo hiện những cột nào thì cấu hình được theo từng vai trò – một khách hàng nhận một khung nhìn khác với một nhân viên xử lýHướng dẫn
Khách hàng tự lấy được báo cáo của mình – giới hạn trong ticket của chính họHướng dẫn
Xuất ra CSV, Excel và PDF – Excel với hai trang tính (các con số then chốt và ticket), biểu đồ thì nằm trong PDFHướng dẫn
Tệp PDF in các con số bên cạnh biểu đồ – riêng một bức hình thì không kiểm tra đượcHướng dẫn
CSV và Excel thì đầy đủ; tệp PDF dừng ở 20.000 dòng và ghi điều đó trong tài liệuHướng dẫn
Khảo sát mức hài lòng (CSAT)
Sau khi ticket được đóng: một e-mail với thang đánh giá bằng sao, một cú nhấp là toàn bộ câu trả lờiHướng dẫn
Không cần tài khoản khách hàng – liên kết chạy được mà không phải đăng nhập, bình luận là tùy chọn, và đánh giá xuất hiện trên ticket cho nhóm đã xử lý nóHướng dẫn
Báo cáo: trung bình, tỷ lệ hài lòng và tỷ lệ trả lời – kể cả những ticket đã đóng mà chưa từng được hỏiHướng dẫn
Phần tách đánh giá theo từng nhân viên xử lý tắt được và mặc định là tắt – đánh giá đơn lẻ trên ticket thì luôn hiện với nhómHướng dẫn
Giới hạn cấu hình được – từ mọi ticket cho tới nhiều nhất một lần mỗi tuầnHướng dẫn
Một đánh giá kém có thể kích hoạt một quy tắc tự động hóaHướng dẫn
Cơ sở tri thức
Ô chủ đề với bài viết định dạng và tệp đính kèmHướng dẫn
Khả năng nhìn thấy theo từng chủ đề: chỉ nội bộ hay mở cho khách hàngHướng dẫn
Gợi ý cách xử lý ngay khi ticket đang được tạoHướng dẫn
Biến một ticket thành một bài viết chỉ bằng một nút bấmHướng dẫn
Bài của một nhân viên xử lý chờ quản trị viên phê duyệtHướng dẫn
Lịch sử thay đổi trên các bài viết và chủ đề (dành cho quản trị viên)Hướng dẫn
Sao lưu & khôi phục
Quá trình cài đặt tự thiết lập việc sao lưu hằng ngày (23:00) – được giữ là 14 ngày, 4 tuần, 12 tháng, 4 quý và 5 năm, còn những bản sao lưu bạn tự tạo thì được giữ vĩnh viễn; thay đổi của bạn với cái lịch thì sống sót qua một lần cập nhậtHướng dẫn
Việc lên lịch do chính hệ điều hành lo – Task Scheduler trên Windows, cron trên Linux; không có dịch vụ nào chạy thêmHướng dẫn
Việc sao lưu chạy mà không cần ai đang đăng nhập – cron trên Linux, còn trên Windows là một dịch vụ khởi động được cả trên máy chưa đăng nhập; không bao giờ hỏi mật khẩu WindowsHướng dẫn
Bản sao lưu bao gồm mọi thứ tạo nên trạng thái: cơ sở dữ liệu, tệp đính kèm, kho lưu trữ và những khóa dùng để giải mã các thông tin đăng nhập đã lưuHướng dẫn
Vì thế một lần khôi phục mang mọi thứ trở lại. Theo lệ thường thì hệ thống lại làm việc được ngay sau đó ít lâuHướng dẫn
Một ứng dụng riêng cho việc sao lưu và khôi phục, cho Windows và Linux, có lối tắt trên màn hình nền – tạo một bản sao lưu, xem danh sách, khôi phụcHướng dẫn
Trên một máy chủ không có màn hình đồ họa thì vẫn những chức năng đó dưới dạng lệnh – sao lưu, liệt kê, khôi phục, đặt lịchHướng dẫn
Các bản sao lưu nằm trên cùng một máy – chúng che chắn cho những sai sót và những trục trặc khác, chứ không che chắn cho một lần hỏng đĩa; với trường hợp xấu nhất, xin hãy giữ các tệp sao lưu thêm ở một nơi khác nữaHướng dẫn
Trước mỗi lần cập nhật, hệ thống tự tạo thêm một bản sao lưu riêng – độc lập với cái lịchHướng dẫn
đã bao gồmkhông bao gồmMọi thông tin đều nói về phiên bản hiện tại 1.x.
Nhìn kỹ hơn
Những tính năng mà một dòng trong bảng nói chưa đủ.
Yêu cầu kèm công việc & phê duyệt
Professional
Có những yêu cầu không phải là một yêu cầu mà là cả nửa tá. “Đồng nghiệp mới bắt đầu vào thứ Hai” nghĩa là: tài khoản Windows, hộp thư, quyền truy cập ERP, điện thoại, thẻ ra vào — mỗi thứ do một nhóm khác nhau lo, mỗi thứ có người phụ trách riêng, và quản lý trực tiếp phải đồng ý trước đã. Hôm nay ai đó gõ từng ấy thứ năm lần rồi đi vòng quanh hỏi han. Ở đây bạn dựng luồng đó một lần: người yêu cầu điền một biểu mẫu, hệ thống tạo từng ticket riêng trong đúng nhóm, thu thập phê duyệt, và cho bạn thấy ở một chỗ những gì đã xong.
Một yêu cầu, nhiều công việc
Mỗi mục trở thành một ticket riêng — trong nhóm phụ trách nó, với người phụ trách riêng, thời gian chạy riêng và hướng dẫn riêng. Hai công việc có thể cùng về một nhóm: một service desk trông coi ba ứng dụng sẽ nhận ba ticket, chứ không phải một ticket với ba gạch đầu dòng. Bản thân yêu cầu hiện “3 trên 5 đã xong”, mỗi dòng nhảy thẳng vào ticket của nó, và yêu cầu đóng lại sau cùng.
Người yêu cầu chọn CÁI GÌ họ cần – không phải ai làm
Với mỗi công việc, bạn quyết định nó luôn chạy, được đánh dấu sẵn, hay phải được chủ ý đánh dấu. Trong biểu mẫu, người yêu cầu chỉ thấy một danh sách những gì có thể đặt — cơ cấu nhóm của bạn không lộ ra. Và “ứng dụng nào thuộc nhóm nào” không cần một bộ dữ liệu gốc thứ hai để duy trì: nó nằm ngay trên chính công việc đó.
Một lần phê duyệt, không phải tám
Việc phê duyệt thuộc về yêu cầu, không thuộc về từng công việc. Vì vậy tám tài khoản được đề nghị chỉ kích hoạt một e-mail gửi quản lý trực tiếp thay vì tám — đó chính là chỗ mà những luồng như thế này thường chết trong sử dụng hằng ngày. Nếu một công việc nhạy cảm còn cần thêm cái gật đầu của một bộ phận chuyên môn, bạn gắn một bước thứ hai vào riêng công việc đó. Cả hai được hỏi cùng lúc, và nếu bộ phận đó nói không thì chỉ công việc của họ bị ảnh hưởng; phần còn lại vẫn chạy tiếp.
Quản lý trực tiếp không cần tài khoản
Họ nhận một e-mail có liên kết, thấy ai đã đề nghị và những công việc nào được bao gồm, rồi quyết định bằng một cú nhấp — không phải đăng nhập, và không chiếm một chỗ ngồi nhân viên xử lý. E-mail có chủ ý chỉ mang đúng một liên kết đó và không có sẵn địa chỉ “phê duyệt”: trình quét vi-rút và dịch vụ xem trước mở mọi URL trong một bức thư, và một phê duyệt sinh ra như vậy sẽ không thể phân biệt được với phê duyệt thật. Từ chối thì phải nêu lý do — và người yêu cầu được cho biết lý do đó.
Không có gì xảy ra trước khi được duyệt
Các công việc xuất hiện ngay để những nhóm chuyên môn thấy được cái gì đang tới — nhưng chúng bị khóa, không ai được giao, và không thể di chuyển chừng nào còn thiếu phê duyệt. Điều đó được máy chủ bắt buộc, không chỉ làm mờ đi trên màn hình: thao tác hàng loạt và quy tắc tự động hóa cũng không có đường vòng nào. Nếu không ai phản hồi, một lời nhắc sẽ được gửi đi — không có chuyện quá hạn thì coi như đã duyệt, vì đó đúng là điều mà về sau kiểm toán viên sẽ bắt lỗi.
Ai đã quyết định vào lúc nào đều được lưu lại
Mọi bước đều được liệt kê trên yêu cầu kèm người phê duyệt, mốc thời gian và bình luận — chính là dấu vết kiểm toán mà những luồng như thế được đưa vào để có. Không ai có thể phê duyệt thay người khác, kể cả quản trị viên. Cho những ngày nghỉ thì có việc chuyển giao thay thế: một quản trị viên gửi yêu cầu đang mở cho người thay thế, liên kết cũ chết ngay lập tức, và lịch sử ghi lại ai đã chuyển nó từ ai sang ai, và khi nào.
Lần đặt lại mật khẩu thứ mười trong tuần không cần một câu trả lời viết mới — nó cần câu trả lời tốt mà nhóm của bạn đã viết sẵn, gửi đi trong vài giây và không có những lỗi gõ hay len vào lúc bốn giờ chiều. Một mẫu trả lời điền cả phần chữ LẪN phần việc thường lệ đi kèm: đặt trạng thái, giao cho tôi, đặt nhắc việc. Nút gửi vẫn nằm trong tay bạn.
Phần chữ và phần việc quanh nó, trong một lần chọn
Một mẫu không chỉ dán chữ vào. Nó gợi ý những thay đổi trường luôn đi cùng câu trả lời đó: trạng thái sang Đã xử lý, hạ mức ưu tiên, giao cho tôi, nhắc việc sau ba ngày. Mỗi gợi ý hiện thành một thẻ riêng và có thể bỏ đi từng cái — ticket này gần như là trường hợp chuẩn, chỉ khác là lần này bạn chưa muốn đóng nó.
Không có gì được gửi cho tới khi bạn gửi
Chọn một mẫu chỉ điền vào trình soạn thảo. Phần chữ nằm trước mắt bạn, bạn sửa lại, rồi gửi bằng đúng cái nút như mọi khi. Một macro chạy ngay lập tức sẽ gửi câu trả lời sai tới một khách hàng thật ngay khoảnh khắc bạn nhấp nhầm — và một e-mail thì không rút lại được. Một giây thêm này là có chủ ý.
Chỗ giữ chỗ mà bạn tin được
Chỉ cần viết “Chào {requesterName}” một lần, và mỗi lần dùng, hệ thống điền đúng người, số ticket, tiêu đề, tên bạn. Chúng được thay ngay lúc bạn chọn mẫu — nên phần chữ hoàn chỉnh chính là cái bạn thấy trong trình soạn thảo, không phải một bất ngờ trong hộp thư của khách hàng. Một chỗ giữ chỗ gõ sai sẽ bị từ chối khi lưu mẫu, chứ không phải do khách hàng phát hiện ra.
Câu trả lời đến với người yêu cầu qua e-mail
Một dấu tích và bình luận của bạn đi ra dưới dạng e-mail — tới người đứng sau ticket, và hệ thống tự xác định người đó cho bạn. Tệp đính kèm lưu trên mẫu được thêm vào ticket cùng lúc: hãy đặt tệp PDF hướng dẫn ở đó một lần thay vì mỗi lần lại đi lục trong thư mục tải về.
Mẫu tốt sinh ra từ những câu trả lời thật
Mẫu tốt nhất là câu trả lời bạn vừa viết. Một cú nhấp lên một bình luận biến nó thành bản nháp của một mẫu — với phần chữ điền sẵn, còn tên, địa chỉ và tệp của khách hàng thì có chủ ý bị bỏ lại. Bạn đặt tên cho nó, đọc lại một lần bằng con mắt tỉnh táo, và chỉ khi đó nó mới tồn tại. Chừng nào bạn chưa công bố, không ai khác nhìn thấy nó.
Mẫu ticket: ticket lặp đi lặp lại mà không phải gõ
Nhận một nhân viên mới, thanh lý một thiết bị, người gọi điện thoại — có những ticket được tạo đi tạo lại với cùng một hình hài. Một mẫu ticket điền sẵn biểu mẫu: tiêu đề, mô tả, danh mục, mức ưu tiên, nhóm phụ trách. Nhân viên xử lý thêm phần riêng biệt rồi gửi đi. Chưa có gì được tạo cho tới khi họ gửi.
Kiến thức của nhóm, không phải kho riêng
Mẫu thuộc về một nhóm hoặc về tất cả mọi người — không nằm trong ngăn kéo của một cá nhân. Khi ai đó rời đi, những câu trả lời hay nhất của họ vẫn ở lại. Và mỗi lần dùng đều được ghi vào lịch sử ticket: nhiều tuần sau bạn vẫn thấy được rằng một ticket đã được xử lý bằng câu trả lời chuẩn, và bằng cái nào.
Có trong cả hai phiên bản
Mẫu được bao gồm đầy đủ trong Basic — không giới hạn số lượng, không có tính năng nào bị giữ lại cho phiên bản cao hơn. Những công cụ tiết kiệm cho nhóm của bạn nhiều thời gian hằng ngày nhất thì không nên nằm sau một bức tường thu phí.
Ở một bộ phận hỗ trợ, phần lớn sự cố xảy ra không phải vì ai đó làm sai, mà vì không ai làm gì cả. Một ticket chờ một câu trả lời không bao giờ đến; một yêu cầu nằm im không người nhận suốt giờ nghỉ trưa; một vụ việc được xử lý xong rồi bị quên bẵng. Tự động hóa phản ứng đúng với điều đó — với sự VẮNG MẶT của một hành động. Nó kiểm tra mỗi phút và làm điều bạn sẽ tự làm, nếu bạn để ý thấy.
Bốn quy tắc đã có sẵn — và đang tắt
Bạn không bắt đầu với một màn hình trống. Hệ thống kèm sẵn bốn ví dụ bao quát các trường hợp thường ngày: nhắc người yêu cầu sau ba ngày làm việc im lặng; đóng một ticket sau mười ngày không có hồi âm; nâng mức ưu tiên của một ticket không ai nhận trong bốn giờ làm việc; và đặt nhắc việc cho bất cứ ticket nào một tuần không có hoạt động. Cả bốn đều đang tắt. Hãy bật một cái lên, chỉnh lại các con số, hoặc dùng nó làm điểm khởi đầu cho quy tắc của riêng bạn.
Bạn chọn, bạn không phải viết
Mọi giá trị đều đến từ dữ liệu của chính bạn: trạng thái của bạn, mức ưu tiên của bạn, nhóm của bạn, danh mục của bạn — chọn từ một danh sách. Không có ô nào để bạn gõ tên trường, không có ngôn ngữ truy vấn, không có biểu thức cron. Một quy tắc đọc là KHI một điều gì đó đã một thời gian không xảy ra, NẾU ticket trông như thế này, THÌ hãy làm điều kia.
Quy tắc nói bằng lời thường cho bạn biết nó sẽ làm gì
Phía trên trình soạn thảo có một câu chạy theo lựa chọn của bạn: “Khi một ticket ở trạng thái Chờ người dùng phản hồi và đã hơn 3 ngày làm việc không có hồi âm từ người yêu cầu, thì gửi một e-mail cho người yêu cầu.” Hãy đọc lại câu đó trước khi bật bất cứ thứ gì. Chính một câu ấy bắt được lỗi cấu hình mà nếu không bạn sẽ chỉ phát hiện trên một ticket khách hàng đã đóng.
Xem nó sẽ chạm tới ai — trước khi nó chạm tới họ
Mỗi quy tắc có một nút “ngay lúc này quy tắc này sẽ ảnh hưởng tới những ticket nào?”. Bạn nhận được danh sách, và không có gì khác xảy ra: không e-mail, không đổi trạng thái, thậm chí không một dòng nhật ký. Đây là bước tạo nên khác biệt giữa dám thử và không bao giờ dám.
Một lời nhắc không biến thành cơn lũ
“Không có hồi âm trong 24 giờ” là đúng trở lại vào từng phút một kể từ giờ thứ 24 — nếu xây một cách ngây thơ thì đó là 1.440 e-mail mỗi ngày. Vì vậy một quy tắc chỉ chạy một lần cho mỗi tình huống rồi nằm yên. Nó chỉ chạy lại sau khi điều kiện đã hết rồi xảy ra lần nữa: khách hàng trả lời, mọi thứ lại im ắng, và chỉ khi đó lời nhắc tiếp theo mới được gửi đi.
Giờ làm việc mới được tính, không phải ngày trên lịch
“Ba ngày làm việc” dùng đúng lịch giờ làm việc như các thời hạn của bạn, theo từng nhóm — một ticket từ tối thứ Sáu không bị quá hạn vào sáng thứ Hai. Nếu bạn muốn tính thời gian trôi qua thuần túy thì cũng có phút, giờ và ngày. Đó là lựa chọn của bạn cho từng điều kiện, không phải một thiết lập chung.
Không bao giờ có hạn mức lượt chạy
Vài hệ thống tính tiền tự động hóa theo lượt chạy: một hạn mức mỗi tháng, và khi dùng hết thì mọi quy tắc bạn có đều dừng cho tới ngày mồng một. Ở đây không có bộ đếm như vậy. Giới hạn duy nhất là các chốt an toàn theo từng ticket để một quy tắc không thể đánh thức quy tắc khác thành vòng lặp — chúng có mặt để bảo vệ ticket của bạn, không phải để đo đếm bạn.
Không có gì xảy ra một cách vô hình
Mọi hành động đều được ghi vào lịch sử của ticket kèm tên quy tắc đã gây ra nó, nên không ai phải thắc mắc vì sao một ticket tự đóng. Mỗi quy tắc cũng giữ nhật ký riêng: ticket nào, khi nào, và kết quả ra sao — kể cả những lần thất bại. Và nếu một giấy phép hết hiệu lực, các quy tắc vẫn nằm nguyên chỗ cũ và chỉ đơn giản là ngừng chạy; trang này nói rõ điều đó thay vì im lặng.
Nhắc việc bằng tay có trong mọi phiên bản
Đặt một ngày và một ghi chú ngắn lên ticket để lấy nó ra sau — “thứ Năm gọi lại” — là một phần của Basic, gồm cả các bộ lọc Hôm nay / Tuần này / Quá hạn trong danh sách ticket. Người yêu cầu không bao giờ thấy nó. Professional là bước từ chỗ nhân viên xử lý của bạn tự đặt nhắc việc sang chỗ hệ thống đặt giúp bạn.
Hai tình huống trông giống hệt nhau trong hộp thư và phải được xử lý theo hai cách hoàn toàn khác nhau. Một: cùng một người báo cùng một vấn đề hai lần — một lần qua e-mail và một lần qua điện thoại, vì họ không chắc thư đã tới. Hai: một thiết bị chuyển mạch hỏng, và trong vòng mười lăm phút có ba mươi lượt báo từ ba mươi người khác nhau. Mỗi tình huống có một cách riêng, và hai cách đó khác nhau là có chủ ý.
Cùng một người, hai ticket
Bạn đánh dấu cả hai dòng và quyết định ticket nào ở lại — ticket cũ hơn được chọn sẵn, để thời hạn chạy từ lần liên hệ đầu tiên chứ không phải từ lần thử thứ hai. Bình luận, tệp đính kèm và mô tả của ticket thứ hai chuyển vào ticket thứ nhất; không mất gì cả. Trước khi bạn xác nhận, hệ thống viết rõ ra: “#124 sẽ được đóng và chuyển vào #122.”
Một sự cố, ba mươi lượt báo
Bạn gom ba mươi ticket đó dưới một ticket sự cố duy nhất. Mỗi ticket vẫn giữ người yêu cầu của mình, trạng thái của mình và thời hạn riêng của mình — không cái nào biến mất. Người báo muộn có thể được thêm vào từng cái một, và ai mở một ticket mới trong lúc sự cố đang chạy sẽ được mời liên kết sẵn thay vì phải đi tìm.
Vì sao hai chuyện này không giống nhau
Nếu bạn cứ thế gộp ba mươi lượt báo đó, hai mươi chín người sẽ mất ticket của mình và không bao giờ nghe được gì nữa. Và vì hai mươi chín vụ việc bị đóng mà chưa từng nhận được câu trả lời, con số của bạn sau đó sẽ đẹp hơn thực tế. Vì vậy hệ thống kiểm tra ai đứng sau từng ticket: nếu là những người khác nhau, nó không hề mời gộp mà chỉ ra hướng ticket sự cố.
Trả lời một lần thay vì ba mươi lần
Khi nguyên nhân đã được khắc phục, bạn viết lời giải quyết đúng một lần. Mọi ticket được liên kết đều nhận nó dưới dạng bình luận rồi được đóng, và mỗi người bị ảnh hưởng nhận e-mail riêng của mình — không có danh sách gửi chung, không ai thấy địa chỉ của ai. Nếu sau đó vẫn có người trả lời, ticket của riêng họ được mở lại, chứ không phải cả sự cố.
Không ai mất số ticket của mình
Một lượt báo đã gộp không bao giờ bị xóa. Nếu nhiều tuần sau người yêu cầu trả lời vào e-mail cũ, câu trả lời của họ vẫn tìm đúng ticket — dù họ trả lời vào bức thư, để nguyên số cũ trong dòng chủ đề, hay cả hai. Nếu không, họ sẽ tin rằng thư trả lời đã được chuyển tới trong khi nó nằm trong một vụ việc đã đóng mà không ai ngó tới.
Biểu ngữ tự nó biến đi
Một sự cố có thể được thông báo bằng một dấu tích: khi đó nó hiện ra cho tất cả mọi người dưới dạng biểu ngữ và dưới dạng một ghi chú trong thư trả lời tự động — người báo qua e-mail không bao giờ phải thấy trang đăng nhập. Khi bạn xử lý xong, biểu ngữ tự biến mất. Một khung giờ bảo trì đã thông báo cho thứ Bảy vẫn hiện bên cạnh thay vì bị đẩy sang một bên.
SLA là một lời hứa: “chúng tôi trả lời một yêu cầu trong vòng hai giờ và xử lý xong trong vòng tám giờ”. Hệ thống ticket tháo lời hứa đó ra, đặt một chiếc đồng hồ lên mọi ticket phù hợp và cho bạn biết còn bao nhiêu thời gian — trước khi hạn trôi qua, không phải sau đó.
Thời hạn chỉ chạy trong giờ làm việc của bạn
Một thời hạn tám giờ bắt đầu vào chiều thứ Sáu không được phép hết hạn vào sáng thứ Bảy. Vì vậy mọi thời hạn đều gắn với một lịch giờ làm việc: giờ mở cửa theo từng ngày trong tuần, múi giờ riêng, nhiều khung trong ngày cho giờ nghỉ trưa hay ca gãy — kể cả ca đêm kéo qua nửa đêm. Mỗi nhóm có thể có lịch riêng; đêm, cuối tuần và ngày lễ không được tính.
Bạn quyết định ngày lễ, không phải chúng tôi
Ngày lễ phụ thuộc vào nơi bạn ở, không phụ thuộc vào ngôn ngữ bạn dùng — 16 bang của Đức, 26 bang của Thụy Sĩ, 50 bang của Mỹ. Thay vì kèm theo một danh sách mà sớm muộn cũng sai với khu vực của bạn, bạn nhập tệp .ics chính thức cho địa phương mình hoặc nhập từng ngày bằng tay. Sau khi nhập, hệ thống cho bạn biết đã tiếp nhận bao nhiêu ngày và bỏ qua bao nhiêu ngày. Nếu suốt mười hai tháng tới một lịch không có ngày nghỉ nào, trang cài đặt sẽ nói rõ — nếu không, hệ thống sẽ lặng lẽ tính xuyên qua mọi ngày lễ.
Cái gì được tính là một câu trả lời — và cái gì thì không
Đây là chỗ mà con số hoặc có ý nghĩa hoặc không. Đồng hồ phản hồi đầu tiên chỉ dừng khi một nhân viên xử lý viết một bình luận công khai. Thư xác nhận tự động không được tính, ghi chú nội bộ không được tính, và thư đến của khách hàng thì chắc chắn không. Nếu xây theo cách khác, mọi thời hạn đều sẽ “đạt” trong vài giây và báo cáo của bạn luôn hiện 100 % trong khi thực tế chưa ai trả lời cả.
Chờ khách hàng thì đồng hồ dừng lại
Khi bạn hỏi lại và chờ người yêu cầu, thời hạn ngừng chạy — bạn không bị tính thời gian chờ mà bạn không kiểm soát được. Việc một thời hạn có tạm dừng hay không được đặt theo từng mục tiêu, vì câu trả lời cho “phản hồi đầu tiên” và “xử lý xong” không nhất thiết giống nhau. Nếu một ticket đã xử lý xong được mở lại, một chu kỳ mới bắt đầu; chu kỳ cũ vẫn được lưu cho báo cáo thay vì lập tức đánh dấu ticket là vi phạm.
Khi một thời hạn bị vi phạm
Bạn quyết định cho từng thời hạn điều gì sẽ xảy ra: chỉ ghi lại, báo cho người được giao và người theo dõi, hay tự động chuyển ticket sang một nhóm khác — chính là chuyển cấp cổ điển từ cấp 1 lên cấp 2. Việc chuyển giao có chủ ý không phải là mặc định, vì nó dời trách nhiệm và giải phóng người được giao; điều đó không nên làm ai bất ngờ ngay ở lần vi phạm đầu tiên. Dù bạn chọn gì, nó cũng chỉ chạy đúng một lần, kể cả khi hệ thống khởi động lại.
Thời hạn nào áp cho ticket nào
Bạn tạo các chính sách và xếp thứ tự cho chúng; chính sách khớp đầu tiên sẽ thắng. Điều kiện là nhóm, mức ưu tiên và danh mục — chọn từ danh sách, không phải một ngôn ngữ truy vấn mà bạn phải học trước. Một ô để trống nghĩa là “bất kỳ”, không phải “không có”: một chính sách không ghi nhóm sẽ áp cho mọi nhóm.
Sau đó bạn thấy gì
Thời gian còn lại hiện ngay trong danh sách ticket, sắp xếp được theo “hết hạn trước” và lọc được theo “đã vi phạm”, cùng với thời hạn trên chính ticket. Báo cáo cho thấy tỷ lệ tuân thủ, số lần vi phạm và thời gian trung bình đã dùng cho mỗi thời hạn. Tỷ lệ này chỉ tính những thời hạn đã ngã ngũ — những thời hạn còn đang chạy không làm loãng nó, nếu không thì mọi lời hứa mới đưa ra ban đầu đều trông thảm hại rồi tự nó tốt lên.
Chừng nào bạn chưa tạo chính sách thì không có gì thay đổi
Khi chưa có chính sách nào hoạt động thì không có đồng hồ nào chạy, không có cột nào thêm vào, và những ticket sẵn có của bạn giữ nguyên như cũ. Không có mục tiêu đặt sẵn, không có vụ việc cũ nào qua một đêm bỗng thành vi phạm. Ticket không có thời hạn hiện một dấu gạch trung tính — không phải “đã vi phạm”.
Ai tính tiền theo công sức thì phải ghi lại nó ở đúng nơi nó phát sinh: trên vụ việc. Nhân viên xử lý gõ “20” hoặc bấm một nút đặt sẵn, và cuối tháng các con số tổng đã sẵn sàng theo khách hàng, trung tâm chi phí hay hợp đồng — dưới dạng bảng trên màn hình và dưới dạng CSV cho hóa đơn. Cái mà nó có chủ ý KHÔNG phải: một hệ thống chấm công. Nó ghi lại công sức cho một vụ việc, không bao giờ ghi lại sự có mặt của một con người.
Gõ vào nhanh hơn mọi đồng hồ bấm giờ
Đường chính là nhập nhanh: bốn nút cấu hình được tự do và một ô hiểu được cả “90”, “1.5h” lẫn “1h 30m”. Với một vụ việc ba phút, hai cú nhấp lên đồng hồ bấm giờ còn tốn hơn chính con số. Nếu các phiên làm việc của bạn kéo dài, hãy bật thêm đồng hồ bấm giờ — nó chỉ đề xuất, và chưa có gì được lưu cho tới khi một con người xác nhận.
Thời gian đã ghi và thời gian tính tiền là hai chuyện
Bạn tự đặt bước làm tròn và mức tối thiểu — theo khối 15 phút thì 17 phút thành 30. Nhưng chỉ giá trị tính tiền mới được làm tròn, luôn theo từng lần nhập, không bao giờ theo tổng. Thời gian thật sự đã làm thì giữ nguyên, nên sau này bạn có đổi cách làm tròn thì những tháng đã qua cũng không xê dịch theo.
Tính tiền theo công ty, trung tâm chi phí hay hợp đồng
Báo cáo gộp thời gian theo người yêu cầu, theo nhóm, theo ngày — và theo bất kỳ trường tùy chỉnh nào bạn đã tạo. Nhờ vậy bạn tính tiền đúng theo cách gọi mà tổ chức của bạn dùng, thay vì theo một cách gọi do chúng tôi nghĩ ra. Trang này hiện những nhóm lớn nhất và nói rõ khi nó cắt bớt; bản xuất CSV của từng lần nhập thì không bao giờ bị cắt, vì một tổng hóa đơn lấy từ một danh sách bị cắt không phải là thiếu, mà là sai.
Kỳ báo cáo tính theo phần việc, không theo ticket
Một ticket từ tháng Sáu nhưng được làm trong tháng Bảy thì thuộc về hóa đơn tháng Bảy với số giờ đó. Báo cáo cắt đúng như vậy — theo ngày của lần nhập, không theo lúc ticket được tạo. Nghe thì hiển nhiên, và đó chính là chỗ mà một hóa đơn hằng tháng lặng lẽ sai đi.
Nhiều nhân viên xử lý, truy vết được đầy đủ
Mỗi lần nhập đều mang ngày, tác giả, ghi chú và dấu tính phí. Ai được sửa lần nhập của người khác, và ai còn được sửa sau khi đã đóng, là hai quyền riêng biệt — vì ai sửa thời gian của người khác là sửa hóa đơn của người khác. Khi hai ticket được gộp thì thời gian đi theo; nó không nên bị bỏ lại trên cái ticket sinh đôi đã đóng.
Việc đánh giá theo từng nhân viên xử lý có thể tắt đi
Thời gian theo từng người là dữ liệu về hiệu suất và hành vi. Vì thế phần tách theo nhân viên xử lý là một công tắc riêng, mặc định tắt — và chốt chặn nằm trong máy chủ, không chỉ ở phần hiển thị. Với các nhà cung cấp đám mây thì cách đánh giá này không tắt được; với một tổ chức có hội đồng lao động, đó là khác biệt giữa triển khai được ngay và phải đi thương lượng trước.
Khách hàng của bạn không thấy thời gian
Mặc định, công sức đã ghi chỉ dùng nội bộ. “Năm phút — cho từng ấy thôi à?” là cuộc tranh luận không ai muốn, và nó chỉ nổ ra vì con số bị nhìn thấy. Nếu bạn muốn khác, hãy chủ ý mở trường đó ra; mặc định không quyết định thay bạn.
Bật tắt được, và theo từng nhóm nữa
Ghi nhận thời gian mặc định tắt — nếu bạn không cần, bạn không thấy ô nào, cột nào hay ô số nào. Khi đã bật thì mọi nhóm đều tham gia và bạn loại ra từng nhóm: nhóm CNTT nội bộ không cần ghi, nhóm dịch vụ tiếp xúc khách hàng thì có. Nếu muốn, bạn có thể bắt buộc nhập thời gian trước khi đóng; những lần đóng tự động không bị ảnh hưởng, nếu không sẽ có những ticket mà không ai đóng được.
Rốt cuộc chỉ một người biết bộ phận hỗ trợ của bạn làm tốt hay không: chính người được giúp. Sau khi một ticket được đóng, họ nhận một e-mail có năm ngôi sao — một cú nhấp là xong. Đánh giá đó rồi đi đúng chỗ của nó: lên ticket, tới trước mặt người đã làm việc đó, và vào báo cáo dưới dạng một con số. Khảo sát đang tắt cho tới khi bạn bật lên; bạn quyết định có hỏi ai hay không và hỏi khi nào.
Một cú nhấp, không hỏi gì thêm
E-mail mang năm ngôi sao dưới dạng liên kết. Nhấp vào ngôi sao thứ ba là toàn bộ câu trả lời — không tài khoản, không đăng nhập, không biểu mẫu trải dài hai màn hình. Ai muốn thì có thể thêm một câu trên trang hiện ra sau đó, và chính những câu ấy thường là phần thú vị nhất của cả bản báo cáo. Nhấp nhầm ngôi sao vẫn sửa lại được chừng nào liên kết còn hiệu lực.
Tỷ lệ trả lời nằm ngay cạnh số trung bình
Con số 4,6 chẳng nói lên điều gì cho tới khi có người viết bên cạnh rằng nó dựa trên mười hai câu trả lời trên bốn trăm. Vì thế báo cáo hiện cả hai — và bên cạnh đó là số ticket đã đóng mà chưa hề được hỏi. Một con số giấu đi mẫu của chính nó thì còn kém giá trị hơn là không có con số nào.
Đo lường mà không giám sát nhân viên
Đánh giá theo từng người là dữ liệu về hiệu suất và hành vi — ở nhiều công ty, đó là việc của hội đồng lao động. Ở đây, việc đánh giá theo nhân viên xử lý là một công tắc riêng, mặc định tắt, và điều đó được máy chủ bắt buộc: tắt là tắt, kể cả khi xuất dữ liệu. Đánh giá trên từng ticket vẫn hiện dù thế nào, vì đồng nghiệp đã xử lý vụ việc là người đầu tiên có thể rút kinh nghiệm từ đó.
Không ai bị chôn vùi
Mỗi ticket được khảo sát nhiều nhất một lần. Cùng một người được hỏi bao lâu một lần là do bạn quyết định – mặc định nhiều nhất một lần trong bảy ngày: ai báo năm việc trong một buổi sáng thì nhận một e-mail thay vì năm. Một bộ phận khách hàng với nhiều người gửi khác nhau thì đặt giới hạn về không và hỏi ở mọi ticket. Nếu một ticket được mở lại ngay sau khi đóng, không có khảo sát nào được gửi — câu hỏi chỉ đến khi vụ việc thật sự kết thúc.
Một sự cố diện rộng không làm méo con số
Những lượt báo được gắn vào một ticket sự cố gộp thì có chủ ý không được khảo sát. Nếu không, một cú nhấp “đã xử lý sự cố” sẽ bắn ra hai trăm phiếu khảo sát về đúng một phần việc, và cả tháng đó rốt cuộc sẽ mô tả sự cố chứ không phải dịch vụ của bạn. Chính ticket sự cố thì được hỏi; hai trăm người bị ảnh hưởng thì không.
Một đánh giá kém là một vụ việc, không phải một điểm dữ liệu
Một ngôi sao không thuộc về bản tổng kết tuần sau — nó thuộc về bàn làm việc ngay trong ngày. Một quy tắc tự động hóa có thể phản ứng ngay khoảnh khắc đánh giá tới: nâng mức ưu tiên, giao cho trưởng nhóm, gửi một bức thư. Vẫn máy quy tắc đó, vẫn cách xử lý đó; đánh giá chỉ đơn giản là thêm một điều kiện.
Liên kết cho quyền đánh giá, không cho quyền đọc
Trang khảo sát hiện số ticket và tiêu đề, không gì khác — không mô tả, không bình luận, không tệp đính kèm. Những liên kết như thế hay bị chuyển tiếp hoặc rơi vào một hộp thư dùng chung; ai giữ nó thì được đánh giá, chứ không được đọc theo. Sau 30 ngày nó hết hạn, và nhìn từ bên ngoài, hết hạn và không tồn tại trông giống hệt nhau.
Trình quét vi-rút cũng không đánh giá
Một liên kết ngôi sao chỉ dựa vào việc bị mở sẽ bị các bộ kiểm tra liên kết của những nhà cung cấp thư lớn nhấp vào một cách tự động — khi đó điểm số hoàn toàn là bịa đặt và trong cơ sở dữ liệu thì không phân biệt được với câu trả lời thật. Ở đây, mở liên kết chỉ hiển thị trang; chưa có gì được lưu cho tới khi có một con người ngồi trước nó. Với họ thì vẫn chỉ là một cú nhấp.
