A clinic patient enquiry pipeline: stages from first contact to treatment decision

A patient enquiry pipeline becomes reliable when everyone understands exactly when each stage is complete. In Zoho CRM, every stage needs one exit condition, every record needs one owner, and the team must know which intake channels activate each rule.

On Monday morning, a coordinator opens the pipeline and says that half of its records are “in discussion.” Two coordinators have placed the same record at different points, so the team has to question each person during the meeting to discover which patient is waiting for whom. The stage names describe personal interpretations rather than observable outcomes.

A stage is a decision point, not a state of mind

“In discussion” can mean different things to different people. One coordinator may count an attempted call, while another waits for a conversation. “Proposal sent” describes a result that can be checked: the proposal was delivered to the patient.

In Zoho CRM, stages in the Deals module are held in the system defined Stage Pick List. Every value should represent an actual decision point. A definition can place the name, exit condition, and evidence side by side. The team then moves a record because an outcome occurred, not because someone senses progress.

A patient enquiry pipeline is shaped not by its length but by linking each stage to one exit condition and one owner. Whether it works also depends on knowing which rules run for records entering through which channels.

Write exit conditions around outcomes, not attempts

A candidate who does not answer a call has not reached “contact established” because no conversation took place. The attempt should still remain visible in the team process without assuming an extra field type or automation behavior. The stage describes the outcome; the way the attempt is marked is defined separately.

If the exit condition says “the first contact attempt was made,” the team advances the record as soon as an attempt occurs. That contradicts a stage named contact established. The stage should advance only when the direction of the decision changes.

The existing stage and category structure has a purpose

Zoho CRM maps stages to one of three record categories: open, won, or lost, and the mapping can be changed. Selecting a stage mapped to won or lost opens Verify Details. For lost stages, the built in Reason for Loss Pick List is requested. The reason is hidden at a won stage. If a lost stage is selected later, the old value is not shown and the reason is selected again.

The clinic should keep won and lost values separate from its progression stages and each other. Combining them breaks the connection between the loss reason and lost category. Won alone is not a command that closes a record. The effect comes from the mapped category.

Assignment rules do not run on manually created records

An assignment rule runs only for records created through import, a webform, or the API. It is not triggered when a coordinator manually creates a record after a telephone or face to face enquiry. Choosing the owner during manual entry needs to be a separate working rule. A record always has one user as owner; there is no unowned shared pool.

A telephone enquiry is entered manually from a coordinator’s own screen. The team assumes records are distributed by a rule, so nobody checks ownership, and the record remains with its creator for two weeks. An unassigned record already goes to a default user: the person initiating an import, the API token owner, the user who created the webform rule, or the super administrator if that user is inactive.

Before assignment, Zoho CRM can check whether a user is logged in and within shift hours in company settings. If both options are selected, both conditions must be satisfied. Online status information can be delayed by up to five minutes. The control view should filter records accumulated under the default user or super administrator.

Put a requirement in one of three places, not two

The right mechanism depends on which action needs to be stopped. A validation rule consists of a layout, one primary field, criteria, and an error or warning message. “Stop with error” blocks saving, but only during manual creation and editing. Imports, webforms, and the API require separate treatment.

A layout rule’s “Set Mandatory Fields” action makes a field mandatory on the page. Layout rules do not run during import, on webforms, or on the lead conversion page; only this mandatory field action is supported in API operations. A Blueprint can make a field mandatory in the transition’s “During” section. While a record is in that process, Blueprint validation takes precedence.

Select one mechanism appropriate to the channel and decision point. A workflow is not one of them. Zoho CRM workflow actions cannot make a field mandatory, prevent saving, block a stage transition, or move a record into a custom view.

A report does not calculate time in stage by itself

Adding stage to a report does not produce the time spent there. When history tracking is enabled for the relevant Pick List, its related list holds the value, duration, time of change, person making the change, and destination value. It can be enabled for only one Pick List per module. Deals have stage history by default.

Whether a workflow field update can write the current execution time dynamically to a Date/Time field is not verified here, so the design does not depend on that behavior. A Formula field using Datecomp returns the difference between two existing date fields in minutes; it is read only, recalculates when participating fields change, cannot freeze a value, and may remain blank on existing records until one of those fields changes. This design reads time in stage from Pick List history tracking.

Measure where records accumulate, not pipeline length

Two custom views can provide an initial control: records in selected stages and records assigned to the default user. A custom view does not calculate how long a record has remained in a stage; that duration is read from Pick List history tracking. The view only fills with records matching its criteria and does not send a notification, create a task, assign an owner, or produce a reminder. Using it each morning is an operating habit.

Mass actions in a list view are separate from automation and wait for a user click. Changing owner is one such action, so open records belonging to a coordinator on leave can be reassigned there. The view exposes the issue; the team separately decides who reviews it, when, and what follows.

Configuration starts with definitions, not fields

Place recent enquiries on the table and ask the team to name each record’s stage and the outcome required to leave it. If answers differ, another field will not solve the problem. Agree on the stage dictionary, then select fields and rules.

Edition threshold: Blueprint, which conditions stage transitions, is available in Professional and higher. Formula fields are also available from Professional and can return the difference between two existing date fields in minutes, but they do not create a stage entry timestamp. Standard allows ten custom fields per module; the documentation states no separate Standard threshold for validation or layout rules. Time in stage is read from Pick List history tracking. The documentation does not state an edition threshold for this feature, so it varies by edition and is verified in the target account before a proposal; enabling it requires Module Customization permission, and a customer initiated downgrade deletes the tracking data immediately and permanently. The Free edition has no custom fields or custom modules, so the design in this article cannot be applied there.

The field type needs to be correct from the beginning because it cannot be changed after creation. With clear definitions, observable exit conditions, and explicit ownership, the team gives the same record the same meaning. The final step is not adding stages, but calmly reviewing accumulation points and checking whether the definitions work.

Zoho CRM for clinics