Database structure - customers and/or contacts 
Author Message
 Database structure - customers and/or contacts

I'm designing a database system for a sales team and am trying to work
out the best configuration of files/related dbs. My thoughts so far...

1) "Customers" (they buy the services) and a related db
2) "customers_staff" (customers can have a number of staff we need to
contact in different ways)

Over time the sales team will meet potential customers, get sales
leads and make other contacts. If they use "Customers"  for keeping
this info (which in many ways makes sense), in a couple of years the
file will become enormous.

One possibility is 3 related dbs:

1) "Customers"
2) "Customers_staff"
3) "Contacts" (who graduate to "customers" once business begins)

or a fourth db which acts as an interface for "customers" & "contacts"
??

I want to make the right decision regarding this structure before I
start the development. Any advice on how to approach this example (or
the concepts behind it) is appreciated. Thanks



Thu, 10 Feb 2005 06:11:52 GMT
 Database structure - customers and/or contacts



Quote:
> I'm designing a database system for a sales team and am trying to work
> out the best configuration of files/related dbs. My thoughts so far...

> 1) "Customers" (they buy the services) and a related db
> 2) "customers_staff" (customers can have a number of staff we need to
> contact in different ways)

> Over time the sales team will meet potential customers, get sales
> leads and make other contacts. If they use "Customers"  for keeping
> this info (which in many ways makes sense), in a couple of years the
> file will become enormous.

> One possibility is 3 related dbs:

> 1) "Customers"
> 2) "Customers_staff"
> 3) "Contacts" (who graduate to "customers" once business begins)

> or a fourth db which acts as an interface for "customers" & "contacts"
> ??

> I want to make the right decision regarding this structure before I
> start the development. Any advice on how to approach this example (or
> the concepts behind it) is appreciated. Thanks

My recommendation is to keep things simple. Your approach of relating
Customers to Staff is correct, but organizations that are not currently
customers really only differ in one respect: they have not bought the
product or sevice, yet.

So you need to create a single field in Customers like "Active?" with
Yes/No radio buttons. Or, if you are going to track business, any
"customer record" that has any transactions in the sales area is defined
as a customer. In this case, the Active? field could be calculation such
as:
if(Count(Sales::Transaction#","Active",Prospect")

Don;t worry about the number of records. Filemaker can handle millions
of records easily.

Hope this helps.
--
Richard Gross
Blueberry Database Consulting
FSA Member



Thu, 10 Feb 2005 21:51:25 GMT
 
 [ 2 post ] 

 Relevant Pages 

1. SQL Customer Contact data => Outlook Contact

2. Issue database structure changes to customers

3. Customer Directory database structure

4. PRESS - INFORMIX AND SAP ANNOUNCE ENHANCED WORLDWIDE CUSTOMER SUPPORT STRUCTURE

5. Eastern Europe Contacts = We're seekin People With Contacts

6. SQLServer Contact Data into Exchange Contacts

7. Eastern Europe Contacts = We're seekin People With Contacts

8. Eastern Europe Contacts = We're seekin People With Contacts

9. Best SQL for Joing Customer and last customer Transaction

10. OR-PORTLAND-93760--ORACLE-Project Management-Customer Support-Program Manager - Client Services,Customer Support

11. OR-PORTLAND-93760--ORACLE-Project Management-Customer Support-Program Manager - Client Services,Customer Support

12. Is customer Proc really faster than customer Method?


 
Powered by phpBB® Forum Software