Growing Pains with FastPath

We’ve been running Openfire with Fastpath for years now, we’ve grown substantially and Openfire has helped us a ton, but at the same time to be down right honest, we’ve long since outgrown the Live Assistance Fastpath module.

To be specific there are a number of features its lacking in terms of bulk management, namely:

  1. Have the ability to notify all logged in agents in fast path simultaneously. (Perhaps even as an overflow method after X seconds.)

  2. Log which agents ignore/accept chat requests? (Very NB)

  3. Notify ‘non-logged in’ customer chat users that there are customers waiting in a live chat queue?

  4. An ‘auto-login’ feature to FP.

  5. Spark does not notify when the connection has timed out, often staff don’t realise the connections have timed out.

Any input appreciated.

Anyone?

Hey webafrica,

  1. Have the ability to notify all logged in agents in fast path simultaneously. (Perhaps even as an overflow method after X seconds.)

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.

  1. Log which agents ignore/accept chat requests? (Very NB)

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.

  1. Notify ‘non-logged in’ customer chat users that there are customers waiting in a live chat queue?

I think this is a customization of the product that could be done by PS. This feature is not part of the roadmap.

  1. An ‘auto-login’ feature to FP.

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.

  1. Spark does not notify when the connection has timed out, often staff don’t realise the connections have timed out.

What do you mean by time-out? Are you referring to connections being lost and Spark is not doing an auto-reconnect?

Thanks,

– Gato

Hi there,

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