Testing this out has led me down a mind maze here so hopefully this is easy enough to follow and there’s likely more to unpack but I wanted to get a conversation started at least:
My first thought was that having different layouts for goals would be useful from an end-user perspective:
- At launch there are a number of fields that cannot be removed or changed, some of which make sense, but others for us add some clutter as not all goals may need a “Relationship” or “Opportunity” field.
- Many Gainsight areas allow for different “layouts” so that you can add fields that are relevant to a specific type of process not clutter a “layout” for another process that are less relevant.
Think Timeline Activity types - if you had 15 timeline types with 20 fields unique among them, if you only had the option of one layout you’d have 20 extra fields whenever you made a Timeline entry. Not ideal for end users.
I can see something similar happening here. As you build out your goal library you may not need the same fields for all Goal “templates” you create. I may have created 10 goals for my end-users, but they all look the same except for some pre-populated data they can change anyways (which I will get to later), but not every field will likely be useful for every one of those goals.
This becomes more important when trying to answer the question - what is the point of making more than one “Goal Template” right now?
- As an end-user:
- I could freely select from any available goal template and change anything about them that I want. So as an end-user maybe I select the wrong one. No big deal! I just edit whatever I want and slap it in the C/R360. There’s no decision making required on what to select, unlike a CTA or Timeline Activity type that is contextual in a more permanent way. If I select the incorrect CTA, I don’t have the right fields or maybe I won’t be able to flag risk properly. There’s no investment in following a particular prescribed business process that a template would normally provide right now.
- There’s also less of a reason not just to create my own goal, which sort of undercuts the utility of having a library. If I have a library goal of “Reduce Time to Value”, I might just make my own “Reduce TTV” goal that is really the same thing, but lacks any standardization that pulling one from the library might bring.
- The UI itself makes the library a bit of an afterthought rather than putting it at the forefront to prompt users to select something already built for them.
- For the business:
- These create a bit of a problem if I want to track how often specific “Goal templates” are being used and collect actual data on what goals and templates my customers have, how they are used, etc. If there’s no way within the system to programmatically “incentivize” my end-users to follow a specific process (e.g, at least require they select the correct layout to have certain fields visible) then the quality of your data will take a serious nose dive.
- End-users who selected the ‘wrong’ template may over inflate my usage data for a particular template, and under inflate others.
- If we have a KPI around usage of specific goals for customers with certain products, if end-users are constantly selecting the ‘wrong template’ and just fixing it, how can we get accurate reporting without more manual intervention?
The general concept of “template” vs “custom” I think is generally sound. From the business side I want a consistent, scalable and repeatable library of goals my users can draw from where they can create an instance of that goal for there customers as many times as they need.
As a user, I want an easy way to create and manage the goals of my customers. If they have a specific goal that isn’t captured in the library, I want a way to still capture that.
However, I just don’t know that what I’m seeing executes on that in a way that enables a business to get real valuable insights without additional layers of customization to get the capabilities this seems to hint at but not provide a way to deliver on.