Chat can be an outstanding support tool because it allows for rapid response to customers. Conversely, waiting a long time for chat response (like sitting on hold on the phone) is a terrible customer experience. For the sake of a good experience, many organizations using Chat specify a one-minute response Service Level Agreement (SLA) for their chat agents. The question: how do you measure the response/wait time?
Measure a Chat agent's performance with Wait Time
This is the preferred way to measure your Chat agent's response time. Each chat_queue_entry record has a Wait time field in it. When a chat agent accepts the chat request, this field is populated with the amount of time the person was waiting for the chat request to be accepted. You can report against this field directly.
The business rule SNC - Chat Queue Average Wait Time averages the last 20 chat responses and updates the chat queue with the value so it is available as a running statistic.
Metric Definition vs. SLA
You can also choose to track the chat response time with a Metric Definition or a Service Level Agreement. How do you choose between these two methods? Let's compare the criteria and the methods to see which choice makes the most sense.
- This is a very short duration.
- Because of the brevity, we are not worried about applying a schedule or business hours; we want to measure the actual elapsed time.
Metric Definition
If you are going to track your own wait time, a Metric Definition is a better choice for tracking such a short duration.
- Runs in the background in a worker thread.
- Has low overhead.
- Calculates only the duration in question.
Service Level Agreement
This is a bad choice and should be avoided.
- Can run under the user's thread (synchronously) or under a worker thread (asynchronously).
- Will lock the record for exclusive use while it is checking to see if the SLA is starting or stopping.
- Will run significantly higher overhead calculations if a schedule is specified for the SLA Definition.
- If configured with a workflow for notifications, will result in significant extra wasted processing.
- Regardless of whether you are intending email notifications or SMS notifications, there is too much system latency for these to have any value.
If you are determined to use a Service Level Agreement, keep in mind these SLA configuration tips:
- Run these SLAs synchronously (under the user's session).
- Running them under a worker increases the load, plus the worker has to establish a lock and read the record again, just adding more overhead.
- Ensure your SLA Definition does not use a schedule, so it is on a 24x7 schedule.
- This reduces the overhead of unneeded schedule processing.
- DO NOT SPECIFY A WORKFLOW ON YOUR SLA DEFINITION.
- 50% of the SLA Engine's time is spent handling workflows.
- This is wasted effort for notifications which are going to arrive after a breach and serve no purpose.
Conclusions
- It is important to monitor and measure the response time for your chat agents because this is the amount of time your customers are waiting for a chat to be accepted.
- A frequent standard for the response time is one minute.
- ServiceNow tracks this value for you automatically in each chat_queue_entry record in the wait_time field.
- The last twenty wait_time values are used to compute the average_wait_time for the chat_queue.
- PREFERRED METHOD: Use these supplied fields to measure chat agent performance.
- There is no need for you to duplicate these values by calculating them with another method.
- Defining an SLA with notifications to generate these statistics is bad practice, can lead to response time issues, and is not recommended.
1 Comment
