Hi,

We need to implement Dialer with the following requirements.  We are looking for the most optimal solution to reduce Dialer admin efforts for maintaining the campaign.  I would really appreciate your suggestions if you have any.

We have a calling list that has a StoreID column.

• Up to 1400 different storeIDs in the contact list
• Multiple records with same storeID.

 We have about 70-100 agents.

 Specific requirements:

• When an agent is assigned a record with a storeID, all subsequent records pushed to the agent must be with the same storeID until there are no more records for that storeID.
• Only one agent can be assigned to a storeID at a time.  

The only way we found for now would be to create multiple campaigns (one per agent) by filtering the calling list on groups of storeIDs.  However the business does not find this "manageable".

Any suggestion is appreciated!

Thank you​
#Outbound

------------------------------
Marc-Andre
------------------------------

Marc-Andre,

Firstly, I would agree with the business - having 70-100 campaigns isn't exactly manageable!

My gut is telling me Skills-Based Dialing in some way, possibly including some Custom Handlers.

So, thinking out loud. You could create another column. Initially populate this with some value like "None". Next, create a skill for each Agent and one extra for "None". Give each Agent their own skill and also the "None" skill. Create a Dialer Skill Set that maps each of the skills to a corresponding value in the new column, give everything other than "None" a really high dialing ratio.

Next, create a Stored Procedure that you can pass a Store ID and Agent to. This SP should find all the records with a particular Store ID and change the new column to contain the value that maps to the Agent in Question's skill.

Finally, create a Disposition Policy that calls the SP whenever the new column contains "None" (you could also have it only do this if the call was actually answered and so on...)

So, what should happen is that initailly all agents can call all stores. As soon as they call one, however, the database is updated so that the skill requirement for all matching stores is only satisfied by the agent. The crazy dialing ratio should ensure that the vast majority, if not all, calls are for the skill and not "None". Since no other agent has the skill, they can't be offered the same StoreID. Once there are no callable records left in the recycle, the agent should get offered another "None" and the cycle repeats.

Probably not perfect, and may require some additional tweaking (for example, it is possible that prior to a store being allocated to an agent, it gets called by two agents on different contacts at the same time.) But I *think* that for the most part it should work. You will need to test...!

Of course others may have alternate ideas....

------------------------------
Paul Simpson
Senior Technical Instructor
------------------------------

Original Message:
Sent: 06-25-2020 10:51
From: Marc-Andre Nadeau
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Hi,

We need to implement Dialer with the following requirements.  We are looking for the most optimal solution to reduce Dialer admin efforts for maintaining the campaign.  I would really appreciate your suggestions if you have any.

We have a calling list that has a StoreID column.

• Up to 1400 different storeIDs in the contact list
• Multiple records with same storeID.

 We have about 70-100 agents.

 Specific requirements:

• When an agent is assigned a record with a storeID, all subsequent records pushed to the agent must be with the same storeID until there are no more records for that storeID.
• Only one agent can be assigned to a storeID at a time.  

The only way we found for now would be to create multiple campaigns (one per agent) by filtering the calling list on groups of storeIDs.  However the business does not find this "manageable".

Any suggestion is appreciated!

Thank you​
#Outbound

------------------------------
Marc-Andre
------------------------------

Hi Paul,

Thank you for the great idea.   

Couple of things that comes to mind with the potential solution that we will test down the road...

 - Is there a potential risk of database/table lock by doing a WRITE to the calling list during PreCall policy?  Or is this something that is frequently done and that since the WRITE is performed by Dialer/PureConnect (and not a third party application), we have do not have potential lock issues?

 - I believe Dialer sometime caches records in memory.  If this is the case, the table update would not be seen by Dialer for records.  However, since we are using Preview, maybe Dialer does not cache any records.. To be validated.

Thank you!
Marc-André

------------------------------
Marc-Andre
------------------------------

Original Message:
Sent: 06-25-2020 11:23
From: Paul Simpson
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Marc-Andre,

Firstly, I would agree with the business - having 70-100 campaigns isn't exactly manageable!

My gut is telling me Skills-Based Dialing in some way, possibly including some Custom Handlers.

So, thinking out loud. You could create another column. Initially populate this with some value like "None". Next, create a skill for each Agent and one extra for "None". Give each Agent their own skill and also the "None" skill. Create a Dialer Skill Set that maps each of the skills to a corresponding value in the new column, give everything other than "None" a really high dialing ratio.

Next, create a Stored Procedure that you can pass a Store ID and Agent to. This SP should find all the records with a particular Store ID and change the new column to contain the value that maps to the Agent in Question's skill.

Finally, create a Disposition Policy that calls the SP whenever the new column contains "None" (you could also have it only do this if the call was actually answered and so on...)

So, what should happen is that initailly all agents can call all stores. As soon as they call one, however, the database is updated so that the skill requirement for all matching stores is only satisfied by the agent. The crazy dialing ratio should ensure that the vast majority, if not all, calls are for the skill and not "None". Since no other agent has the skill, they can't be offered the same StoreID. Once there are no callable records left in the recycle, the agent should get offered another "None" and the cycle repeats.

Probably not perfect, and may require some additional tweaking (for example, it is possible that prior to a store being allocated to an agent, it gets called by two agents on different contacts at the same time.) But I *think* that for the most part it should work. You will need to test...!

Of course others may have alternate ideas....

------------------------------
Paul Simpson
Senior Technical Instructor

Original Message:
Sent: 06-25-2020 10:51
From: Marc-Andre Nadeau
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Hi,

We need to implement Dialer with the following requirements.  We are looking for the most optimal solution to reduce Dialer admin efforts for maintaining the campaign.  I would really appreciate your suggestions if you have any.

We have a calling list that has a StoreID column.

• Up to 1400 different storeIDs in the contact list
• Multiple records with same storeID.

 We have about 70-100 agents.

 Specific requirements:

• When an agent is assigned a record with a storeID, all subsequent records pushed to the agent must be with the same storeID until there are no more records for that storeID.
• Only one agent can be assigned to a storeID at a time.  

The only way we found for now would be to create multiple campaigns (one per agent) by filtering the calling list on groups of storeIDs.  However the business does not find this "manageable".

Any suggestion is appreciated!

Thank you​
#Outbound

------------------------------
Marc-Andre
------------------------------

Yeah, I did say it was "Top of mt head" and would need testing...!

One (minor) correction, it would be a Disp[osition, not a Pre-Call policy.

You are correct that Dialer caches records and, ordinarily, with Skills-Based dialing the "profile" of the records in cache should match that of the agents logged in. I don't know if it is possible to control the size of this cache, so this may well be an issue for you.

I did say I thought it may involve Handlers as well, although what those Handlers would actually need to do is anybody's guess!

Hopefully some others will chip in with suggestions.

I did have another thought. Have you looked at the Lattitude product? I know very little about it, but I do know it's used for Collections and integrates with Dialer. I'm just thinking that it also has the concept of record "ownership" which you may be able to re-purpose in some way?

I never heard of Lattitude, I will take a look.

Thanks!

------------------------------
Marc-Andre
------------------------------

Original Message:
Sent: 06-25-2020 14:16
From: Paul Simpson
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Yeah, I did say it was "Top of mt head" and would need testing...!

One (minor) correction, it would be a Disp[osition, not a Pre-Call policy.

You are correct that Dialer caches records and, ordinarily, with Skills-Based dialing the "profile" of the records in cache should match that of the agents logged in. I don't know if it is possible to control the size of this cache, so this may well be an issue for you.

I did say I thought it may involve Handlers as well, although what those Handlers would actually need to do is anybody's guess!

Hopefully some others will chip in with suggestions.

I did have another thought. Have you looked at the Lattitude product? I know very little about it, but I do know it's used for Collections and integrates with Dialer. I'm just thinking that it also has the concept of record "ownership" which you may be able to re-purpose in some way?

------------------------------
Paul Simpson
Senior Technical Instructor

Original Message:
Sent: 06-25-2020 13:54
From: Marc-Andre Nadeau
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Hi Paul,

Thank you for the great idea.

Couple of things that comes to mind with the potential solution that we will test down the road...

 - Is there a potential risk of database/table lock by doing a WRITE to the calling list during PreCall policy?  Or is this something that is frequently done and that since the WRITE is performed by Dialer/PureConnect (and not a third party application), we have do not have potential lock issues?

 - I believe Dialer sometime caches records in memory.  If this is the case, the table update would not be seen by Dialer for records.  However, since we are using Preview, maybe Dialer does not cache any records.. To be validated.

Thank you!
Marc-André

------------------------------
Marc-Andre

Original Message:
Sent: 06-25-2020 11:23
From: Paul Simpson
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Marc-Andre,

Firstly, I would agree with the business - having 70-100 campaigns isn't exactly manageable!

My gut is telling me Skills-Based Dialing in some way, possibly including some Custom Handlers.

So, thinking out loud. You could create another column. Initially populate this with some value like "None". Next, create a skill for each Agent and one extra for "None". Give each Agent their own skill and also the "None" skill. Create a Dialer Skill Set that maps each of the skills to a corresponding value in the new column, give everything other than "None" a really high dialing ratio.

Next, create a Stored Procedure that you can pass a Store ID and Agent to. This SP should find all the records with a particular Store ID and change the new column to contain the value that maps to the Agent in Question's skill.

Finally, create a Disposition Policy that calls the SP whenever the new column contains "None" (you could also have it only do this if the call was actually answered and so on...)

So, what should happen is that initailly all agents can call all stores. As soon as they call one, however, the database is updated so that the skill requirement for all matching stores is only satisfied by the agent. The crazy dialing ratio should ensure that the vast majority, if not all, calls are for the skill and not "None". Since no other agent has the skill, they can't be offered the same StoreID. Once there are no callable records left in the recycle, the agent should get offered another "None" and the cycle repeats.

Probably not perfect, and may require some additional tweaking (for example, it is possible that prior to a store being allocated to an agent, it gets called by two agents on different contacts at the same time.) But I *think* that for the most part it should work. You will need to test...!

Of course others may have alternate ideas....

------------------------------
Paul Simpson
Senior Technical Instructor

Original Message:
Sent: 06-25-2020 10:51
From: Marc-Andre Nadeau
Subject: Any suggestions on how to implement Dialer for those specific requirements?

Hi,

We need to implement Dialer with the following requirements.  We are looking for the most optimal solution to reduce Dialer admin efforts for maintaining the campaign.  I would really appreciate your suggestions if you have any.

We have a calling list that has a StoreID column.

• Up to 1400 different storeIDs in the contact list
• Multiple records with same storeID.

 We have about 70-100 agents.

 Specific requirements:

• When an agent is assigned a record with a storeID, all subsequent records pushed to the agent must be with the same storeID until there are no more records for that storeID.
• Only one agent can be assigned to a storeID at a time.  

The only way we found for now would be to create multiple campaigns (one per agent) by filtering the calling list on groups of storeIDs.  However the business does not find this "manageable".

Any suggestion is appreciated!

Thank you​
#Outbound

------------------------------
Marc-Andre
------------------------------