Use an Account for the organization and a Contact for the person you work with. Keep the sales opportunity separate from both. This makes it easier to understand who the customer is, who you should speak to, and which sale you are trying to advance.
Before fixing existing records, agree on that model with your team. A cleanup that changes company links without checking the underlying relationships can make reports look tidier while putting people under the wrong customer.
Accounts, Contacts, Leads, and Deals at a glance
Zoho's Accounts documentation describes Accounts as companies or departments associated with contacts and sales opportunities.
Use this working model when designing your process:
| Record | Question it answers | Example in your design |
|---|---|---|
| Account | Which organization are we dealing with? | A customer company or department |
| Contact | Which person are we speaking to? | The buyer or project sponsor |
| Lead | Which inquiry needs qualification? | A new inquiry awaiting review |
| Deal | Which opportunity are we pursuing? | A specific proposed sale |
The table is a process guide. Agree on your own qualification and opportunity rules before creating or converting records.
Zoho documents that lead conversion can create Contacts, Accounts, and Deals. Inspect the intended result before converting a qualified inquiry, especially if the company or person already exists.
Use convert a qualified lead to turn that decision into a reviewed CRM action. Conversion should preserve a meaningful customer model rather than introduce another spelling of the same company.
For more on the inquiry boundary, see Leads versus Contacts. The distinction is especially useful when a marketing import mixes new inquiries with people your sales team already knows.
Keep a written example for each record type. A short shared definition helps users make consistent choices without learning every configuration option first.
Decide where each field belongs
Place information where its meaning belongs. A company's industry describes the organization. A person's direct email describes the individual. An opportunity's expected outcome belongs with that sale.
Use a field worksheet:
| Information | Preferred home in your design | Reason |
|---|---|---|
| Company industry | Account | Shared across the organization |
| Company website | Account | Describes the business |
| Person's role | Contact | May differ between people at one company |
| Direct email | Contact | Identifies a person or reviewed shared mailbox |
| Opportunity stage | Deal | Describes one sale |
| Opportunity-specific requirements | Deal | May differ across sales to one customer |
These are design recommendations, not a list of fields guaranteed to appear in every layout. Compare the worksheet with your current configuration.
Avoid copying a company classification into every contact without a maintenance rule. If the classification changes, copied values can drift. Decide who owns each value and what must happen when the source changes.
If users want to filter contacts by account parameters, specify the exact question first. For example: “Which contacts belong to accounts in this reviewed industry segment?” Then have your administrator or the assistant inspect the available view or report configuration and test it against known records.
Do not assume that a field visible on an Account is automatically available as a Contact filter in your current setup. Check Zoho's help docs for the relevant view or report if the required relationship is unclear.
Choose a known account and list the people you expect the filter to return. Compare the actual results with that list. Include a person at a different account so you can detect an overly broad filter.
If a report needs a copied field, document its source, update owner, and reason. A deliberate reporting field is easier to maintain than an unexplained duplicate.
Build the company-to-people relationship
Consider a fictional company, Example Manufacturing, with a purchasing manager and an operations lead. Your team has a proposal for one project and a separate inquiry about another.
First, search for the company in your existing CRM. Review spelling variations, website information, and linked records before deciding to create a new Account.
Creating an Account requires access to the Accounts tab and Create permission, according to Zoho's account creation guide. Do not interpret a missing creation option as evidence that the company needs to be stored as a Contact instead.
If the company does not already exist, create the agreed Account record. Then identify or create the two people and establish their intended company associations.
Keep the two opportunities distinct. Use names that help your team recognize the actual proposed sale, and check that each opportunity points to the intended organization and people in your configuration.
Zoho's Account details page brings related Contacts, Deals, activities, notes, and other information together. Open that page to confirm that the resulting relationships are useful to the team.
Check both directions during the pilot. Open the Account and find the expected people. Open each Contact and confirm the intended company. Open the Deal and verify its customer relationship.
If you want to see contact emails from the Account, inspect the related Contacts information and available display configuration. Do not paste several personal addresses into a company email field merely to make them visible together. Test the view with the salesperson's access.
Use the Contacts guide for the person-level workflow. Keep company identity consistent as additional people join the relationship.
When another salesperson creates a new opportunity for the same customer, reuse the reviewed company record where appropriate. A new sale does not automatically mean a new company.
Handle individuals and multiple affiliations
For an individual customer, do not invent an employer just to satisfy a habit inherited from business sales. Decide how your team represents individual customers and verify that the current fields, required values, and reporting support the model.
Use a pilot person with no company relationship. Walk through capture, qualification, an opportunity if needed, and follow-up. Check every point where the process expects an organization.
If your configuration requires a company value, treat that as a design issue to resolve. A placeholder company can spread into reports and integrations, so document any intentional convention and its consequences before adopting it.
A consultant or adviser who works with several businesses creates a different question. You need to represent the meaning of each affiliation, not just select a convenient company name.
Record what the relationship requires:
- Is one organization the current employer?
- Does the person buy for several organizations?
- Do affiliations need start and end dates?
- Should opportunities identify the organization represented in that sale?
- Who may update the relationship when it changes?
Do not assume a standard account lookup represents every affiliation. Inspect your existing relationship configuration and check Zoho's current help docs before promising a particular implementation.
Zoho documents Member Accounts for separate divisions or subsidiaries under a parent account. That organization hierarchy is a different modeling question from one person having several affiliations.
Similarly, two branches with similar names are not automatically duplicates. Establish whether they are distinct buying organizations or divisions before combining records.
Ask the process owner to approve the relationship model using real cases. Once agreed, record examples so imports and future users follow the same rule.
Fix account links with the AI Assistant
The Zoho CRM AI Assistant can review CRM relationships, propose matches, correct approved associations, and verify reports. It waits for your approval before correcting account and contact relationships.
Start with a read-only audit:
Review these Contacts and their Account links. Use existing CRM evidence to propose the right company for each person. Show missing links, conflicting evidence, and ambiguous matches separately. After approval, update only the agreed associations and check the Account views.
Use contacts under the wrong account to assemble the review. Compare available email domains, company websites, names, and existing relationship evidence.
Treat those signals as evidence to inspect. A personal email domain does not identify an employer. A shared corporate domain can cover subsidiaries, former employees, or several business units.
Build a review table with the current Account identifier, proposed Account identifier, supporting evidence, and unresolved questions. Have the responsible owner review ambiguous cases rather than letting a name resemblance determine the answer.
Keep missing links separate from incorrect links. A person with no Account may be a valid individual customer. A person attached to a different company may reflect a real change of employer.
Use duplicate accounts by name to find company records that need inspection. Before removing a copy, compare the people, opportunities, activities, and notes involved. Do not treat deduplication as a prerequisite for changing every Contact link.
Approve a bounded group of association changes. Afterward, reopen representative Contacts and Accounts to confirm the intended relationships. Check that unrelated personal details and opportunity values remain as intended.
The assistant can also create CRM fields, layouts, workflows, Blueprint, Deluge functions, and reports to support the agreed model. It does not operate a third-party directory or infer an employer from information you have not supplied.
For a proposed change, compare the before and after view of a known customer. Ask whether the Account still shows the people your team expects, whether the Contact's current affiliation is understandable, and whether the Deal still represents the correct buyer. Record any historical reporting question separately from the current contact detail.
For example, a person may leave a customer while a completed opportunity should remain attributed to that customer. Changing a current association should not become an undocumented decision to rewrite the meaning of the old sale. Review that case with the sales process owner before applying a broad cleanup rule. Use the same example in future import checks so a later upload does not undo the agreed treatment.
Keep a list of unresolved people with an owner and a next action. An honest review queue is more useful than a fully populated set of guessed company links.
Validate imports and account-level reporting
Before importing Contacts, map the company relationship deliberately. A source column containing a company name does not by itself prove that the import will populate the intended Account association.
If Account Name is not populated after an import, inspect the source value, mapping, target Account, and the import's actual result. Confirm the current layout and relationship requirements rather than reimporting the whole file immediately.
Check a small sample:
- A person linked to an existing reviewed Account.
- Several people who should share one Account.
- A company name with a known spelling variation.
- An individual customer with no company under your model.
- An ambiguous company name that should be held for review.
- A person already present in CRM.
Preserve source identifiers and record the outcome for each row. Distinguish a missing field value from a missing relationship and from a record you cannot see under the test user's permissions.
Use import contacts without overwriting data to plan updates that preserve reviewed CRM values. Make the intended treatment of existing people explicit before approving writes.
Once relationships are correct, validate the Account view and account-level reporting. Choose a known company and compare its people and opportunities with a manually reviewed list.
Reconcile opportunity totals from the underlying Deal records. Check the selected stages, date range, owners, and any repeated rows introduced by joining people to opportunities. A company with several Contacts should not inflate the value of one opportunity in your report design.
If a person moves to another company, decide which current and historical relationships should change. Reassigning a Contact does not by itself answer how past opportunities should be reported. Ask the process owner to approve that interpretation.
Keep the final acceptance check practical: can a salesperson open the company, identify the right people, find the current opportunities, and understand the next action? If so, the model is serving the customer workflow as well as the report.
Watch it done
See the Assistant find duplicate accounts and contacts linked to the wrong company.
Watch: Find duplicate accounts in Zoho CRM | Zoho CRM AI Assistant
Watch: Find contacts under the wrong account in Zoho CRM | Zoho CRM AI Assistant