Finding won patients who have not started treatment

A patient who paid a deposit is marked won, and the consultant closes the screen. Three weeks later, the patient calls about a date, but nobody knows whose list contains the record. It left the open-work screen that day. The record still exists. Zoho changed its daily visibility through a category marker, while the post-closing question remained unanswered.

The clinic manager does not need to reopen closed opportunities. Won represents the commercial outcome, while treatment commencement measures another event. The stage describing closure should therefore remain separate from the field describing what happens afterward. A view can then read that field alone. The team preserves its won count while seeing patients who have not started treatment in a dedicated working screen.

Won is a category marker rather than the end of work

A deal stage is not an isolated label. Its structure combines stage, probability, deal category, and forecast category. Deal categories are open, won, or lost. Custom stages can sit beside system-defined stages, with each stage mapped to one category. The forecast category follows automatically: open maps to pipeline, won to closed, and lost to omitted.

When a stage mapped to won is selected in Zoho, Verify Details opens and requests the amount, closing date, and stage. Closing stages also appear in separate groups with an icon on the record detail. The visible stage name alone does not create the closing effect. Its mapped category is decisive, keeping the commercial result separate from the operational start.

The record remains but disappears from the team’s daily screen

List criteria can read the deal category directly. Stage is open returns open deals, stage is won returns won deals, and stage is lost returns lost deals. These criteria still examine the mapped category when the visible stage name changes. A record entering a won category therefore leaves the daily open-work view but remains available in an appropriate won-deals list.

This gap is not deletion or archiving. It arises because the team works from a screen limited to the open category. When post-closing questions are absent from that screen, the patient leaves operational attention. The answer is not reversing the category. It is creating another view that selects unfinished work within closed records, preserving closure while exposing a separate daily queue.

Measure post-closing progress separately from the commercial closing event

Custom stages such as treatment planned or treatment started can follow closing. Deals continue to count toward the target while those stages remain mapped to won, because the mapped category matters more than the stage name. Users also cannot edit the forecast category of a closed deal. Process language can become more precise without losing the won result, while a separate field measures treatment commencement.

The treatment start date should not replace the commercial closing date. Before creating a reason for not starting, review the existing Reason for Loss field. It appears only for stages in the closed lost category. It becomes hidden when a record enters a won stage, and its previous value is not shown. Unifying its name with other reason fields prevents duplicate concepts.

Criteria build the list without any rule moving its records

A custom view can evaluate the record’s fields, parent-module fields reached through lookups, subform fields, and the presence of related records. Depending on the data model, criteria can select won deals with an empty treatment-start field. If treatment is represented by a separate related record, the view can instead select won deals without that related treatment record. The existing record structure determines the choice.

A Zoho view can use up to three related modules or subforms and read up to three fields from each. Criteria may also use up to three lookup fields and five fields from each lookup module. Without permission for a related module, the view still works but masks that criterion. Matching records populate it automatically; no rule moves them into the list.

A list does not notify anyone or begin follow-up alone

A custom view only presents matching records. It does not send a notification or start follow-up. Cadences is the documented mechanism for connecting the list to action. Its audience can be selected manually or taken from an existing custom view, with separate control over when new records join. Once the targeted response arrives, the record automatically leaves the sequence.

The audience view cannot contain Campaign Name, related-module criteria, or belongs to for user fields. Multiselect fields cannot use Include All, Include Any, Exclude All, or Exclude Any. Follow-ups include email, task, call, and WhatsApp, but calls are unsupported for Deals and WhatsApp requires Business Messaging activation. Initial setup allows five follow-ups; afterward, only the final follow-up can be removed.

Use the rule type designed for conditional required fields

A planned treatment date can become conditionally required through the layout rule action Set Mandatory Fields. When the stage changes from record detail, Blueprint, or Pipeline view, required fields appear in a pop-up. The rule is also evaluated during drag and drop in Kanban and applies in approval processes. It does not run for imports, webforms, or lead conversion; the API supports only its mandatory-field action.

A validation rule behaves differently: it may stop saving or display a warning, but it has no stage-transition concept. Blueprint validation takes precedence while a record is inside Blueprint. Making a transition conditional therefore requires Blueprint. Limits are ten rules per layout, twenty-five primary conditions, five branches per condition, and twenty-five actions per branch, encouraging a focused configuration within the available capacity.

Postponement counts and waiting time require different measurement mechanics

A field update writes only a predetermined constant or blank value. It cannot read and increment the current number. A postponement counter must use a workflow-linked custom function or a documented manual team practice. A formula field is read-only and recalculates when participating fields change, so it cannot freeze a momentary value. Waiting time is instead examined through history enabled for one picklist per module.

At month end, the won count is visible, while started treatments are compiled from consultant notebooks and two people give different answers for one patient. Standard is the minimum for custom fields, custom views, and Cadences; layout rules are edition-independent. Blueprint and formulas require Professional. An automatic counter needs an Enterprise custom function. Related-record counts allow ten rollups in Enterprise and fifteen in Ultimate; lower tiers lack them. Free lacks the custom field required for this design.

Begin implementation with the lowest-cost structural change available first

First review stage-to-category mapping and document the category behind each post-won stage. Then add the treatment-start field and build the view selecting records that have not started. If eligible, make that view the Zoho Cadences audience and keep conditional requirements in one layout rule. The yonetici-cockpit pattern is built for the manager view. Each step reveals whether the next investment is necessary.

A view using related-record criteria cannot become a Cadences audience, so follow-up requirements must shape the criteria design. Use a layout rule for conditional requirements, Blueprint for controlled stage transitions, and a custom function for an incrementing counter. Each mechanism answers only its own question. Won opportunities and started treatments are separate management measures, shown on separate screens for commercial closure and post-closing delivery.

Zoho CRM for clinics