Lead or Contact in Zoho CRM: when should a clinic convert an inquiry?

In a clinic, the boundary between Lead and Contact does not define medical or legal status. It identifies the record structure used for an inquiry. A Lead evaluates whether the inquiry is genuine, reachable, and within the clinic's scope. A Contact carries an ongoing relationship. Conversion in Zoho CRM is not clinical proof that care has begun. Conversion and clinical status remain separate.

The conversion threshold should not depend on personal interpretation. Converting too early mixes unverified inquiries with continuing relationships, while converting too late leaves verified relationships in the Lead structure and scatters later work. A sound threshold is visible in the record, supported by documented transfer behavior, and followed by authorized human approval after critical fields are compared, before an irreversible conversion begins.

Lead and Contact describe record structure

A Lead record answers three operational questions: Is the inquiry genuine, is the person reachable, and does the request fit the clinic's defined scope? A Contact carries the structure for verified, continuing communication. Neither purpose determines clinical condition. The distinction organizes records, clarifies ownership, and makes the next operational work visible to the team.

Becoming a Contact does not mean an examination, treatment, or care relationship has started. Conversion status and clinical status remain in separate fields. The first describes the record lifecycle; the second belongs to the authorized clinical process. This separation lets advisers monitor operational progress without changing clinical meaning or inventing a new status from module names.

An early boundary can fill the Contact pool with unreachable or unqualified inquiries. A late boundary leaves continuing conversations among Leads and makes ownership harder to follow. The right moment is not general intuition, but the point when team-defined conditions are visible in the record, documented, and reviewed consistently without being confused with a clinical decision.

Connect the threshold to an observable value

Define explicit measures such as qualification outcome, contact verification, and area of interest. Express them through predetermined options rather than free interpretation. This replaces “looks ready” assessments with a readable value combination that qualifies a record for conversion review. Document each option's operational meaning and consolidate different phrases that represent the same outcome for the team.

These values do not start conversion by themselves. When a record meets the criteria, it becomes a candidate for human review. The responsible person checks contact information, qualification outcome, area of interest, and ownership together, then decides deliberately. The threshold remains observable without making an irreversible operation the uncontrolled result of a single field change.

Conversion in Zoho is edition-independent and requires the user's profile to carry Convert Leads permission. Implementing the threshold with a custom field requires at least Standard; Free has no custom fields or custom modules. Reviewing the threshold and executing the conversion can be organized as separate responsibilities. This separation prevents field values from replacing authority. The team documents who verifies each value, how a record is held when information conflicts, and who gives the final approval before execution.

Conversion outputs and transferred objects are documented

Converting a Lead creates a Contact. If Company Name is present, it also creates an Account. The user may choose to open a Deal. When selected, the order is fixed: Account and Contact are created from Lead data first, followed by the Deal. Conversion cannot be reversed and requires Convert Leads profile permission, so targets and mappings need prior review.

If a Deal is created, Lead notes move there, and copies appear on the related Account and Contact. Without a Deal, notes appear only on the Contact. Attachments go to one user-selected target: Contact, Account, or Deal. Tags can move to those targets; Account-directed tags move to Contact when no new or existing Account is found.

An adviser converts a record, then looks for its X-ray attachment on the Contact screen. It is absent because the selected attachment target was the Deal. Since conversion cannot be undone, the file is linked again manually. Open-activity destinations are undocumented, so test a representative conversion in Zoho, compare the before and after screens, and record each object's destination.

Empty-field rules govern matches with existing records

During conversion, the system checks unique fields in Contacts and Accounts first. If none matches, it evaluates the Lead email address, company name, and Lead name in that order. Unique fields take priority over those system fields. When a similar record appears, the user may merge instead of creating another record, after confirming that the match represents the same person.

When a Lead is merged with a Contact, its values transfer only where target fields are empty. Existing values are not overwritten. This can protect established information but can also prevent newer data from replacing obsolete data. With read-only access to the target module or record, conversion and merging occur, but the target fields remain unchanged.

A Contact created two years earlier contains an old phone number. The same person submits a new inquiry, and conversion merges it into that Contact, but the new number is not written because the target field is occupied. The team calls the old number. Compare phone, email, language, and ownership values before merging, then identify information that needs correction.

Build field mapping around type and length

The mapping path is Setup, Customization, Modules and Fields, Leads, then Lead Conversion Mapping. Standard fields are mapped by default, while custom fields are mapped manually. Source and target must share a type, and the target must be at least as long as the source. Text maps to text and similar picklist types map together. Incompatible targets do not appear.

Similar field labels are insufficient. If the source contains free text and the target uses controlled choices, value compatibility still needs separate resolution. Do not map a source field describing origin to a target field describing the current channel. Review business meaning, data type, and length together for every mapping decision instead of relying on nearby labels.

With several layouts, conversion mappings are configured separately across them. Subform fields can map to subforms in Contacts, Accounts, or Deals when their data types and lengths match; this mapping does not work in bulk conversion. Layout-based conversion mapping and subform mapping require Enterprise or above. Enterprise allows two subforms per module and Ultimate five; lower editions allow none. After a downgrade, layout-based conversion stops, while its settings remain until edited. Before using the Zoho configuration, test individual and bulk paths separately, and do not generalize an observed result from one path to the other.

Bulk conversion differs from individual conversion

With multiple page layouts, workflow or bulk conversion displays only three required Deal fields: Deal Name, Closing Date, and Stage. Unique Deal fields cannot be used during bulk conversion. Each new Deal enters the layout's default pipeline. If the chosen Stage is absent from that pipeline, its first stage is applied instead.

If record currency is not selected, currency amounts are treated as home currency, then converted using the Lead's currency and exchange rate. Do not generalize an individual conversion screen to bulk processing. Test layout, pipeline, stage, and currency results on a small record set, and document the expected targets and acceptance conditions before running the larger operation.

Official descriptions conflict on whether validation rules run during conversion, so test this in your organization without assuming a result. Validation operates during manual creation and editing. Field changes prevail during imports, workflow field updates, approvals, Blueprint, and API updates. Before bulk work, use a separate eligibility review and human approval instead of relying on an unresolved validation outcome.

Run duplicate checks before conversion

Uniqueness is a field property applied across its module. Up to three fields can be unique in Leads, Contacts, custom modules, and Products; other modules allow up to two. Tasks, Calls, and Meetings have no unique fields. Supported types are Text, Email, Phone, Integer, Big Integer, and URL. Unique matching ignores case, and unique fields cannot be encrypted. Zoho offers no fuzzy matching.

Find and Merge runs from record details, offers six criteria, and merges up to three records; merged records are permanently deleted. De-duplicate runs from list view in its supported modules, uses up to three fields, merges exact values, and selects the latest Last Activity Time as master. Check normalized phones and lowercase emails first. Leave identity-document use to a separate legal assessment. Verify relationships on a small set before conversion.

Zoho CRM for clinics