Updating users data from a different system and presenting this to them

Question

We will be linking our user database to a CRM system. As part of the project if a match is found our web database record will be linked to the CRM record and the data syncd.

If a match is found and identity details are updated from CRM to the web database, I want to present this to the user. This is so if the matching rules from the CRM system are wrong - it doesn't update the user's web database record with incorrect data.

I want to give the user the choice but am unsure on how to present this potentially sensitive and potentially incorrect data. The datasets that are likely to change will be address and phone.

How would you go about this? Are there any examples of this done well?

Answer 1

Say that match went OK, show the result and a link 'Um... there's a mistake'

After clicking that apologise for your system imperfection, suggest manual data entry with the data you had pre-filled, place a treat for the user (neat picture would go a long way).

Answer 2

Since this is a new system, a one-time required confirmation form in a modal window when they first open the app makes sense. Something like "Welcome! Please confirm your contact information below."

Be sure to highlight which fields have been pre-filled by your system, and use a descriptive label for the submit button so they don't breeze past it (ie, "This information is correct").

This dribbble shot is something like what I have in mind.

Answer 3

Per the comments segment here's what I would suggest :

Since this is a cronjob that, per your admission; runs twice a day so a user "may or may not be prompted immediately" is perfectly fine with the exception that you should really not focus so much on "data integrity" (i know my teeth are grinding too, hear me out) initially but rather, "human willingness to correct"

There are 2 possible outcomes if you present a member of the sales staff with a list of say ..... 2500 contacts that have conflicting or out of date records:

1: They close the system and don't use it for the next week

2: They quit.

hahaha

I think a better thing to do - since we're (you and I) are not only user experience advocates but also technical professionals - derive a "priority" queue and serve sales agents maybe a batch of 10 records at a time. How you prioritize these records is likely dependent on how your organization ABC's the contact / lead qualifications.

That being said - an alternate is "when this system goes live" you have a 4hr space of time dedicated to learning and updating. Subsequent updates would be on a case by case basis ( again - depending on your ABC criteria, some accounts may want to be validated more often than others.. etc.. )

The prior is less daunting to the user (sales rep) and the later is better for IT (all data gets updated en masse initially and then goes into it's lifecycle mode there after )

If you have a contact db of say ..... 45k and you have 400 sales reps (arbitrary just trying to suggest volume) - perhaps a hybrid approach of : training and updating ALL "A" level accounts instantly is the best approach and then B and C can follow "at leisure" there after.

Of course, if and when you present the user with the "10 or less" list of stale account information - you should also give them the issue to tackle the "next 10" that they might be responsible for. Pagination of sorts but not a strict requirement

This way - humans that like doing the bare minimum engage in that minimum and your records are updated eventually and likely the man hours spent are used better (assuming your ABC account logic is good, then the A's will always be current, the B's only a marginal chance of stale, and the C's, well, the C's can wait)

./3cents.