Design CRM systems to empower not frustrate users
The way the IT business community patronises business users never ceases to amaze me. This is sometimes quite explicit with developers bemoaning “stupid users” who fail to adopt their wonderful work. My frequent retort is that there is no such thing as a stupid user – only a stupid system.
These attitudes are often apparent in CRM system designs. The tendency is to build a CRM solution that supports a rigid end-to-end process that is heavily loaded with validation. At Ergo we’d argue that this approach is flawed for several reasons.
First of all, it makes the arrogant assumption that the business analysis process has come up with the precise business process flow to support every possible scenario. No matter how experienced the vendor, it is very difficult to capture 100 per cent of scenarios correctly, particularly when deployment times are tight. Once we humbly accept this, we are more likely to make the effort to build in flexibility.
Secondly, the process is always subject to change in the future. How many times have you heard a user say “we never do it this way and never will so you don’t need to design for it”, before changing their minds six months later?
Most worrying of all, this approach arises from a fundamental misunderstanding of what makes a good CRM system – and a good Microsoft Dynamics 365 system in particular.
Many designers, and indeed users, assume that a robust system necessitates 100 per cent accuracy when it comes to inputting data. This goes without saying if you’re building a financial system, but I haven’t seen many financial systems built in Microsoft Dynamics 365 and for good reason. CRM allows for some leeway as long as broad strokes are agreed. As an example, consider the following CRM chart showing an opportunity pipeline:
For this chart to make sense there has to be consensus amongst sales staff as to the requisites that move a prospect from “Initial Contact” to “Qualification”, and so on. Agreeing on broad definitions and trusting users to adhere to them will achieve this. We might not have an entirely consistent reflection of the pipeline because individual users could interpret these rules slightly differently, but it doesn’t really matter. We will still have good visibility of our pipeline.
Contrast this approach with a rigid design that uses the CRM Business Process feature to enforce business rules. It makes users enter a number of mandatory fields before they can move on to the next stage – qualification. This may be valid for most opportunities but any exception to this rule will frustrate the user.
The chevrons at the top of the screen indicate the stages of the opportunity. This may look appealing on day one for users, but do we really want to allocate a third of the form to telling users what they already know? If the system is simply relaying processes that sales people have imprinted on their brains anyway, then it won’t get used. Poor user adoption will rapidly undermine the power and potential of the CRM solution because it will no longer be a comprehensive source of all opportunities from all users.
Adaptability is an Ergo core value and this applies to our approach to system design. We build in flexibility to deal with the infinite number of scenarios that users will have to deal with and we trust users to be the experts in their own business.
It’s better to have a CRM solution where all users are using the system with loosely defined rules, than having a partial view of the data that’s incomplete because the users can’t work around the design. This is but one example of this flexible approach. Keep an eye out for my next blog for more approaches.