PureEngage On-Premises

Discussion Thread View
Expand all | Collapse all

RONA Requirement - Change Agent State from Ready to Not Ready

  • 1.  RONA Requirement - Change Agent State from Ready to Not Ready

    GCAP Member
    Posted 01-07-2020 15:16
    I have a RONA requirement.  First requirement is when a call does not get accepted or rejected, that agent's state is to change to Not Ready.  This is currently happening.  The other requirement is when the agent rejects the call, their state should also change from Ready to Not Ready.  This is not happening.  Currently, when the agent rejects the interaction, agent still remains in Ready status.

    David C.

  • 2.  RE: RONA Requirement - Change Agent State from Ready to Not Ready

    Posted 01-21-2020 12:48
    I have an Orchestration routing answer, but you aren't going to like it.  :-)
    Typically, ORS asks URS to queue a call and URS finds the available agent then gives that agent ID back to ORS, dequeuing the interaction. At that time, ORS gives SIP server the destination it has been waiting for and the interaction leaves SIP server on a refer and ORS terminates the session (feel free to visualize ORS wiping their hands clean and moving on to the next interaction).
    Whatever happens at the agent desktop is none of ORS's concern... unless you keep the session running.
    Why would I do that, you ask? Well, if you can gain back control of a declined interaction, you can play a message to the declined caller, change the priority of the interaction to the highest and they will be routed to the next available agent. In addition, you have all of the agent information that declined the call, and you can log them out and create a new BAD_AGENT KVP with their name on it that alerts splunk and ICON.

    But to keep a session alive, you have to be running an interaction-less session where the _composer_global parent state is not listening for 'interaction.deleted'. (that will take some creative thinking)
    Part of this plan is to add the ORS server name and _sessionid to a KVP that follows the interaction, so that a consecutive route request will present the same set of KVPs. That way, an intermediate strategy could read the KVPs and perform an ixn:attach to move the interaction back to the session it was routed from. I use that strategy today, but in your case, you would have to have a special route point that was used for declined callers that launched the special intermediate strategy that re-associated the interaction back to the waiting session. And you need a 30 second timed event in the waiting interaction that will allow it to close.

    I know this is alot of work, but if you can implement this, it really opens up a number of possibilities and fancy solutions for chat and email and even virtual call back.

    Happy Coding!


    Todd McCall
    Bank of America