(Case study · 01)
Clinora
I built Clinora to make the journey from enquiry to follow-up, appointment and recorded revenue visible. Every new enquiry gets an owner, a response clock and a next step, and the owner sees what is slipping and what it is worth while there's still time to act.
A self-initiated product, live in production and ready for a pilot, with no clinic onboarded yet, so no results are claimed. The clinic, patients and figures in the screens are fictional demo data; WhatsApp and Meta lead ads are built but not yet verified with a live account.
(Why I built this)
What happens after a clinic pays for an enquiry?
I wasn't interested in building another clinic dashboard.
What I kept coming back to was the part after the ad. A clinic pays for an enquiry from Instagram, a Facebook lead form, Google or WhatsApp. Then a price question gets answered hours later, a callback has no owner, a booked patient is never reminded.
And because nobody records how each enquiry ended, the owner can't tell a bad campaign from a slow reply. That felt like an operations problem, not a marketing one.
(The problem)
Where I thought the journey was breaking
Workflow reconstruction · drawn from the stages the product now tracks
- Meta lead ads
- Website
- Phone call
- Walk-in
- Referral
- EnquiryThe reply comes hours later
- Front deskNobody clearly owns it
- Follow-upCallback missed, no next step
- AppointmentBooked, never confirmed
- VisitNo-show, nobody recovers it
- RevenuePayment never linked back to the ad
(What I looked at)
What I wanted to understand
This part is a retrospective scan, written for this case study in October 2026 from public material. It isn't a record of research done before the build, so it doesn't pretend to be one.
- Meta lead ads
- What arrives with a lead, and what gets lost on the way? Every lead in Clinora keeps its source and campaign.
- WhatsApp Business Platform
- When may a clinic message someone first? Each lead records whether, and when, the person opted in.
- Clinic, CRM and WhatsApp tools
- What would a clinic otherwise use, and what is each built around? The scan below.
| Category | Example | What its public material centres on | My read, for a small clinic |
|---|---|---|---|
| Clinic software | Practo Ray | Appointments, medical records, billing and e-prescribing1 | Starts once a patient is booked. The enquiry before the booking isn't the centre. |
| General CRM | HubSpot | Rotating record owners through workflows; customisable deal stages2 | Powerful, but a clinic would build its own stages, response clocks and service values. |
| WhatsApp inbox | Interakt | A shared inbox: assign, reassign and auto-assign chats3 | The conversation is the unit. Whether it became a visit, and revenue, lives somewhere else. |
| Healthcare CRM | LeadSquared | Capture from many channels, distribution to agents, booking and reminders4 | The closest category. Its case studies describe call-centre dialer setups; its speed figures are vendor-reported. |
"My read" is my interpretation, not a feature audit. Sources are listed at the end of the page.
(What changed because of it)
Observation, decision, screen
Design hypotheses · each one is visible in the live product
Totals are easy to show. Exceptions are what an owner actually needs.
Open the dashboard on Needs attention, ordered by the estimated value at stake.
Owner dashboard
An estimate placed next to revenue gets read as revenue.
Revenue only when the team records a payment. Everything else says est.
"Configured average, not revenue"
Receptionists work between patients, on their phones.
One queue, each lead once, under its most pressing reason. One button.
Receptionist home
A visit booked outside the lead loses where it came from.
Book from the lead's page, so every visit stays attributed to its enquiry.
Appointments
(Information architecture)
How the product is organised
Today holds work, not reports. Reports sit under Insights, away from the things you act on.
A lead's history lives inside the lead as one timeline, instead of becoming another feed to check.
Settings hold the numbers that decide when a lead counts as late, quiet or at risk, so the clinic sets its own definition of "slipping".
Clinora
- Today
- Dashboard
- My work
- Leakage radar
- Inbox
- Tasks
- Appointments
- Leads
- All leads
- Lead page: contact · commercial · ownership · activity · next action
- Pipeline
- All leads
- Insights
- Reports
- Team
- Messaging costs
- Setup
- Automations
- Settings
- Response time · pipeline stages · branches and doctors · services and values · team and access · lead channels · WhatsApp and costs · audit log
- Help and guide
Four front doors, one product
- Owner Dashboard, radar, attribution, daily brief
- Receptionist Who to call next, inbox, today's appointments
- Manager Team, pipeline, automations, settings
- Viewer Reports, no edit rights
(Flows)
Four journeys the product has to get right
Taken from the product's own activity log and states
01 · New enquiry
- Source
- Lead created
- Owner assigned evenly
- First-call task
- 10-minute response clock
- First reply, or managers told
- Next step
02 · Appointment
- Qualified lead
- Booked from the lead
- Unconfirmed
- Confirmed
- Visited · no-show · cancelled
- No-show recovery
03 · Revenue
- Source and campaign
- Lead
- Appointment
- Visit
- Conversion recorded by the team
- Report by channel
04 · Leak
- Response missed · callback overdue · gone quiet
- Radar group
- One line on what to do
- Someone acts
- Off the radar
(Scope)
What made the first version, and what stayed out
I could have kept adding modules. But Clinora had one job: make the enquiry-to-revenue journey visible and actionable.
Adding medical modules would have made the product bigger, not clearer. Clinora holds contact and commercial details only, and even the note field asks the team to keep medical details out.
Must have
- An owner for every enquiry
- A response clock
- A next step on every lead
- The appointment lifecycle
- Source and campaign on every lead
- A leakage radar
- Walls between clinics
Built, still being proven
- WhatsApp and Meta lead ads: built, not yet verified with a live account
- AI reading of enquiries: built, switched off by default
Not in V1
- Diagnoses
- Prescriptions
- Clinical notes
- Pharmacy
- Insurance
- Telemedicine
(What didn't work)
The first dashboard was wrong
My first dashboard opened with eight number tiles of equal weight. It answered "what happened?" and pushed the owner's real question, "what needs me now?", below the fold.
I rebuilt it around exceptions: Needs attention first, ordered by what's at stake, the daily brief beside it, and the totals last.
Drawn for this case study, after the fact. They show the structure, not the original working files.
(Values)
What I refused to compromise
Action before reporting
The owner sees what needs attention before any chart.
Honest numbers
If a number is estimated, it looks estimated. "Replied 2 min late" stays grey; red "No reply" is kept for someone still waiting.
AI with boundaries
Everything works with AI switched off, the default for every clinic. The enquiry reading is rule-based, says so, and is never used for diagnosis or medical advice.
No medical overreach
Commercial and operational work only. No diagnoses, prescriptions or clinical notes.
Walls between clinics
One clinic must never see another's data, even if a check in the code is missed.
Real software
Roles, permissions, failures, edge cases and deployment included, not just the screens.
(Mood board)
Calm paper, sharp signals
A front desk is noisy enough. I wanted the product to feel like warm paper, not hospital white, with one deep green for action and colour kept for status: red only for someone still waiting, amber for a warning, green when it's done.
Assembled from the product's own colour tokens and screens
- Paper
#F6F5F1 - Ink
#15171A - Action
#0F4C45 - Still waiting
#B42318 - Warning
#8A5300 - Done
#1D6A3A - Sage
#8FE3C8 - Ember
#F08A6C
- Calm
- Exact
- Front-desk fast
- Honest about estimates
- Paper, not hospital white
(What I built)
A system that follows one enquiry all the way
I built a multi-clinic web app that follows an enquiry from first contact to appointment, visit and recorded revenue, with a phone view for the front desk, a marketing site, and a demo anyone can open.
- Lead ownership
- Response clock
- Next best action
- Appointments
- Leakage radar
- Source attribution
- Daily brief
- Automations
- Help in Hinglish, Hindi or English
The screens
A revenue-leak system for high-value clinics: every enquiry gets an owner and a response clock, the team always sees the next step, and the owner sees what is slipping and what it is worth.
(Up close)
The decisions, on the screen
12345
- Attention before analytics
- At risk, labelled as an estimate
- What each group is worth, "est. at stake"
- The brief is written by rules from the clinic's own records
- "They are not revenue": said once, under the list
123456
- The next step gets its own panel, above the history
- "No reply · 1d 4h late": how late, not just late
- Estimated value: "Configured average, not revenue"
- The note field asks to keep medical details out
- The score is explained line by line
- "Rule-based reading (AI off)": it says what it is
(System)
How it fits together
Every clinic's rows are walled off by the database itself, with row-level security in PostgreSQL, not only by checks in the code. The app runs under database roles that can't bypass those policies.
Simplified · drawn for this case study from how the product behaves
- Lead sourcesMeta lead ads · WhatsApp · website · Google · Instagram · phone · walk-in · referral
- IntakeLead created with source, campaign, service and branch
- AutomationsAssign evenly · first-call task · response clock · WhatsApp acknowledgement · manager alert
- WorkOwner, stage, tasks, next best action, activity timeline
- AppointmentsBranch hours and doctors · unconfirmed → confirmed → visited / no-show / cancelled
- RevenueConversions recorded by the team
- InsightLeakage radar · reports · daily brief written by rules
- Next.js · React · TypeScript
- PostgreSQL + Drizzle
- Row-level security · 134 policies
- Roles: owner · manager · receptionist · viewer
- Audit log
- Vercel
Simplified data model · reconstructed from the product's screens, names simplified
- Clinic
- Branches · doctors · hours
- Members · roles
- Services · average values
- Pipeline stages · win probabilities
- Automations · audit log
- Lead source · campaign · service · branch · owner · stage · score
- Activity timeline
- Tasks
- WhatsApp messages · opt-in
- Appointments
- Conversions (recorded revenue)
(States)
Beyond the happy path
Each of these is a real state in the live demo
- Nobody has repliedRed "No reply" with how late it is. Managers are told when the response target is missed.
- Replied, but late"Replied 2 min late" in grey. Late isn't the same as ignored.
- Several problems at onceA lead counts once on the radar, under its most pressing reason.
- New, not yet at riskUntouched enquiries sit on a watch list until their clock runs out.
- Interested, no next stepEngaged leads with no task and no appointment get their own group.
- Booked, not confirmedUpcoming bookings still waiting for confirmation get their own group, with a line on what to do.
- No-showMissed appointments with no new booking become something to recover.
- No WhatsApp opt-inThe lead says "No opt-in recorded", so nobody messages them first.
- AI switched offThe default. The enquiry reading falls back to rules and says so.
- Read-only partnerA viewer sees reports without edit rights.
- Clear queue"Your queue is clear", and today's appointments, instead of an empty table.
- Demo visitorsEach gets a private copy of a fictional clinic, deleted after 24 hours. Nothing reaches a real person.
(Testing)
What I didn't want to leave to chance
I audited every screen in a real browser and fixed what was unclear before adding anything new.
Then I ran the full browser suite against production, on its own database, through the same invite-only path a clinic uses. It caught two things local runs hadn't: a back door in invite-only sign-up, and a demo refill that timed out. I fixed both with a test first.
- Automated tests
- 194, with 14 run against the live site
- Database policies between clinics
- 134, under roles that can't bypass them
- Bugs the live run caught
- 2, each fixed with a failing test first
(What I learned)
Clinora changed how I think about dashboards. The best one isn't the one that shows the most. It's the one that makes the next decision obvious.
(Sources for the category scan · checked October 2026)
- Practo Ray features as listed by Capterra and SoftwareSuggest (third-party listings): capterra.com/p/167778/Ray
- HubSpot Knowledge Base, "Assign and rotate record owners using workflows": knowledge.hubspot.com; HubSpot deal pipeline: hubspot.com
- Interakt help, "Shared team inbox: assigning and reassigning chats": interakt.shop
- LeadSquared healthcare pages and a published customer case study: leadsquared.com/healthcare, case study
Need something like Clinora?
Tell me what you want to build. I'll reply with how I'd build it, a rough timeline and a cost range. Free, and no obligation.
Next project
Pitwall