Avoiding Contact Data Entry Flaws

Contact data is the data domain most often mentioned when talking about data quality. Names and addresses and other identification data are constantly spelled wrong, or just different, by the employees responsible of entering party master data.

Cleansing data long time after it has been captured is a common way of dealing with this huge problem. However, preventing typos, wrong hearings and multi-cultural misunderstandings at data entry is a much better option wherever applicable.

I have worked with two different approaches to ensure the best data quality for contact data entered by employees. These approaches are:

  • Correction and
  • Assistance


With correction the data entry clerk, sales representative, customer service professional or whoever is entering the data will enter the name, address and other data into a form.

After submitting the form, or in some cases leaving each field on the form, the application will check the content against business rules and available reference data and return a warning or error message and perhaps a correction to the entered data.

As duplicated data is a very common data quality issue in contact data, a frequent example of such a prompt is a warning about that a similar contact record already exists in the system.


With assistance we try to minimize the needed number of key strokes and interactively help with searching in available reference data.

For example when entering address data assistance based data entry will start with the highest geographical level:

  • If we are dealing with international data the country will set the context and know about if a state or province is needed.
  • Where postal codes (like ZIP) exists, this is the fast path to the city.
  • In some countries the postal code only covers one street (thoroughfare), so that’s settled by the postal code. In other situations we will usually have a limited number of streets that can be picked from a list or settled with the first characters.

(I guess many people know this approach from navigation devices for cars.)

When the valid address is known you may catch companies from business directories being on that address and, depending on the country in question, you may know citizens living there from phone directories and other sources and of course the internal party master data, thus avoiding entering what is already known about names and other data.

When catching business entities a search for a name in a business directory often leads to being able to pick a range of identification data and other valuable data and not at least a reference key to future data updates.

Lately I have worked intensively with an assistance based cloud service for business processes embracing contact data entry. We have some great testimonials about the advantages of such an approach here: instant Data Quality Testimonials.

Bookmark and Share

9 thoughts on “Avoiding Contact Data Entry Flaws

  1. dirtydatadonkeys 19th May 2012 / 17:22

    Good stuff, Henrik.

    I like the zip+4 in the US. If you can link to the right information repository, that 9-digit code will give you an exact address. Then you can compare it with the rest of the address information you have available to enter. If it matches, then you are done with the address. If there is a discrepancy you can verify whether the zip+4 was entered incorrectly (or is just plan incorrect) or if the rest of your contact information is bad.

    Unfortunately relatively few people memorize their zip+4 so that is usually derived from the actual address.

    • Henrik Liliendahl Sørensen 19th May 2012 / 17:41

      Thanks Bryan.

      Challenges are indeed different around the world.

      In the UK where I live now the street level granular postal code includes letters and are therefore shorter and a bit easier to remember – also the system have been so for a long time.

      In Denmark where I lived before only central Copenhagen have street level postal codes while the 4 digit postal code in the rest of the country includes several streets.

  2. johnowensblog 19th May 2012 / 20:18

    As you suggest above, Henrik, one simple change in input form design that would greatly reduce both key strokes and errors (both for data entry staff and online customers) would be to have the Country as the first line of the address.

    This would immediately be able to pick up the relevant zip/post code rules for that country to enable this to be input next, which would in turn pick up suburb, street, etc. and populate them as candidate values – that could be overwritten if not the precise address.

    The traditional postal address structure was designed in the mid nineteenth century for postmen walking house to house hand delivering mail – even then it was not the most efficient design! – so to carry it through to 21st century computerised systems may not be the most sensible thing to do.

    • Henrik Liliendahl Sørensen 20th May 2012 / 08:49

      That’s true John. And as you mention, the tips and tricks for address data entry will work for online self registration too.

  3. Jutta 21st May 2012 / 09:33

    Hi Henrik,

    we have an ongoing discussion about the way to capture country-specific data, especially the use of special characters. Each member of the (international) team has a different opinion: Should it be Köln, Koeln, Koln or Cologne? Is it Newcastle, Neuburg or Neuchâtel? What happens when in the city two languages are valid like in Switzerland (Biel = Bienne). OK for cities we have still the postal code as identifier but big cities like Köln (this is the correct German spelling) might have different ones…I think your discussion scratches only the surface of the problematic and can end up easily in a political one. I’d be glad to participate!

    • Henrik Liliendahl Sørensen 21st May 2012 / 11:03

      Jutta, thanks a lot for adding in. The challenges are indeed plentiful and stretch across the data governance realm including that issues may be political.

      Will be glad to discuss further, it’s one of my favorite subjects.

      • lynnvanavermaet 21st May 2012 / 12:09

        In Belgium we have the same problem. Even within one country, some addresses exist in French and in Dutch, other addresses exist in French and German. And as, moreover, the Belgian postal system is not very structured and logic, it can be quite dificult to create a single ‘address’ view as of the point of data entry of new client records. One solution can be to create a unique address key that identifies a street (or an another geographic element) in a unique way, independent from the language it is written in. One of the Belgian companies that has created this unique view on Belgian addresses, is WDM Belgium with it’s Road65 tool.

      • Henrik Liliendahl Sørensen 21st May 2012 / 13:20

        Thanks for joining Lynn. Just checked out the WDM Road 65.

  4. johnowensblog 21st May 2012 / 20:46

    With proper analysis and design input screens should be easily able to deal with this problem. Once you have selected a) the country and b) the language you wish to use, the address can be verified against a database for that country in that language.

    The data structures to support this functionality are relatively simple.

    The real challenge is loading the correct domain data a into the database or wiring the form into the cloud. This latter would be the preferred option as it would keep all data current.

    Unique keys are simply that, unique keys. They do not identify anything and, consequently, cannot uniquely identify anything. Their misuse as unique identifiers is one of the greatest causes of duplication in databases.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s