Medical Tourism Lead Management: How We Moved from Manual Routing to a Real-Time Sales System

💡 Quick Summary (TL;DR):

• The business problem: Vanity managed roughly 100,000 yearly leads through a Google Sheets-based routing process that required constant manual intervention across languages, countries, shifts, and leave schedules.
• The decision: Instead of replacing the CRM, we built the Agent Management System (AMS), a decision layer that applies operating rules in real time and connects CRM and advertising data.
• The result: Routing moved from 5–15 minutes to real-time assignment. Accuracy exceeded 99%, while team leads and executives gained a shared view of capacity, performance, and the conversion funnel.

During the period covered by this case, Vanity Cosmetic Surgery Hospital received roughly 100,000 leads a year, performed tens of thousands of surgeries, and had more than 200 team members. Most prospective patients came from abroad, so inquiries arrived throughout the day from different countries, languages, and time zones.

At that scale, medical tourism lead management is not just a matter of saving a form submission in a CRM. Each inquiry has to reach a sales representative who speaks the right language, is working at that moment, is not on leave, and still has capacity. A late or incorrect assignment consumes team time and delays the first contact with the prospective patient.

I joined Vanity in December 2022 as Deputy General Manager of Information Technologies, also referred to as CTO. The problem in front of me was an operating-system problem before it was a software project: the rules were known, but people were still applying them manually in Google Sheets.

This case records work that began in December 2022. It is about more than automating lead distribution: it shows how we made a recurring operating decision explicit, measurable, and manageable. It does not describe the company’s or the system’s current state.

The starting point: Rules without a decision system

When I joined Vanity, routing inquiries from different countries and languages to the right sales representatives was a long-discussed but unresolved need. A rough scope document existed. A working system did not.

Each language had separate forms. Inquiries flowed into Google Sheets and were then distributed manually. When someone took leave, changed shifts, left the company, or joined the team, the sheets also had to change. Weekends and holidays created additional exceptions.

The assignment itself could take 5–15 minutes. The deeper problem was the lack of a consistent record of why a specific representative received an inquiry. Rules existed for country, language, source, priority, capacity, and previous ownership. But those rules lived in people's attention rather than in a decision system.

We needed a decision layer, not a new CRM

At first glance, this may look like a CRM procurement or configuration problem. Our starting point was different. The CRM already held the sales record, while Google Ads showed which campaign generated the inquiry. What was missing was a layer that could evaluate operating conditions before assignment and carry the resulting decision into the other systems.

A simple round-robin queue was not enough. The system had to consider several inputs at once:

• The inquiry's country, language, source, and pipeline
• The representative's shift, leave status, and maximum lead capacity
• Distribution ratios and representative-level priorities
• Whether an existing lead should retain the same owner
• The state of CRM stages and required fields after assignment

We therefore built a focused decision layer around the CRM instead of replacing it. The Agent Management System, or AMS, was not an attempt to recreate an entire medical tourism CRM. It was designed to execute one expensive, frequently repeated decision reliably: Who should receive this inquiry now?

That distinction shaped the custom-software decision. When rules stop being peripheral configuration and begin to encode the operating model itself, a system that makes those rules explicit and measurable can earn its place.

What we chose to solve first

The first version had a deliberately narrow job: read the defined rules and assign each incoming inquiry to the right sales representative automatically.

We designed the system as a modular platform from the beginning. Representatives could be assigned to pipelines, while working hours, leave periods, distribution ratios, priorities, and lead caps could be managed centrally. If someone had previously spoken with a particular representative, the system could preserve that ownership.

This first version delivered two gains. It removed the routing decision from human memory and made rule changes visible in one place. It also allowed us to test the reliability of the core flow before expanding the system.

From routing tool to management system

Once the core routing flow became reliable, AMS took on a broader role. It no longer just distributed inquiries. It made the sales operation visible.

Over time, we added:

• Performance dashboards by country, representative, channel, source, and campaign
• End-to-end conversion tracking through Google Ads and CRM integration
• Integration and reporting for our Virtual Sales Assistants
• Automatic updates for most CRM stages
• Alerts and notifications for missing mandatory CRM fields
• Dashboards limited to each team lead's own team
• Daily summary reports delivered to executives by email

The same data then began supporting different decisions at different management levels. A team lead could see capacity and representative performance. Sales and marketing leaders could follow the path from campaign to CRM stage. Senior management could use daily summaries to notice where intervention was needed earlier.

This is where the technology produced operating value. AMS became a shared decision infrastructure for the sales operation rather than another data-entry interface.

Results and the limit of the evidence

The clearest before-and-after measurement we can disclose is routing performance:

• Routing moved from 5–15 minutes to real-time assignment.
• Routing accuracy rose above 99%, bringing errors close to zero.
• Routine manual distribution and control work was largely removed.
• Representatives could spend more time speaking with prospective patients instead of maintaining sheets.
• Team leads and executives gained real-time visibility into performance, capacity, and the conversion flow.

We also observed improvements in conversion, cost, and team efficiency. I am not publishing detailed before-and-after figures for those effects here. I therefore treat them as part of the system's broader operating impact, not as proof of a precise causal effect attributable to AMS alone.

My role in the project

I worked across the project, from defining the business problem and product scope to software architecture, development, and cross-functional coordination.

For me, the important part was larger than building a working algorithm. I was accountable for both the technical reliability of the system and its actual use in the sales operation. Those two responsibilities remained inseparable throughout the development of AMS.

The decision principle behind this case

For medical tourism lead management, the first question should not be, “Which CRM should we buy?” Start by examining the recurring decision itself:

• Which information changes the assignment decision?
• Is that information current and accessible?
• Who owns the decision when an exception occurs?
• How are delay and error measured today?
• Does the existing CRM execute the decision, or merely record its outcome?

In our case, the problem was not just missing technology. The decision itself was distributed across people. AMS created lasting value by making that decision explicit, manageable, and measurable before automating it.

For systems like this, the next area to evaluate may be the use of AI and machine learning in the reporting layer. The same threshold applies: Which management decision will a generated interpretation or forecast improve, and where will we see the result? Without a clear answer, more technology does not create a better operating system.