Hi everyone! CSM pooled models (a.k.a. round robin CTA assignments) have been quite the hot topic lately with more and more customers looking for scalable ways to manage their long tail of customers.
I know
First, let’s start with the prerequisites.
-
Queue CSM (string) - Purpose is to denote whether a CSM belongs in the pooled model. Manually update from Administration > User Management, and enter “Yes” if they are a Queue CSM. Otherwise leave blank.
-
Queue Next Up Number (number) - This is updated via rule(s) that you have in place for pooled CSM CTAs. In addition to the action of creating a CTA, there will be an action to load to user and update the Queue Next Up Number for every user (from 1 to 2, for example), so that next time the rule runs it will assign to a different CSM. When first setting up your queue CSMs via Administration > User Management, simply add “1” in this field for each of your pooled users, no matter how many you have.
-
Queue Number (number) - Assigns a number for each Queue CSM. Do this in your initial setup from the Administration > User Management interface. So if there are 3 CSMs, enter “1” as their queue number, the next one gets 2, the one after that gets 3, and so on. This number does not change.
-
Queue Total Members (number) - Contains the total number of CSMs who belong in the queue and will get assigned pooled customers. This number will be the same for all your users. So if you have 3 total queue CSMs, just enter “3” in this field.
-
Queue Next Calculation (number; formula field) - This is a helpful formula field that you can create directly in the MDA User object. The formula is a number field and is simply (“Queue Next Up Number” minus “Queue Number”). This is a helpful shortcut because if the number is “0”, you know it’s that CSM’s turn to get a CTA, and you can therefore use “Queue Next Calculation = 0” as a filter in your dataset.
-
Queue NextUp Plus 1 (number; formula field) - This calculated field exists to add 1 to whatever the Queue Next Up Number is. Purpose is to be able to reset Queue Next Up Number to 1 whenever Queue NextUp Plus 1 is greater than Queue Total Members (i.e. if the Queue NextUp Plus 1 is 4, but there are only 3 total CSMs, the rule action would manually reset the Queue Number to 1, in order to start over the Queue)
Queue CSMs will now look like this in Report Builder
Now, let’s walk through an example of how to create a CTA for your pooled model
-
Start by creating a CTA like you normally would. Query the appropriate data in your initial dataset.
-
Then, you need to do a transformation task, bring over all the fields from your original dataset, then add an artificial join that yields the word “yes” for each row of data. You can do this by creating a concatenate formula field that combines “Ye” and “s”. You can also do this with a case expression, whichever you prefer.
-
Once your artificial join is created, you’ll need to query your user table and pull in your pooled CSMs. That dataset should include your user GSID, Name, all six Queue fields you created (reference above), and whatever else would be helpful (e.g. email, etc). Be sure to add the filters “Queue CSM = Yes” and “Queue Next Calculation = 0”
-
Now you are ready to merge your datasets. You’ll be using the “artificial” merge to bring the two datasets together, meaning your formula field for “Yes” that you created will merge with the “Queue CSM” field, so any user that has “Yes” for Queue CSM will be merged into your final dataset.
-
This is helpful because it allows you to potentially have a rule that can assign CTAs to pooled and non-pooled users.
-
In the CTA rule(s), also create additional actions to update User records
-
Your first action will be to assign the CTA to the Queue CSM GSID just like you would assign any other CTA action.
-
Your next two actions are both Load to User update operations and both use “Queue CSM” as the identifier. The first one advances the queue’s number by one and loads the “Queue NextUp Plus 1” formula field directly to the “Queue Next Up Number.” So if the queue number was 1, it will now be 2. You need two actions because for the second one, you need to reset the queue number to 1 if the “Queue NextUp Plus 1” formula field exceeds the “Queue Total Members.”
-
For example, let’s say you have 3 total CSMs in the Queue. If the Queue Number is 3 and the CTA gets assigned to that person, then the Queue NextUp Plus 1 would be 4, which exceeds the 3 total queue members. So you’d add a filter saying the queue needs to reset to 1 if “Queue NextUp Plus 1” > “Queue total members”.
-
Here is the update user action if “Queue NextUp Number + 1 <= Queue total members
Here is the update user action if “Queue NextUp Number + 1 > Queue total members
Future-proofing your CSM pooled model + Caveats
-
There are a lot of variables to consider, of course. Say, for example, you need to account for PTO or an extended leave for someone in the queue. We don’t have a great way to handle that. It would require manual intervention on the admin’s part to either replace that person in the queue with another user or manually reassign the CTAs that get assigned to the absent person.
-
If you want to take time or complexity into account (i.e. not overload one pooled CSM with complicated tasks while the other pooled CSMs are dealing with much easier ones), you’ll need to add that logic into your pooled CTA rule(s).
-
We recommend scheduling any pooled CTA rules every 2 hours. The shorter the interval, the more you can control variance - e.g. if you scheduled a rule daily, you might assign 10 CTAs to queue number 1, then 1 CTA to queue number 2 the next day. If scheduled every 2 hours though, there’s a much greater likelihood that you’d have a more even split.
-
Overall, this solution future proofs pretty well because the rules do all the updating of the queue CSM fields. Besides the initial setup, there should be very little maintenance for an admin. The obvious exception is if someone needs to leave or enter the queue. Here’s a breakdown on those scenarios:
-
If you need to add someone, this is easy. Just follow the process noted above and assign that person a “Queue Number” of whatever the next number up is (e.g. “4” if she is the 4th CSM in the queue).
-
If you need to replace someone, this should also be straightforward. You’ll have to manually remove one person’s queue status (change “Queue CSM” back to null and erase the other Queue fields) and simply assign it to the new person.
-
If you need to remove someone and not replace them, this becomes more complicated. Let’s say you have three CSMs at first, but now someone’s leaving so you’ll only have two CSMs. You’ll need to remove the queue fields from the user who’s leaving while also updating the “Queue Total Members” field for the remaining users. You may also have to reassign “Queue Numbers” for the other users if, say, “Queue Number” 1 user is leaving.
