CSM Pooled Model Documentation


Userlevel 7
Badge +1

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 @jean.nairon  and others have posted about this concept previously, and so I wanted to share a detailed solution, complete with thorough documentation and a video example from a dev org. Please note that this is meant to be a base foundation for a CSM pooled model, so you may well need to add more nuanced configuration to your own. I’m here to help with any questions or feedback! 

 

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.

 

b5fHdh0Z710BZ6ro9pd63W8en-N6Nefq3znYf1s625ierU0TMr8SctbJoZQP9y0KxGK6oY2eEOgkME43nsFt9eKueKXzqOI4D0x26jViUPSanUoBW4omuBjpNLdGLyL7Roarz0ge

 

  • 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)

 

7J3pNiitzImSWLu7AGKAXYsbakSBDDToigc4C9q1BfVg2lP0E-pcW0tC7FQ2pe2gkZQ0m8tb3tH_i2NUzRSBuNgXb1OIlcqvqwYuwSxwRY3iyNgJRtNTGU4HeGCrU9BcoxnyTN1m

 

Queue CSMs will now look like this in Report Builder

 

weryJkFIBpzP_MDsjjYWpS4w_8oWY8MUf12y2xi8dMnFw04NHR7ODWcPGaWcWNwYNsQ3-FVnprGTpqMjC09aaVCXTvY4dWWsztt4FtBDOLgyNKweEW_rjllsmNrfp_pDfwjn1U_e

 

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. 

 

VVUTXhK92eEs7BseEorPY99SlSgvnQeZcv2WFIbOE8q3tNslD7OhspnVfz2m4sIHVJ-1e9rJycl-eJJ6lR1s1JmMMRLTWA0JZHFGRV6Xh9esMQQgFfbwSqdu315MRN7qA7Qhfd49
 

  • 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”

 

y954I2CZZpF4Q6kr7zmdG2B6f5oVMHOP71ayzP6fG2Hv6DFJDOOYw9wIjTfU56Zn-FcyYofuYi9U0HRdavvMgYR8nG15rwfRcS-cZ9CD4NPRhI5Te7nnFUldMCK7pcOp3LePKcT0

 

  • 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.
       

mv4s0TzsATaN3i8lBU7nqDbg-mMHI7B18ROtVJ5noRZMzHCgpKl_9j5xp7GJHp3t7c2ELwOjo14itb3Rgpusy7-hRgsxHwB93-X93OGW3RaoA6yGLwQ-lUKo-oEXycosMDnmqWwI

 

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

XmRyVvezjbatibrYb5MZvwEwQcYPOkj-jJLak9Bwl20Pn1X1_LeKD8lJBjCz8OTzKUOsNf3Mr_t8i6ipnD7II-oOD9YvhNPfRVVYsy5bT9WWf2uGhIqvS7PqJcQKTqsvWQmeB7Ar

 

Here is the update user action if “Queue NextUp Number + 1 > Queue total members

 

kT0xwC-QRVZxRjyCJAtndDPk7R56WSFEdHPnBknQIP-g4FIOCMpbdDsCvBaSpoFTb0G1w3g-kl_-rQAscj7aSBJByTRGOdcCme4vJpx_dnf04mhdpp0QwuEFd-gI8apKSULqyGaR

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.


11 replies

Userlevel 7
Badge +2

Wow, @spencer_engel!  Thanks for taking the time to provide all the detail here!

Userlevel 4
Badge

cc: @hitesh_sharma we recently discussed this in the Cockpit office hours. There’s a lot of effort that goes into workarounds, so hoping that one day in the future this can be native to Gainsight. Thanks!

Userlevel 7
Badge

Nice work on this one @spencer_engel !

This is extremely helpful - really appreciate you putting this together!

Userlevel 7
Badge +2

Bumping this to the top for more visibility. Helpful for all the Rules engine lovers.

Userlevel 4

for some reason I cannot get the Queued CSM GSID to show up in the Owner field for the action.  Any suggestions?

 

 

Userlevel 7
Badge +1

Not sure @heather_landgraf. Did you make sure that Queue CSM GSID made it into your final dataset? 

Userlevel 4

@spencer_engel you can see in the image it is in the merge data which is what I am using to create the action.  

 

Userlevel 4

still not showing...not sure why.  @spencer_engel help?

Userlevel 4

ok got the pooled csm loaded.  cannot do rule to run every 2 hours in SFDC version can we?  @spencer_engel 

Userlevel 7
Badge +1

@heather_landgraf Sure you can. Documentation is here:
 https://support.gainsight.com/SFDC_Edition/Rules_Engine/Admin_Guides/Cron_Expression_for_Advanced_Scheduler_in_Rules_Engine

Reply