Trunking to an IVR 2

[ewaaijenberg]

We currently have a trunk group (5) that routes to a Steadycomm box that we
use to house our IVR, so if for example a customer wants to check his/her
account balance, they press 1 for example and the call is routed over this
trunk to the IVR (Steadycomm) box where the query is handled. Once the
customer has checked their account balance, they may wish to speak to a
medewerker in which case they are transferred out of the IVR and back into
the PBX. However, this means that 2 circuits are opened: one for the call to
the IVR and one back into the PBX.

The guys responsible for the Steadycomm box have asked if instead of opening
another circuit to send the call back to the PBX is it possible to keep one
circuit open and drag the call back to the PBX depending on what signal or
code is sent to the PBX from Steadycomm. Specifically they are talking about
sending an ipc message to the PBX which could signify that the customer has
checked her balance and now wishes to speak to an agent (for example). Is
the PBX capable of receiving these messages and then taking the call from
the Steadycomm box back into the PBX along the same channel? Basically, once
the call has left the PBX, we'd like to keep the line open and wait until we
receive a signal from Steadycomm informing us what to do with the call.


Thanks in Advance

 

[budgetgh]

We are using a PULSE IVR to do exactly the same thing. Each trunk is configured as VRUFD for the type, and switchhook flash is turned on. When they are through checking their balance, we do a switchhook flash, and transfer the call back to one of the queues. We don't even keep one trunk open that way. If I remember correctly from the class I went to, you could vector the call out to the trunk with a "Converse-on" step. That way, the switch never gives up control of the call. You would have to add some steps to handle the call properly when it returns from the IVR. We are running G3SI V9.5...

Hope this helps.

 

[Donaldus]

That's right! If you issue a converse-on command the PABX keeps control of the call. The call routes into the IVR and as soon as you customer is done with the balance-checking and wants to speak to a representative you can issue a command on the IVR the send the call back to the PABX. It goes back to the vector it came from on from there on you can do anything you want. For instance if you have the IVR sending out a special number for these type of calls you can pick up these up in the vector by using the "route-to digits" command. So you can create a special VDN in the PABX corresponding with the digits the IVR send out. Or something like that...

D naldussss

 

[marcell55]

To use the "converse on" command in a vector, you need to set up the IVR ports as single analog stations (Where the port is the port on the ds1 board). You then make those stations part of an ACD Hunt Group that is vector controlled and has a queue. You'll also turn the AAS field to yes. (AAS means Auto Available Skill). The IVR ports will be a part of the hunt group as agents. The vector will "converse on" the skill or split of the IVR and then ,to return to the next step in the vector, the IVR will dial the "converse data return code" (found in Feature Access Codes). After it dials the converse data return code, it can then dial the VDN that you'd like it to go to to queue. The vector would look something like this...

converse on skill 100 passing none and none
collect 4 digits after announcement none
route to digits with cov y
route to number 1234 with cov n if unconditionally

The 1st line is how you talk to the IVR (you can also pass digits to the IVR if you wish).
The 2nd line is where the caller will come back to once the converse data return code is dialed by the IVR.
The 3rd line will collect the 4 digit VDN that the IVR dials when returning the call.
The 4th line will route to the digits entered.
The 5th line is a default in case the IVR sends back unrecognizable digits, or if the IVR is down and not accepting calls.

When set up this way, you can also get reporting for the IVR hunt group through BCMS or CMS.

The one "gotcha" is that it will use up agent licenses. However many IVR ports you have is how many agent licenses you'll need.