Mẫu dữ liệu dịch vụ khách hàng

Freshdesk
Mẫu dữ liệu dịch vụ khách hàng

Mẫu dữ liệu dịch vụ khách hàng

Mẫu này hướng dẫn bạn về các thuộc tính dữ liệu và hoạt động quy trình cần thiết để phân tích dịch vụ khách hàng. Mẫu cũng có hướng dẫn trích xuất thực tế để bạn thu thập dữ liệu hiệu quả. Hãy dùng tài nguyên này để đơn giản hóa việc thu thập dữ liệu và chuẩn bị cho quá trình process mining.
  • Các thuộc tính nên thu thập
  • Các hoạt động chính cần theo dõi
  • Hướng dẫn trích xuất dữ liệu
Chưa quen với nhật ký sự kiện? Tìm hiểu cách tạo nhật ký sự kiện cho process mining.

Thuộc tính dịch vụ khách hàng

Đây là những trường dữ liệu nên có trong event log để phân tích dịch vụ khách hàng và hiểu rõ quy trình.
3 Bắt buộc 4 Nên có 12 Không bắt buộc
Tên Mô tả
Hoạt động
Activity
Tên của một sự kiện hoặc bước nghiệp vụ cụ thể diễn ra trong quy trình dịch vụ khách hàng.
Mô tả

Thuộc tính Hoạt động thể hiện một thao tác riêng biệt hoặc thay đổi trạng thái trong vòng đời của yêu cầu dịch vụ. Thuộc tính này ghi lại các sự kiện nghiệp vụ quan trọng như 'Tạo phiếu hỗ trợ', 'Phân công phiếu hỗ trợ', 'Gửi phản hồi đầu tiên' và 'Xử lý xong phiếu hỗ trợ'. Những hoạt động này tạo thành các nút trên sơ đồ quy trình.

Phân tích trình tự và tần suất của các hoạt động là trọng tâm của process mining. Việc này giúp trực quan hóa luồng quy trình, xác định các đường đi phổ biến và hiếm gặp, đồng thời phát hiện sai lệch so với quy trình vận hành chuẩn. Hiểu rõ các hoạt động là điều cần thiết để tìm ra chỗ kém hiệu quả, vòng lặp làm lại như 'Mở lại phiếu hỗ trợ' hoặc vấn đề về tuân thủ.

Vì sao điều này quan trọng

Thuộc tính này xác định các bước trên sơ đồ quy trình, giúp trực quan hóa và phân tích luồng quy trình từ đầu đến cuối.

Lấy dữ liệu ở đâu

Được suy ra từ các loại sự kiện trong Freshdesk. Dữ liệu có thể kết hợp thay đổi trạng thái từ endpoint 'Tickets' trong API với các sự kiện cụ thể như ghi chú hoặc phản hồi từ endpoint 'Conversations'.

Ví dụ
Tạo phiếu hỗ trợGửi phản hồi đầu tiênChuyển trạng thái sang chờ xử lýXử lý xong phiếu hỗ trợĐóng phiếu hỗ trợ
Thời điểm sự kiện
EventTime
Dấu thời gian cho biết thời điểm một hoạt động hoặc sự kiện cụ thể diễn ra.
Mô tả

Thời điểm sự kiện, hay dấu thời gian, ghi lại chính xác ngày giờ một hoạt động diễn ra. Đây là thành phần quan trọng để sắp xếp sự kiện theo trình tự thời gian và tính khoảng thời gian giữa các bước trong quy trình. Mỗi hoạt động được ghi lại cần có dấu thời gian tương ứng.

Khi phân tích, thuộc tính này được dùng để dựng dòng thời gian cho từng yêu cầu dịch vụ. Đây là cơ sở để tính mọi KPI liên quan đến thời gian, chẳng hạn như thời gian xử lý, thời gian phản hồi đầu tiên và thời gian kéo dài của điểm nghẽn. Dấu thời gian chính xác giúp bạn hiểu hiệu suất quy trình và xác định chậm trễ.

Vì sao điều này quan trọng

Dấu thời gian này rất cần thiết để sắp xếp sự kiện theo trình tự thời gian và tính mọi chỉ số dựa trên thời lượng, chẳng hạn như thời gian xử lý và mức độ tuân thủ SLA.

Lấy dữ liệu ở đâu

Tương ứng với các trường 'created_at' hoặc 'updated_at' gắn với sự kiện, phản hồi hoặc thay đổi trạng thái của phiếu hỗ trợ trong API Freshdesk.

Ví dụ
2023-10-25T10:00:00Z2023-10-25T10:05:14Z2023-10-26T14:30:00Z
Yêu cầu dịch vụ
ServiceRequest
Mã định danh duy nhất của một thắc mắc hoặc vấn đề cụ thể từ khách hàng, thường được gọi là phiếu hỗ trợ hoặc trường hợp cần hỗ trợ.
Mô tả

Yêu cầu dịch vụ là mã định danh chính của trường hợp, liên kết mọi hoạt động liên quan đến một lần tương tác với khách hàng. Mỗi thắc mắc, vấn đề hoặc yêu cầu mới của khách hàng sẽ có một mã yêu cầu dịch vụ riêng. Mã này không thay đổi trong suốt vòng đời của phiếu hỗ trợ, từ lúc tạo và phân công đến khi xử lý xong và đóng lại.

Trong process mining, thuộc tính này là nền tảng để tái dựng toàn bộ hành trình của từng trường hợp dịch vụ khách hàng. Khi nhóm mọi sự kiện liên quan theo cùng một mã yêu cầu dịch vụ, nhà phân tích có thể trực quan hóa luồng quy trình, đo thời gian xử lý và xác định những khác biệt hoặc điểm nghẽn ảnh hưởng đến từng trường hợp.

Vì sao điều này quan trọng

Đây là mã Case ID thiết yếu, liên kết mọi sự kiện liên quan thành một phiên bản quy trình duy nhất, giúp bạn có cái nhìn đầy đủ về hành trình của từng trường hợp dịch vụ khách hàng.

Lấy dữ liệu ở đâu

Đây là mã phiếu hỗ trợ chính trong Freshdesk, thường nằm trong trường 'id' của endpoint 'Tickets' trong API.

Ví dụ
SR-2023-10-4831SR-2023-11-0192SR-2023-11-5210
Loại yêu cầu dịch vụ
ServiceRequestType
Phân loại yêu cầu dịch vụ, chẳng hạn như 'Câu hỏi', 'Sự cố', 'Vấn đề' hoặc 'Yêu cầu tính năng'.
Mô tả

Loại yêu cầu dịch vụ là trường phân loại quan trọng, cho biết bản chất thắc mắc của khách hàng. Loại yêu cầu thường được xác định khi tạo phiếu hỗ trợ hoặc trong bước phân loại ban đầu, giúp chuyển yêu cầu đến đúng nhóm hoặc nhân viên.

Khi phân tích, thuộc tính này giúp chia quy trình thành các nhóm để hiểu cách xử lý từng loại yêu cầu. Thuộc tính giúp trả lời những câu hỏi như 'Sự cố có mất nhiều thời gian xử lý hơn câu hỏi không?' và 'Loại yêu cầu nào thường bị mở lại nhất?'. Việc phân nhóm này rất quan trọng để xác định điểm nghẽn riêng của từng loại và tối ưu quy trình làm việc phù hợp.

Vì sao điều này quan trọng

Giúp chia quy trình thành các nhóm để so sánh hiệu suất và quy trình làm việc giữa những loại vấn đề khách hàng khác nhau, chẳng hạn như sự cố và câu hỏi.

Lấy dữ liệu ở đâu

Thuộc tính này có thể tương ứng với trường 'type' trong đối tượng 'Tickets' của Freshdesk.

Ví dụ
Câu hỏiSự cốVấn đềYêu cầu tính năng
Mức độ ưu tiên
Priority
Mức độ ưu tiên được gán cho yêu cầu dịch vụ, chẳng hạn như 'Thấp', 'Trung bình', 'Cao' hoặc 'Khẩn cấp'.
Mô tả

Thuộc tính Mức độ ưu tiên thể hiện mức độ khẩn cấp của yêu cầu dịch vụ và thường quyết định thời hạn phản hồi, giải quyết mục tiêu. Hệ thống có thể tự động đặt mức ưu tiên theo quy tắc hoặc nhân viên hỗ trợ có thể đặt thủ công trong bước phân loại.

Thuộc tính này rất cần thiết để phân tích việc tuân thủ SLA và phân bổ tài nguyên. Khi lọc sơ đồ quy trình theo mức độ ưu tiên, chuyên viên phân tích có thể xác định liệu phiếu ưu tiên cao có thực sự được xử lý nhanh hơn phiếu ưu tiên thấp hay không. Thuộc tính này cũng giúp tìm hiểu mức độ phổ biến của việc đổi ưu tiên, một dạng làm lại, và ảnh hưởng của việc đó đến quy trình.

Vì sao điều này quan trọng

Cần thiết để phân tích SLA và xác định tài nguyên có được phân bổ hợp lý để xử lý vấn đề ưu tiên cao nhanh hơn vấn đề ưu tiên thấp hay không.

Lấy dữ liệu ở đâu

Tương ứng với trường 'priority' trong đối tượng 'Tickets' của Freshdesk.

Ví dụ
ThấpTrung bìnhCaoKhẩn cấp
Nhân viên được phân công
AssignedAgent
Tên hoặc mã ID của nhân viên dịch vụ khách hàng phụ trách phiếu hỗ trợ tại thời điểm sự kiện diễn ra.
Mô tả

Thuộc tính này xác định nhân viên cụ thể được phân công xử lý yêu cầu dịch vụ. Người phụ trách có thể thay đổi trong vòng đời của phiếu hỗ trợ do phân công lại hoặc chuyển cấp.

Phân tích dữ liệu theo nhân viên được phân công rất quan trọng đối với dashboard quản lý hiệu suất. Bạn có thể đo các KPI riêng của từng nhân viên như thời gian xử lý trung bình, số lượng phiếu hỗ trợ và tỷ lệ mở lại. Qua đó, bạn có thể xác định nhân viên có hiệu suất cao, tìm ra nhu cầu đào tạo và phân tích tác động của việc chuyển giao đến tổng thời gian xử lý.

Vì sao điều này quan trọng

Giúp phân tích hiệu suất của từng nhân viên, xác định người có thành tích tốt, cơ hội đào tạo và tác động của việc phân công lại.

Lấy dữ liệu ở đâu

Tương ứng với trường 'responder_id' trong đối tượng 'Tickets' của Freshdesk. Bạn có thể kết hợp trường này với thông tin chi tiết của nhân viên.

Ví dụ
Alice JohnsonRobert SmithMaria Garcia
Trạng thái
Status
Trạng thái hiện tại hoặc trước đây của yêu cầu dịch vụ, chẳng hạn như 'Đang mở', 'Đang chờ', 'Đã giải quyết' hoặc 'Đã đóng'.
Mô tả

Thuộc tính Trạng thái cho biết tình trạng của yêu cầu dịch vụ tại một thời điểm cụ thể. Các lần đổi trạng thái thường đánh dấu những mốc quan trọng trong quy trình. Ví dụ, yêu cầu chuyển từ 'Đang mở' sang 'Đang chờ' khi cần khách hàng cung cấp thông tin, hoặc từ 'Đang chờ' sang 'Đang mở' khi khách hàng phản hồi.

Theo dõi các lần đổi trạng thái là điều cần thiết để hiểu vòng đời của phiếu. Việc này giúp xác định phiếu mất bao lâu ở từng trạng thái và tìm ra điểm nghẽn. Chẳng hạn, nếu phiếu ở trạng thái 'Đang chờ' quá lâu, có thể nhóm đang chậm nhận thông tin từ khách hàng.

Vì sao điều này quan trọng

Theo dõi các lần đổi trạng thái giúp bạn hiểu vòng đời của phiếu và xác định thời gian xử lý ở những trạng thái cụ thể như 'Đang chờ' hoặc 'Tạm giữ'.

Lấy dữ liệu ở đâu

Tương ứng với trường 'status' trong đối tượng 'Tickets' của Freshdesk. Cần suy ra trạng thái trước đây từ nhật ký hoạt động.

Ví dụ
Đang mởĐang chờĐã giải quyếtĐã đóng
Có vi phạm SLA
IsSlaBreached
Cờ đúng/sai cho biết thời gian giải quyết yêu cầu dịch vụ có vượt quá thời hạn SLA hay không.
Mô tả

Thuộc tính được tính toán này cho biết rõ yêu cầu dịch vụ có tuân thủ SLA hay không. Giá trị được xác định bằng cách so sánh 'ResolutionTime' thực tế với 'SlaTargetResolutionTime'. Nếu thời gian thực tế dài hơn thời hạn mục tiêu, cờ sẽ là true.

Thuộc tính này giúp đơn giản hóa việc phân tích và theo dõi mức độ tuân thủ SLA trên bảng điều khiển. Bạn có thể dễ dàng đếm và lọc các phiếu vi phạm, nhanh chóng xác định quy mô vi phạm SLA, rồi đi sâu xuống một cấp để tìm nguyên nhân gốc rễ trong các mẫu quy trình của những phiếu đó. Thuộc tính này hỗ trợ trực tiếp bảng điều khiển và KPI Tổng quan về tuân thủ SLA.

Vì sao điều này quan trọng

Giúp phân tích mức độ tuân thủ SLA bằng một cờ rõ ràng cho từng trường hợp không đạt thời hạn mục tiêu, từ đó hỗ trợ tìm nguyên nhân gốc rễ của vi phạm.

Lấy dữ liệu ở đâu

Trường được tính toán bằng cách so sánh thời điểm giải quyết thực tế với 'SlaTargetResolutionTime' hoặc trường 'due_by' trong Freshdesk.

Ví dụ
truefalse
Đã mở lại
IsReopened
Cờ đúng/sai cho biết yêu cầu dịch vụ đã giải quyết có từng được mở lại hay không.
Mô tả

Thuộc tính ở cấp trường hợp này được đặt thành true nếu trong vòng đời của yêu cầu dịch vụ có hoạt động 'Ticket Reopened'. Thuộc tính giúp bạn dễ dàng nhận diện và phân tích những trường hợp cần làm lại.

Tỷ lệ phiếu được mở lại cao cho thấy lần giải quyết đầu tiên chưa hiệu quả hoặc chưa đầy đủ, gây lãng phí và khiến khách hàng không hài lòng. Lọc các phiếu được mở lại giúp chuyên viên phân tích tìm nguyên nhân gốc rễ, chẳng hạn như lý do mở lại phổ biến, nhân viên hoặc nhóm có tỷ lệ cao, và loại phiếu dễ bị mở lại nhất.

Vì sao điều này quan trọng

Nhận diện các trường hợp cần làm lại, một dấu hiệu quan trọng về chất lượng giải quyết và hiệu quả quy trình. Phân tích những trường hợp này giúp cải thiện tỷ lệ giải quyết ngay từ lần liên hệ đầu tiên.

Lấy dữ liệu ở đâu

Trường được tính toán. Đặt thành true cho một yêu cầu dịch vụ nếu trường hợp đó có sự kiện với Hoạt động = “Phiếu được mở lại”.

Ví dụ
truefalse
Hệ thống nguồn
SourceSystem
Hệ thống dùng để trích xuất dữ liệu, trong trường hợp này là 'Freshdesk'.
Mô tả

Thuộc tính này xác định ứng dụng nguồn của dữ liệu quy trình. Trong phân tích này, giá trị sẽ cố định, chẳng hạn 'Freshdesk', cho biết mọi sự kiện đều đến từ nền tảng dịch vụ khách hàng Freshdesk.

Thoạt nhìn, thuộc tính này có vẻ đơn giản nhưng lại quan trọng đối với việc quản trị dữ liệu và các trường hợp gộp dữ liệu từ nhiều hệ thống. Thuộc tính giúp xác định rõ nguồn gốc và bối cảnh, để nhà phân tích biết dữ liệu đang xem đến từ đâu. Điều này rất cần thiết để giữ tính toàn vẹn của dữ liệu và tạo niềm tin vào kết quả phân tích.

Vì sao điều này quan trọng

Cung cấp thông tin cần thiết về nguồn gốc dữ liệu, rất quan trọng cho việc quản trị dữ liệu và khi kết hợp dữ liệu từ nhiều hệ thống nguồn.

Lấy dữ liệu ở đâu

Đây là giá trị cố định 'Freshdesk', được thêm trong quá trình chuyển đổi dữ liệu để xác định nguồn dữ liệu.

Ví dụ
Freshdesk
Kênh liên lạc
CommunicationChannel
Kênh khách hàng dùng để gửi yêu cầu dịch vụ, chẳng hạn như 'Email', 'Điện thoại', 'Trò chuyện' hoặc 'Cổng thông tin web'.
Mô tả

Thuộc tính này cho biết khách hàng đã liên hệ qua kênh nào. Mỗi kênh có thể có luồng xử lý và thời gian giải quyết khác nhau. Ví dụ, yêu cầu gửi qua trò chuyện có thể được giải quyết nhanh hơn yêu cầu gửi qua email.

Phân tích quy trình theo kênh liên lạc giúp tối ưu phân bổ tài nguyên và đánh giá hiệu quả của từng kênh. Qua đó, bạn có thể biết kênh nào giúp giải quyết nhanh hơn hoặc mang lại mức độ hài lòng cao hơn, từ đó quyết định nên ưu tiên hay đầu tư vào kênh nào.

Vì sao điều này quan trọng

Giúp phân tích hiệu suất và hiệu quả quy trình trên các kênh liên hệ khách hàng như email, điện thoại hoặc trò chuyện.

Lấy dữ liệu ở đâu

Tương ứng với trường 'source' trong đối tượng 'Tickets' của Freshdesk.

Ví dụ
EmailĐiện thoạiCổng thông tin webTrò chuyện
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
Dấu thời gian cho biết lần gần nhất dữ liệu được làm mới từ hệ thống nguồn.
Mô tả

Thuộc tính này ghi lại ngày giờ bộ dữ liệu được trích xuất hoặc cập nhật lần gần nhất từ Freshdesk. Thuộc tính cho biết dữ liệu đang phân tích mới đến mức nào, yếu tố quan trọng để đưa ra quyết định kinh doanh kịp thời và phù hợp.

Nhà phân tích dùng thông tin này để biết dữ liệu bao quát khoảng thời gian nào và xác nhận rằng họ đang làm việc với thông tin mới nhất hiện có. Đây là siêu dữ liệu quan trọng trong mọi dashboard hoặc báo cáo process mining, giúp các bên liên quan biết dữ liệu được cập nhật gần đây hay chưa.

Vì sao điều này quan trọng

Cho biết dữ liệu mới đến mức nào, giúp bảo đảm phân tích và quyết định dựa trên thông tin cập nhật.

Lấy dữ liệu ở đâu

Đây là trường siêu dữ liệu được tạo trong quá trình trích xuất, ghi lại dấu thời gian lấy dữ liệu.

Ví dụ
2023-12-01T08:00:00Z
Mức độ hài lòng
SatisfactionRating
Điểm hài lòng khách hàng gửi sau khi phiếu được giải quyết.
Mô tả

Mức độ hài lòng là chỉ số kết quả quan trọng, thường được thu thập qua khảo sát gửi sau khi giải quyết phiếu. Kết quả thường là điểm số hoặc mức đánh giá như 'Hài lòng', 'Bình thường' hoặc 'Không hài lòng'.

Thuộc tính này giúp đối chiếu các mẫu quy trình với kết quả của khách hàng. Khi phân tích những biến thể quy trình dẫn đến điểm hài lòng thấp, tổ chức có thể xác định hành vi hoặc sự chậm trễ cụ thể ảnh hưởng tiêu cực đến trải nghiệm khách hàng. Qua đó, bạn thấy rõ mối liên hệ giữa hiệu quả quy trình và mức độ hài lòng của khách hàng.

Vì sao điều này quan trọng

Liên kết cách quy trình được thực hiện với kết quả của khách hàng, giúp xác định hành vi nào trong quy trình dẫn đến mức độ hài lòng cao hoặc thấp.

Lấy dữ liệu ở đâu

Dữ liệu này thuộc tính năng đánh giá mức độ hài lòng trong Freshdesk và có thể được truy xuất qua endpoint API 'Surveys' hoặc 'Satisfaction Ratings'.

Ví dụ
5314
Nhóm được giao
AssignedGroup
Nhóm hoặc phòng ban được giao xử lý yêu cầu dịch vụ.
Mô tả

Nhóm được giao là nhóm nhân viên hỗ trợ chịu trách nhiệm xử lý một yêu cầu dịch vụ cụ thể. Phiếu thường được chuyển đến nhóm chuyên trách dựa trên loại yêu cầu hoặc độ phức tạp, chẳng hạn như 'Hỗ trợ kỹ thuật' hoặc 'Phòng thanh toán'.

Thuộc tính này giúp phân tích việc chuyển giao giữa các phòng ban và hiệu suất của từng nhóm. Bạn có thể xác định nhóm nào xử lý nhiều phiếu nhất, nhóm nào có thời gian giải quyết lâu nhất và phiếu được chuyển giữa các nhóm thường xuyên ra sao. Thông tin này giúp tối ưu cơ cấu nhóm và quy trình làm việc.

Vì sao điều này quan trọng

Cho phép phân tích hiệu suất theo nhóm hoặc phòng ban, làm rõ các lần chuyển giao và giúp tìm điểm nghẽn riêng của từng nhóm.

Lấy dữ liệu ở đâu

Tương ứng với trường 'group_id' trong đối tượng 'Tickets' của Freshdesk.

Ví dụ
Hỗ trợ cấp 1Hỗ trợ kỹ thuật cấp 2Thanh toánThành công khách hàng
Sản phẩm
Product
Sản phẩm hoặc dịch vụ liên quan đến yêu cầu của khách hàng.
Mô tả

Thuộc tính này xác định dòng sản phẩm hoặc dịch vụ được đề cập trong yêu cầu. Đây thường là trường tùy chỉnh trong Freshdesk, dùng để phân loại phiếu phục vụ việc chuyển tuyến và lập báo cáo.

Lọc quy trình theo sản phẩm giúp tổ chức phát hiện vấn đề riêng của từng sản phẩm. Chẳng hạn, bạn có thể thấy một sản phẩm tạo ra số phiếu hỗ trợ cao bất thường hoặc đợt ra mắt sản phẩm mới khiến lượng yêu cầu tăng mạnh. Phân tích này cung cấp thông tin hữu ích cho nhóm phát triển và quản lý sản phẩm.

Vì sao điều này quan trọng

Cho phép lọc quy trình theo nhóm sản phẩm, giúp bạn biết sản phẩm nào tạo ra nhiều yêu cầu hỗ trợ nhất hoặc có thời gian giải quyết lâu nhất.

Lấy dữ liệu ở đâu

Đây thường là trường tùy chỉnh. Vị trí chính xác tùy thuộc vào cấu hình Freshdesk, có thể nằm trong phần 'custom_fields' của phản hồi API 'Tickets'.

Ví dụ
Nền tảng AlphaỨng dụng di động BetaGói đăng ký Gamma
Số lần chuyển nhân viên hỗ trợ
AgentTransferCount
Tổng số lần yêu cầu dịch vụ được chuyển từ nhân viên hỗ trợ này sang nhân viên khác.
Mô tả

Chỉ số ở cấp trường hợp này đếm số lần nhân viên được giao xử lý phiếu thay đổi. Chỉ số được tính bằng cách đếm số hoạt động 'Ticket Reassigned' của từng yêu cầu dịch vụ.

Việc chuyển qua lại thường xuyên có thể gây chậm trễ đáng kể và khiến khách hàng khó chịu, vì thông tin về trường hợp có thể bị mất sau mỗi lần bàn giao. Phân tích số lần chuyển giúp phát hiện vấn đề trong khâu phân tuyến ban đầu, thiếu hụt kỹ năng của nhân viên hoặc quy trình quá phức tạp. Mục tiêu thường là giảm các lần chuyển không cần thiết để nâng cao hiệu quả và sự hài lòng của khách hàng.

Vì sao điều này quan trọng

Đo tần suất bàn giao nội bộ, vốn có thể gây chậm trễ và khiến khách hàng khó chịu, qua đó giúp cải thiện khả năng giải quyết ở cấp hỗ trợ đầu tiên.

Lấy dữ liệu ở đâu

Trường được tính toán. Đây là số hoạt động 'Ticket Reassigned' của từng yêu cầu dịch vụ.

Ví dụ
0132
Tên khách hàng
CustomerName
Tên hoặc mã của khách hàng đã gửi yêu cầu dịch vụ.
Mô tả

Thuộc tính này xác định khách hàng gắn với yêu cầu dịch vụ. Nhờ đó, bạn có thể phân tích quy trình từ góc nhìn khách hàng và theo dõi mọi lần tương tác với một khách hàng theo thời gian.

Phân tích theo khách hàng có thể cho thấy khách hàng nào gửi nhiều phiếu nhất hoặc thường gặp vấn đề khiến phiếu phải mở lại. Thông tin này hỗ trợ các hoạt động chăm sóc khách hàng và giúp nhận diện khách hàng có nguy cơ rời bỏ do trải nghiệm dịch vụ kém. Đây cũng là dữ liệu quan trọng để hiểu hành trình đầu cuối của khách hàng qua nhiều yêu cầu dịch vụ.

Vì sao điều này quan trọng

Cho phép xem quy trình từ góc nhìn khách hàng, giúp nhận diện người thường xuyên gửi yêu cầu hoặc khách hàng liên tục gặp vấn đề.

Lấy dữ liệu ở đâu

Thông tin này được liên kết qua 'requester_id' trong đối tượng 'Tickets', kết nối với đối tượng 'Contacts' hoặc 'Users' trong Freshdesk.

Ví dụ
Nguyễn Văn ATrần Thị BGlobal Tech Inc.
Thời gian phản hồi đầu tiên
FirstResponseTime
Thời gian từ lúc tạo phiếu đến khi nhân viên hỗ trợ phản hồi khách hàng lần đầu.
Mô tả

Thời gian phản hồi đầu tiên đo tốc độ khách hàng nhận được phản hồi ban đầu không tự động từ nhân viên hỗ trợ. Chỉ số này được tính bằng thời điểm diễn ra hoạt động 'First Response Sent' trừ thời điểm diễn ra hoạt động 'Ticket Created'.

KPI này cho biết mức độ phản hồi của dịch vụ và ảnh hưởng lớn đến sự hài lòng của khách hàng. Phản hồi nhanh giúp khách hàng biết rằng yêu cầu của họ đã được ghi nhận và đang được xử lý. Phân tích chỉ số này giúp tổ chức đảm bảo đáp ứng SLA phản hồi ban đầu và phục vụ khách hàng kịp thời.

Vì sao điều này quan trọng

Đo tốc độ phản hồi của dịch vụ, yếu tố quan trọng ảnh hưởng đến sự hài lòng của khách hàng và mục tiêu chủ động phục vụ.

Lấy dữ liệu ở đâu

Trường được tính toán bằng khoảng thời gian từ sự kiện 'Ticket Created' đến sự kiện 'First Response Sent'.

Ví dụ
3000009000001800000
Thời hạn giải quyết mục tiêu theo SLA
SlaTargetResolutionTime
Thời gian giải quyết yêu cầu dịch vụ đã thỏa thuận trong hợp đồng hoặc đặt làm mục tiêu.
Mô tả

Thuộc tính này xác định thời gian mục tiêu để giải quyết yêu cầu dịch vụ theo Thỏa thuận mức dịch vụ (SLA). Thời hạn này thường phụ thuộc vào mức độ ưu tiên hoặc loại phiếu.

Đây là dữ liệu đầu vào quan trọng để tính mức độ tuân thủ SLA. So sánh thời gian giải quyết thực tế với thời hạn mục tiêu sẽ cho biết yêu cầu đã 'Đạt' hay 'Vi phạm'. Phân tích hiệu suất SLA theo loại yêu cầu, nhóm hoặc nhân viên hỗ trợ là phần cốt lõi trong quản lý dịch vụ.

Vì sao điều này quan trọng

Làm cơ sở đo lường mức độ tuân thủ SLA, một chỉ số hiệu suất quan trọng đối với mọi tổ chức dịch vụ khách hàng.

Lấy dữ liệu ở đâu

Thông tin này có thể nằm trong trường như 'fr_due_by' (phản hồi đầu tiên) hoặc 'due_by' (giải quyết) của đối tượng 'Tickets' trong Freshdesk. Nếu không có, bạn có thể cần tính dựa trên các quy tắc chính sách SLA.

Ví dụ
2023-10-25T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
Bắt buộc Nên có Không bắt buộc

Hoạt động dịch vụ khách hàng

Đây là các bước chính và cột mốc quan trọng cần ghi lại trong event log để khám phá quy trình chính xác và xác định điểm nghẽn.
5 Nên có 8 Không bắt buộc
Hoạt động Mô tả
Đóng phiếu hỗ trợ
Đây là hoạt động cuối cùng, đánh dấu phiếu hỗ trợ được đóng vĩnh viễn. Hệ thống thường tự động thực hiện việc này sau một khoảng thời gian nhất định ở trạng thái 'Resolved' nếu khách hàng không phản hồi thêm.
Vì sao điều này quan trọng

Hoạt động này đánh dấu kết thúc chính thức vòng đời của yêu cầu dịch vụ. Đây là mốc cuối để tính chính xác tổng thời gian xử lý từ đầu đến cuối.

Lấy dữ liệu ở đâu

Lấy từ nhật ký “Hoạt động phiếu”, nơi ghi lại lần chuyển trạng thái cuối cùng sang “Đã đóng”. Thường thì thao tác tự động của hệ thống sẽ kích hoạt thay đổi này.

Thu thập

Sự kiện được ghi lại khi trường 'Status' của phiếu hỗ trợ được cập nhật thành 'Closed'.

Loại sự kiện explicit
Gửi phản hồi đầu tiên
Đánh dấu phản hồi công khai đầu tiên mà nhân viên gửi cho khách hàng sau khi tạo phiếu hỗ trợ. Freshdesk ghi nhận sự kiện này để đo 'First Response Time' phục vụ theo dõi SLA.
Vì sao điều này quan trọng

Đây là mốc quan trọng để đo tốc độ phản hồi khách hàng và mức độ tuân thủ SLA. Phân tích thời gian đến hoạt động này giúp xác định chậm trễ trong lần tương tác đầu tiên với khách hàng.

Lấy dữ liệu ở đâu

Đây là sự kiện cụ thể mà Freshdesk theo dõi để phục vụ SLA. Sự kiện tương ứng với dấu thời gian của bình luận công khai đầu tiên do nhân viên thêm vào.

Thu thập

Được xác định qua phản hồi công khai đầu tiên của nhân viên trong lịch sử trao đổi của phiếu hỗ trợ.

Loại sự kiện explicit
Phân công phiếu hỗ trợ
Đây là sự kiện phân công phiếu hỗ trợ cho một nhân viên hoặc nhóm cụ thể để xử lý. Nhật ký phiếu hỗ trợ ghi nhận sự kiện này mỗi khi trường nhân viên hoặc nhóm được phân công có giá trị mới hoặc thay đổi.
Vì sao điều này quan trọng

Theo dõi việc phân công giúp phân tích khối lượng công việc của nhân viên, xác định điểm chưa hiệu quả trong khâu điều phối và đo KPI về thời gian phân công. Qua đó, bạn hiểu được công việc được phân bổ ra sao và chậm trễ xảy ra ở đâu trước khi bắt đầu xử lý.

Lấy dữ liệu ở đâu

Lấy từ nhật ký “Hoạt động phiếu”, nơi ghi lại thời điểm các trường “Nhân viên xử lý” hoặc “Nhóm” thay đổi.

Thu thập

Sự kiện được ghi lại khi trường 'Assigned to' được cập nhật cho nhân viên hoặc nhóm.

Loại sự kiện explicit
Tạo phiếu hỗ trợ
Đây là sự kiện đầu tiên trong vòng đời dịch vụ khách hàng, đánh dấu thời điểm yêu cầu của khách hàng được ghi nhận chính thức trong Freshdesk. Hệ thống ghi nhận hoạt động này khi tạo phiếu hỗ trợ mới, qua email, cổng thông tin, điện thoại hoặc tích hợp API.
Vì sao điều này quan trọng

Hoạt động này là điểm bắt đầu của mỗi trường hợp. Đây là dữ liệu cần thiết để tính tổng thời gian xử lý và phân tích xu hướng số lượng phiếu hỗ trợ theo kênh hoặc loại yêu cầu.

Lấy dữ liệu ở đâu

Đây là sự kiện được ghi rõ trong nhật ký “Hoạt động phiếu” của Freshdesk. Sự kiện được tạo tự động khi có phiếu mới.

Thu thập

Được ghi trực tiếp vào luồng hoạt động của phiếu hỗ trợ khi phiếu được tạo.

Loại sự kiện explicit
Xử lý xong phiếu hỗ trợ
Đây là mốc quan trọng khi nhân viên đã đưa ra giải pháp và chuyển trạng thái phiếu hỗ trợ sang 'Resolved'. Lịch sử phiếu ghi lại rõ thay đổi trạng thái này.
Vì sao điều này quan trọng

Hoạt động này đánh dấu thời điểm kết thúc công việc xử lý phiếu và là cơ sở để đo thời gian xử lý. Đây là sự kiện quan trọng để phân tích hiệu suất của nhân viên và hiệu quả chung của quy trình.

Lấy dữ liệu ở đâu

Lấy từ nhật ký “Hoạt động phiếu”, nơi ghi lại thời điểm trạng thái chuyển sang “Đã giải quyết”.

Thu thập

Sự kiện được ghi lại khi trường 'Status' của phiếu hỗ trợ được cập nhật thành 'Resolved'.

Loại sự kiện explicit
Chuyển trạng thái sang chờ xử lý
Hoạt động này xảy ra khi nhân viên chờ khách hàng cung cấp thông tin và chuyển trạng thái phiếu hỗ trợ sang 'Pending'. Nhật ký hoạt động của phiếu ghi rõ thay đổi trạng thái này.
Vì sao điều này quan trọng

Hoạt động này xác định khoảng thời gian quy trình tạm dừng để chờ thông tin từ bên ngoài. Phân tích thời gian ở trạng thái này giúp đo lường chậm trễ từ phía khách hàng và hỗ trợ phân tích tuân thủ SLA, vì bộ đếm SLA thường tạm dừng trong trạng thái này.

Lấy dữ liệu ở đâu

Lấy từ nhật ký “Hoạt động phiếu”, nơi ghi lại mọi thay đổi trạng thái, bao gồm cả khi chuyển sang “Đang chờ”.

Thu thập

Sự kiện được ghi lại khi trường 'Status' của phiếu hỗ trợ được cập nhật thành 'Pending'.

Loại sự kiện explicit
Gửi khảo sát mức độ hài lòng
Đây là sự kiện gửi khảo sát mức độ hài lòng của khách hàng, thường được kích hoạt bởi quy tắc tự động hóa sau khi xử lý xong phiếu hỗ trợ. Sự kiện có thể được ghi nhận nếu thao tác tự động hóa được lưu trong lịch sử phiếu.
Vì sao điều này quan trọng

Đánh dấu thời điểm bắt đầu thu thập phản hồi. Đối chiếu câu trả lời khảo sát với các biến thể quy trình giúp hiểu sâu hơn về tác động của hiệu suất quy trình đến mức độ hài lòng của khách hàng.

Lấy dữ liệu ở đâu

Sự kiện này thường được kích hoạt bởi 'Automation Rule'. Việc sự kiện có xuất hiện riêng trong nhật ký hoạt động của phiếu hay không tùy thuộc vào cấu hình ghi nhật ký tự động hóa của Freshdesk.

Thu thập

Sự kiện được ghi lại khi quy tắc tự động hóa chạy sau khi xử lý xong phiếu hỗ trợ.

Loại sự kiện explicit
Khách hàng phản hồi
Đây là phản hồi hoặc liên lạc mới nhận được từ khách hàng. Sự kiện được ghi rõ trong luồng trao đổi của phiếu hỗ trợ và thường khiến trạng thái chuyển từ 'Pending' về 'Open'.
Vì sao điều này quan trọng

Hoạt động này giúp hiểu rõ quá trình trao đổi qua lại với khách hàng và đo thời gian phản hồi của khách hàng. Hoạt động cũng khởi động lại bộ đếm SLA đã tạm dừng, ảnh hưởng đến các chỉ số tuân thủ.

Lấy dữ liệu ở đâu

Được ghi thành mục mới trong luồng trao đổi của phiếu hỗ trợ. Sự kiện được liên kết với hồ sơ liên hệ của khách hàng.

Thu thập

Khách hàng liên hệ thêm ghi chú công khai mới vào phiếu hỗ trợ.

Loại sự kiện explicit
Mở lại phiếu hỗ trợ
Hoạt động này xảy ra khi khách hàng phản hồi một phiếu hỗ trợ đang ở trạng thái 'Resolved', khiến trạng thái tự động chuyển lại thành 'Open'. Hệ thống ghi lại rõ sự kiện này.
Vì sao điều này quan trọng

Tỷ lệ mở lại cao cho thấy giải pháp ban đầu chưa hiệu quả, dẫn đến phải làm lại và khiến khách hàng không hài lòng. Phân tích hoạt động này rất cần thiết để xem xét việc mở lại phiếu hỗ trợ và cải thiện khả năng xử lý ngay từ lần liên hệ đầu tiên.

Lấy dữ liệu ở đâu

Ghi nhận sự kiện này khi phản hồi của khách hàng khiến trạng thái tự động chuyển từ “Đã giải quyết” về “Đang mở”. Nhật ký “Hoạt động phiếu” lưu lại thay đổi trạng thái này.

Thu thập

Trạng thái chuyển từ 'Resolved' sang 'Open' sau khi khách hàng tương tác.

Loại sự kiện explicit
Phân công lại phiếu hỗ trợ
Sự kiện này xảy ra khi phiếu hỗ trợ được chuyển từ nhân viên hoặc nhóm này sang nhân viên hoặc nhóm khác sau lần phân công đầu tiên. Nhật ký hoạt động của phiếu ghi rõ sự kiện này dưới dạng thay đổi người phụ trách.
Vì sao điều này quan trọng

Việc phân công lại thường xuyên hoặc chuyển phiếu giữa các nhân viên với tỷ lệ cao có thể cho thấy phiếu được điều phối sai từ đầu hoặc kiến thức bị chia cắt giữa các nhóm. Phân tích này giúp tìm ra cơ hội cải thiện khả năng xử lý ngay từ lần liên hệ đầu tiên.

Lấy dữ liệu ở đâu

Theo dõi các thay đổi ở trường “Nhân viên xử lý” hoặc “Nhóm” trong nhật ký “Hoạt động phiếu” sau lần phân công đầu tiên.

Thu thập

Cập nhật trường 'Assigned to' sau khi phiếu đã được phân công lần đầu.

Loại sự kiện explicit
Thay đổi mức độ ưu tiên của phiếu hỗ trợ
Sự kiện này xảy ra khi nhân viên hoặc quy tắc tự động hóa thay đổi mức độ ưu tiên của phiếu hỗ trợ, chẳng hạn từ 'Low' sang 'High'. Nhật ký hoạt động của phiếu ghi lại rõ thay đổi này.
Vì sao điều này quan trọng

Thay đổi mức độ ưu tiên có thể cho thấy phiếu được chuyển cấp hoặc mức độ khẩn cấp của vấn đề được đánh giá lại. Phân tích những thay đổi này giúp hiểu nguyên nhân chuyển cấp và tác động đến thời gian xử lý.

Lấy dữ liệu ở đâu

Lấy từ nhật ký “Hoạt động phiếu”, nơi ghi lại mọi thay đổi thuộc tính của phiếu, bao gồm cả trường “Mức độ ưu tiên”.

Thu thập

Sự kiện được ghi lại khi giá trị trường 'Priority' được cập nhật.

Loại sự kiện explicit
Thêm ghi chú nội bộ
Nhân viên thêm ghi chú riêng vào phiếu hỗ trợ để phối hợp với các nhân viên khác. Đây là sự kiện được ghi rõ trong luồng hoạt động của phiếu và chỉ nhân viên mới xem được.
Vì sao điều này quan trọng

Theo dõi ghi chú nội bộ giúp phân tích cách phối hợp và xác định những vấn đề cần nhiều trao đổi trong nhóm. Nếu có nhiều ghi chú nội bộ trước khi xử lý xong, vấn đề có thể phức tạp hoặc nhóm còn thiếu thông tin cần thiết.

Lấy dữ liệu ở đâu

Được ghi là 'Private Note' trong lịch sử trao đổi của phiếu hỗ trợ, tách biệt với phản hồi công khai gửi khách hàng.

Thu thập

Sự kiện được ghi lại khi nhân viên thêm ghi chú được đánh dấu là 'Private'.

Loại sự kiện explicit
Vi phạm SLA
Đây là sự kiện được tính toán khi thời gian phản hồi hoặc xử lý phiếu hỗ trợ vượt quá mục tiêu trong chính sách SLA. Freshdesk theo dõi trạng thái SLA và đánh dấu phiếu là 'violated'. Dữ liệu này có thể dùng để xác định hoạt động vi phạm SLA.
Vì sao điều này quan trọng

Hoạt động này hỗ trợ trực tiếp cho việc phân tích tuân thủ SLA, giúp xác định chính xác thời điểm và khâu không đáp ứng cam kết về mức dịch vụ. Đây là dữ liệu quan trọng để tìm ra nguyên nhân chậm trễ mang tính hệ thống.

Lấy dữ liệu ở đâu

Sự kiện này được suy ra hoặc tính toán từ trạng thái 'SLA' của phiếu hỗ trợ. Có thể tạo hoạt động khi trạng thái SLA của phiếu chuyển thành 'Violated', hoặc bằng cách so sánh dấu thời gian phản hồi và xử lý với mục tiêu SLA.

Thu thập

Suy ra từ dữ liệu phiếu hỗ trợ khi 'Time to Resolve' vượt quá 'SLA Target Resolution Time'.

Loại sự kiện calculated
Nên có Không bắt buộc

Hướng dẫn trích xuất dữ liệu

Cách lấy dữ liệu từ Freshdesk

Sẵn sàng bắt đầu?

Bắt đầu cải thiện vận hành dịch vụ khách hàng bằng cách hiểu rõ quy trình của bạn. Mẫu này là bước đầu tiên để tối ưu hóa dựa trên dữ liệu.

Cải thiện dịch vụ khách hàng trên Freshdesk ngay hôm nay

Đạt tỷ lệ xử lý ngay lần liên hệ đầu tiên 80% và làm khách hàng hài lòng hơn.

Bắt đầu dùng thử miễn phí

Không cần thẻ tín dụng, thiết lập chỉ trong vài phút