3 Way transfer doubts

[liigi]

Hi everyone

I have some doubts about 3 way transfer. I am trying to make a conference with 2 agents from different campaigns. At the beginning everything is fine, I have 1 agent in Campaign A and list 001 and 1 agent in campaign B with list 002.

the goal is that when the call from campaign 1go to campaign 2 , the script that appears to agent 2 will be the data loaded in list 002, however, the data that appears in the scripts are those in list 001. In the inboum group I have to look up for the records in a specific list, the 002, however this does not work

[liigi]

I have another campaign where I apply something similar, but I do a direct transfer using a DID 55 then it goes to an inboun group, then to the agent of campaign 2, and in this way loads the data from the list 002. Analyzing the traces I realize that the 3 way transfers for some reason is not using the DID that you configure to make the transfer

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

I have another campaign where I apply something similar, but I do a direct transfer using a DID 55 then it goes to an inboun group, then to the agent of campaign 2, and in this way loads the data from the list 002. Analyzing the traces I realize that the 3 way transfers for some reason is not using the DID that you configure to make the transfer

3 way transfers do not use DIDs. They use ingroups. DIDs are for inbound calls only, by definition "Direct Inward Dial" is meant to route a call from an external caller to an internal agent. Not internal to internal.

Transfers do not involve "changing the record" in any way during the transfer. The act of a 3-way transfer sends a lead from one agent to another agent (internally or externally) but it's the lead that is being transferred.

I strongly suspect you need to tell us why you think you need two records in two lists for one client and I bet we find your problem is one of understanding instead of a problem with Vicidial. I also bet you're doing more work than you need to.

[liigi]

Hi there thanks for the reply ,You are right i miss some data .I use vicibox 7
VERSION: 2.12-563a BUILD: 160801-2119
MORE INFO : Version: 2.12b0.5 SVN Version: 2578 DB Schema Version: 1464

ANd yes i have the paid doc y buy it long ago time

well I was validating the logs and I realized that it does not use the DID, the reason why I wanted to use two different records is because both users use and must put different information, however to simplify things, decide to add all the fields even script

[liigi]

However, another problem arose, I understand that the three-way conferences are internal, but i can do a conference with an external agent? It's possible? I mention this, because I thought to use the DID to do it, but since it does not work I do not know how to do it

I have Another vicidial cluster ViciboX 8 an i need the agents in CLuster A to do a 3way conference with agents form cluster B sounds complicated

[williamconley]

You're going in a lot of directions there.

So you apparently decided to put all information in one record, we're done there. That's good.

But there are no "internal" or "external" agents. Agents in Vicidial are "logged in" (those with computers) or "remote" (those without computers). Note that if you use a Remote Agent in Vicidial, that remote agent *could* be on a completely different Vicidial server and see this as an incoming call to their system. But in transferring the call to a different Vicidial (or other) system, the new agent no longer has access to the Vicidial Lead record you just finished creating (bit of a waste there, obviously).

So WHY do you think you need to send a call to someone "externally?"

A fairly standardized Vicidial Call Center will have Fronters, Closers, Verifiers and blended inbound/outbound calls for the Fronters (possibly for the Closrs). Verifiers will have "transfers" only. Closers don't ordinarily get outbound calls, they usually only get transfers from the Fronters, but some rooms will use Closers to avoid Drops and if they have enough Closers, they may only keep "some" closers available for transfers to better make use of the Closer's time.

But all of these will work within Vicidial on a single lead record for each prospect, collecting all data and call recordings in a single place for data harvesting and decisionmaking (eg: Do we call this person again? based on prior history, all of which is available).

[liigi]

Again, thank you very much, maybe some things are not very clear (apologize for my English)
the idea of ​​having 2 clusters in the beginning was to divide workloads since the first cluster was getting a little short even though we had correctly sized it and applied corrections to improve the performance

[liigi]

Something that does not clarify is that there are 2 campaigns, the 1 campaign (telemarketing) receives the calls from the client and if the sale is achieved by transferring it to a campaign 2 (post-sale), making normal transfers worked correctly between the vicidail cluster. but the high executive asked us to make transfers of 3 wayinstead of normal transferences so things got complicated.
And by the seen, according to the conversation it will not be possible to do it at least in the structure that we have now.

to conclude and not to bother anymore

-In 3 way transfer decided to put all information in one record.
-I decided to divide the 2 campaigns into 4 campaigns (2 for the cluster vicidial1 and 2 for the cluster vicidial 2). In this way, we would make transfers in 3 ways with no problems, just divide the DB so that half of it is managed in each cluster

I hope the information can serve others

[williamconley]

Again, thank you very much, maybe some things are not very clear (apologize for my English)
the idea of ​​having 2 clusters in the beginning was to divide workloads since the first cluster was getting a little short even though we had correctly sized it and applied corrections to improve the performance

If all the 2nd cluster was handling was transfers from the primary cluster: Sounds like you should have merely had more servers in the first cluster and/or a more powerful database. Or possibly just a better understanding of how Vicidial Transfer Groups Work.

Something that does not clarify is that there are 2 campaigns, the 1 campaign (telemarketing) receives the calls from the client and if the sale is achieved by transferring it to a campaign 2 (post-sale), making normal transfers worked correctly between the vicidail cluster. but the high executive asked us to make transfers of 3 wayinstead of normal transferences so things got complicated.
And by the seen, according to the conversation it will not be possible to do it at least in the structure that we have now.

to conclude and not to bother anymore

-In 3 way transfer decided to put all information in one record.
-I decided to divide the 2 campaigns into 4 campaigns (2 for the cluster vicidial1 and 2 for the cluster vicidial 2). In this way, we would make transfers in 3 ways with no problems, just divide the DB so that half of it is managed in each cluster

I hope the information can serve others

The original client/agent call would occur in the Fronters campaign (which may or may not involve the call arriving from an Ingroup to get to this campaign.

Then the call would be "warm transferred" (ie: agent1/fronter, agent2/closer, and Prospect all talking to each other for the comfort of the prospect during transfer). Note that this COULD occur in the SAME campaign. The transfer would occur in a Transfer Group. The campaign in which agent2/closer logs in is NOT relevant. The Ingroup/Transfer group from which they receive calls, however, is very relevant. That transfer group could be in the same campaign or in another campaign, and in NO way has any requirement to be on a separate server. In fact: It should remain on the same server for speed of transfer, visibility of data from one agent to the next and even for visibility of "closer availability" to the Fronter.

I think you just need to learn how to use Vicidial's Ingroup/Transfer group functionality. Get the manual. Start at page one. Do Not Skip Anything until you get to the end. I strongly suspect you'll have an epiphany and find that you could be doing this MUCH easier than you are. I repeat: Do not skip any page. Beginning to end of the Free version of the manual, but get the paid one, too, since you will likely be able to use a lot of the extras as well. But do every exercise in the Free one until you understand how it all works. Did I mention it won't cost you anything? Free?

[liigi]

Very well I will follow your advice thank you very much