At reception, the phone rings while an employee moves between two screens. One shows appointments and communication history; the other holds the treatment record. Because nobody has documented which screen answers which question, every new employee learns the distinction again. The problem is not having two screens. It is leaving their boundary undefined. A Zoho CRM evaluation should begin by making that boundary explicit.
A CRM can be considered for patient communication, incoming enquiries, and the commercial process. Diagnosis, treatment records, and official health reporting remain within the vertical clinical system. This distinction does not describe a product deficiency. It defines scope accurately. When recorded before implementation, it makes data placement, staff training, permissions, and handovers between systems easier to understand and consistently explain.
One patient, two records in two systems
When two systems operate together, records for the same person can serve different purposes. One side may contain communication and enquiry history, while the other contains the clinical process. If the primary location is undefined, similar fields get completed twice. Later corrections become ambiguous, and employees follow personal habits instead of a written rule about ownership, identity, and updates.
A manager asks how many initial consultations became treatments last month. The answer requires manually comparing two files. The discussion continues not because the number is wrong, but because the same patient appears under different names in the systems. Software selection alone does not resolve this. Identity matching, record ownership, and the direction of information flow need an explicit operating decision.
What the standard module list includes
The standard Zoho CRM module list includes Leads, Contacts, Deals, Tasks, Calls, and Meetings across all editions. It has no ready module for clinical records, diagnoses, prescriptions, or official reporting. Services and Appointments are listed but disabled initially. Those two modules can be enabled only in the Professional, Enterprise, and Ultimate editions, which sets a clear boundary for their use.
If information received by the clinic needs a separate structure, custom fields or modules make edition choice part of the design. These customizations are unavailable in Free. Custom module capacity is 10 in Standard, 25 in Professional, 200 in Enterprise, and 500 in Ultimate. Per-module custom field capacity follows the same order at 10, 155, 300, and 500.
Appointments are not clinical records
The presence of Appointments or Services does not create a ready clinical-record object. Tracking appointment information in the CRM and keeping diagnosis and treatment records in the vertical system are separate scope decisions. A data placement table should express that distinction at field level. It should prevent teams from assuming that records with similar names necessarily have the same purpose, authority, or lifecycle.
Documents and images also need assessment against technical limits. File or image upload fields per module number 2 in Standard, 5 in Professional, 10 in Enterprise, and 15 in Ultimate. Each file can be at most 20 MB, while one image upload accepts no more than 10 images. Attachments are encrypted by default. None of these values turns the CRM into a clinical archive.
What compliance settings do and do not do
Zoho's HIPAA setting supports selecting up to 10 modules and marking no more than 25 fields in each as health data. It also provides four restriction switches. Lookup, multi-select lookup, and auto-number fields cannot be marked. For organizations within the relevant scope, signing a Business Associate Agreement with Zoho is another stated condition. These are technical controls, not a legal conclusion.
GDPR and HIPAA infrastructure can be configured for Leads, Contacts, Vendors, and custom modules. Deals, Accounts, and team modules are outside that list. Enabling the setting does not itself establish organizational compliance. Product documentation describes this material as nonlegal guidance and leaves assessment to legal counsel. It also provides no basis for a conclusion about Turkey's health-data regime.
Audit expectations and recorded activity differ
The audit log does not identify which records a user merely viewed. It records writing activity such as adding, updating, deleting, bulk updating or deleting, importing, exporting, converting, restoring, and merging. Changes made in Setup also appear in that history. Access to the audit log depends on the role hierarchy rather than a profile permission, an important distinction when assigning oversight responsibilities.
Field encryption applies only to supported custom-field types; standard fields cannot be encrypted. Encrypted fields cannot be used in advanced filters or criteria searches, and exports reveal their decrypted values. Deleted records and attachments remain in the recycle bin for 60 days. There is no automatic record-level retention setting, so deletion cannot be treated as immediate and final destruction.
Define the boundary before choosing an edition
Create a one-page data placement table that names the primary system for every information group. Show which system creates the record, where corrections occur, and in which direction any necessary copy travels. The boundary between communication, enquiries, and commercial work on one side and diagnosis, treatment records, and official reporting on the other then becomes teachable without relying on verbal tradition.
This arrangement requires at least Standard because custom fields and custom modules are unavailable in Free. Appointments and Services require Professional, Enterprise, or Ultimate. The edition threshold for compliance settings is unspecified and should be verified before a proposal. No edition threshold is stated for encryption, which needs administrator or customization permission. None is stated for audit logs, whose access follows role hierarchy.
Keep reporting obligations outside the product debate
The institution remains responsible for its official health-reporting obligations; choosing software does not transfer that responsibility. CRM evaluation should stay within documented modules, fields, permissions, and technical settings. Product controls provide no conclusion about national obligations or the rules applying to an institution. That assessment belongs in a separate review conducted by the institution's own legal team or legal adviser.
Eksenium's Clinical CRM Pattern Library includes the onam-kvkk and riza-geri-cekme patterns. They are neither evidence of legal compliance nor an official reporting mechanism. The institution's duties, data ownership decisions, and legal assessment belong in separate documentation, while the product design follows the boundary established through that work.
What a written boundary achieves
A written boundary tells the implementation team which fields to create and which information to leave outside. Training can explain the question answered by each screen. New staff do not have to rediscover the distinction. During handovers, the primary record, copied information, and correction direction remain visible in one table. Two systems therefore do not automatically become two competing sources of truth.
Positioning Zoho CRM without treating it as a replacement for clinical software simplifies the decision. The next step is to complete the data placement table by information group, primary system, and flow direction. Edition capacities and unspecified thresholds can then be verified before a proposal. A clear boundary supports communication and commercial work while keeping clinical records and reporting responsibility visibly where they belong.
