Phoenix Revenue Intelligence Implementation: A Step-by-Step Guide for Indian Clinics

Phoenix is ICG's revenue intelligence overlay above any existing PMS. The product page covers what Phoenix does (Phoenix product page). This article covers the implementation process — what actually happens during a Phoenix deployment, what the clinic team experiences, and what the outcomes look like at each milestone.

Across 46+ centres for a national chain plus standalone deployments, the implementation timeline has stabilised at 4 weeks from kickoff to first action queue. The structure matters because most "revenue intelligence" products promise outcomes but fail in implementation — the data doesn't flow, the team doesn't use the queues, and within 60 days the deployment is shelfware.

angryturtle/13-weekly-tasks.png" alt="Angryturtle Weekly Tasks — prioritised action queue per listing, week by week" loading="lazy" decoding="async" style="width:100%;height:auto;display:block;">

Week 1: Discovery + PMS integration

Day 1-2: Operational diagnostic

ICG's implementation team meets with clinic leadership for a structured operational diagnostic:

• Current PMS (HealthPlix, MocDoc, Practo Ray, Zenoti, Genamet, Bahmni, custom)
• Patient volume (monthly, by specialty, by location)
• Retention patterns (what does churn look like? what does it cost?)
• Payment plan structures (single-procedure, packages, EMI)
• Team structure (who would action the daily queue?)
• Existing CRM (if any)

Output: a configured Phoenix scope document covering which of the 5 action queues will be live in week 1 vs phased in later.

Day 3-7: PMS integration build

Engineering team builds the PMS-to-Phoenix data pipeline:

For PMSs with API (HealthPlix, MocDoc, Practo Ray, Zenoti, Genamet):

• API authentication setup
• Entity mapping (patients, visits, appointments, billing, treatment plans)
• Incremental sync schedule (typically every 4-6 hours)
• Data validation rules
• Error handling + alerting

For PMSs without API (Bahmni via OpenMRS, custom builds):

• OpenMRS REST API for Bahmni
• Scheduled CSV export for custom builds (24-hour data freshness)
• Data validation + reconciliation

End of Week 1: Phoenix has live data flowing from the PMS into the Phoenix data layer.

Week 2: Action queue configuration + team identification

Day 8-10: Action queue configuration

Phoenix's 5 action queues are configured for the specific clinic context:

Queue 1 — Prevent Loss. Configured with specialty-specific churn signals:

• Aesthetic: package-session gap exceeding 90 days
• Dental: cleaning recall window exceeding 6 months
• Hair transplant: 3-month follow-up window open + no contact
• IVF: cycle stage stall

Queue 2 — Maintain and Engage. Configured with active-treatment touchpoint cadence:

• Aesthetic mid-package check-in
• Orthopaedic rehab compliance check
• IVF cycle medication adherence
• Oncology survivorship follow-up

Queue 3 — Grow Revenue. Configured with cross-procedure CLTV signals:

• LHR patient at session 4/6 — HydraFacial candidate
• Botox patient at 5-month mark — filler conversation
• General dental — orthodontic consult candidate
• IVF complete — second-cycle planning candidate

Queue 4 — Win Back. Configured with lapsed patient thresholds + CLTV scoring.

Queue 5 — Reactivate Failed Payment Plans. Configured with payment plan churn rules.

Day 11-14: Team identification + role mapping

Phoenix queues are only useful if someone actions them daily. ICG's implementation team identifies:

• Which team member owns each queue
• What's their daily cadence (10 AM standup? End of day?)
• What's the escalation path for queues with stuck patients
• What's the closed-loop reporting (did the team intervene? what happened?)

Most clinics initially try to assign all 5 queues to one telecaller. ICG's recommendation: split by queue type. Queue 1 (Prevent Loss) goes to senior coordinator. Queues 2-3 (Maintain/Grow) go to specialty telecaller. Queue 4 (Win Back) goes to a dedicated win-back specialist. Queue 5 (Payment Plans) goes to billing team.

Week 3: Pilot run + reconciliation

Day 15-17: Soft launch with reconciliation

Phoenix goes live with the first 2 action queues (Prevent Loss + Maintain/Engage). The assigned team members start actioning the queues. Daily reconciliation meeting with ICG implementation team:

• What did the queues surface today?
• Did the team intervene?
• What was the patient response?
• Are the queue rules calibrated correctly (too sensitive? not sensitive enough?)?
• What's missing?

This is the critical week — most implementations fail here because the rules need refinement and most vendors leave the clinic to figure it out alone. ICG's hands-on reconciliation prevents that.

Day 18-21: Add remaining queues + integration with Nexus CRM

Queues 3, 4, 5 go live. If the clinic uses Nexus CRM, Phoenix queues are routed into Nexus as auto-generated leads with full context. If not, Phoenix sends queue items via WhatsApp notifications to assigned team members.

Week 4: Optimisation + training reinforcement

Day 22-25: Performance review + rule tuning

By Week 4, Phoenix has surfaced 200-500+ patients across the 5 queues. The team has actioned a meaningful sample. ICG conducts a performance review:

• Which queues produced the highest intervention success rate?
• Where are the false positives (queue surfaced a patient but intervention was inappropriate)?
• Where are the false negatives (patients who should have been surfaced weren't)?

Rules are tuned based on real intervention outcomes.

Day 26-28: Client Alleviation Programme training

The team running Phoenix queues gets structured training via Client Alleviation Programme:

• How to read a Phoenix queue
• How to action different queue types
• How to escalate stuck patients
• How to record intervention outcomes
• How to interpret the weekly performance report

End of Week 4: Phoenix is operational, the team is trained, and outcomes are measurable.

What outcomes look like at milestones

End of month 1 (deployment complete):

• All 5 queues operational
• Team actioning queues daily
• Initial intervention pattern emerging

End of month 3:

• 22-35% lift in patient retention
• 18-28% reduction in payment plan churn
• ₹3-8 lakh/month in recovered stale revenue at median deployment

End of month 6:

• Compounding effects visible
• Specialty-specific queues fully calibrated
• Team capability matured
• ICG quarterly calibration session refines targets for next quarter

End of month 12:

• Mature Phoenix operation
• Year-over-year retention metrics show structural improvement
• Phoenix has paid for itself many times over via recovered revenue

Related reads

• Phoenix product page
• Clinic revenue intelligence — why your PMS records but cannot tell you what to do
• Practice Management Software India pillar
• HealthPro 360
• Client Alleviation Programme