Queue monitoring, how to handle events

Device registration

Login, logout events in the queue

Agent login and logout events are tracked by the Queue Agent Event resource (/agent/.../event/)

Event analysis for monitoring

The main call events are DIAL-IN, DIAL-OUT, ANSWER, and HANGUP.

For each DIAL-IN, DIAL-OUT, ANSWER event, it is convenient to create/update a separate data structure like:

<Call Identification Key>: {<call data>}

Example:

And for the HANGUP event (and in some cases for ANSWER), these data structures are deleted by their identification keys.

The identification key combines three entities: ExtensionId, CallFlow, and CallId. Recommendations for forming the identification key for each event type are specified below for each type of event.

If your interface does not plan to display any call state, you can simply ignore unnecessary events. For example, if your interface only displays answered calls (in the "answered" state), you only need to create new data structures for answer events, and dial-in and dial-out can be ignored.

Events can be analyzed as follows:

EventType "dial-in"

Indicates an incoming call to an extension. In such a call, we are interested in WHO is being called (the calledExtension).

The identification key for such a call: CalledExtensionId + "IN" + CallId

IF calledExtension is a queue, it means the caller has reached the queue and is waiting for a response from one of the agents in that queue.

This can be displayed in the interface: incoming call to a queue ("hanging in queue" call) *

IF calledExtension is a phone, it means someone is currently trying to reach this phone.

This can be displayed in the interface: incoming call to a specific employee

EventType "dial-out"

Indicates an outgoing call from an extension. In this call, we are interested in WHO is calling (the callerExtension).

The identification key for such a call: CallerExtensionId + "OUT" + CallId

IF callerExtension is a queue, it means the queue is currently calling one of its agents.

This can be displayed: outgoing call from a queue to a specific employee

IF callerExtension is a phone, it means a phone is currently trying to call someone.

This can be displayed: outgoing call from a specific employee to a number

EventType "answer"

Indicates an answer to a call. Here, we need to analyze the direction of the call (callFlow).

CallFlow "in"

This is an answer to an incoming call. We are interested in WHO answered (calledExtension).

The identification key for such a call: CalledExtensionId + "IN" + CallId

IF calledExtension is a queue, we ignore such an event, as the call's arrival in the queue is already created by the dial-in event on the queue.

IF calledExtension is a phone, it means one of the employees answered the call.

This can be displayed: the responding employee is talking right now (answering an incoming call)

CallFlow "out"

This is an answer to an outgoing call. We are interested in TO WHOM the response was given (callerExtension).

The identification key for such a call: CallerExtensionId + "OUT" + CallId

IF callerExtension is a queue, it means a queue agent has answered the call.

This can be displayed: removing the call from the "hanging in queue" list (if you created it at the stage described above - EventType “dial-in” calledExtension queue - marked with “*“

IF callerExtension is a phone, it means someone answered the call to the calling employee.

This can be displayed: the calling employee is currently talking (received an answer, making an outgoing call)

EventType “hangup”

Indicates the end of a call. As before, we need to analyze the direction of the call (CallFlow).

CallFlow “in”

This is a hangup on an incoming call. We are interested in TO WHOM the call was made in this call (calledExtension). Here, we need to end the call by such a key: CalledExtensionId + "IN" + CallId

CallFlow “out”

This is a hangup on an outgoing call. We are interested in WHO made the call in this call (callerExtension). Here, we need to end the call by such a key: CallerExtensionId + "OUT" + CallId

Let's consider a possible example

You have a queue 200 (extensionId 222222) with one agent 101 (extensionId 111111). A call comes into the queue from the number +798198736545.

You receive a DIAL-IN event, in which CalledExtension is the queue. The CallId of this call is qqqwwweeerrrtttyyy999. You form the identification key: 222222INqqqwwweeerrrtttyyy999 and put the event information under this key in the data structure:

Using this information, you display the "hanging in queue" call.

The queue starts calling its agents. You receive a DIAL-OUT event, in which CallerExtension is the queue. You form a new key and add the event data to the data structure:

Using this information, you display whom the queue is currently calling.

Since there is only one agent 101 in the queue, the queue immediately starts calling them, and you receive a DIAL-IN event, in which agent 101 is CalledExtension. You form a new key and add the event data to the data structure:

With this data, you display that agent 101 currently has an incoming call but has not yet picked up the phone.

When 101 picks up the phone, you will receive two ANSWER events.

The first ANSWER with CallFlow === “in”, in which CalledExtension will be agent 101. This event signals that 101 has answered the incoming call.

The identification key for this event will be the same as the DIAL-IN event on 101 (111111INqqqwwweeerrrtttyyy999**)**. When we put a new event into the data structure under this key, it will replace the old event. And that's correct, as agent 101 is now in a talking state, not in a calling state. Here's how the updated data structure will look:

Now, based on this data, we display not the queue's call to 101, but that 101 is already talking.

Additionally, since we have already received an answer from the extension, we do not need to display the "hanging in queue" call. So we remove the incoming queue call (number 1) from the data structure:

The second ANSWER we receive with CallFlow === "out", and in it, CallerExtension is the queue. This event signals that someone has answered the call from the queue. When forming the identification key, we also find that it matches an existing key (222222OUTqqqwwweeerrrtttyyy999). We don't need to display anything for this event, so we simply delete it by this key.

After this, the structure looks like this:

At this moment, we only display the current conversation of extension 101.

When he finishes talking, HANGUP events will start coming in. Two hangups will arrive for the calls we already ended by the ANSWER event, so we don't need to do anything with them. And one of the hangups will have CallFlow === "in" and will have agent 101 as CalledExtension. The identification key for this event will match the key of the last remaining event in the data structure (number 3). We delete it by this key:

At this point, all calls have ended, and nothing else is displayed in the interface.

NB: This document is a simplified example of building an event analysis system. Events can be analyzed in other ways and data structures can be created differently. Choose the option that suits your specific integration.