Get Your Data Right

Doing it wrong? I can show you how to get it right.

Hello business executives and those helping to codify systems for them!

Let’s consider the ways we can bend technology to serve our needs better! I am going to walk you through some very common issues related to technologies that are easily available, yet companies either don’t leverage them correctly, or they execute them in a way that is less than efficient. In the worst outcomes, the technology is either entirely missing, or leaves the consumer with an experience that is more negative then when they entered the customer journey.

Major companies are still “doing it wrong”. But these issues can be remediated with a little consideration, some specific requirements and an exchange of information. In this article, I am going to give to you the *exact* specifications that you can share with development teams to ensure you Get Your Data Right!

First, let’s talk improving #customerexperience on entry point systems. This applies to #userportals, #intakeforms #patients #ecommerce #payments #customerportal and really, any system where we are asking our clients or customers to provide information, set up an account, or update information for our (and theoretically their!) benefit. I'm talking about address forms - what we're doing wrong, and how to easily remedy the problems.

What you’re getting wrong

We have all experienced the frustration of data input forms which seem nonsensical, or provide contradictory choices that don't make sense to the consumer or client. Information we want to put in is not allowed, or information we think should be obvious (zip code? country? county?) can be selected which are inaccurate and degrade #dataintegrity, #dataquality and #datagovernance. Sometimes, we are asking for information that a modern system can, and should be able to determine based on the information already provided. This is frustrating for our customers and clients, and has the potential to degrade #dataanalysis for the business.

We have some cool tools out there (not going to name names, but you know who you are) which changed the way we find addresses. By using the uniqueness of a left to right search of the street address, the discreet #data points of City, State and Zip can be quickly found and auto populated into a form for addresses! But wait – we get to the “country” drop down and that is blank. Or the zip code field. Or the “county” field returns provinces, or every county ever created in every country. 

Some cities exist in more than one county, as in the north part of the city or town is in one county and the south part of the city or town is across the county line. Some cities exist in multiple states. Think Kansas City, Kansas and Kansas City, Missouri, a unique metropolitan area example where Kansas City resides in two different states, and in their respective (and different!) counties. This is more common than you might think.

This is a miss that is easily fixed. Below I give you the exact #technical #requirements that you can simply cut and paste into your system update or new #systemdesign requirements document. I’ll give you two versions: One for use in a Business Requirements Document or Technical Requirements Document (#BRD or #TRB) and a version for use in #Agile environments.

How to get it right

Business or Technical requirements:

• Include geo fencing for jurisdictions – Country, State, Province, County, and City (many cities do not have this information yet)
• Limit jurisdictions to those you are willing / able to operate in
• Create or leverage a "Source of Truth" for your jurisdictions
• Practice proper #datagovernance over your jurisdictions source of truth
• Zip code field must be alpha numeric
• Zip code field input or capture is limited to the characters (0-9)
• Where allowed, use the entry point to determine country of origin (IP entry point)
• If not using a validation tool or application, ignore case for all address fields, else convert case for comparison reasons
• Normalize address field case for "pretty print" for #Invoicing, #SMS, #emails or Reporting systems like #TM1, #Blackline, #Cognos, #Workday, #Monday, #Smartsheets, or other systems that you use
• Ensure address field length is sufficient for worst case scenario
• Determine the correct data dimensions for your addressing needs
• Determine data dimensions required for #invoicing, #SMS, or other #SAAS and #Onprem systems
• Determine data dimensions required for #taxsystems like #Avalara
• Determine if data dimensions for addresses must be normalized against current systems, such as #Workday or #Salesforce or #Oracle #ERPs
• Where required, ask consumer for permission to leverage their entry point (IP as per above)
• Use geo fencing to sub-search for street address
• When match for street address is ambiguous or returns multiple matches, ask the consumer to choose the best choice
• When match for street address is complete, update country field
• When match for street address is complete, lookup the county (not country) field and update it, if you need to know the county
• When match for street address is validated, update 10-digit zip code field
• Add confirmation check box for consumer
• Save address information temporarily or to consumer record

Agile Feature

As a (consumer) I want the system to accurately validate my physical address with the minimum amount of data entry and ensure compatibility with existing enterprise systems. (You should reference a list of those existing systems!)

Next post, I’ll show you some strategies for Master Product Naming Conventions, an area that I first worked on, and won a national award for, over 10 years ago.

Future Topics:

Master Product Naming

Data Value Chain – what is it?

Meta Data – Let’s talk about this together!

Searching but Not Finding, or "Flat searching in a round world!"