I think he does a really great job and is the sort of person & consultant that I trust and can work with!
Getting CRM to do EXACTLY what the customer asks for
CRM consultants can be too quick to take a business requirement literally and try to bend CRM to fit the need. This is a risky path to follow and can lead to un-supported systems and solutions that result in more pain than they actually resolve. In this blog I discuss why this approach should be avoided particularly in terms of going against using the in-built customer model of CRM.
CRM consultants often find themselves being asked to do something with the CRM software stack that makes sense from a business perspective but doesn’t fit well with the CRM model. This is usually when we are trying to bend the customer oriented model in a different direction.
The best consultants push back and explain how the functionality may be met but unfortunately, many don’t and end up trying to hack the system to deliver exactly what the customer wanted.
In this blog I want to address the risk of taking a requirement literally and trying to model it in CRM.An example I saw recently was a consultant asking how a case could be linked to a lead (rather than an account or a contact) – because that’s what the customer wanted. This is a good example of a fairly common trend I see often on LinkedIn, Facebook and other social media sites.
Many consultants new to CRM who have bought into the XRM model assume that because we can flex the solution then there is no real limit to that flexibility. The other side of that scenario is that the customer just doesn’t understand the model and the rationale for doing things in a certain way.
I’ve written before about using Leads in CRM – it’s often one of the most contentious issues there is when looking at sales automation processes. What is a lead and when does it move on to become an account or contact causes a lot of discussion and there are as many models as you like. However, CRM has a pre-determined core Customer model which you fiddle with at your peril.
I believe that there are certain intractable rules in CRM and I believe that you (consultant or client) should never break them.
Going back to the example above – linking a Case to a Lead. Now I think I can understand the scenario – we have a well developed ‘prospect’ who might be trialling our product and has hit a problem – they raise an issue which we need to track – that sounds like a Case to me. But, Cases have a mandatory link to the composite Customer lookup (being an Account or Contact) and Leads are not considered to be part of that.
So, what to do. Well, we could try and hack the model – create a link back to the lead from the Case (feasible) but how do we deal with the link to the Customer? Given its mandatory you have a problem creating the record and then trying to work with it at a later point.
I really dislike hacked CRM models. If your organisation is now providing service to a company or person, even if they haven’t yet paid for it, then they should be considered to be a Customer. You’ve spent time identifying if they are worth the service, so they are well beyond a lead and really I would suggest that you set them to be some kind of Prospect Customer. Now you can link the Prospect Customer to the Case. Additionally, when this Prospect Customer becomes a Paying Customer you can see the history of all the service delivery from the earliest point.
If that model doesn’t work then you should be thinking about adding a different kind of lightweight entity (perhaps a custom activity) to record this kind of service engagement and you can link these to Leads, Accounts or Contacts. Fundamentally, you need to think about how you are defining your organisations use of the Lead, Account, Contact and Case entities and ensure you apply business rules accordingly.
Whenever I see scenarios like the above I worry about a few things. Firstly, consultants being far too ready to accept a requirements that is stated as system behaviour and not challenging (or clarifying) the actual business rationale. Secondly, customers expressing such functional requirements in system language when they clearly don’t understand the basic model that CRM uses with respect to the core entities. Thirdly, I worry about the amount of time that developers or customisers will have to spend to find a suitable solution or build a bespoke model (sadly all too often). Lastly, but certainly not least, there is the later impact of a bespoke model that cannot take advantage of in-built system functionality.
So, for example, let’s say the custom model permitted a Lead to be linked to a Case – the client is likely to assume that they can then build a workflow that sends an email to the ‘Lead’ directly from the Case. Sorry, Mr Client – that is not possible when we’ve linked the lead to the case. To achieve the last function, another round of specification, development and complex functionality will be required. The problem with custom functions are that they achieve one thing but usually bring with them a whole host of other problems caused by the very fact that they are custom functions. In the end it would be far faster and cause far fewer problems to use standard functionality and extend in a supported manner. Oh, and by the way, the example above would not be supported by Microsoft and would break in future versions – perhaps the best reason to not mess about with standard functionality.
If you would like to better understand in-built CRM functionality and how to apply and extend the model to meet business needs then please contact me at firstname.lastname@example.org.