Not OP but CRM consulting work usually involves customizing existing CRM solutions (often Salesforce) for a client's needs. This means interpreting vague requests from usually non-technical users and finding a way to bash it into the really terrible developer experience that CRMs have.
The reasons its pays so well are several:
1) Most CRMs are initally setup by non-technical users and suffer from a litany of performance issues stemming from bad architectural decisions (i.e. lets do all our analytics in Salesforce Apex (java-like) code instead of a mainstream ETL solution).
2) The process of customizing a CRM is the epitomy of enterprise development, there is a severe lack of standardization and many examples of close but not quite: Salesforces SOQL is kind of like normal SQL but with lots of weird quirks, Salesforce lignteningforce components are like some front-end frameworks but not quite and with lots of weird quirks.
3) Most development knowledge is tribal, meaning you learn Salesforce by going through the trenches and then that knowledge lives or dies by you and your team. It's difficult to learn and train for legacy development (training docs are often for the ideal cases which rarely exist in the wild) thus you get to charge whatever you want. Often the really tough questions can only be solved by wading through the customer support muck (if your licensing allows it) until you get to denvercoder9.
4) Every few years the Sales reps of the CRM company shove new development techniques and methodologies at their clients which can mean a large refactoring or migration is needed.
Both. You've got to work with the client to get an understanding of how they want to use their CRM, guide them on best practices and then pull the levers to configure things correctly. You can niche out and focus on one of the three areas but we find solving issues end-to-end is what our customers are looking for. They want us to come to them with issues we've found, best practices on solving them(as they apply to THEIR business) and to also take the steps to put it all in place.
All of our work is remote so there's no face-to-face per se but we do come on-site or take them out to lunch every quarter or two
The reasons its pays so well are several:
1) Most CRMs are initally setup by non-technical users and suffer from a litany of performance issues stemming from bad architectural decisions (i.e. lets do all our analytics in Salesforce Apex (java-like) code instead of a mainstream ETL solution).
2) The process of customizing a CRM is the epitomy of enterprise development, there is a severe lack of standardization and many examples of close but not quite: Salesforces SOQL is kind of like normal SQL but with lots of weird quirks, Salesforce lignteningforce components are like some front-end frameworks but not quite and with lots of weird quirks.
3) Most development knowledge is tribal, meaning you learn Salesforce by going through the trenches and then that knowledge lives or dies by you and your team. It's difficult to learn and train for legacy development (training docs are often for the ideal cases which rarely exist in the wild) thus you get to charge whatever you want. Often the really tough questions can only be solved by wading through the customer support muck (if your licensing allows it) until you get to denvercoder9.
4) Every few years the Sales reps of the CRM company shove new development techniques and methodologies at their clients which can mean a large refactoring or migration is needed.