I accept data in any format or condition.

But here are some best practices you can keep in mind if you are considering starting a new database for the first time.

Related: How to password protect your database; https://markis.com.au/how-to-password-protect-an-excel-file/

At minimum you want your database to contain the following fields;

| Name | Address | Suburb, State, Postcode |

For best DPID matching (postage savings) I would be recommending;

| Name | Address1 | Address2 | Suburb | State | Postcode |

And for best practice I would recommend;

| Title | FirstName | LastName | Dear | Address1 | Address2 | Suburb | State | Postcode | Notes |

There are many other variations on that; some databases need to include Company and Position descriptions for example.

Consider these points with your database;

Just having a database isn’t enough. Being able to utilise the data within your data is one of most important things you can do right now for your business going forward. You’ve already spent many hours recording or obtaining data and if you can’t utilise it correctly for a promotion, then it could be delayed while you have to sort out the data. If you’re not getting what you want from your data now is the time to reconsider how you are recording it.

Column fields you may want to include in or add to your database;

  1. ‘Title’ field. While not many people still preface their first name with “Miss” or “Master” anymore there are still reasons why including a title can be important. “Dr.” or “Mr & Mrs” are some entries that you will want to save room for and don’t work in the ‘FirstName’ field as you’ll see below if you read on.
  2. ‘Dear’ field. This is arguably one of the most overlooked fields and a necessity for mailing. Some people believe that a ‘FirstName’ field is enough, but it isn’t. Here is an example that I come across all the time; a database contains address of two people at the same address. The database might contain ‘FirstName’ and ‘Spouse’ as an example, if you’re not using a separate ‘Dear’ field you can’t include ‘Spouse’. While this can be alleviated using conditional formatting, it’s not ideal (you’ll always get false positives) and it does make more sense to jump on this early and include it in the database.
  3. Instead of just one address field, use two, or even three address fields. This is handy if you need to record ‘Care of’ details, or if the address requires a building name, a suite or level information. It’s not practical to place all this information in the one address field.
  4. Separate ‘Suburb’, ‘State’ and ‘Postcode’ fields. While not critical, it is best practice to keep these fields separate. Initially, your database may only be a few hundred, or thousand if you are lucky. But once your database grows to thousands of entries, being able to filter by Suburb, State or Postcode is very handy if you want to be able to breakdown your data for analysis. An example would be to see how many customers you have in a metropolitan area outside a city for a letterbox drop. The other reason is it just gives better matching and DPID barcoding (postage savings) results when I process the database against Australia Posts PAF (Postage Address File) of over 18 million (and growing) physical addresses.
  5. ‘Notes’ field. This is another overlooked field. I’ve seen instances when data that should be in a separate field is tacked onto the end of an existing field. For example, in an ‘Address’ field; “Unit 98, 453 Street Name – Do Not Send”. This type of information clearly does not belong here and requires a separate field.
  6. Customer or client number field. Give each record a personalised number. Again, it might be okay if you have a small database, but if you have a larger database, it’s much easier to filter by a number than it is to locate a “John” amongst a few dozen “Smith”.

Of course, this is not an exhaustive list and there are many ways to set up a database, but these are just a few suggestions based on my experience of processing millions of records from thousands of databases.

Good luck and happy data capturing and processing!