Databases for Dummies

Have you ever noticed that database people are fussy? Really, really fussy. (It's okay for me to say this, first because it's true, second because I am one.) It's because we have to be, because literally everyone else in the company constantly tries to mess everything up. Our lives are spent rolling our eyes and fixing problems that cost you a tremendous amount of money and lost man-hours, and that never should have happened in the first place.

If you don't have a database of your Customers and prospects, it's time to create one. If you do have one, it's time to clean it. The first will help you make money; the second will help you save money.

A database, for the purpose of today's topic, is a place to save Customer information. There are 5 main must-do's when creating a database:
  • Only have one database, ever.
  • Figure out in advance what information you want to save in your database, now and in the future.
  • Create clear, meaningful names for each database field, with no redundancy.
  • Decide which data fields are mandatory and what constitutes acceptable data for each field.
  • Require that everyone use the database, always (especially salespeople).
And there are 2 must not's:
  • Never, ever use Excel in place of a real database.
  • Never, ever use Act in place of a real database.
The reason that you only want one database is to avoid pocketing and the cost & aggravation of having to merge dozens of databases later (trust me; I used to do this for a living). You have to figure out in advance exactly what information you want your database to include, now and in the future, because of a triusm that applies to a lot of things in business:

Plan carefully now, or regret expensively after.

You always want your database fields to have real-world names, without cryptic acronyms. Otherwise, you are just begging for people to put the wrong info in the wrong fields, means turns your database into worthless crap. Never use the same field more than once. You've already asked for the info; why do you need it twice? Some fields can be optional, like the Customer's birth date, but you should set most so that they have to be filled in. What good is a Customer name without an address, phone number, and email address?

Also, don't allow anyone who uses the database to use abbreviations, or I guarantee that you will have duplicate records. If your Customer's name is 'David', use 'David' and not 'Dave'. If he likes to be called 'Dave', put that in a 'Nickname' or 'Goes By' field. Otherwise, when you buy lead lists or someone else enters him under the other name, you'll have duplicate records. Also, always spell out street names, city names, and country names. (I once had to work with a database where a single city name appeared as 6 different abbreviations, plus spelled out correctly, which meant the company was spending money to send the same mailer to each Customer 7 times. Now imagine if the street names and county names were sometimes abbreviated, too.)

If you already have a database, now you know why you need to get someone to clean it. The sooner the better.

If your organization has salespeople, I'm going to suggest that you create a new rule, if you haven't already: Any sale that takes place before a Customer is entered into the database belongs to the company. No exceptions, period. This will ensure that every Prospect is entered into the database, because there are salespeople who have a bad habit of sandbagging leads, in the mistaken impression that your Customers 'belong' to them.

Customers belong to the company. Period.

Not only will this create a more flexible corporate culture, it will also make things much easier when you have to reassign a Customer to another salesperson or split a territory.

And, while everyone who touches Customers should have access to your database, only Sales, Customer Service, Accounting, and Tech Support should be able to enter or change data. Not only that: any good database should also record who entered or changed that data, and when.

Finally, why not use Excel or Act?

Excel is not a database; it's a spreadsheet (duh). Microsoft puts all kinds of code in each field that you can't see to make it work well as a spreadsheet. Unfortunately, this code makes it difficult to do anything with the data if you try to use it for anything else, and a costly conversion if you have to convert it to a true database format when you eventually move up to SQL or some other real database, and someone has to manually clean out all that gunk (and your pockets, while they're at it; remember the Leaky Roof rule).

Act, while easy to use and great for a self-employed, standalone salesperson, does not share data well across a network - the whole point of having a database.

No comments:

Post a Comment