We are finding that CSMs like to “bundle” their work to complete multiple units of work in a single performance coaching CTA / call. My idea is to allow multiple Playbooks to be associated with a single CTA. For example, we might create 3 CTAs to the CSM that they ultimately plan to address in a performance call.
CTA-A, Playbook 1: fires 3/1
CTA-B, Playbook 2: fires 3/5 (we wouldn’t know on 3/1 this is happening)
CTA-C, Playbook 3: fires 3/20 (we wouldn’t know before 3/20)
The CSM already had a call scheduled for 3/25 and the requests are not urgent enough to warrant a stand-alone call. Ideally, CSMs could add Playbooks 2 & 3 to CTA-A and have everything centralized for the talking points, follow-up, and timeline entries related to all 3 playbooks.
Ideally, we would as admins love to be able to bundle these processes together for the CSMs without having to re-create the same tasks in multiple playbook for every possible configuration. It would be ideal to have logic that says, when CTA-C fires, if CTA-A is open, add Playbook 3 to CTA-A. I recognize that is a much bigger ask, but that would be a long-term vision.
I like this idea. Currently, you have the option to Replace a playbook. What if you had the option to add an additional playbook?@angela_domenichelli the way I’ve handled in the past is just have the CSM close out the other CTAs and include a note that they addressed with another CTA. Not ideal I know. 
. I can’t really think of another way to deal with it today other than that.
We just tell them to either close the CTA as N/A or as Closed Success, whichever is more appropriate.
I can understand the use case, but think it could introduce complexities and potentially create administrative issues for reporting and other logic (for example, we use the Playbook name/ID in logic in many rules and reports to identify CTAs because that’s the only non-end user editable entity associated with a CTA). Also, something like this I expect would require a large data overhaul because of how the data is stored...today Playbook is a lookup on the CTA object to a singular entity/ID. And since GS doesn’t really handle multi-picklists very well, from a logic perspective, it raises concerns in my mind, so I don’t feel ready to “vote” for it.
We just tell them to either close the CTA as N/A or as Closed Success, whichever is more appropriate.
I can understand the use case, but think it could introduce complexities and potentially create administrative issues for reporting and other logic (for example, we use the Playbook name/ID in logic in many rules and reports to identify CTAs because that’s the only non-end user editable entity associated with a CTA). Also, something like this I expect would require a large data overhaul because of how the data is stored...today Playbook is a lookup on the CTA object to a singular entity/ID. And since GS doesn’t really handle multi-picklists very well, from a logic perspective, it raises concerns in my mind, so I don’t feel ready to “vote” for it.
Totally appreciate that! We also report on playbook name, and this is part of our challenge with the 1:1 mapping of playbooks to CTAs. If the CSM has marked 1 playbook closed-success, but won’t actually complete (some, most?) of the tasks until another CTA is closed out, then in reporting it looks like they have completed the steps …. but they really haven’t. We would like to report on the tasks that are still in play and having multiple playbooks to 1 CTA would help with accurately reporting that. Open to other ideas about how to solve! Maybe a “merge CTA” button?
Yes! Today CSMs can append tasks, but not a full playbook that has pre-set instructions, due dates, and email templates. Thank you for considering.