Given it is part of what I do these days, I thought I should comment on some sage advice in last week's Get Stacked about CRM customisation, from more than one speaker. Their advice was: Don't do it!
The particular dangers of customising a CRM (or other parts of the MarTech stack) are:
Prepared interfaces to other software tools will not work,
You will end up with an undocumented mess,
Those responsible will move on and leave you with an unmaintainable beast.
So, should you customise your CRM?
Company size is a pertinent factor. If you are very small, do you really need a CRM? Maybe some shared spreadsheets and a bit of discipline is enough. If you are large (or ambitious), then you will have a portfolio of applications in your martech stack, and those standard interfaces will be important. Too much customisation will also lock you into a package, so you can't then replace it with something more appropriate as you grow, or circumstances change. I would suggest that any non-trivial extensions to functionality are built by your IT department as distinct cloud applications. This will give you more flexibility and may well be cheaper than paying high user fees in perpetuity. Most likely, this advice is too late for you.
For SMEs, particularly those without an IT department, customising a CRM gives you an opportunity to leverage the data in the CRM by extending what it does beyond sales and marketing. Potentially it gives you the single customer view that the big companies will spend so much time trying to create. CRMs will typically have some sales order processing functionality, but this will require tailoring to the products or services you offer. You have the opportunity to push coverage further both ways on your value chain to add order/job processing and to include your suppliers and purchase order processing. All those spreadsheets with their separate records of orders, suppliers and customers can be done away with. Customer relations should be able to see the progress of orders, and any communication with the customer, so will not need to interrupt operations to ask how a particular job is progressing. There are huge gains to be had through this sharing and collaborative working. If you already have other systems, then some investment in a technical resource to use APIs to link your systems will quickly pay for itself in time not spent re-keying, manually passing files, or chasing data mis-matches.
So there are sunlit uploads to be reached through customisation, but plenty of pitfalls en route. So, either do a little, or be prepared to be bold. In reality, there are always likely to be a few fields you will need to add to record things particular to your business, and these won't stop an interface working. My own recommendation is that this minimal set should include some cross-references to your other systems so that you can, for example, invoice the same instance of a customer each time, easily create reports that combine data from the different silos of your SaaS systems, and even better, reconcile them. But be sparing, as all the fields increase the burden of adding and maintaining the data. Once you start mangling the default data structures you should expect that some interfaces will not work, and moreover that some downstream functionality within your particular package will not work. If you need it, you may have to re-create it.
The ease of configuration of modern tools is a problem in itself. If configuration is not controlled you will end up with lots of new fields, many of them probably redundant as they were added for a single campaign. Different users of varying competence will have used different naming conventions, re-created existing fields, packed multiple fields into one, or worked around a mandatory field with a character that was meaningful to them. The accretion of all those little changes creates one big mess. You need a consistent and coherent view, and for this you should have one responsible data architect. This does not need to be a technical person: you require someone with common sense, some familiarity with data, and the confidence to both push back and to make things happen.
Bear in mind that changes need to be driven to completion, or they should not happen at all. Every extra field you put in a Salesperson's way is a marginal disincentive to use the CRM, and that new contact will end up on a post-it note, in their phone or Outlook, instead of in the CRM. If you want data for insight purposes, then it will be of no use if only 30% of it is populated. So generally, outputs, checks, reconciliations, procedures and incentives should be part of any reconfiguration, otherwise it will fall into disuse and just get in the way.
My experience suggests that, however much you customise your CRM, the biggest issues you face will be behavioural rather than technical. So lay your plans, and have some fun wrangling that beast.
John.Davis@cranfieldsoftware.co.uk
11 May 20.