A multi-branch private healthcare group, Saudi Arabia

The organization already had multiple channels generating and handling patient inquiries.

The call center played a central role in receiving inquiries, understanding patient needs, routing requests and supporting appointment booking.

But information moved across different tools and processes.

An interaction might begin with a phone call.Another might start through WhatsApp.Another through social media.Future campaigns would introduce additional acquisition sources.

Not every inquiry became an appointment, and the organization needed visibility into what happened between those two points.

Without a connected system, fundamental commercial questions became difficult to answer:

• Where did this patient come from?
• What were they asking about?
• What happened after the first interaction?
• Who followed up?
• Did the inquiry progress to an appointment?
• Where are inquiries being lost?

The problem wasn’t lack of activity. It was the lack of a connected commercial record.

The project started with discovery rather than configuration.

The goal was to understand how the patient inquiry journey actually worked — not how it was assumed to work.

That meant working across the teams involved in the process, including Call Center, Marketing, Operations, IT and Management.

We documented:

Structured surveys, stakeholder meetings and process discovery were used to capture the current state.

This also established an important project boundary.

The objective wasn’t to redesign every operational process inside the organization. It was to identify what the CRM needed to understand and support.

Discovery should clarify the system — not turn a CRM project into an operations transformation project.

One of the most important design questions was defining what actually enters the CRM.

The organization handles a large volume of inbound and outbound communication. But those interactions represent different intents.

A patient might:

• Ask about a specialty
• Request information
• Compare branches
• Follow up on an existing request
• Respond to a campaign
• Request an appointment
• Change an appointment
• Call for another reason entirely

Treating all of those interactions as identical leads would create a CRM full of activity but very little commercial intelligence.

The architecture therefore begins with the patient inquiry — capturing context before assuming commercial intent.

That distinction creates a much cleaner foundation for reporting and automation.

A patient doesn’t experience the organization as separate systems.

They may see an advertisement, send a WhatsApp message, call the unified number and later receive an appointment confirmation.

Internally, those interactions can easily become disconnected.

The future-state CRM is being designed around a different principle:

One patient. One journey. One commercial history.

The integration model connects relevant interactions around the patient rather than around the channel:

This also creates the foundation for future attribution. Instead of simply knowing that Marketing generated inquiries, the organization can progressively understand:

• Which channels generate demand?
• What type of demand?
• For which specialties?
• At which branches?
• What happens to those inquiries?

The objective is not more integrations. It is continuity of information.

With a high volume of inbound and outbound calls every day, the call center represents one of the most important sources of patient intelligence in the organization.

But a call alone doesn’t create useful data. The CRM needs to understand the context behind it.

The system is therefore being designed to capture structured information such as:

Initial Channel · Inquiry Type · Specialty · Preferred Branch · Campaign · Priority · Appointment Status · Follow-up · Interaction History · Final Outcome

Telephony integration with the existing call-center infrastructure is part of the architecture so agents can operate with greater continuity between conversation and patient record.

The goal isn’t simply to log calls. It’s to turn interactions into usable commercial context.

Zoho CRM was selected as the core CRM platform.

But the architecture isn’t being designed by starting with Zoho modules and forcing the organization into them. The process works in the opposite direction:

The CRM becomes the system connecting the journey rather than defining it.

At the center is the patient inquiry and its progression toward an appointment or another documented outcome.

The future-state architecture brings the pieces together:

This keeps the architecture understandable for the people actually operating it while leaving room for future expansion.

The CRM should reflect how the business works — not make the business work around the CRM.

The CRM project doesn’t end when an inquiry is recorded. The next major milestone is the appointment.

The desired future state connects the inquiry journey with appointment information so agents can work with greater continuity rather than moving between disconnected processes.

Integration with the existing healthcare information environment is being assessed as part of the project.

Where direct integration is technically viable, appointment information can become part of the connected journey.

Where it isn’t, the architecture needs to preserve a clear boundary between systems without pretending the integration exists.

This is deliberate. A good architecture acknowledges technical constraints instead of designing around assumptions.

Once interactions become structured, CRM can become a commercial intelligence layer.

Management should progressively be able to understand:

• Inquiry volume by channel
• Demand by specialty
• Demand by branch
• Campaign-generated inquiries
• Appointment progression
• Follow-up performance
• Inquiry outcomes
• Where patients disengage

For Marketing, this connects acquisition activity with what happens after the inquiry.For the Call Center, it provides greater continuity.For Management, it creates visibility into demand and journey performance.

The engagement is being delivered progressively rather than attempting to configure the entire system at once.

Understand — Document the real patient inquiry journey, stakeholders, channels, information requirements and system constraints.

Design — Translate that reality into CRM architecture, fields, workflows, ownership and integration requirements.

Build — Configure the agreed system and connect priority channels and processes.

Validate — Test the architecture against real operational scenarios with the teams who will use it.

Launch & Optimize — Move into live operation, identify friction and improve the system based on actual usage and performance.

The goal isn’t a technically complete CRM. The goal is a CRM people can actually use.

This engagement is currently in progress.

Discovery and current-state documentation are being used to define the patient inquiry architecture, CRM structure and integration requirements before full implementation.

For that reason, I am deliberately not presenting projected conversion improvements, efficiency gains or ROI as achieved results. Those outcomes will be measured after implementation against an established baseline.

Multiple channels — being designed into one patient inquiry journeyOne CRM foundation — connecting demand, follow-up, appointments and commercial visibility

The technology itself isn’t the most interesting part of this engagement.

The real question is whether the organization can move from disconnected interactions to a system where patient demand becomes visible from beginning to end.

If implemented successfully, that foundation can support much more than CRM administration.

It can support better Marketing decisions.Better patient follow-up.Better attribution.Better operational visibility.And eventually, better commercial performance.

But those outcomes need to be measured, not assumed.