A relationship type represents an entity that needs to be managed separately and would need a different process including different playbooks. It is also important for a success designer to be able to make tweaks to a playbook without being worried about impacting the process of other relationship types that might be using the same playbook.



While restricting a playbook to a single relationship type makes it easier for each relationship type to manage their process independently, it add additional overhead like you mentioned. It is also an overheard when you would want to define a common Customer Success practices/process across the org or across multiple relationship types. We will optimize for this case as well by allowing you to setting company level processes guidelines that can be pushed down across multiple relationship types more seamlessly and without additional configuration overhead. 

---

Is there not a way to allow the option to use either an Account or Relatinoship playbook no matter what level? Many enterprise companies will benefit from this separation. But, there will be use cases where an enterprise company would want multiple relationships (e.g. by Business Unit) with consistent playbook tasks. As Jeff mentioned, companies like this would need to duplicate playbook and remember to maintain as such (e.g. updating multiple playbooks).

---

Keep in mind that playbooks can now reference Relationship fields, which is necessary to support default task assignment and such.  Having a single playbook apply to multiple types could then break as the fields may be different. Of course, sometimes that isn't a problem but going down this path can lead to confusing situations where some playbooks can be shared but others can't and it isn't obvious why. Lots of corner cases here.  As Sidhu mentioned, the cleanest approach is to have a conceptually simple foundation -- playbooks per relationship type -- but then build tools that make this easy to deal with, stuff like one click copy to many types or 'synchronization' actions, etc. 

---

I suppose that makes sense....I think. 🙂  Anything that can be done to help save us admins time would be greatly appreciated. Thanks Karl!

---