AppSpecialist
Programmer
Does anyone have a good reasoning or know of any good links to information supporting or comparing one option over the other?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
IVR In front or behind ACD 1
- Thread starter AppSpecialist
- Start date
- Status
Physical placement or call routing?
Physical - Doors won't open if it's in front
Call routing - The ACD has a toned down IVR in it already. If that is all you need then no reason to add another point of failure. If you are looking to do enhanced IVR features like Voice Reco then you will need to place the IVR in front to do all of your prompts.
If you have a phone number that is soley handled by the IVR and does not have a "talk to a rep" option then, depending on call volume, you should dedicate a line right into the IVR and reduce your points of failure.
You probably won't find anything comparing the 2 option because it largely depends on your applications
Physical - Doors won't open if it's in front
Call routing - The ACD has a toned down IVR in it already. If that is all you need then no reason to add another point of failure. If you are looking to do enhanced IVR features like Voice Reco then you will need to place the IVR in front to do all of your prompts.
If you have a phone number that is soley handled by the IVR and does not have a "talk to a rep" option then, depending on call volume, you should dedicate a line right into the IVR and reduce your points of failure.
You probably won't find anything comparing the 2 option because it largely depends on your applications
- Thread starter
- #3
AppSpecialist
Programmer
We currently have some limited IVR functionality... as you mention off the ACD. But we will be adding a number of advanced apps soon and will be using a stand alone IVR to do it.
We do not and would not use a separate number for a umber of reasons.
I was hoping there would be someone willing to offer some strategic reasons why you would install in front of or behind such as hardware costs, trunc line costs, possibility of failure, etc...
I notice you mention having to place IVR in front to do prompting... I find that interesting, no one at Aspect ever said that?
We do not and would not use a separate number for a umber of reasons.
I was hoping there would be someone willing to offer some strategic reasons why you would install in front of or behind such as hardware costs, trunc line costs, possibility of failure, etc...
I notice you mention having to place IVR in front to do prompting... I find that interesting, no one at Aspect ever said that?
-
1
- #4
We use an Aspect ACD with a standalone IVR.
Concerning call routing we have IVR sitting "behind" the ACD
It has no additional direct connection to our carrier. It's a grown environment, we have a lot of service numbers, the ones with the most traffic are routed through the IVR. The IVR gives the opportunity to query progress of orders, but many callers want to talk to a person, too.
We use it to qualify customers whishes and route them apropriate. That can be done by the ACD (DTMF), but we want to offer speech recognition, too. The calls are coming into the ACD, are transfered into the IVR, after some time many of them are transfered back into the ACD and then routed (differend DDIs) according to the needs of the customers. 1/3 of the calls is handled by our own CSRs, the rest is transfered to other callcenters using ordinary transfers, NIQ, and IP-NIQ.
Works fine, but traffic and points of failure are an issue.
Today we want CTI, too. As we are a carrier, we are going to use our really big IVR (>8k ports) in the carrier-network and punch in the CTI-servers there, too.
As databit already said, there is no general rule;everything depends on how you are going to use your IVR
If you route calls from the ACD into the IVR and back, all (!) voice-channels are in use until the customer hangs up. If there are a lot of these calls you should implement some kind of anti-tromboning. Talking about ISDN/PRI, Aspect supports anti-trunk-tromboning using Q.SIG or DPNSS on the E1/T1.
When you need speech recognition only for a small part of the calls, placing the IVR "behind" the ACD might be right. Additional lines connected directly to the IVR are a good option when needed.
Reporting may be an issue, too. When calls arrive in the ACD at first, it might be easier. But with a standalone IVR you'll have to match data of different systems anyway, if you want to know what's going on...
Points of failure... our IVR has 6 independant modules with 60 channels (2 PRI) each. Seems to be no problem, but during high traffic all ports can be busy, there might be some CSR sitting and waiting for calls. In case of IVR failures it may be worse. I have to provide additional DTMF-menus to qualify calls within the ACD, in case all IVR ports are busy or IVR is not available at all.
If the IVR would be sitting "in front" of the ACD I would have to do the same programming effort in the ACD, 'cause in case of an IVR failure the service-numbers would have to be routed to lines terminating in the ACD instead if the IVR...
- traffic
- voice recognition needed for all calls?
- are IVR services independant from ACD (optional).
- can you live without IVR?
- does your IVR application provide some kind of self service (ACD with routing to CSR is optional)?
- can you imagine how your business will develop within some years?
- what are your boss' expectations?
You see... it depends.
I would try to be variable, start with a small application transfering calls from ACD to IVR, get used to customers reactions and the reporting (just another big point). And be prepared to connect lines terminating into the IVR if it's necessary. You'll might end up having your IVR "in front" and "behind" the ACD at the same time
Not completely off topic: integrated systems providing ACD functionality, CTI and speech recognition are on their way and probably VoIP will give them a boost... but if you have more than 300 users, you can keep with your systems for the next few years...
just my 2cents.
Concerning call routing we have IVR sitting "behind" the ACD
It has no additional direct connection to our carrier. It's a grown environment, we have a lot of service numbers, the ones with the most traffic are routed through the IVR. The IVR gives the opportunity to query progress of orders, but many callers want to talk to a person, too.We use it to qualify customers whishes and route them apropriate. That can be done by the ACD (DTMF), but we want to offer speech recognition, too. The calls are coming into the ACD, are transfered into the IVR, after some time many of them are transfered back into the ACD and then routed (differend DDIs) according to the needs of the customers. 1/3 of the calls is handled by our own CSRs, the rest is transfered to other callcenters using ordinary transfers, NIQ, and IP-NIQ.
Works fine, but traffic and points of failure are an issue.
Today we want CTI, too. As we are a carrier, we are going to use our really big IVR (>8k ports) in the carrier-network and punch in the CTI-servers there, too.
As databit already said, there is no general rule;everything depends on how you are going to use your IVR
If you route calls from the ACD into the IVR and back, all (!) voice-channels are in use until the customer hangs up. If there are a lot of these calls you should implement some kind of anti-tromboning. Talking about ISDN/PRI, Aspect supports anti-trunk-tromboning using Q.SIG or DPNSS on the E1/T1.
When you need speech recognition only for a small part of the calls, placing the IVR "behind" the ACD might be right. Additional lines connected directly to the IVR are a good option when needed.
Reporting may be an issue, too. When calls arrive in the ACD at first, it might be easier. But with a standalone IVR you'll have to match data of different systems anyway, if you want to know what's going on...
Points of failure... our IVR has 6 independant modules with 60 channels (2 PRI) each. Seems to be no problem, but during high traffic all ports can be busy, there might be some CSR sitting and waiting for calls. In case of IVR failures it may be worse. I have to provide additional DTMF-menus to qualify calls within the ACD, in case all IVR ports are busy or IVR is not available at all.
If the IVR would be sitting "in front" of the ACD I would have to do the same programming effort in the ACD, 'cause in case of an IVR failure the service-numbers would have to be routed to lines terminating in the ACD instead if the IVR...
- traffic
- voice recognition needed for all calls?
- are IVR services independant from ACD (optional).
- can you live without IVR?
- does your IVR application provide some kind of self service (ACD with routing to CSR is optional)?
- can you imagine how your business will develop within some years?
- what are your boss' expectations?
You see... it depends.
I would try to be variable, start with a small application transfering calls from ACD to IVR, get used to customers reactions and the reporting (just another big point). And be prepared to connect lines terminating into the IVR if it's necessary. You'll might end up having your IVR "in front" and "behind" the ACD at the same time
Not completely off topic: integrated systems providing ACD functionality, CTI and speech recognition are on their way and probably VoIP will give them a boost... but if you have more than 300 users, you can keep with your systems for the next few years...
just my 2cents.
- Thread starter
- #5
AppSpecialist
Programmer
Thanks Chris for the insightful response.
A couple of your comments peaked my interest... if you or anyone else could comment, I would appreciate it.
You mention reporting issues created by adding the IVR... does anyone want to elaborate on that.
Also, we currently have and use the IVR functionality on the ACD and will be moving toward the stand alone IVR... what were the deciding factors... other than speech reco, that caused you or others to move to a stand alone IVR.
Also if anyone could comment on implementation challenges or issues they had to work through during a stand alone IVR implementation, that would be helpful as well.
A couple of your comments peaked my interest... if you or anyone else could comment, I would appreciate it.
You mention reporting issues created by adding the IVR... does anyone want to elaborate on that.
Also, we currently have and use the IVR functionality on the ACD and will be moving toward the stand alone IVR... what were the deciding factors... other than speech reco, that caused you or others to move to a stand alone IVR.
Also if anyone could comment on implementation challenges or issues they had to work through during a stand alone IVR implementation, that would be helpful as well.
Hi Frank,
come on, what are the deciding factors? Makes me curious Some reasons to use Aspect + standalone IVR with speech recognition or TTS:
- someone was flashed by "IVR - YOUR future!" and managed to buy the system. Now it's time to do something concerning ROI...
- your standalone IVR is an open system. You can develop your own applications. And within your app you can use all the interfaces and protocols needed to interact with your other business-systems... without buying contact-server or funding big, long lasting projects
OK, some details from real live, probably others can provide more usefull points.
If you make the IVR sitting behind the ACD:
- if you expect callers to be transfered from the IVR back into the ACD, you'll have to keep some channels free. Sitting in the IVR waiting for a channel won't make your customers happy. In the ACD you'll have to remove some channels of your spans from the outbound trunk group and make them member of a (dummy-) group which is not used to transfer calls to the IVR. Thus you'll want the IVR to transfer calls back into the ACD on exactly these channels of the span. Often you'll find some settings concerning trunk usage like within the ACD (ascending/ decending/least used), that's your tool.
- activating anti-trunk-tromboning (Q.SIG, DPNSS) for the connections between ACD and IVR, the IVR sends a request to the ACD, to connect the voice-path of 2 actually used by channels (in + out) within the ACD and free up the 2 channels of the span.
To be able to fullfill this request, the call must not be waiting for a resource of the ACD! For successfull ATT the call must be connected to a ressource (agent, admin. phone, another trunk or the voice-system).
The ACD just polls for these requests every 90s! Even if a call is finally conneted to an ACD-ressource you'll have to wait up to 90s to see the previously used channels going into idle state.
- make shure that ANI/CLI is transferred between ACD/IVR and back. Especially if you use ANI-routing in the ACD...
- Q.SIG spans are reliable. But when down, they sometimes need to be initialized/activated from both ends at the same time.
Concerning reporting:
If you just need some rough numbers, no problem.
But even then you'll have to teach your readers. X calls came into the IVR, Y calls did'nt make it back into the ACD. What happened to the rest? That's in the reports of the IVR. Probably you'll have to merge the numbers...
When the IVR sits behind the ACD (or when you transfer calls from ACD into the IVR) , you get at least 2 records in the ACD for every call. These are independant! If the ACD receives a call from the IVR, it does not know that this is a call which has been transfered _to_ the IVR before. It's a completely new call. You need to know your scheme to group your calls by DDIs and applications within the reports.
I ended up storing reference numbers in a variable (CALLDATA_C or whatever) and the reports do the grouping on that variable.
When ATT (anti trunk tromboning) is active, the situation gets even more interesting concerning CDRs:
- 1st call comes into ACD, gets transfered into IVR.
- 2nd call comes from IVR back into ACD, waits and gets connected to an agent.
20s later ATT takes place!
- 1st call is terminated
- 2nd call is terminated.
- 3rd CDR is created. Origination-info (origination, trunk-group, DDI and application) is the same as for the 1st call. Destination-info (destination, dest_group) is the same as for the 2nd call (answered by agent).
It has the track_id of the 1st call and an incremented track_sequence. It contains the remaining talk_time and the wrapup_time which should count to the 2nd call. But it has no reference to it (different track_id, DDI and applic).
If you want to show the real numbers based per call (customer point of view), you'll have to sum up the talk_time of 2nd and 3rd CDR. To achieve this, you'll need grab the records for CDRs for matching destinations, term_time of 2nd CDR = orig_time of 3rd CDR and some flags. Can give more details if needed...
Seems no problem if you show talk-/wrapup-time per agent or application, but the 3rd CDR increments the number of handled calls in the daily summary tables, too.
The average numbers computed using talk_time/handled calls are far from beeing accurate now.
That's the price of anti trunk tromboning. Without ATT it may be easier, but even then you'll have to think about what the numbers from the different systems say about your business.
- if something gets wrong between ACD and IVR, every vendor will blame the vendor of the other system to be guilty
that's all for today.
bye,
chris
- Time of day in ACD and IVR must be synchronized . Best practice is to use the same time reference as your other systems do.
- Everything you do might have effects on the reports.That's a general rule, even concidering an ACD on its own...
I have to be able to dig in the DBs of ACD and IVR to find all the traces of a single call. We get > 30k calls per day, and most of them produce more then 3 records in the systems.
come on, what are the deciding factors? Makes me curious
Some reasons to use Aspect + standalone IVR with speech recognition or TTS:- someone was flashed by "IVR - YOUR future!" and managed to buy the system. Now it's time to do something concerning ROI...
- your standalone IVR is an open system. You can develop your own applications. And within your app you can use all the interfaces and protocols needed to interact with your other business-systems... without buying contact-server or funding big, long lasting projects
OK, some details from real live, probably others can provide more usefull points.
If you make the IVR sitting behind the ACD:
- if you expect callers to be transfered from the IVR back into the ACD, you'll have to keep some channels free. Sitting in the IVR waiting for a channel won't make your customers happy. In the ACD you'll have to remove some channels of your spans from the outbound trunk group and make them member of a (dummy-) group which is not used to transfer calls to the IVR. Thus you'll want the IVR to transfer calls back into the ACD on exactly these channels of the span. Often you'll find some settings concerning trunk usage like within the ACD (ascending/ decending/least used), that's your tool.
- activating anti-trunk-tromboning (Q.SIG, DPNSS) for the connections between ACD and IVR, the IVR sends a request to the ACD, to connect the voice-path of 2 actually used by channels (in + out) within the ACD and free up the 2 channels of the span.
To be able to fullfill this request, the call must not be waiting for a resource of the ACD! For successfull ATT the call must be connected to a ressource (agent, admin. phone, another trunk or the voice-system).
The ACD just polls for these requests every 90s! Even if a call is finally conneted to an ACD-ressource you'll have to wait up to 90s to see the previously used channels going into idle state.
- make shure that ANI/CLI is transferred between ACD/IVR and back. Especially if you use ANI-routing in the ACD...
- Q.SIG spans are reliable. But when down, they sometimes need to be initialized/activated from both ends at the same time.
Concerning reporting:
If you just need some rough numbers, no problem.
But even then you'll have to teach your readers. X calls came into the IVR, Y calls did'nt make it back into the ACD. What happened to the rest? That's in the reports of the IVR. Probably you'll have to merge the numbers...
When the IVR sits behind the ACD (or when you transfer calls from ACD into the IVR) , you get at least 2 records in the ACD for every call. These are independant! If the ACD receives a call from the IVR, it does not know that this is a call which has been transfered _to_ the IVR before. It's a completely new call. You need to know your scheme to group your calls by DDIs and applications within the reports.
I ended up storing reference numbers in a variable (CALLDATA_C or whatever) and the reports do the grouping on that variable.
When ATT (anti trunk tromboning) is active, the situation gets even more interesting concerning CDRs:
- 1st call comes into ACD, gets transfered into IVR.
- 2nd call comes from IVR back into ACD, waits and gets connected to an agent.
20s later ATT takes place!
- 1st call is terminated
- 2nd call is terminated.
- 3rd CDR is created. Origination-info (origination, trunk-group, DDI and application) is the same as for the 1st call. Destination-info (destination, dest_group) is the same as for the 2nd call (answered by agent).
It has the track_id of the 1st call and an incremented track_sequence. It contains the remaining talk_time and the wrapup_time which should count to the 2nd call. But it has no reference to it (different track_id, DDI and applic).
If you want to show the real numbers based per call (customer point of view), you'll have to sum up the talk_time of 2nd and 3rd CDR. To achieve this, you'll need grab the records for CDRs for matching destinations, term_time of 2nd CDR = orig_time of 3rd CDR and some flags. Can give more details if needed...
Seems no problem if you show talk-/wrapup-time per agent or application, but the 3rd CDR increments the number of handled calls in the daily summary tables, too.
The average numbers computed using talk_time/handled calls are far from beeing accurate now.
That's the price of anti trunk tromboning. Without ATT it may be easier, but even then you'll have to think about what the numbers from the different systems say about your business.
- if something gets wrong between ACD and IVR, every vendor will blame the vendor of the other system to be guilty
that's all for today.
bye,
chris
- Time of day in ACD and IVR must be synchronized . Best practice is to use the same time reference as your other systems do.
- Everything you do might have effects on the reports.That's a general rule, even concidering an ACD on its own...
I have to be able to dig in the DBs of ACD and IVR to find all the traces of a single call. We get > 30k calls per day, and most of them produce more then 3 records in the systems.
- Thread starter
- #7
AppSpecialist
Programmer
Your right I think a main reason for us to go with the IVR are the recommendations and the you cannot live without it warnings from the vendor. And also the fear that if we do not... we are not thinking long term or strategically.
We already have contact server and e-flow, so I continue to question what the IVR will give us over what we already have... or better yet... are not using, when you throw us the speech capabilities.
I am only recently getting into this space, but I have a feeling a few years back we were promised the same type of functionality would be possible if we would only purchace Contact Server and e-flows. And don't forget the power of CTI... other than a screen pop to our legacy Call Centre Application, I have not seen anything that Contact Server, e-flows or CTI has offerred.
Now that we know we need to develop a few more applications (right now we only have account balance), the vendor is pushing IVR as the "easy" way to do this. However, I fear other issues may arise in a number of other areas... such as reporting, configuration, line capacity, etc... which may come back to bit us in the butt. Also, I wonder why we cannot leverage things like e-flows and contact server to do what need to do.
Would detailed training in all these specific areas help? We all know how expensive Aspect Training is... Are there non-Aspect consultants out there that know how all the pieces of these hardware and software glue together and can help us by providing un-biased recommendations and analysis? Are there other forums that I could use to continue this topic?
If anyone can help... or add to this discussion, please respond.
I think a main reason for us to go with the IVR are the recommendations and the you cannot live without it warnings from the vendor. And also the fear that if we do not... we are not thinking long term or strategically.We already have contact server and e-flow, so I continue to question what the IVR will give us over what we already have... or better yet... are not using, when you throw us the speech capabilities.
I am only recently getting into this space, but I have a feeling a few years back we were promised the same type of functionality would be possible if we would only purchace Contact Server and e-flows. And don't forget the power of CTI... other than a screen pop to our legacy Call Centre Application, I have not seen anything that Contact Server, e-flows or CTI has offerred.
Now that we know we need to develop a few more applications (right now we only have account balance), the vendor is pushing IVR as the "easy" way to do this. However, I fear other issues may arise in a number of other areas... such as reporting, configuration, line capacity, etc... which may come back to bit us in the butt. Also, I wonder why we cannot leverage things like e-flows and contact server to do what need to do.
Would detailed training in all these specific areas help? We all know how expensive Aspect Training is... Are there non-Aspect consultants out there that know how all the pieces of these hardware and software glue together and can help us by providing un-biased recommendations and analysis? Are there other forums that I could use to continue this topic?
If anyone can help... or add to this discussion, please respond.
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question