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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hunt instead of ACD queue? What's the difference?

Status
Not open for further replies.

Benighted

Technical User
May 2, 2006
43
SE
I got a quote from our vendor on 60 new ACD licenses as we are going to deploy a new IVR which will utilize 60 ports.
Since it was a lot of costs involved I asked to vendor to look at some other way to do it. The project leader then comes back to me and say that they can circumvent the issue by using something called "hunt" instead of ACD queues. He didn't know the difference, but reassured me that the IVR would work just as fine, and there would be no costs involved. Does anyone here know what hunt is?
 
In short.. painful.. fair amount of programming, no stats as such, and if you want to out or mov a phone you have to remove the extn from all the hunt groups.

But will work

It's not getting any smarter out there. You have to come to terms with stupidity, and make it work for you.
 
If you use Symposium (log agents into the virtual TNS associated to the ports you can...

1) Get ports that don't answer the call to be logged out of symposium > less risk of dropped calls. Can't do this with hunt/distribution groups. If the faulty number is one of the first, this will havea significant impact (although you would realistically set the group up as round robin)

2) Use a CTI engine to track call events/what's happening in the IVR and send a screen pop with call to the CSR. This would, for example, mean you didn't have to redo security checks, get description of customer demand.

And as Mikey B says, the historical stats will be much better and you can also put key real-time stats to a display screen/PC for staff/managers.
DD
 
Hunting is moronic. We haven't programmed an IVR port as hunt or multi-call ring group since the 80's. And, there are numerous reasons. For starters, if you have a problem with a span or even just a single port, you will have to touch the entire group as Mikeyb and DD pointed out. You will have no real reporting on what your IVR is doing so you will have no way of building discernable metrics.

If you guys are that tight on money, don't even bother wasting it on an IVR this way. You'll never know what your weaknesses or your strengths are. Better that you spend that money on a couple more Agents, at least then you can have some stats and still stick with twenty year old technology.

Sorry if that’s too blunt, I’m just sick of managers who look at technology and say, “I want you to bring something in here to fix every problem I have, and I’m not going to pay anything for it.”
 
Thanks for all your replies. I have basically gone back to the vendor and asked them to forget about hunt and instead go for ACD groups. We are going to use CTI with GUI for CSR's, and we are using a Symp DB to get all our call data into a datawarehouse. I don't want to risk anything by utilizing a solution with less functionality, so ACD it is!

I totally agree with you mte0910 but in this case the vendor didn't tell us that we needed additional licenses for ACD groups until a very late stage in the project. Luckily the issue around costs are fixed now, and we can move ahead as planned.
 
Not sure what others' experiences have been, but I'd advise paying close attention to the integration of the IVR and Meridian if theswitch support and IVR vendors are different companies.

We had awful trouble with both of our IVR installations (two different IVR suppliers - don't ask!), which resulted in a lot of toing and froing between the IVR vendor and our switch supporter.

Have they provided you with reference calls that have run on the same set up? We got a lot of "yeah, yeah, we can do X, Y and Z", but when push came to shove we ended up doing a lot of the work for them as they didn't have the skills with the switch and Symposium.

Out of interest, how are you doing your CTI? Are you using a Nortel CTI engine (TAPI or CCT) or a third party one?

Good luck

DD
 
We are using the same vendor for the switch and the IVR, but I have heard of integration issues nevertheless. The main problem is that the IVR developer doesn't know the details of the switch. They end up sitting in the phone with remote support.

We will use CTI based on a CCT app server. Have you used anything similar?
 
We used CT Connect for our CTI. Bit of a nightmare providing screen pops for calls that were answered by the IVR and broken out to an agent on a different switch.

DD
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top