Trranu

The Problem

Medicare insurance agents spend a significant portion of every sales call looking things up manually — plan benefits, drug formularies, in-network providers — while the client waits on the line. Mistakes happen. Calls run long. Conversions drop.

The AEP (Annual Election Period) and OEP (Open Enrollment Period) windows are narrow. Agents need to move fast and with confidence.

What I Built

Trranu is a CRM and real-time decision tool built specifically for Medicare agents, combining data lookup, pipeline management, and AI assistance in one interface.

Core features:

• Plan comparison: Search and compare Medicare Advantage plans in real time, filtered by zip code, carrier, and coverage type
• Doctor verification: Confirm whether a specific physician is in-network for a given plan — one of the most common questions during calls
• Formulary checker: Verify drug coverage and tier levels before committing a client to a plan
• Medicare chatbot: An AI assistant (powered by Claude) trained on Medicare context — AEP/OEP windows, D-SNP eligibility, Medicaid tier interactions — available during the call so agents don’t break momentum
• Agency dashboard: Shared pipeline across agents, client history, and conversion statistics

Technical Decisions

The frontend is split between Vue.js (interactive CRM dashboard) and Astro (marketing and static content). This keeps the app bundle lean — agents load only what they need.

Claude API handles the Medicare chatbot. The key challenge was prompt engineering: Medicare has highly specific terminology, date-bound rules (AEP opens October 15, etc.), and eligibility nuances that vary by plan type. The system prompt encodes this context so the model stays accurate and confident even on edge cases.

PostgreSQL stores agency data, client records, and pipeline stages. The schema was designed to handle multi-agent access patterns — multiple agents at the same agency sharing a client view without conflicts.

AI at the Center of the Call

The chatbot is not a generic assistant. It’s a Medicare-domain agent that understands the specific situation an agent is in during an active call.

An agent can type or ask:

• “Does Plan X cover Dr. García, cardiologist, zip 33160?” — the AI cross-references the plan’s provider network and returns a yes/no with the in-network tier
• “My client has Type 2 diabetes and takes Metformin and Ozempic — which plans in Miami cover both?” — the AI queries formulary data, filters by zip, and ranks by out-of-pocket cost for those specific medications
• “She’s turning 65 in March, can she still switch during OEP?” — the AI answers with the correct eligibility window and any Special Election Period exceptions that apply

The recommendation engine combines the client’s stated priorities (keeping their doctor, minimizing premiums, specific drug coverage) and outputs a ranked list of plans with plain-language justification for each ranking. This is the closest thing to having a compliance expert on the call without paying for one.

What I Learned

Building domain-specific AI tools requires domain expertise first. I spent considerable time learning Medicare rules, carrier data structures, and the actual workflow of agents before writing a line of AI-related code. The prompting is only as good as your understanding of the problem.