I would suggest that you reconsider keeping them in the same database  Create a new field for status.  Actually, use three fields:
Status - Description - StatusEffectiveDate. 

Then you can add info and have a life cycle of status codes.  Perhaps something like:
Prospect - can have multiple types, maybe based on contact status or source.
Negotiating - Now considering quotes, etc.
Customer -  Have recived an order
Inactive - No order in past 30/60/360? days
Closed - Will be no future orders.

Based on Status you can have different fields made Visible/Iinvisible.  You can have status codes updated automatically based on other activities:  When a Quote is entered, status is upgraded to Negotiating.  When Sales Order is places, status is upgraded to Customer.  Regular routine can be run for aging on alll clsasses to determine actions and/or change in status.

I find that using a Status code is much less maintenance, just need to include Status in Retrieve Specs.  Status codes could also be numbers, and the categories I noted above are status descriptions.  Number the status codes with gaps, like 1,5,10,20,50 so you can add more codes in future, in between existing numbers and not need to renumber them for newer ranking.

If you also track the dates that status changes you can start to get some meaningful marketing analysis tools.

Now you can see how long it takes to convert prospects to  Customers, how long you keep customers before they stop placing orders, etc.  What percentage go from Prospect to Closed immediately, and how long that takes.

And all the information re contacts, credit ratings, business levels, etc. are entered and maintained only once.

You can use OnFormEntry with security to limit who can see what based on Status.  Some people can add/edit records, some can change status, etc.  Fields can be made Visible/Invisible, ReadOnly, etc.

But your needs will vary from business to business.  When you say most of your prospects will never become customers, then perhaps separate databases makes more sense.  It may be a tradeoff between numbers of records and performance hits and filtering with Retrieve Specs.

You will get many other opinions on this, so this is my contribution.

I see: Quote:
and I am curious about the terminology you are using.  I know that as a former (and current) Q&A user, there was a lot of confusion about these terms as we moved into Sesame.  And I am much more conscious of the terms being used.

Do you have Customer and Inventory in the same "database" or the same "application"? 

The "application" is the Filename.db that you open with Sesame File, Open.  The "database" is the collections of data that use forms for data maintenance within the "application".  One application usually contains many databases.

In either case, I think that both Inventory and Customers can/should be in the same application, but should be in different databases.  If they are in the same database now, then I wonder if you should step back and pause in your development and review the structure of your databases. 

I just hate to see you put a lot of limited time into something that could benefit from a solid foundation that was set up specifically for your needs.  It is real easy to fall  into "flat-file" design concepts from Q&A type databases vs. using the hierarchical benefits that Sesame offers.

There are plenty of resources here who can help with your design needs, just explain what you want to use Sesame for, and I think that many suggestion will be provided for you. 

You can start by listing the applications and databases within them that you have.  Which if any are using subforms?

Based on your description, I would suggest your initial thought are almost correct.  I would keep Prospects and Customers in the same database, with a status code.  Maybe rename from Prospects to more encompassing name like ContactsInfo.

But I would also have a separate database for the Pianos. 
This is probably what you are referring to as Inventory.  What you identify as Inventory sounds like Customer Service/Warranty type of info vs. classical inventory.  Inventory is usually owned by you, purchased for resale, on consignment, etc. 

From your description, you should consider having a record
for each Piano sold, and each should have its own status code for maintenance in addition to Customer(XLU info from Prospects.), Serial NO., Date Purchased, Delivered Tuned, PartsReplaced, NextTuneUpDate, etc.

You could possibly include Sales Order info in here also.  This depends on how you want to do Invoices, Billing, and other accounting functions.  But that might be too much too soon.  Get comfortable with the basic Prospect/Piano/CustomerService info first.

Off line question....Is Mr. Opper Nokkity on your staff?.
I understand that he is the best piano tuner available. 
You may have heard that "Opper Nokkity only tunes once!"