International Addresses aren’t something that everyone needs to manage regularly. Yet if you’re generating your own data, they will creep in. So – how to handle them?

The greatest challenge that organisations face is often the limitations of their internal data management software. It is not uncommon for “Input Masks” or “Formatting” to be placed within databases or a Graphical User Interface (GUI).  And while these are great ways to minimise data entry errors and maintain a consistent format within your data, they’ll create a road block when information that can’t conform to them has to be inputted.

I.e. If your input mask ensures that 10 digits MUST be keyed in for a phone number, such as 0413123123, yet it’s been provided as +61413123123 – there are now 12 characters and it won’t fit.  Furthermore, if it’s a New Zealand local number it only has a base of 9 digits, and thus again – won’t fit.  In this case you could argue that by dropping the zero and adding in the country code of 64 you’ve made it back to 10 digits and all is well with the world again.  But what if this data is destined for a New Zealand call centre that finds the country code redundant information?  Now you have to remove the country code, and replace it with a leading zero (0).  All of this isn’t difficult to manage, but it IS management, and adds to the overhead required to properly format the data ready for its respective use.

Ensuring that your database structure can handle an international data set is not hard.  There are already standards in place, such as ISO 3166-1.  This standard allows for the effective classification of 249 countries.  Once this is in place, a number of paths can be taken;

1.       A GUI can dynamically change, to label the address fields relative to the country.

2.       The order of the information to be entered could be changed.

3.       The backend database structure can be dynamically coded to recognise that this is an International Address.
NOTE: for any dynamic change of information to take place, the address must be keyed in COUNTRY first.

By ensuring compliance to the ISO, you’ll be able to determine what data is international, and what is not.  Currently, the Rapid Addressing Tool only supports Australian and New Zealand address information.  Because of this, it’s important to be able to effectively identify those addresses which do not belong in AU or NZ. This will reduce wasted overhead when processing large data sets.

Once the Country Code is in place, the rest is relatively simple.  For the most part, the address elements need not be changed to handle different regions.  If your database has the following elements, the rest will fall into place;

  • Address Line1
  • Address Line2
  • Address Line3
  • Address Line4 (optional)
  • City
  • Region/Province
  • State
  • PostCode/Zip
  • CountryCode

If any of these fields are missing, then a good quality CRM/Data Management solution will provide for User Defined Fields (UDF).  These can be dynamically mapped, relative to their need, or statically set for the entire table.  If this function is not available, then adding an extra column to the database is generally very straight forward.  Once this field is set within the Database, a simple change of the data entry form, will allow for this to be seen on the Front End GUI.

So, International Data sets.  Not hard to manage, but it’s vitally important to ensure that;

1.       Your Foundation is set – meaning that your Data Base structure has the capacity to handle the varying fields from different countries, and has a “CountryCode” field

2.       Your GUI does not have “general” input masks.

3.       You conform to ISO 3166-1

If you have these three elements in place, the rest is just a part of normal day-to-day activity.  Get any of these three requirements wrong, and you’ll end up with a mess!

For more on the Rapid Addressing Tool and handling international addresses, contact us on (02) 9687 4666.