Virtual Hold Preview Mode

At this client we have deployed Virtual Hold (http://www.virtualhold.com/) to provide in-queue callbacks (e.g. queue buster type functionality). Whilst VH is a great standalone product, when integrated with Genesys CIM there are some limitations.

One of the biggest limitations is that VHT is only integrated with Genesys T-Server (via the Queue Manager service) and there is no integration with Stat Servers which means that VHT Queue Manager applies its own logic to derive the Estimated Wait Time (EWT).

In reality this means that VH Queue Manager in predictive mode initiates callbacks (via TMakePredictiveCall) based on Queue Manager maintained statistics rather than Stat Server statistics. As a result, when the callback is made there is no guarantee that a) there are any advisors available and b) the customer will not have to queue again.

As an alterative VH queues can be configured on preview mode.

In preview mode after a customer requests a callback, Virtual Hold uses a Genesys Virtual Routing Point (VRP) to queue the call virtually. When it is the customer’s turn to speak to an advisor and an advisor becomes available, VH will receive a message from Genesys T-Server that the advisor is available; VH will then send the virtual call and its information to the agent desktop through a user event. The advisor desktop gives the advisor options, which can include: call the customer, reject the call (the call will be given to another advisor), cancel the callback, or reschedule the callback. If the customer is called back, the advisor desktop forces the advisor to select a call result value.

Effectively, the solution is a manual callback which is presented to an available advisor and they are then expected to either accept or reject the callback request. If they accept the callback request they are required to dial the customers’ number manually.

There are a number of limitations with the approach such as:

  • Requires custom functionality on the advisor desktop. Out of the box this functionality is only provided by the Genesys Agent Desktop (GAD)
  • Manual dialing of contact numbers is prone to error

As a proof of concept I have developed a Virtual Hold Preview Dialler which connects to Genesys T-Server and acts as a T-Server client, registering for events on Advisor extension (station) DNs and processes callback user events. The Virtual Hold Preview Dialler responds advisor desktop callback user events as follows:

1. If a user event with key “VCB_USER_EVENT_REQUEST” is received and the value is “RequestCallbackPreview” an outbound call to the callback number (KVP VCB_CONTACT) is initiated from the advisor’s station / extension (TMakeCall).

Image

2. The Virtual Hold Preview Dialler waits for EventEstablished and then sends a user event with key “VCB_USER_EVENT_RESPONSE” and value “RequestCallbackProcessed”. VCB_CALL_RESULT is set to 33 (Answered).

Note that VH only considers the call result value of “Answer” to be a successful callback. Unless the callback is canceled or rescheduled; any other call result value will cause the callback to be marked as “callback failed”, and the callback will be re-initiated according to the VH retry parameters.

Image

The diagram below shows the overall architecture:

Image

As a result, the Virtual Hold Preview Dialler allows us to run Virtual Hold callbacks in preview mode without any customisation of the advisor desktop application. This means that manual intervention by the advisor is not required, business process is enforced and dialing errors are prevented.

 

 

Share

My first iPad application

Apple have had another $99 from me to join the developer program (in addition to the cost of buying a MacBook Pro and iPad!) so I thought that I had better make use of them.

Over the last few weeks I’ve been getting to grips with development on the Apple iPhone OS (iPod Touch / iPhone / iPad). It’s been quite a learning curve with lots of new languages, tools and frameworks to get used to: Objective-C, Xcode IDE, Inferface Builder, Cocoa Touch, Framework, UIKit etc. Fortunately there are lots of good tutorials out there and some excellent vidoes on Apple iTunes U.

At first it all seemed a bit daunting given my Microsoft C# and .NET background (although I also know C on UNIX from many years ago which makes Obective-C at bit easier). However, the more I get into this the more I realise that a lot of the design patterns such as MVC and tools are very similar. It’s just a case of different terminology for the same thing.

Using the tutorials I have managed to get a simple Objective-C based “Hello World” application running the hard way on my iPad. The reason I say the hard way is because I have also discovered MonoTouch (http://monotouch.net/).

“MonoTouch allows developers to create C# and .NET based applications that run on Apple’s iPhone and Apple’s iPod Touch devices, while taking advantage of the iPhone APIs and reusing both code and libraries that have been built for .NET, as well as existing skills.”

I have also been able to get a MonoTouch based GPS application running on my iPad as well. Given that my application is pretty simple it is too early to say whether I am going to splash out another $399 to license MonoTouch and use the associated MonoDevelop IDE as my primarly iPhone OS development tool. It also depends on how the iPhone Developer Program License Agreement pans out in OS 4 aka the Apple v Adobe war.

MonoTouch is obviously a lot more familiar and allows me to re-use existing C# code that I have in my toolbox. Also, with MonoTouch I don’t need to worry as much about memory management e.g. retain / release and the autorelease pool.

Regardless of whether I use Objective-C or Mono / C# I still need to learn Interface Builder (IB) so this is where I will focus my learning for now.

Still a long long way to get towards my full first “proper” application but at least I have made a start.

Share