In our company we are all very dedicated to serving our customers with their business problems with bad quality customer master data. Aren’t we all?

A few days ago, one of our customer support desk engineers sought an answer to what happens with the addresses on the islands of the former Netherlands Antilles. See also my previous post The dissolution of a nation. Kids of my generation had to memorize the names of these islands at primary school: the ABC islands – Aruba, Bonaire, and Curaçao – and the three islands with an “S”: Saba, Sint Eustatius and Sint Maarten. My colleague, now fully internet savvy, wanted to look up an address on Sint Maarten. Why not use an internet map and type “sint maarten”?

Yes, here it is! They even have a Spar supermarket there (just like home), and the address of this supermarket shows a postal code! A postal code with the same structure as in the Netherlands (NNNN AA). Pleased with this catch, he started to compose an answer to the customer.

Just before sending it, I passed his desk and we started talking about this (the topic has my attention, you know). And he showed me the map proving his arguments: the coastline was near. But when we zoomed out, the picture became clearer: tunnel vision obscured that he had been focused on Sint Maarten near the Dutch coast!

Every year when autumn comes the assistants of the sales department get a little nervous. They know what will happen in short term. It’s almost Christmas and the selections of contacts to receive a Christmas card have to be made.

Every year it’s the same. First the selections for every account manager are made and they will have to check manually if these are correct. This year will be the same as ever, which means that:

• relevant companies and contacts are missing
• new companies and contact persons will be added
• contact persons will be deleted
• contact persons will be transferred to their new company
• addresses appear to be not up-to-date

This is one of the best audits to validate the quality of your data. The number of additions, modifications and deletions indicates how accurate your employees have maintained the data in the CRM system. I think that most of us recognize the problem and maybe are part of the cycle themselves. Moreover, it clearly shows where your data management procedures fail. Most likely the account managers are expected to maintain the data themselves, which they don’t see as their primary task. If not account managers have to maintain the data the sales support team usually has to do so. But who will give them the required input? Only accurate data entry, actively monitoring and periodically checking against external sources will help to keep your CRM system up-to-date.

In general the Christmas card has little value for your relation with your contact persons, but such an intense mass mailing is very profitable for your data quality. Until your procedures are in place, keep sending Christmas cards to optimize your data quality.

I have looked at the location using Google Maps. Normally you expect that a street consists of one thoroughfare. But in this case the street, named “Kraakweg”, consists of three different parts, which are clearly not in one direct line. I have indicated it with 1, 2 and 3. Number 4 indicates another street, but with almost the same name “De Kraak”.

To make things even more confusing. The “Kraakweg” used to be called the “Stenenkamerseweg”. The “Stenenkamerseweg” still exists, but is more than one kilometer from the “Kraakweg”. Double streetname signs are used in this area. So if your are not familiar with the neighbourhood you are completely left out in the dark whether you are at the “Stenenkamersweg” or at the “Kraakweg”.

Photo taken by Ruben Schipper. Residents have been complaining over and over about the confusing situation and roadsigns. Hopefully now it will be settled for once and for all.

In Holland we already have three officially approved manners of naming streets an addresses. Nowadays we have the TNT Post standard, based on the very first publication of the postal code book, and afterwards corrected several times. This naming convention was the basis for the NEN 5825 standard (NEN is the dutch variant of ISO). But the true source of streetnames comes from the municipality and is called “Raadsbesluit”.Due to the different versions this can easily result in five different ways of spelling of the same street, as the example below shows:

What do you think, should we add a new “English” standard to existing standards. What are the pro’s and con’s for having English labels of the streetnames, please add your opinion in the comments. Should we also replace all signs and add the English label for the streetnames? For more information and history of Dutch street names I recommend the following site “alles over straatnamen”.

The local authorities in the town of Webster, Massachusetts are planning to change the road signs that lead to the local lake. The sign leads to lake “Chargoggagoggmanchaoggagoggchaubunaguhgamaugg”, but it should actually lead to “Chargoggagoggmanchauggagoggchaubunagungamaugg”.

According to the Guiness Book of Records, the name of the lake is the fifth longest word in the world and the longest lake name anywhere. The name originates from the local language of the Nipmuc indians. Freely translated, the name means “You fish on your side, I fish on my side and nobody fishes in the middle of the lake”. A nice example of native Amercican divide and conquer…

The interesting bit, however, is that there are 26 spelling variations of the name in the US Geographic Names System and that none of these variations match the actual road signs.

Naturally, the authorities could spend time and money to find out how these mistakes have been brought about. I think, however, that an investment in standardisation would be a much wiser choice.

This example is of course rather extraordinary and the discriminating value of “Chargoggagoggmanchauggagoggchaubunagungamaugg” is quite high. But different spelling of geographical items will eventually lead to toponymic confusion (see my blogpost earlier this year). Apparently, the inhabitants of Webster call the lake “Lake Webster”. I wonder whether that has got something to do with the pronunciation of Chargoggagoggmanchauggagoggchaubunagungamaugg…?

In some cases, this means only a little change in the street type; so for example, ‘Van Sytzamaweg’ is changed to ‘Van Sytzamawei’. In other cases the resemblance is only knowledgeable for people who know both Dutch and Frisian: ‘Spreeuwenstraat’ is changed to ‘Protterstrjitte’.

Language preference issues like this form one of the reasons why streets or localities get a new name. There are also some other situations: sometimes people give a street a new name because they want to remember someone; sometimes it is the reverse: they want to forget the person who was in the old name.

Name changes can also occur if two localities are merged into one locality; in such situations it can occur that two streets in the new locality have the same name; then usually one of them gets a new name, in order to prevent confusion.

In some towns the names of the streets are carved in stone, like in Bordeaux (the beautiful French town that you should not miss if you go to the Service National de l’Adresse in order to get your French address standardization tool certified). As it is not so easy to erase a name that is carved in stone, this leads to the situation that the naming history of the streets is rather visible. This could help delivering mail that is sent to outdated addresses.

However, even in Bordeaux they have stopped carving names in stone. So it seems better to invest in a good data quality solution, that is able to replace the out-dated names by their new versions.

When working on products for address standardisation, one can discover an interesting variant: people sometimes write – unintentionally, I suppose – addresses in such a way that they are rather understandable for people, but very difficult to process for computers.

Consider for example this street name:

Kerkchoosteeg hoogl

The official version is:

Hooglandsekerk-choorsteeg (‘high land church – choir alley’)

This street contains a couple of errors:

• A hyphen is missing.
• One ‘r’ is missing.
• One word (‘Hooglandsekerk’) has been split up into two words.
• The first word (‘Hooglandse’) is written at the end.
• One word is abbreviated (‘hoogl’).

The first two errors are not very special, but the last three can only be discovered in common: it can only be discovered that the word ‘hooglandsekerk’ has been split up into two words, if at the same time it is understood that the left part has been abbreviated and moved to the end.

Similar problems occur in:

O Lieve Vrouweschutstr

Official:

O.L.V. Schutsstraat

‘O.L.V.’ is a common abbreviation of the ‘Onze lieve Vrouwe’ (‘Our Lady’); in order to determine that this abbreviation plays a role here, it must be understood that the word ‘Vrouwe’ is part of ‘Vrouweschutstr’ and that the rest of this word matches fairly well with ‘Schutsstraat’, which again is only possible if the missing ‘s’ and the abbreviation ‘str’ (for ‘straat’) are correctly handled.

An extra complication occurs if there are multiple candidates:

rue dendicolle

This has some resemblance with two official streets:

RUE HENRI COLLET
RUE JEAN RENAUD DANDICOLLE

The first candidate has four differences:

• Three typos (‘d’-'h’, ‘d’-'r’, missing ‘t’).
• One missing space.

The second candidate has three differences:

• Two missing first names.
• One typo (‘e’-'a’; in French these letters get in this context the same pronounciation).

The second street matches clearly better; this can only be determined if the errors in the first case are considered more severe than the errors in the second case.

If an address consists of many elements, there are even more possibilities to make things difficult:

30 FERMONT ROAD
199 CANARY WHARF
E33 9SF
E33 9SF LONDON

Official:

Flat 199
Canary Wharf
30 Fairmont Road
LONDON
E33 9SA

• Street and house number are on the first line, but should be on the third line.
• ‘Fermont’ must be written as ‘Fairmont’; the pronounciation is not equal, but fairly similar.
• The address contains two postcodes; both are not on the right position and both are incorrect.
• ’199′ should be ‘Flat 199′ and must be written on a separate line.

A product that can recognize the error situations shown in these examples, must be able to switch constantly between different error types. Searching for displaced words or address fields must occur in combination with resolving abbreviations, determining whether to accept typing errors, and distinguising between typo’s that lead to different pronounciations and typo’s which don’t.
A product like this is never completely finished; therefore, when developing, it is good to start with the most common errors and the most common combinations of errors, and to add error situations in next releases. Investigating examples like these in an early stage of development helps setting up an architecture that is ready for further development.

Anyone got other nice examples?

(The addresses are real life examples; only the British example has been changed for privacy reasons, without changing the errors.)