Last reviewed: 10 October 2026. Product details reflect this review date. Availability and behavior can vary by account, role and release.
Editorial ink illustration: A central customer folder connects to separate contact, billing and delivery records.
A salesperson meets someone at an event, opens a possible deal, and later wins an order. Several things have happened: a person has been identified, a business relationship has developed, and a particular sale has progressed. Treating all three as the same record makes the sales history harder to understand.
NetSuite organizes potential and buying relationships through lead, prospect, and customer stages. Contacts represent the people involved, while opportunities represent specific potential sales. Related activity and transactions add context to the relationship.
This lesson follows a fictional company from first conversation to customer. The aim is to help a sales team choose the right record, agree what its stages mean, and avoid creating a new organization record every time a new opportunity appears.
Start with three questions. Who might buy? Who are we speaking with? What might they buy from us?
For an organization-based sale, the company answers the first question, a contact answers the second, and an opportunity describes the specific potential sale. NetSuite can also represent relationships with individuals, so the team’s identity rules should cover the business model it actually uses.
Consider fictional Cedar Works. Mara is the person coordinating its search for installation services. “Cedar Works” identifies the business relationship. “Mara” identifies a person connected to it. “Installation services for the new workshop” describes the opportunity.
If Mara later asks about a second service, the team may have another opportunity involving the same business relationship. That request is not, by itself, a reason to create Cedar Works again. Maintaining the distinction helps preserve a coherent view of conversations and business activity.
For a wider explanation of record relationships, read records and transactions in NetSuite. Here, the focus is how a sales team interprets the relationship’s lifecycle.
A lead represents a potential customer at the beginning of the sales lifecycle. A prospect represents a relationship being developed toward a sale. A customer represents the buying relationship. The account’s statuses and conversion configuration determine how those concepts are applied in the actual workflow.
Do not assume that every business must move every record through an identical mandatory sequence. A prospect can be created through lead conversion or created directly with a prospect status. Account preferences and the configured sales process affect conversion and transaction-driven behavior.
The team still needs operational definitions. What evidence makes an inquiry worth pursuing? When should a representative treat it as a prospect? What record or event establishes the customer stage in this account? Who owns a disputed classification?
Write those answers in the sales process guide. They should describe evidence rather than intuition alone. “We have confirmed an identifiable requirement and an agreed next conversation” is more useful than “this feels promising,” if that is the team’s approved qualification standard. It is an example policy, not a universal NetSuite rule.
At a trade event, Mara describes an upcoming workshop installation. The team first checks whether Cedar Works already exists in the account and whether Mara already has a relevant contact record. That identity check happens before creating new records.
Suppose this is a genuinely new relationship. The team records the initial inquiry using its approved lead process. A representative confirms the requirement and the appropriate next step. When the agreed qualification evidence exists, the authorized user follows the account’s configured process for the prospect stage.
An opportunity now captures the particular installation sale. The representative keeps the relevant contact and activity connected so another team member can understand the conversation. When the customer agrees to buy, the sales team uses its approved order process and verifies the relationship’s resulting status.
This example does not assume that opening an opportunity automatically performs every conversion or that all accounts use the same trigger. The important checks are that the intended stage is correct, the opportunity belongs to the right relationship, and the prior context remains discoverable through the configured records.
After the installation, Cedar Works asks about a maintenance service. That is a new potential deal with an existing customer. The account team should examine the established relationship before creating anything new. A second opportunity can describe the new sale without fragmenting the organization identity.
A pipeline review becomes inconsistent when one representative treats any conversation as a prospect and another waits for a detailed proposal. The resulting counts compare different business meanings.
Choose a small set of evidence for each stage transition. Depending on your process, this might include a confirmed organization, a known contact, a stated requirement, an assigned owner, and an agreed next action. The exact criteria should fit the team; avoid adding fields solely because another company uses them.
Also define the exception. What should happen when the contact is known but the buying organization is unclear? What if the business is already a customer? What if an inquiry is real but outside the services you provide? These cases should have an owner and an approved treatment.
Keep relationship stage separate from the outcome of one opportunity. An existing customer may decide against a particular proposal and remain a customer. Losing one opportunity does not erase the wider relationship or imply that a duplicate lead should be created for the next conversation.
Search for an existing relationship using the organization’s agreed matching approach. Names can vary through abbreviations, trading names, punctuation, or changes over time. A similar name is a clue, not proof of a match.
Compare the permitted identity details and ask the data owner about ambiguous cases. Separate legal entities may need distinct records even when their names look similar. Conversely, one organization may appear under several variations that should be reviewed as potential duplicates.
If two records might be duplicates, preserve their identifiers and relevant context for the authorized owner. Do not delete or merge them casually to make the list look cleaner. Their transactions, relationships, and permissions may require careful review.
Bulk lead intake makes the matching decision more important. The CSV import validation and recovery guide explains a broader import discipline. Establish identity rules and test a representative sample before uploading a large event list.
Prospect records can bring together contacts, opportunities, communications, activities, and transaction history. That context is most useful when users consistently associate new activity with the relevant relationship and, where appropriate, the particular deal.
Before saving a conversation record, ask who and what it concerns. A discussion about Cedar Works’ installation scope should be discoverable by the representative handling that opportunity. A contact’s changed responsibilities may matter more broadly to the relationship.
Avoid using a copied note as a substitute for the correct relationship. If an activity appears to be missing, verify where it was recorded and which records the current role can see. The information may be attached elsewhere or outside the user’s visibility.
The roles and permissions access review guide helps investigate that visibility question without granting unnecessary access. For marketing-source context, continue with campaign lead-source attribution.
A trade event may produce several contacts at the same company and more than one potential opportunity. Counting contacts, organizations, and opportunities will therefore answer different questions.
Before discussing conversion rates, state what is counted and which period applies. Are you comparing newly created relationships, relationships that changed stage, or opportunities with a particular outcome? Have records created directly as prospects been considered in the definition?
Do not combine these populations merely because they share a sales label. A customer with two open opportunities remains one business relationship in an organization-level count. It contributes two potential deals to an opportunity-level count, subject to the report’s scope.
Use a small known example to test the report. Cedar Works and Mara can serve as a training case: explain how each record should appear in the specific report before trusting a larger funnel total.
If an organization appears twice, investigate identity and record ownership. If the stage looks wrong, inspect the status and configured conversion behavior. If an opportunity is missing from the expected relationship, verify its actual association and the reader’s access. If communication context is missing, trace the activity’s owner and related records.
A useful support request includes the record types, identifiers, expected relationship, active role, and observed result. Avoid describing every issue as “CRM is wrong.” The more precisely you name the mismatch, the easier it is to assign the correct owner.
Before ending the review, confirm that the organization identity is checked, the contact is distinct, the opportunity represents a specific sale, and the stage has agreed evidence. Verify the configured conversion path and the next action’s owner.
CuriousRubik’s NetSuite training services can help teams rehearse those decisions. Once the sale is agreed, the sales-order lesson explains how the commitment connects to fulfillment and billing without losing the distinction between them.