Mẫu dữ liệu dịch vụ khách hàng
Mẫu dữ liệu dịch vụ khách hàng
- 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 dịch vụ khách hàng trong Microsoft Dynamics 365
Thuộc tính dịch vụ khách hàng
| Tên | Mô tả | ||
|---|---|---|---|
|
Yêu cầu dịch vụ
ServiceRequest
|
Mã định danh duy nhất của một yêu cầu dịch vụ khách hàng, còn gọi là vụ việc hoặc phiếu yêu cầu. | ||
|
Mô tả
Yêu cầu dịch vụ là mã định danh chính, liên kết mọi hoạt động liên quan đến một yêu cầu hoặc vấn đề của khách hàng. Đây là Case ID dùng trong process mining, giúp tạo góc nhìn đầy đủ và nhất quán về từng tương tác với khách hàng, từ lúc tạo đến khi đóng. Phân tích theo yêu cầu dịch vụ giúp theo dõi toàn bộ hành trình, đo thời gian giải quyết và tìm ra các mẫu chung giữa những vụ việc tương tự.
Vì sao điều này quan trọng
Đây là Case ID thiết yếu, kết nối mọi sự kiện liên quan thành một phiên bản quy trình duy nhất, giúp thực hiện phân tích quy trình từ đầu đến cuối.
Lấy dữ liệu ở đâu
Đây là khóa chính của thực thể Case (incident) trong Microsoft Dynamics 365 Customer Service.
Ví dụ
CAS-01024-F3B4V6SR-2023-00589TKT-4815162342
|
|||
|
Hệ thống nguồn
SourceSystem
|
Xác định hệ thống nguồn nơi dữ liệu được trích xuất. | ||
|
Mô tả
Thuộc tính này cho biết nguồn gốc của dữ liệu sự kiện. Với quy trình này, giá trị luôn xác định Microsoft Dynamics 365 Customer Service là nguồn. Trong môi trường có nhiều hệ thống, trường này rất quan trọng để phân biệt nguồn dữ liệu và đảm bảo khả năng truy xuất nguồn gốc dữ liệu.
Vì sao điều này quan trọng
Thuộc tính này giúp truy xuất nguồn gốc dữ liệu rõ ràng, rất quan trọng đối với quản trị dữ liệu và xử lý sự cố không nhất quán, nhất là khi phân tích dữ liệu kết hợp từ nhiều hệ thống.
Lấy dữ liệu ở đâu
Đây thường là giá trị tĩnh được thêm vào trong quá trình trích xuất và chuyển đổi dữ liệu để ghi nhãn nguồn gốc của tập dữ liệu.
Ví dụ
Microsoft Dynamics 365 Customer Service
|
|||
|
Hoạt động
ActivityName
|
Tên của sự kiện nghiệp vụ cụ thể xảy ra tại một thời điểm trong quá trình xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này mô tả một bước hoặc lần đổi trạng thái trong quy trình dịch vụ khách hàng, chẳng hạn như 'Tạo vụ việc', 'Nhân viên hỗ trợ tìm hiểu vấn đề' hoặc 'Giải quyết vụ việc'. Các hoạt động này tạo nên sơ đồ quy trình, giúp bạn hình dung và phân tích luồng quy trình. Khi kết hợp hoạt động với dấu thời gian, bạn sẽ có một sự kiện xác định trình tự quy trình.
Vì sao điều này quan trọng
Hoạt động xác định các bước trong quy trình. Phân tích trình tự và tần suất hoạt động là việc cốt yếu để hiểu luồng quy trình, xác định sai lệch và tìm điểm nghẽn.
Lấy dữ liệu ở đâu
Thường được xác định bằng cách ánh xạ các thay đổi trạng thái (
Ví dụ
Tạo vụ việcNhân viên hỗ trợ tìm hiểu vấn đềĐề xuất giải pháp cho khách hàngĐóng vụ việc
|
|||
|
Lần cập nhật dữ liệu gần nhất
LastDataUpdate
|
Dấu thời gian của lần làm mới hoặc trích xuất dữ liệu gần nhất từ hệ thống nguồn. | ||
|
Mô tả
Thuộc tính này cho biết lần gần nhất dữ liệu được lấy từ Microsoft Dynamics 365. Thuộc tính giúp xác định dữ liệu đang phân tích mới đến mức nào, đồng thời cần thiết cho việc báo cáo và theo dõi. Nhờ đó, người dùng biết dữ liệu được cập nhật đến thời điểm nào khi xem dashboard và kết quả phân tích.
Vì sao điều này quan trọng
Cho người dùng biết dữ liệu được cập nhật gần đây đến đâu. Đây là thông tin quan trọng để đưa ra quyết định kinh doanh kịp thời và chính xác dựa trên phân tích quy trình.
Lấy dữ liệu ở đâu
Giá trị này được tạo và gắn vào tập dữ liệu khi trích xuất dữ liệu.
Ví dụ
2023-10-27T08:00:00Z
|
|||
|
Thời gian bắt đầu
EventTime
|
Dấu thời gian cho biết thời điểm hoạt động diễn ra. | ||
|
Mô tả
Thuộc tính này ghi lại chính xác ngày giờ một hoạt động cụ thể diễn ra. Đây là dữ liệu thiết yếu để sắp xếp sự kiện đúng thứ tự và thực hiện mọi phân tích dựa trên thời gian, bao gồm tính thời gian chu kỳ, thời lượng và thời gian chờ giữa các hoạt động. Dấu thời gian chính xác và nhất quán rất quan trọng để đảm bảo kết quả phân tích process mining đáng tin cậy.
Vì sao điều này quan trọng
Dấu thời gian sắp xếp sự kiện theo trình tự thời gian và cho phép tính mọi khoảng thời lượng. Đây là cơ sở quan trọng để phân tích hiệu suất và xác định điểm nghẽn.
Lấy dữ liệu ở đâu
Thường tương ứng với các trường như
Ví dụ
2023-04-15T10:00:00Z2023-05-20T14:35:10Z2023-06-01T09:12:45Z
|
|||
|
Kênh
Channel
|
Kênh liên lạc mà khách hàng dùng để gửi yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này xác định nguồn gốc tương tác với khách hàng, chẳng hạn như điện thoại, email, cổng thông tin web hoặc trò chuyện. Mỗi kênh thường có luồng quy trình, kỳ vọng của khách hàng và mức độ phức tạp khi giải quyết khác nhau. Phân tích quy trình theo kênh giúp cải tiến quy trình làm việc và phân bổ tài nguyên phù hợp với từng kênh.
Vì sao điều này quan trọng
Cho biết các kênh liên hệ khác nhau ảnh hưởng thế nào đến hiệu quả quy trình, thời gian giải quyết và mức độ hài lòng của khách hàng.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Case Origin' (caseorigincode) trên thực thể Case (incident).
Ví dụ
Điện thoạiEmailWebTrò chuyện
|
|||
|
Loại yêu cầu dịch vụ
ServiceRequestType
|
Danh mục hoặc phân loại chính của yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này phân loại yêu cầu dịch vụ theo tính chất, chẳng hạn như 'Yêu cầu về thanh toán', 'Hỗ trợ kỹ thuật' hoặc 'Phản hồi về sản phẩm'. Đây là cơ sở để chia nhỏ phân tích quy trình và tìm hiểu cách xử lý từng loại yêu cầu. Phân tích theo loại có thể cho thấy một số danh mục mất nhiều thời gian giải quyết hơn, có tỷ lệ chuyển cấp cao hơn hoặc đi theo luồng quy trình khác.
Vì sao điều này quan trọng
Cho phép chia nhỏ quy trình để tìm điểm nghẽn, nhu cầu tài nguyên và cơ hội cải tiến theo từng loại yêu cầu, từ đó hỗ trợ định tuyến và xử lý phù hợp hơn.
Lấy dữ liệu ở đâu
Thông tin này thường được lưu trong trường 'Subject' (subjectid) hoặc trường danh mục tùy chỉnh trên thực thể Case (incident).
Ví dụ
Yêu cầu về thanh toánHỗ trợ kỹ thuậtPhản hồi về sản phẩmQuản lý tài khoản
|
|||
|
Lý do trạng thái
StatusReason
|
Cho biết lý do cụ thể hơn về trạng thái hiện tại của yêu cầu dịch vụ. | ||
|
Mô tả
Vụ việc có thể có trạng thái chung như 'Active' hoặc 'Resolved', còn Lý do trạng thái cung cấp thêm thông tin cụ thể, chẳng hạn như 'Information Provided' hoặc 'Problem Solved'. Thuộc tính này rất quan trọng để hiểu rõ cách thức và lý do vụ việc đi qua các giai đoạn trong vòng đời. Ví dụ, thuộc tính giúp phân biệt vụ việc được giải quyết thành công với vụ việc bị khách hàng hủy, điều cần thiết để phân tích kết quả chính xác.
Vì sao điều này quan trọng
Cung cấp thông tin chi tiết về kết quả vụ việc và lý do thay đổi trạng thái, giúp phân tích chính xác hơn các hướng giải quyết và nguyên nhân gốc rễ.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Status Reason' (statuscode) trên thực thể Case (incident).
Ví dụ
Đang xử lýTạm giữĐã giải quyết vấn đềĐã cung cấp thông tin
|
|||
|
Mức độ ưu tiên
Priority
|
Mức độ ưu tiên được gán cho yêu cầu dịch vụ, cho biết mức độ khẩn cấp. | ||
|
Mô tả
Thuộc tính này xác định mức độ khẩn cấp của yêu cầu dịch vụ, thường được phân loại là Thấp, Bình thường, Cao hoặc Khẩn cấp. Mức độ ưu tiên giúp xác định thứ tự xử lý vụ việc và thường quyết định mục tiêu SLA. Phân tích ảnh hưởng của mức độ ưu tiên đến luồng quy trình, phân bổ tài nguyên và thời gian giải quyết rất quan trọng để đảm bảo các vấn đề cấp thiết được xử lý kịp thời.
Vì sao điều này quan trọng
Giúp xác định yêu cầu ưu tiên cao có được xử lý nhanh hơn và đạt mục tiêu hay không, cũng như mức độ ưu tiên ảnh hưởng thế nào đến hiệu suất chung của quy trình.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Priority' (prioritycode) trên thực thể Case (incident).
Ví dụ
ThấpBình thườngCao
|
|||
|
Tên khách hàng
CustomerName
|
Tên khách hàng hoặc tài khoản liên kết với yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này xác định khách hàng đã gử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, xác định khách hàng nào gửi nhiều yêu cầu nhất, mất nhiều thời gian giải quyết nhất hoặc gặp vấn đề phức tạp nhất. Đây là thông tin thiết yếu để quản lý quan hệ khách hàng và cải thiện dịch vụ theo nhu cầu từng khách hàng.
Vì sao điều này quan trọng
Cho phép phân tích ở cấp khách hàng để tìm ra xu hướng, cải thiện dịch vụ cho các tài khoản quan trọng và hiểu rõ hành trình khách hàng.
Lấy dữ liệu ở đâu
Đây là trường tra cứu 'Customer' (customerid) trên thực thể Case (incident), có thể trỏ đến bản ghi Account hoặc Contact.
Ví dụ
Global Tech Inc.Jane DoeInnovate Solutions
|
|||
|
Tên nhân viên hỗ trợ
AgentName
|
Tên nhân viên hỗ trợ khách hàng hoặc người dùng chịu trách nhiệm thực hiện hoạt động. | ||
|
Mô tả
Thuộc tính này xác định nhân viên hỗ trợ hoặc người dùng hệ thống cụ thể đã thực hiện một hoạt động, chẳng hạn như nhận mục từ hàng đợi hoặc giải quyết vụ việc. Đây là dữ liệu quan trọng để phân tích hiệu suất của nhân viên, phân bổ khối lượng công việc và bố trí tài nguyên. Theo dõi hoạt động ở cấp nhân viên giúp tổ chức xác định người có hiệu suất cao, nhu cầu đào tạo và tình trạng mất cân đối trong khối lượng công việc.
Vì sao điều này quan trọng
Cho phép phân tích hiệu suất cá nhân và đội ngũ, hỗ trợ cân bằng khối lượng công việc và xác định cơ hội hướng dẫn để nâng cao chất lượng dịch vụ.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Owner' (ownerid) trên thực thể Case (incident), liên kết đến thực thể System User (systemuser).
Ví dụ
Alice SmithBob JohnsonHệ thống
|
|||
|
Thời hạn giải quyết theo SLA
SlaTargetResolutionTime
|
Thời hạn đã thỏa thuận trong hợp đồng để giải quyết yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này xác định khoảng 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) đang áp dụng. Đây là mốc chuẩn để so sánh với hiệu suất thực tế. Giá trị này rất quan trọng đối với dashboard theo dõi mức độ tuân thủ SLA và việc tính KPI 'SLA Compliance Rate', giúp xác định những khâu chưa đáp ứng cam kết dịch vụ.
Vì sao điều này quan trọng
Đây là mốc chuẩn chính để đo hiệu suất dịch vụ so với cam kết, đồng thời hỗ trợ trực tiếp việc phân tích mức độ tuân thủ SLA và các trường hợp vi phạm.
Lấy dữ liệu ở đâu
Giá trị này được xác định theo cấu hình SLA trong Dynamics 365 và liên kết với vụ việc thông qua SLA KPI Instances.
Ví dụ
2592008640014400
|
|||
|
Đã chuyển cấp
IsEscalated
|
Cờ cho biết yêu cầu dịch vụ đã được chuyển cấp hay chưa. | ||
|
Mô tả
Thuộc tính dạng đúng/sai này cho biết yêu cầu dịch vụ có được chuyển cấp hay không. Việc chuyển cấp xảy ra khi bộ phận hỗ trợ cấp 1 không thể xử lý vấn đề và cần đến nhóm cấp cao hơn hoặc chuyên gia. Theo dõi cờ này rất quan trọng đối với bảng điều khiển Lộ trình chuyển cấp nội bộ và KPI Tỷ lệ chuyển cấp nội bộ. Dữ liệu giúp xác định nguyên nhân gốc rễ dẫn đến việc chuyển cấp và những điểm yếu ở các cấp hỗ trợ ban đầu.
Vì sao điều này quan trọng
Đo trực tiếp tần suất chuyển cấp, qua đó làm rõ các vấn đề trong việc xử lý ngay từ lần liên hệ đầu tiên và chỉ ra những khâu cần cải tiến quy trình hoặc nâng cao kỹ năng của nhân viên hỗ trợ.
Lấy dữ liệu ở đâu
Tương ứng với trường 'Is Escalated' (isescalated) trong thực thể Case (incident).
Ví dụ
truefalse
|
|||
|
Điểm CSAT
CustomerSatisfactionScore
|
Điểm hài lòng do khách hàng đánh giá sau khi yêu cầu được xử lý. | ||
|
Mô tả
Thuộc tính này lưu điểm số hoặc mức đánh giá từ khảo sát mức độ hài lòng của khách hàng (CSAT), thường được thu thập sau khi đóng yêu cầu dịch vụ. Đây là thước đo trực tiếp cảm nhận của khách hàng về chất lượng dịch vụ. Dữ liệu này rất quan trọng đối với bảng điều khiển Xu hướng hài lòng của khách hàng và KPI Điểm CSAT trung bình sau khi xử lý, giúp liên kết hiệu quả quy trình với kết quả dành cho khách hàng.
Vì sao điều này quan trọng
Đo trực tiếp mức độ hài lòng của khách hàng, giúp tổ chức đối chiếu cách vận hành quy trình với cảm nhận của khách hàng và xác định hướng cải tiến.
Lấy dữ liệu ở đâu
Thông tin này thường lấy từ một thực thể khảo sát liên quan, chẳng hạn như Customer Voice, rồi liên kết với thực thể Case (incident).
Ví dụ
5341
|
|||
|
ID bài viết kiến thức
KnowledgeArticleId
|
Mã định danh của bài viết trong cơ sở kiến thức được liên kết với yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này ghi lại ID của bài viết kiến thức được sử dụng hoặc liên kết trong quá trình xử lý yêu cầu dịch vụ. Dữ liệu cho biết nhân viên hỗ trợ khai thác cơ sở kiến thức hiệu quả đến đâu để giải quyết vấn đề của khách hàng. Đây là thông tin quan trọng cho bảng điều khiển Mức độ sử dụng bài viết kiến thức và KPI tương ứng, giúp đánh giá giá trị cũng như mức độ đầy đủ của cơ sở kiến thức.
Vì sao điều này quan trọng
Theo dõi việc sử dụng cơ sở kiến thức, giúp bạn biết nhân viên hỗ trợ có tận dụng tài nguyên sẵn có để xử lý vấn đề nhanh và nhất quán hơn hay không.
Lấy dữ liệu ở đâu
Thông tin này nằm trong mối quan hệ giữa các thực thể Case (incident) và Knowledge Article (knowledgearticle).
Ví dụ
KA-01337KA-02048
|
|||
|
Làm lại
IsRework
|
Cờ được tính toán để cho biết yêu cầu có phát sinh hoạt động làm lại hay không. | ||
|
Mô tả
Cờ dạng đúng/sai này xác định các yêu cầu có vòng lặp làm lại hoặc hoạt động lặp lại, chẳng hạn như nhiều sự kiện 'Yêu cầu khách hàng cung cấp thông tin' hoặc sự kiện 'Kích hoạt lại yêu cầu' sau khi đã xử lý xong. Cờ được tính bằng cách phân tích trình tự hoạt động để tìm dấu hiệu kém hiệu quả hoặc xử lý chưa đúng ngay từ đầu. Thuộc tính này rất quan trọng đối với bảng điều khiển Phân tích việc làm lại và liên hệ lặp lại.
Vì sao điều này quan trọng
Giúp định lượng và xác định các điểm kém hiệu quả trong quy trình, để chuyên viên phân tích tập trung vào nguyên nhân gốc rễ của công việc lặp lại và nguồn lực bị lãng phí.
Lấy dữ liệu ở đâu
Được tính bằng cách dùng process mining để phát hiện các trình tự hoạt động cụ thể (ví dụ: Đã xử lý xong -> Kích hoạt lại) hoặc hoạt động lặp lại trong một yêu cầu.
Ví dụ
truefalse
|
|||
|
Nhóm phụ trách
OwnerTeam
|
Nhóm hiện chịu trách nhiệm xử lý yêu cầu dịch vụ. | ||
|
Mô tả
Thuộc tính này xác định nhóm chịu trách nhiệm xử lý yêu cầu dịch vụ. Yêu cầu có thể thuộc về một nhân viên hỗ trợ hoặc một nhóm (hàng đợi). Phân tích theo nhóm rất cần thiết để hiểu hiệu quả hoạt động, cách phân bổ khối lượng công việc giữa các cấp hỗ trợ hoặc nhóm chuyên môn, cũng như tìm ra khác biệt trong quy trình giữa các nhóm.
Vì sao điều này quan trọng
Cho phép phân tích hiệu quả ở cấp nhóm, cần thiết để quản lý tốt các cấp hỗ trợ và nhóm chuyên môn.
Lấy dữ liệu ở đâu
Lấy từ trường 'Owner' (ownerid) trong thực thể Case (incident) khi chủ sở hữu là bản ghi Team thay vì System User.
Ví dụ
Hỗ trợ cấp 1Bộ phận thanh toánChuyên gia kỹ thuật
|
|||
|
Sản phẩm liên quan
ProductInvolved
|
Sản phẩm gắn với yêu cầu dịch vụ của khách hàng. | ||
|
Mô tả
Thuộc tính này xác định sản phẩm hoặc dịch vụ cụ thể liên quan đến vấn đề của khách hàng. Nhờ đó, bạn có thể phân tích quy trình dịch vụ theo từng sản phẩm để biết sản phẩm nào tạo ra nhiều yêu cầu hỗ trợ hơn, có vấn đề phức tạp hơn hoặc cần nhân viên hỗ trợ có chuyên môn riêng. Kết quả phân tích giúp cải tiến sản phẩm và lập kế hoạch tài nguyên.
Vì sao điều này quan trọng
Cho phép phân tích quy trình theo từng sản phẩm để tìm vấn đề lặp lại, cải thiện tài liệu hỗ trợ và phân bổ chuyên gia phù hợp.
Lấy dữ liệu ở đâu
Tương ứng với trường tra cứu 'Product' (productid) trong thực thể Case (incident).
Ví dụ
Máy in Alpha-100Phần mềm CRM ZetaGói dữ liệu Omega
|
|||
|
Vi phạm SLA
IsSlaBreached
|
Cờ được tính toán để cho biết yêu cầu dịch vụ có vượt quá thời hạn SLA hay không. | ||
|
Mô tả
Cờ dạng đúng/sai này được xác định bằng cách so sánh thời gian xử lý thực tế của yêu cầu dịch vụ với 'Thời gian xử lý mục tiêu theo SLA'. Cờ được đặt thành đúng nếu thời gian thực tế dài hơn thời gian mục tiêu. Thuộc tính này là cơ sở cho bảng điều khiển Theo dõi tuân thủ SLA và KPI Tỷ lệ tuân thủ SLA, đồng thời cho biết rõ từng yêu cầu có đáp ứng SLA hay không.
Vì sao điều này quan trọng
Cho biết rõ từng yêu cầu có đáp ứng SLA hay không, giúp bạn dễ lọc, tổng hợp và phân tích nguyên nhân gốc rễ của các trường hợp vi phạm.
Lấy dữ liệu ở đâu
Được tính bằng cách so sánh 'ServiceRequestCycleTime' với 'SlaTargetResolutionTime'.
Ví dụ
truefalse
|
|||
|
Xử lý ngay lần liên hệ đầu tiên
IsFirstContactResolution
|
Cờ cho biết yêu cầu có được xử lý ngay trong lần liên hệ đầu tiên hay không. | ||
|
Mô tả
Thuộc tính được tính toán này xác định các yêu cầu dịch vụ được xử lý mà không cần khách hàng liên hệ lại hoặc không bị chậm trễ đáng kể đến mức phải chuyển sang nhân viên khác. Việc xác định chính xác có thể phức tạp, nhưng thường dựa trên thời gian xử lý ngắn và không có hoạt động mở lại yêu cầu hoặc khách hàng hỏi thêm sau lần tương tác đầu tiên. Đây là cơ sở để tính KPI Tỷ lệ xử lý ngay lần liên hệ đầu tiên.
Vì sao điều này quan trọng
Đây là thước đo quan trọng về hiệu quả dịch vụ và mức độ hài lòng của khách hàng, cho thấy khả năng xử lý vấn đề nhanh chóng và triệt để.
Lấy dữ liệu ở đâu
Được tính dựa trên trình tự và thời điểm của các hoạt động trong nhật ký sự kiện của từng yêu cầu.
Ví dụ
truefalse
|
|||
Hoạt động dịch vụ khách hàng
| Hoạt động | Mô tả | ||
|---|---|---|---|
|
Bắt đầu tính giờ SLA
|
Cho biết bộ đếm thời gian của thỏa thuận mức dịch vụ (SLA) cho vụ việc đã được kích hoạt. Bộ đếm bắt đầu theo dõi thời gian dựa trên một chỉ số dịch vụ đã xác định, chẳng hạn như 'First Response By' hoặc 'Resolve By'. Đây là sự kiện rõ ràng do bộ máy SLA của Dynamics 365 quản lý. | ||
|
Vì sao điều này quan trọng
Hoạt động này rất quan trọng để theo dõi mức độ tuân thủ SLA và xác định thời điểm bắt đầu tính giờ cho các cam kết dịch vụ. Hoạt động này hỗ trợ trực tiếp việc phân tích xem các mục tiêu dịch vụ có được đáp ứng hay không.
Lấy dữ liệu ở đâu
Sự kiện được ghi trong thực thể 'SLA KPI Instance', có liên kết với thực thể 'Incident'. Dấu thời gian 'createdon' của bản ghi SLA KPI Instance tương ứng đánh dấu thời điểm bắt đầu.
Thu thập
Dùng dấu thời gian tạo bản ghi 'SLA KPI Instance' liên kết với vụ việc.
Loại sự kiện
explicit
|
|||
|
Chuyển vụ việc lên cấp hỗ trợ cao hơn
|
Thể hiện việc chính thức chuyển vụ việc lên cấp hỗ trợ cao hơn hoặc sang một đội ngũ khác. Người dùng có thể chủ động thực hiện thao tác này bằng cách phân công lại vụ việc cho hàng đợi hoặc người phụ trách xử lý chuyển cấp. | ||
|
Vì sao điều này quan trọng
Theo dõi việc chuyển cấp rất quan trọng để tính KPI 'Internal Escalation Rate' và tìm nguyên nhân gốc rễ của những vấn đề mà bộ phận hỗ trợ tuyến đầu không giải quyết được. Dữ liệu này cho thấy điểm yếu trong quy trình và nhu cầu đào tạo.
Lấy dữ liệu ở đâu
Có thể suy ra từ thay đổi của trường 'ownerid' sang hàng đợi hoặc đội ngũ xử lý chuyển cấp đã được chỉ định. Ngoài ra, một thao tác tùy chỉnh rõ ràng cũng có thể đánh dấu vụ việc là đã chuyển cấp.
Thu thập
Xác định dấu thời gian khi 'ownerid' được đổi sang một hàng đợi xử lý chuyển cấp đã biết.
Loại sự kiện
inferred
|
|||
|
Đóng vụ việc
|
Đây là bước đóng hồ sơ vụ việc về mặt hành chính. Việc này có thể diễn ra cùng lúc với lúc giải quyết hoặc sau đó. Hoạt động được ghi nhận khi trạng thái vụ việc chuyển thành 'Closed'. | ||
|
Vì sao điều này quan trọng
Đây là điểm kết thúc cuối cùng của vòng đời quy trình trong hệ thống. Khoảng thời gian từ 'Resolved' đến 'Closed' có thể cho thấy khối lượng công việc hành chính hoặc chậm trễ trong việc hoàn tất hồ sơ.
Lấy dữ liệu ở đâu
Ghi nhận khi trường 'statecode' trên thực thể 'Incident' chuyển thành 'Canceled' (2) hoặc một trạng thái đóng tùy chỉnh. Dấu thời gian có trong lịch sử kiểm tra.
Thu thập
Theo dõi dấu thời gian khi 'statecode' chuyển sang trạng thái kết thúc cuối cùng, chẳng hạn như Canceled/Closed.
Loại sự kiện
explicit
|
|||
|
Giải quyết vụ việc
|
Đây là mốc quan trọng, đánh dấu thời điểm nhân viên cho rằng vấn đề của khách hàng đã được xử lý. Trong Dynamics 365, thao tác này được ghi nhận rõ ràng bằng cách tạo bản ghi hoạt động 'Case Resolution' liên kết với vụ việc. | ||
|
Vì sao điều này quan trọng
Là sự kiện kết thúc chính thể hiện kết quả thành công, hoạt động này rất cần thiết để tính thời gian giải quyết và tỷ lệ thành công. Đây là thành phần quan trọng trong hầu hết KPI dịch vụ khách hàng.
Lấy dữ liệu ở đâu
Sự kiện này tương ứng với việc tạo bản ghi hoạt động 'Resolution' (Case Resolution). Dấu thời gian 'actualend' trên bản ghi đánh dấu thời điểm giải quyết.
Thu thập
Dùng dấu thời gian 'actualend' hoặc 'createdon' từ bản ghi hoạt động 'Resolution' liên quan.
Loại sự kiện
explicit
|
|||
|
Phân công vụ việc
|
Hoạt động này thể hiện việc phân công vụ việc cho một hàng đợi hoặc người dùng cụ thể để xử lý. Hệ thống ghi nhận rõ các thay đổi về chủ sở hữu vụ việc, có thể theo dõi qua nhật ký kiểm tra của hệ thống. | ||
|
Vì sao điều này quan trọng
Theo dõi việc phân công rất quan trọng để phân tích cách phân bổ khối lượng công việc, xác định chậm trễ liên quan đến khâu phân công và đánh giá hiệu quả định tuyến. Việc này giúp trả lời câu hỏi vụ việc được chuyển đến đúng đội ngũ hoặc người phụ trách nhanh đến đâu.
Lấy dữ liệu ở đâu
Ghi nhận bằng cách theo dõi các thay đổi của trường 'ownerid' trên thực thể 'Incident'. Dấu thời gian thay đổi có trong nhật ký kiểm tra.
Thu thập
Trích xuất các thay đổi có dấu thời gian của trường 'ownerid' từ nhật ký kiểm tra.
Loại sự kiện
explicit
|
|||
|
Tạo vụ việc
|
Hoạt động này đánh dấu thời điểm bắt đầu quy trình dịch vụ khách hàng, khi hệ thống tạo một bản ghi vụ việc mới. Đây là sự kiện được ghi nhận rõ ràng với dấu thời gian cụ thể khi bản ghi của thực thể 'Incident' được lưu lần đầu. | ||
|
Vì sao điều này quan trọng
Là sự kiện bắt đầu chính, hoạt động này rất cần thiết để tính tổng thời gian vòng đời của vụ việc và nắm bắt xu hướng về số lượng vụ việc. Đây cũng là mốc tham chiếu cho mọi phân tích quy trình tiếp theo.
Lấy dữ liệu ở đâu
Sự kiện này được ghi nhận từ dấu thời gian 'createdon' trên thực thể 'Incident' (Case) của mỗi bản ghi mới.
Thu thập
Dùng dấu thời gian 'createdon' của bản ghi Incident.
Loại sự kiện
explicit
|
|||
|
Đề xuất giải pháp cho khách hàng
|
Hoạt động này cho biết nhân viên đã tìm ra giải pháp và thông báo cho khách hàng. Thường có thể suy ra từ email gửi đi trong dòng thời gian của vụ việc hoặc khi trạng thái chuyển thành 'Pending Customer Confirmation'. | ||
|
Vì sao điều này quan trọng
Mốc này đánh dấu quá trình chuyển từ tìm hiểu vấn đề sang giải quyết. Phân tích khoảng thời gian từ lúc đề xuất đến khi xác nhận giải pháp có thể giúp phát hiện chậm trễ trong phản hồi của khách hàng hoặc vấn đề với giải pháp được đề xuất.
Lấy dữ liệu ở đâu
Có thể suy ra từ dấu thời gian của bản ghi hoạt động 'Email' gửi đi liên quan đến vụ việc hoặc từ thay đổi statuscode sang trạng thái trước khi giải quyết.
Thu thập
Dùng dấu thời gian của hoạt động gửi email hoặc thời điểm trạng thái chuyển thành 'Solution Proposed'.
Loại sự kiện
inferred
|
|||
|
Gửi khảo sát mức độ hài lòng
|
Đánh dấu thời điểm gửi khảo sát mức độ hài lòng cho khách hàng, thường được kích hoạt tự động sau khi vụ việc được giải quyết. Sự kiện này thường được ghi nhận dưới dạng email gửi đi hoặc hoạt động khảo sát Customer Voice. | ||
|
Vì sao điều này quan trọng
Hoạt động này kết nối quy trình vận hành với kết quả trải nghiệm khách hàng. Nhờ đó, bạn có thể phân tích điểm hài lòng trong bối cảnh đường đi mà vụ việc đã trải qua.
Lấy dữ liệu ở đâu
Có thể suy ra từ việc tạo hoạt động 'Email' gửi đi có liên kết khảo sát hoặc bản ghi hoạt động 'Customer Voice survey invite' liên quan đến vụ việc.
Thu thập
Dùng dấu thời gian tạo bản ghi hoạt động liên quan đến khảo sát.
Loại sự kiện
inferred
|
|||
|
Kích hoạt lại vụ việc
|
Xảy ra khi một vụ việc đã giải quyết được mở lại tự động hoặc thủ công, thường do khách hàng phản hồi hoặc cho biết vấn đề chưa được khắc phục. Đây là hành vi tiêu chuẩn của hệ thống, chuyển trạng thái vụ việc từ 'Resolved' về 'Active'. | ||
|
Vì sao điều này quan trọng
Hoạt động này rất quan trọng để xác định công việc phải làm lại và phân tích 'First Contact Resolution Rate'. Số lần kích hoạt lại cao cho thấy giải pháp ban đầu chưa đầy đủ hoặc chưa hiệu quả.
Lấy dữ liệu ở đâu
Ghi nhận khi trường 'statecode' trên thực thể 'Incident' chuyển từ 'Resolved' (1) về 'Active' (0). Dấu thời gian thay đổi được lưu trong lịch sử kiểm tra.
Thu thập
Theo dõi dấu thời gian khi 'statecode' chuyển từ Resolved sang Active trong nhật ký kiểm tra.
Loại sự kiện
explicit
|
|||
|
Nhân viên hỗ trợ nhận vụ việc từ hàng đợi
|
Sự kiện này xảy ra khi nhân viên hỗ trợ chủ động nhận một vụ việc từ hàng đợi chung để bắt đầu xử lý. Đây là thao tác do người dùng thực hiện, khác với việc hệ thống phân công vụ việc vào hàng đợi. | ||
|
Vì sao điều này quan trọng
Hoạt động này giúp đo thời gian thực tế một vụ việc nằm trong hàng đợi trước khi nhân viên bắt đầu xử lý. Đây là dữ liệu quan trọng để xác định điểm nghẽn trong hàng đợi và đánh giá mức độ chủ động của nhân viên.
Lấy dữ liệu ở đâu
Theo dõi khi người dùng cập nhật trường 'workedbyid' trên thực thể 'QueueItem' liên kết với vụ việc, hoặc khi chủ sở hữu vụ việc được đổi từ hàng đợi sang người dùng.
Thu thập
Xác định dấu thời gian khi trường 'workedbyid' trên QueueItem được điền.
Loại sự kiện
explicit
|
|||
|
Nhân viên hỗ trợ tìm hiểu vấn đề
|
Thể hiện việc nhân viên hỗ trợ chủ động tìm hiểu và chẩn đoán vấn đề của khách hàng. Đây là hoạt động được suy ra, thường dựa trên việc nhân viên liên kết một bài viết kiến thức với vụ việc, cho thấy đã có bước tra cứu. | ||
|
Vì sao điều này quan trọng
Theo dõi hoạt động này giúp đo mức độ sử dụng tài nguyên kiến thức và tác động của chúng đến thời gian giải quyết. Qua đó, bạn có thể biết nhân viên có tận dụng các công cụ sẵn có để xử lý vấn đề hiệu quả hay không.
Lấy dữ liệu ở đâu
Suy ra từ việc tạo bản ghi trong thực thể 'IncidentKnowledgeBaseRecord', liên kết một bài viết kiến thức với một Case. Dùng dấu thời gian tạo bản ghi này.
Thu thập
Dùng dấu thời gian liên kết bài viết kiến thức với Incident.
Loại sự kiện
inferred
|
|||
|
Thay đổi phân loại vụ việc
|
Sự kiện này xảy ra khi nhân viên thay đổi danh mục hoặc chủ đề của vụ việc sau khi vụ việc được tạo. Hệ thống ghi nhận rõ thay đổi này trong chức năng kiểm tra. | ||
|
Vì sao điều này quan trọng
Theo dõi việc phân loại lại rất cần thiết để tính KPI 'Service Request Recategorization Rate'. Tần suất cao cho thấy khâu phân loại ban đầu có vấn đề, dẫn đến định tuyến sai và chậm trễ.
Lấy dữ liệu ở đâu
Ghi nhận từ lịch sử kiểm tra của thực thể 'Incident', cụ thể là theo dõi các thay đổi của trường 'subjectid' hoặc những trường phân loại tùy chỉnh khác.
Thu thập
Trích xuất các thay đổi có dấu thời gian của trường 'subjectid' từ nhật ký kiểm tra.
Loại sự kiện
explicit
|
|||
|
Yêu cầu khách hàng cung cấp thông tin
|
Hoạt động này đánh dấu thời điểm nhân viên cần thêm thông tin từ khách hàng để tiếp tục xử lý. Có thể suy ra hoạt động này khi trạng thái vụ việc chuyển sang trạng thái 'waiting' hoặc khi gửi email đi từ dòng thời gian của vụ việc. | ||
|
Vì sao điều này quan trọng
Dữ liệu này rất quan trọng để đo thời gian chậm trễ do khách hàng và theo dõi KPI 'Customer Information Wait Time'. Qua đó, bạn có thể tách riêng thời gian quy trình phải chờ thông tin từ bên ngoài.
Lấy dữ liệu ở đâu
Có thể suy ra từ thay đổi của trường 'statuscode' trên thực thể 'Incident' sang một giá trị như 'On Hold' với lý do 'Waiting for Customer'. Dùng dấu thời gian của lần đổi trạng thái này.
Thu thập
Theo dõi dấu thời gian khi statuscode chuyển sang trạng thái được chỉ định là 'waiting for customer'.
Loại sự kiện
inferred
|
|||
Hướng dẫn trích xuất dữ liệu
Bắt đầu ngay?
Dùng mẫu dữ liệu này để bắt đầu hành trình process mining và tìm ra cách nâng cao hiệu quả vận hành dịch vụ khách hàng. Hãy bắt đầu cải tiến quy trình làm việc ngay hôm nay để mang đến trải nghiệm tốt hơn cho khách hàng.
Cải thiện dịch vụ khách hàng: tăng tỷ lệ xử lý ngay lần liên hệ đầu tiên, giảm chi phí
Xác định điểm nghẽn để xử lý 80% yêu cầu ngay lần liên hệ đầu tiên, giúp khách hàng hài lòng hơn.
Không cần thẻ tín dụng. Thiết lập chỉ trong vài phút.