Please Help-Trying To Avoid Call Que

[Guest jdiegjdieg]

I recently upgraded from Voiceguide v6 to v7 and my application is failing miserably. Hopefully someone can give me some help.

I have 10 lines, and I place up to 10 calls at a time. I do not want the calls queued, because another application needs to constantly monitor the $RVs and must always know which "Jobs" are being called so that it doesn't try to call the same job on another line.

 

When an offer is "accepted", it must immediately stop calling on that job, and can't have calls queued up that will make more calls for that job.

 

When I send a number of jobs, the monitoring program cannot see them in a timely fashion (by reading $RVs), and on it's next cycle, sends another call for the same job. This causes more than one person to accept an offer that can only go to one person.

 

How can I prevent the Que, so that when I place a call, it immediately shows up in the $RVs of "some line" and remains visible in that line at least until it is hung up?

 

At this point I am desperate, and my application is only sending one call at a time to the Que to prevent 2 lines calling the same job.

[SupportTeam]

What you are really asking here is how to design your application in general.

The issue is not 'caused' by upgrading from v6 to v7 - sounds like the question and the issue is how to ensure that only one person is allowed to accept a particular 'job'.

 

Broadly speaking the common approach is to have the scripts update a database with the reservation ID, and have the SQL written in such a way that the reservation ID update is not made if there is another reservation ID already set in that field.

 

And once reservation is made then you can also delete all other outstanding calls for that job from the outdial database.

And people that accept the job, but the SQL query returns a result indicating that somebody else has just reserved that job can be played a message saying something like this: "sorry, the job was just reserved by somebody else..."

 

This approach would let you send out calls for the same job on multiple ports simultaneously, and only the first person to accept the job have the job assigned to them.

 

If you need further assistance you can post your script here to get more comments on it, or email it to sales@voiceguide.com along with your requirements and we can quote on creating a working solution/script that meets your requirements.

[Guest jdiegjdieg]

Thanks for the suggestions. I understand what you are saying, and you are right, the information that you gave is information about designing the application.

The thing is ... the application is designed, and it will take me a little time to redesign the whole thing. (It's not just Voiceguide scripts)

 

I think my issue today is that when I submitted calls to Voiceguide 6, they immediately appeared in the Line Status list.

The "Waiting for call" status went away, and when I read the $RV's, my call was there.

After the call finished, it said "Waiting for call" again.

This doesn't appear to be happening in Voiceguide 7. After I submit the call, it says "Waiting for call" for a period of time (short period, but sometimes more than 30 seconds), during which the app is not aware which jobs are being handled by Voiceguide. Can I get Voiceguide 7 to make the call immediately and prevent the delay, since I will never be queuing calls in this application?

 

I like your application idea, and will consider it, but I have suggested similar options and the client does not want to make the "offer" so that the user knows the details, and then tell the user that it is taken. Once the user hears the details, they need to be allowed to have the job.

[SupportTeam]

After I submit the call, it says "Waiting for call" for a period of time (short period, but sometimes more than 30 seconds),

Could you please post the vgEngine trace capturing an example of this and indicate at what time/call we should be looking at. The time delay between loading the call and the call being made should be usually 1 second and at most 2 seconds (if there are lines available).

 

the client does not want to make the "offer" so that the user knows the details, and then tell the user that it is taken. Once the user hears the details, they need to be allowed to have the job.

Some other approaches then could be:

 

1. You could 'reserve' the particular job by setting flag in DB before playing back that job details. Other lines would check for 'rserved' flag and not play back reserved jobs. Clear the flag if caller did not accept job or hung up etc.

 

or

 

2. if only one job is offered per outbound call then you can just restrict calls to be made for that job to one specific port only. That way you can be certain that the job is offered to one person at a time. Port restriction is set at call load time.