Agent Status shows "Available" when agent is "On Contact"

[Kirk-H]

Agents who are "On Contact" show as "Available". This leads to a false number of Available agents being reported. An agent who is on contact should show as on contact.

[Kirk-H]

In looking at this, I don't see that the status returns on contact vs. available. It may not be possible to show which agents are on-contact vs. available. Without the ability to show agents as on contact and not available, there is no way for a real time dash to show agent statuses reliably, and relying on the per-queue metric of agents available is the only way to know if no agents are available on your team for a queue.

Since the real time metrics page does show "on contact", it would be nice to have that value available in the serverless real time dashboard.

[Brettles]

Yeah, I don't think that "On Contact" is a state that is emitted by Connect. You can create custom states (you'll need to modify the code slightly to display the right thing for that) but I also don't think that helps because the agent would need to set themselves to that custom state.

[Kirk-H]

I believe you are correct Brettles. I have a ticket into support inquiring if the backend can be changed to return these statuses.

Without the ability to return "on contact" and "after contact work", agents will show as available when they are not, leading to confusion.

I'll share what support comes back to me with here. A possible work around is to use the real time dash for Queue data, and have managers use the real time reports inside the connect admin pages for agent status.

This solution is well put together and easy to deploy. Only limited by the systems ability to return the statuses so far. Well done, nice work.

[Brettles]

Thanks! There's probably a (difficult) middle ground here: If you had another way to detect when the agent was in the "on contact" state you could get the code to recognise that by dropping it into the DynamoDB table. For example, at the front end if the CCP "knows" something extra it could call an API to change the state. Lot of work though.

[Kirk-H]

That is an interesting suggestion.

I'm currently discussing the value offered by the real time dash to the team leads. The Queue data point for "Agents Available" indicates the correct number of agents who are able to handle an inbound contact, so that data point offers the missing accuracy of the Agents Available status, but only generally. Managers can't tell which of the Available agents is actually available without viewing real time metrics in Connect, only that X number of Available agents can accept an inbound contact.

I wish that I could add the DynamoDB table these scripts create to QuickSight as a data source, that would be a very valuable addition to the other data lake resources there. :)

[Kirk-H]

It looks like you can get the DynamoDB into QuickSight if you replicate it into a redshift DB...... interesting idea.

[Brettles]

To your point about available agents: I had a customer who created a calculation in the wallboard that subtracted agents in specific "other" states from the available agents figure so that they did have an accurate representation of agents that were "ready" to take calls.

The schema of the DynamoDB table here can be extended - if you have a custom metric from "somewhere else" that you can retrieve then you can insert it and use it somehow. For example, if you wanted to see the number of emails in a mailbox and you had a way of retrieving that (which I've done before with some Exchange APIs) then that becomes a valid data point to use.

[Kirk-H]

An calculated filed makes sense, as a way to show how many agents are actually available vs. on contact or post contact work.