We have IPCC 7.2(4) with outbound option and CAD.
Skillgroups are set to "preview direct blended". Everything works ok, except:
we want to use the BAAccountNumber content to make routing decisons in the script, but the variable is not filled. It is showing the correct content when the call is presented to the CAD agent for acceptance in the Enerprise Data window.
Any ideas ?
no solutions as far as I know.
The set node can not be used here because the customer call has not gone through the ICM script.
There are two legs of the call, one for the routing script and one for the dialer.
The leg of the call that is direct from the dialer is not hitting an ICM script - only the agent reservation has gone through the routing script.
Therefore the Reservation Call does not have the ability to look at the dialer variables such as BAAccountNumber because the variables you see are for the customer call.
I though something similar, but it is a bit strange though.
The 1st leg of the callback goes thru the script and an agent is selected. There the BA vars are not set.
The agent then gets the screenpop with an enterprise data window containing all BA variables populated.
He then ACCEPTS the call and the customer is called (2nd leg).
What about doing a dblookup in the script on the DL_5000_5000 table to obtain the BA variables ?
Bit dirty, but I think the record will still be there. It is only purged after a certain amount of time after the callback has been done.
You might try on the Dblookup, but it will all depending on timing and the agent to call ratio, not sure with which call you will eventually match and if the info will already be there or not.....
I use DBLookup to retreive outbound details for incoming calls so:
You can use DBLookup by "Call.CallingLineID" retreive the AccountNumber field from DL_500x_500x and use it as routing decision.
For this you have to set a column as Primary Key. I use DialingListID for this purpose. If some problems occur, you can alter table and remove the Pr.Key. I dont have problems everythings works fine for me this way. But no one knows. Some people say that this is wrong so, you can build DL_LIST table replica in some other DB and use it for the DBLookup.
You can do it in CRS too. Retreive the value, set it to Call.PeripheralVariableX and use it in ICM.
Bot ways it works.
I am experiencing the same issue and tried your suggestion by using DBLookup on "Call.CallingLineID"
It seem like the CallingLineID is not being presented with the call because it shows a blank value when it is passed to a dynamic variable.
Would it be possible for you to confirm again that this is working for you and provide detail configs.
Is it possible that the CallingLineID is being surpressed?
I had similar issues and stopped investigation that path.
Instead a created numerous queries, campaigns and dialed numbers.
Maybe Baramov knows as he seemed to get it working.
I think it is a big shortcoming of OBO and makes it pretty useless to make advanced routing decisions.
You can allways use simple crs script to get the phone number then set it to a call variable and then pass it to the dblookup.
Ok if you have IP-IVR it is easy:
Create simple script to get the LineID and set Call.VariableX with the value (this is done in IP-IVR) - than use DBLookup in ICM with this variable (Call.VariableX).
What does IP-IVR have to do with any of this? This is an outbound call.
The dialer sends the reservation call to choose the agent, and then the customer call is made (not from the dialer) from the agent's phone - the mode is DIRECT PREVIEW.
I suspect Chavdar has implemented an outbound campaign with the IVR, hence how he got his particular call flow to work.
I use the details from outbound call which is not yet completed to pass them to agents when there is a call back from person in dialing list.
It is quite simple:
IP-IVR collects data (in my case DLid and DList)
ICM uses this data to do DBLookup to DL_500X_500X tables and fills the fields with the details to agent desktop.
Chadvar, we have controls in an admin script to close campaigns based on time and day. We set some bits in a database table which is referenced in the routing script.
We are trying to screen all calls for callbacks and route them to agents anytime. The callbacks works fine when the campaign is open, but we are trying to customize to allow future call backs.
In your scenario, it sounds like you check the call when presented to the agent, which is the reverse of what we are trying to achieve. Thanks
You can do the check anytime. In my case i do the check prior to send it to agent.
But you can do it anytime.
I`m not checking about open and close campaigns - just check for unfinished contact.
Geoff thanks for that info. If this is the case, do you know of any way that I can link the reservation call to the account number? Thanks
I do not think you can.
you're always "too late" The obo call var's are empty when the icm script is executed. Then when the call arrives at the agent/customer the obo call var's are being populated in CAD/CTIOS AD. I tried to do dblookup in the icm script to the DL_x_x tabl(s) but ran into also sorts of concurrency issues. In input file I misused one of the obo call var fields (obo lastname) for the account number. Then in CAD I used the obo call var populated with the acc.# to do a screenpop.
Chavdar_Baramov, I think you have gone off on a bit of a tangent.
Correct me if I'm wrong, but what you seem to be doing a special type of IP IVR behaviour for inbound calls from customers that are the result of an outbound call by the Dialer. A callback from the customer.
You are checking in the dialer table to find info - all perfectly legitimate and quite interesting, but not the original poster's problem.
I have created outbound campaigns with CVP and there is no problem doing that. Still, nothing to do with the original problem.
The BAAccountNumber is populated when the reservation call hits the agent's desktop for the preview direct call. I have implemented client-side lookups against the customer database to display a pop-up so the agent gets a bunch of details before they press "Accept". This all works fine and my observations are in agreement with the original poster.
He is noting that the BAAccountNumber is not populated as the "call" runs through the routing script and decisions cannot be made on it. So far, no solution.
It is possible that i have misunderstood the OP.
And i totaly agree with you that the only way to do this whay you say is client(agent) based.
P.S. As not native english speaking person i probably lost something in the translation.
So accept my apologies.
It depends on how you have your transfer to IVR script configured, and what type of IVR you are using.
The 7.5(1) Outbound Option guide has some suggestions regarding this in the trouble shooting chapter.
Call Context Not Being Transferred During a Transfer to IVR Call Flow
The call context is not being transferred during a Transfer to IVR call flow.
On a System IPCC system, the Network IVR is not configured.
Check whether or not the Network IVR is configured. If it is not configured, configure it.
On an IPCC Enterprise system the Network VRU is configured as a Type 5, which does notsupport call context.
Consider reconfiguring the the Network VRU as a Type 10.
On an IPCC Enterprise system the IVR transfer route point (CTI Route Point) does not existon the same PG where the Dialer ports are monitored.
This route point must exist on the same PG where the Dialer ports are monitored. This is theperipheral assigned to the Dialer in the Dialer configuration.
For System IPCC, the Transfer to IVR DN should be configured on the agent controller.
The thing is ... the OP does NOT have IVR campaigns - normal "preview direct" outbound campaigns.
We went off on a bit of a side path.
OK, so no IVR.
Assuming you are attempting to make agent routing decisions base on the Account Number ECC variable in the routing script that is reserving the agent, then yea, the ECC variable will not be populated. The agent reservation is separate. Call context is forwarded to the agent desk top via the CTI interface using call data updates after the reservation call has been answered. It is the same mechanism used for Predictive and Progressive agent campaigns.
It wouldn't be out of the question to change functionality of the system so that the ECC variables are populated in the preview reservation routing script, but it wouldn't help with routing after the reservation call has been accepted if the agent chooses to skip or reject the customer. Once the agent skips a call, a new customer record is selected and presented with out the use of a new reservation call. The same reservation call would bridge multiple rejects / skips.