The User's Situation
A typical situation could be described in the following terms ...
There is a huge benefit from capturing and organizing all of the bits of 
information that are randomly tossed around on pieces of paper and linking it 
back to the business data that we already have.  

For instance, it is common to send out little Customer Survey postcards and do quality check calls on a regular basis.
However, this information never hits a database.
Therefore, long term trends can't be identified – and problems can only be dealt as they are discovered when they happen.  

This is but one of many little things that should be integrated into the workflow via a database.  

Others include databases that would capture information about plant production, asset & vehicle management, customer service, etc.  

There are all kinds of stuff that would be useful to measure.  

However, it's best to tackle the easiest one to develop and train people on first.

Additionally, organisations are often in the process of converting to a new version of our business software that involves moving to a new RDBMS – SQL Server 2005.  
That being the case, it would be a perfect place to hold all of the other data that could be envisioned someday being captured.  
How to get it there is another story…

As is the case with many companies, the data currently stored isn’t exactly perfect.  

There’s annoying duplication in places and data entry isn’t as controlled as it should be, so some normalization is in order there.  

Problem is, flexibility demans more columns in some of the tables to accomplish this and software vendors are not usually very receptive to the 
idea of adding user defined fields.  

Although, in passing, we can observe that some large organsations, such as Salesforce.com are very successful in meeting this challenge.

The requirement here is to find a way to take care of these problems with a separate database that could be linked back to the original 
tables in the software’s backend, but it might not be very graceful for the poor Customer Service people from a data entry standpoint.  

Oh, and another REALLY annoying thing is that the customer name is the key field in a customer list, not the customer number.  
Who ever heard of such nonsense!