The lead -> opportunity -> contact flow seems pretty natural, but there are a number of challenges with the model.  Records are not really ‘converted' in the CRM in this channel.  When a lead gets converted to an opportunity, the existing lead record is simply deactivated and a fresh new opportunity record is created.  An opportunity is associated with a potential customer, but much of the information in the original lead is lost in the conversion.  If you convert to a contact, that information is copied to the contact and the new contact record is 'magically' associated with the deactivated lead (which helps maintain the history). But if you convert to an opportunity,  you lose all the address information.  If you were lucky and had an existing task assigned to the lead prior to a conversion, you can click on the activity in the new opportunity, then click on the deactivated lead in the Regarding field to retrieve the address information, but you won't find a convenient place in any of the editors or out-of-the-box fields to view deactivated leads, which means you could easily lose track of some information you have already tracked.  In time, you will be deleting your deactivated records, and if you delete a deactivated lead (it is no longer updated and you have active contact records right?) then you will find that the activities disappear as well and the activities that you were seeing in the new contact record that were related to the old lead record are no longer available.

Another consideration is that marketing lists are tied to a single entity type.  If you want to create marketing lists to send information to both leads and contacts, you must create two separate marketing lists for the same purpose.  When a lead is a member of a list and gets converted to a contact record, the new contact record is not added to another list.  When you send email out through the old list, you are sending it to a deactivated lead, which might not even get sent to the lead and you are probably not maintaining the information in the old lead anyways once they become a contact.  Finally, many other CRM applications are dependent upon using a contact as a record for a person.  For example, let's say your lead has a pre-sales question and you want to treat this as a case that gets routed through your standard helpdesk.  A case record can be associated to an account or a contact, but not a lead.  This means that you would have to convert the lead to a contact before you could open a case for the contact.  The same logic goes for all reports - they work on a single entity - either a lead or a contact, but not both, and if you start mixing and matching your leads in leads and contact records, you are really going to make it difficult for yourself.  The problem is also seen with custom entities - you can create a relationship with a custom entity with a single other entity type for each relationship attribute.  If you have your contacts represented in leads and in contacts, that means you will have to double up on every relationship and place additional code and logic in all of your extensions to deal with each record.  Finally, since converting a lead to a contact is creating a new record with no linkage, any data you have in the CRM that is related to the old deactivated lead remains linked to the old deactivated lead and not to the new contact record.  This means that you really lose some history in the conversion from lead to contact.

Most self-service customer portals, including membership applications have an authentication mechanism to uniquely identify a user.  These web authentication mechanisms must be stable for your customers - you don't want the web authentication broken as a lead record gets converted to a contact record - that would not be a friendly experience for your customer.  Web portals also typically rely on custom entities, and converting a lead to a contact can really mess up an application that is designed to use one or the other.  Remember that to use both leads and contacts, you have to have two separate relationships in each custom entity that you create, and you also have to double-up all of the lookup logic and application code to handle all the combinations that can arise from this.  From a web portal standpoint, it is far more efficient and desirable to have all contact information in a single entity - and that entity to be a stable entity - so it is recommended as best practice to use a contact record to anchor all people in your web portal.

Many websites have interactive features that are tied to the CRM.  For example, you might have a careers application, a contact us form, or a registration form required to access some content, or email list subscription management.  If you tie these applications to using leads, then you risk having duplicate data for a contact and a lead in your CRM for the same person and when you look at the contact record in the CRM you will be missing the activities that are being associated to a lead for the same person.  To compensate for this, you might be first attempted to find a contact record, then look for a lead record, then if you can't find either, create a new lead record.  Similarly, your email subscription management application will have to find a lead or a contact record, then find the list of email lists appropriate for that type of record in order to add or remove that person from the appropriate list, and you will also have to spend extra time developing plugins to convert email list subscriptions when the lead->account conversion takes place, but you will find that you will lose information if the contact is converted to an opportunity.  The end result of all of this is that it adds significant additional application logic that costs you time and money and complicates your testing of your application each time your website or portal is updated.  It is much simpler if you anchor all of these features to a contact record - this will result in less complexity and will ensure that you can maintain the integrity of all history of your contacts without having to worry about the problems that would arise when a lead gets converted to a contact record.

You might find some resistance from your users to use contact records for all contact information.  There are a number of reports in the CRM that come out-of-the-box that are related to lead management.  There are also some built-in views that are also handy.  Resist the urge to panic - the CRM has all the flexibility that you need to replicate the same functionality that you need, even using a contact record.  Reserve your leads for what they are really good at - a holding ground for bulk import operations, but any real contact you have with individuals should be done using a contact record.  This allows you to maintain full history on a contact without losing information from conversion operations.  It also makes building reports and custom extensions much easier if you only have to worry about using the contact or account record.  The CRM is much more functional if you use the contact record, across all of the various CRM applications.  You can use a number of techniques to separate out your ‘leads' from your real ‘contacts', even if you use the contact record for a ‘lead'.  For example, you might add a single attribute that designates a contact as a lead, of which you can then use in a filtered view to select only your leads.  Of course, this doesn't allow for much functionality and you are also likely to add additional attributes like dates, or even possibly a custom entity to represent all information related to a lead (ie: where were they referred from, which dates, etc.)  You can actually do more with a contact than you can with a lead and there is no loss of fidelity in your CRM if you use contact records as a base for all real contacts with your organization.

Some organizations are based on a membership model, and it is common for an organization to consider using leads for non-members and contacts for members.  I recommend against this practice.  I recommend using leads for bulk import of new potential members, but to use a contact record for every human that you can reliably contact and want to track in your CRM.  Many email imports will be with invalid information, so using the lead record in this manner helps keep your contact database clean - only contactable people are placed as contacts, and leads are dumped on a frequent basis once each list is mined for any possible contacts.  Once a contact record, you can still track and qualify opportunities - you don't need a lead record for that.  If you are a membership-based organization, you can track your membership details in a separate custom entity.  If you use the lead/contact barrier to represent your membership information, you are really hard-coding your CRM to a very specific business model and you will find that this will eventually get in the way (let's say you start a partner model later and have a drive for obtaining new partners - oops we use leads for non-members and contacts of paying members...).  If you use a custom entity to represent the membership status of a contact, you can easily extend the model without breaking anything by adding another custom entity to represent partner status.  These custom entities can have attributes of their own (like when they last paid, when they were first a partner, when they have to renew, what level they are).  As members expire and become non-members, it won't be a problem if they are still a contact.  If you use the lead/contact boundary as an indicator of who is a member, then what do you do with a member that lets their membership lapse?  You can't move them back to a lead.

I recommend using leads only for temporary import of large lists for the purpose of quickly going through the list to find ‘live' contacts, which can then get converted to a contact, and everyone else that cannot be contacted remains as a lead until you dump your old data that is not being actively followed up on.  I recommend using contact and account records for every person that you can physically contact you.  For inbound ‘leads' from your website that fill out a ‘contact us' form, I recommend that these go in as contact records, not lead records.  I recommend that any email subscription mechanism that you place on your website uses a contact record instead of a lead.  I recommend that web authentication mechanisms in your customer portals be tied to contact records in your CRM - do not tie them to a combination of lead and contact records.  Keep in mind that whether someone is a lead or a contact doesn't necessarily mean you have to store them in those specific records in the CRM - you can still separate out your leads and your contacts using standard CRM customization techniques.  And I also recommend that you do regular housekeeping on your CRM contacts anyways, not matter which strategy you use for tracking customer information.  In the end, there really is no disadvantage to using a contact record to track contact-related information, yet there are a number of problems and challenges that arise when you use lead records instead.  You will spend less time in the long run if you use the guidance that I am giving in this article.