We ended up having to pull FastPath unfortunately due to not being able to maintain service levels (too many customers were complaining).
We are still investigating other solutions, but would really love to be able to move back to FP, once these features are included.
This feature is not part of the roadmap. The idea of FP is to select the best agent and only invite that agent. In case the agent failed to respond or rejected the invitation then the next best agent will be invited. You can also specify another queue of the same workgroup as a failover. However, FP will keep inviting one agent at a time.
This can leave a customer hanging for a very long time. An agent needs at least 10 seconds to accept an incoming request, thus it could sometimes take 4 agents before the request is answered (or more)…
I see no harm in adding this as a feature, at least if its optional? We run our PBX with this exact same setup (queues & overflows) and it is incredibly effective.
How would you like to log the result of the invitations? If you enable the debug log you will be able to track this information. It is not the ideal solution but a temporary one.
Well, any way (the more elegant the better), to be able to see the accept/deny history of our agents. Thanks for the recommendation, but to be honest enabling debug and fishing through logs is too much of a time drain and obfuscated unfortunately.
If the user is an agent in a single workgroup then Spark with auto log-in the user to the workgroup. However, if the user is an agent in more than one workgroup then no auto-login will be done.
I noticed this, yes thanks
What do you mean by time-out? Are you referring to connections being lost and Spark is not doing an auto-reconnect?
Yeah, the connections seem to die/hang, the agent thinks they are idling, instead of Spark reconnecting or notifying it seems to do nothing until the agent reconnects manually.
Thanks for the response, another reply sometime before 2 months would be appreciated