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