How a Digital Health Startup Cut Search Abandonment by 74% with a Conversational AI Provider-Matching Engine

The client is a Series B digital health company specializing in provider directory management and care navigation for regional health plans. The company manages roughly 85,000 provider records across two U.S. health plans, serving approximately 800,000 insured members through its web and mobile search platform.

Members searching for care on the client's platform faced a friction-heavy process. The search interface relied on dropdown menus and checkbox filters – specialty, insurance network, location radius – that required users to already know the clinical vocabulary before the system would return anything useful. A member with knee pain had to first determine whether they needed an orthopedist, a sports medicine physician, or a physical therapist before a single relevant result appeared.

The result: a 47% search abandonment rate. Internal data showed the median user session ended after fewer than three filter interactions. The product team had added a free-text keyword field in Q2 2023, but it performed string matching against provider bios, returning orthopedic surgeons for "knee pain" only when providers had written those exact words in their profiles.

The team had the domain knowledge to define what the system should do. They did not have the machine learning engineering capacity to build it.

The company's CTO found Cleveroad through Clutch while searching for AI development partners with healthcare domain experience. Two factors drove the decision. Cleveroad's portfolio included prior LLM integration work in regulated industries, which the CTO read as evidence of production readiness – not prototype capability. The engagement model also fit the budget constraints of a Series B company: Cleveroad proposed a fixed-scope discovery sprint before committing to full development, giving the leadership team a concrete deliverable to evaluate before signing off on the full budget.

Cleveroad built a conversational provider-matching engine that allows members to describe their health concern in plain language – "my lower back hurts when I sit for long periods" – and receive a ranked list of relevant providers in seconds.

The system extracts clinical intent from the member's input, maps it to structured search parameters (specialty, procedure codes, accepted insurance, geography), and queries the existing provider database. Results are returned with a short natural-language explanation of why each provider was selected, including specialties, accepting new patients status, and in-network confirmation.

Key components:

• Natural language intake layer that handles ambiguous and symptom-described queries
• Clinical intent extractor that converts symptom descriptions into structured specialty and procedure parameters
• Query construction module that translates parameters into database calls against the existing provider index
• Result-explanation layer that generates brief plain-language summaries for each returned provider

The solution integrated with the client's existing provider database and front-end application without changes to the underlying data model.

• Intake: Member submits a free-text query via web or mobile interface
• Parse: Query routed to a conversation service powered by a large language model
• Extract: LLM identifies clinical intent and produces structured parameters: specialty codes, procedure types, insurance filters, distance radius
• Retrieve: Parameters query the provider database via OpenSearch
• Explain: LLM generates a brief natural-language result summary with follow-up suggestions
• Validate: Automated test suite runs 1,200+ labeled healthcare scenarios daily; edge cases flagged for human review

Validation was built as a first-class requirement. Early testing revealed hallucination patterns when the model translated symptom descriptions into specialty codes – particularly for overlapping specialties such as neurology vs. pain management. A hybrid approach (LLM inference for initial mapping, deterministic rules for ambiguous overlaps) reduced specialty mismatches by 83% before launch.

• Foundation Model: Claude 3.5 Sonnet via Amazon Bedrock
• Search: Amazon OpenSearch Service
• API Layer: AWS API Gateway
• Backend: Node.js
• Cloud: AWS
• CI/CD: GitHub Actions

Search abandonment dropped from 47% to 12% in the eight weeks following launch – a 74% reduction. Appointment completion rates rose 18% over the same period, measured against the prior eight-week baseline.

The signal came early. Two days before launch, during an internal walkthrough, the VP of Product typed "my kid keeps getting ear infections" into the intake field. The system returned three pediatric ENT specialists – all in-network, all within 10 miles, each with an availability note. No dropdowns. No jargon. The screenshot circulated in the company Slack before the meeting ended.

The system now handles approximately 12,000 queries per week. Both health plan clients requested inclusion of this capability in their 2026 contract renewals.

The client is evaluating a second phase that extends the search experience to include appointment scheduling directly within the results, eliminating the current hand-off to a separate booking flow. The clinical intent extraction layer built in this engagement is already being repurposed to power automated provider directory quality checks – a use case that emerged from the data the system began generating at launch.