Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N
mflorell wrote:It would be a massive undertaking, and if you wanted to maintain the same full feature set, it would also actually slow down the database. Every time you had more than one list active in a campaign, you would have to create a temp table every time you ran the hopper, to dump all dialable leads into to do the lead sort(lead order) that was selected. Also, using UNIONs and TRIGGERs and SUBSELECTS greatly slow down the database and reduce the capacity of your system.
It's not a horrible idea, just one that would have side effects that would hinder the goals of having a faster system with more lead capacity. It's actually the strategy we used when creating custom list fields, although with that the main default lead data fields still all exists in one table, the extra fields are created in a list-specific table allowing for more flexibility and speed when storing that extra lead data.
mflorell wrote:On the inbound side, or an agent placing a manual dial call, think about the monster JOIN query that would be needed to search for a phone number in all of those separate list tables.
There are many challenges like these that would be needed to be sorted through before anything like this could be attempted, and there is no way we would embark on a project as big as this as unfunded either. We would have to have a client pay for it, and it would most likely be 200+ hours to make it happen.
cavagnaro wrote:Is there any doc that explains each part of the dialer? Why a manual call needs to be used against a DB? Making it optional makes more sense after call was established...Or idea is to "CRM" each call?
Users browsing this forum: No registered users and 61 guests