This is a good callout - one of the other problems with this, is that many Gainsight features operate with the assumption that these standard fields will be used. I would imagine, as AI takes over the platform more, this will be even more relevant.
If this is true, and to get the most out of a feature, admins need to utilize these fields, we’ll be at odds with our users and the rest of the business in terms of naming. Imagine trying to explain to anyone at your organization “Yes, I know we use ACV everywhere but to use this one feature, we use this field called ARR. Yes I can rename fields, no I can’t rename this one.” You’ll be laughed out of the room.
If instead we’re still able to map to our own fields, using our own naming conventions, you’re still left with a bunch of clutter that can only really add to confusion - especially if you’re trying to leverage things like end user reporting.
I agree with all of the above. I do try to leverage standard fields wherever possible though, and we do use a fair amount of those. As Bradley says, they’re used in a bunch of built-it rather good features (rather good imho).
I’d add that we should be able to add descriptions to these fields and definitely at least change the display name as said above.
Agreed with all the above, like @alizee said. Unfortunately, given that a lot of cool features (AI, cough cough) will mostly like rely solely on standard fields, the best option -- even though it creates clutter and confusion -- will more than likely be a rule mapping our custom fields to Gainsight standard fields, so we’re able to use those features. If it’s even possible… I’ll be the first to admit I’m not experienced when it comes to rules and mapping to different objects.
