We have upgraded our lab to IPCC 7.2.7 and are finding this issue. We are on CCM 4.1.3sr7 and IPIVR 4.0.5sr2.
We are using the Outbound Option to facilitate a callback feature for callers on hold in IPCC. We use a Transfer to IVR campaign set as Progressive Only. When a caller opts out of queue to leave a callback, we run an IVR script to capture their callback number and record it into an external SQL database that happens to live on the AW server. SQL then writes a text file out that contains the row id and the callback number. That file gets imported into the dialer and it then fires two actions. One is to send a dummy call to the IVR that runs a script that just holds on to the call (delay step), thus making the dialer think it has been 'answered'. Then, the dialer starts a call that heads to ICM to get routed to agents. We are using BAAccountNumber to store that rowid so that ICM can then do a db dip and pull all the original call info that has been stored in that table. However, BAAccountNumber usually does not get written (fails moreso than it passes) and this causes our ICM logic to fail as it doesn't have the necessary field to lookup the call data that we base our routing decisions on.
This works in our production system that is same CCM and IVR level, but on ICM 7.0.3.
Is this possibly a race condition <cringe>? Has anyone experienced the dialer not being able to write the BAAccountNumber variable?
We used to have it built that way - with the IVR as both the 'caller' and 'answerer' side of the call. But, we ran into an issue after upgrading the IVRS with trying to write data with a Set Enterprise Data step after running the Place Call step. The data was not being written.
After much investigation with our Cisco partner and with TAC, Cisco's response was that the IVR wasn't meant to hold onto the calls that way and that we were taking advantage of functionality that should not have been there in the first place (in the earlier version). It was 'fixed' in the new version, which broke the solution we had in place.
So, we had to come up with another solution to keep these callback requests in queue. The dialer has worked just fine until this ICM upgrade - but instead of not working at all - it is intermittent.
When BAAccountNumber is missing, is missing from the Dialing List tables as well? Or is it in those tables but your IVR script never gets it? Also check whether it is in the Termination_Call_Variable table for those calls.
Persistent just means it should be kept in the Termination_Call_Variable table.
This should work.
I have used the BAAccountNumber as a key for IVR (actually CVP) campaigns and it is the only variable that can get across and bridge inbound CVP to dialer-generated CVP interactions. I never had a problem with it.
I built a banking application with a security feature on setting up regular transfers (standing orders) that used the dialer to call the phone number the customer had in the database.
This meant that if anyone had hacked the customer's account and PIN, they could not set up a standing order from their phone, because the system would call the customer's phone for confirmation. If the confirmation did not come, the standing order timed out and was deleted.
The BAAccountNumber would bridge the two calls. When the customer answered the IVR (CVP) call, it could look in the database and find the standing order that needed to be confirmed.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...