A GREAT CRM STARTS WITH GREAT DATA

If people don’t use the CRM, or use it incorrectly, the data becomes stale and – over time - inaccurate. When CRM users are creating a report or a mailing list and they find that data is incorrect or incomplete, a spiral of mistrust begins.

 People stop investing time and energy to use the CRM – “why bother if it’s wrong anyway?”

 The topics of Data Quality and User Adoption are deeply intertwined.

Learn how to stop bad data before it enters your CRM system.

  • Thank you, Michael. Useful recommendations.

    What is your opinion about the impact on data-quality and user adoption of the following:

    • intelligent cascading data update in related objects not only accounts and contacts
    • various data validations (on editing, after and before save),
    • calculation and automated fields filling, like "Stage," "Status," "Type," "Tags," etc. based on whole information not only data of current record, and not only for a current record (in some sense this is a part of cascading data update)
    • timely and intelligent notification about the necessity to verify the actuality of data

    In most cases, this requires adding custom logic that is totally automated mostly but sometimes with users' actions.

    Definitely, this has an impact on the budget and time of initial implementation. Still, maybe the biggest challenge is that many such algorithms will change in time and have to be reconfigured quickly and cost-effectively to stay useful.

  • Hi Mykola,

     Thank you for your comment.

    Input restrictions on data fields can be very helpful to omit user errors, however, can create a negative impact on user acceptance on particular occasion. Let me give you one example:

    I have just been in France for vacation and wanted to purchase a local prepaid sim card for my cell phone. The online order form included a field to be filled with my current (German) telephone number.

    IMPOSSIBLE TO ENTER A GERMAN NUMBER resulting in “no purchase”. To include a field validation on the field “telephone” number makes it impossible for any tourist with a non-French number to make a purchase.

    As to automated input on calculated values absolutely makes sense if the underlying rules are unambiguous and do not change too often.

    Regarding intelligent notification about the necessity to verify the actuality of data: Yes, this falls under possible cleansing activities. However, as a first step users should be trained and constantly reminded that quality depends on their input and that other colleagues are relying on it. The cleansing activities might be needed in conditions where you have e.g. an inbound call center, where agents are urged to work fast (with a time limit per call) and where often data quality suffers. In those cases it is recommended to run regular cleansing efforts. They could of course be triggered automatically assigning records to a dedicated “data officer”.

    The design of the user interface always depends on the individual use case and needs to represent a fair trade-off between too many restrictions of any kind that may frustrate users and – subsequently - their awareness for data correctness.

    Under the bottom line: When a user interface and underlying logic are defined it needs to include human-centered design, incorporating human factors and ergonomic and technical reasoning with the objective of raising efficiency and effectiveness, improving human working conditions, and opposing possible unfavourable effects of use on user acceptance or performance.

  • Hi Michael,
    Thank you for the additional comments. I totally agree with your opinion about the usage of hard input restrictions. In many cases, it leads to users' resistance.

    In my opinion, much more efficient to use not only "hard" but and "soft" validations with notification and the possibility to save data.

    "Soft" validation helps to pay user's attention to possibly bad data and correct if it's necessary but at the same time gives a chance to save data if everything is correct or data can't be entered by objectives reasons (like your case with a phone number).

    Of course, it opens a way to save bad data but works well in combination with user training and following some technical rules:
    - show the clear and useful for user notification on "human language."
    - use one notification about all identified situations before data save because often data of one field should be analyzed in combination with other fields, especially for forms with many fields
    - grant a way to see a text of notification during data editing after getting of notification