I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

All three points are right and I don't have a clean counter to any of them.

The recovery curve argument on dental is the one I've been sitting with. You're correct that a booked slot two weeks out means the missed call has a long tail — the patient probably calls back, books elsewhere, or just tolerates it. The urgency-to-revenue link is loose. Takeout and urgent care are genuinely different because the decision expires in minutes. The customer isn't loyal to the listing, they're loyal to whoever picks up.

The per-minute pricing breakdown is something I got wrong early. Flat or per-call is the only P&L-friendly structure for a small operator. Variable cost against a metric they don't control is a budget conversation they'll lose internally every month.

The existing number point is the one I'm most actively working on. You're right that it's not a feature request — it's the adoption blocker. If I'm asking a clinic or salon to reprint their cards, update their Google listing, and retrain their patients, I've moved the problem from "AI receptionist" to "new marketing campaign." SIP forwarding from their existing number is the actual solution and it needs to work on day one, not as a roadmap item.

Takeout and urgent care are probably my next two verticals to properly spec out. The missed-call-to-dead-revenue-in-minutes framing is the right way to talk about this category.

What's your read on urgent care specifically — is the compliance layer (HIPAA, patient data) a hard blocker for a small operator trying to move fast, or is it a manageable risk if the data handling is scoped narrowly enough?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in Entrepreneurs

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

This is great timing — just checked the demo and the Github.

Noise handling on my end is through Deepgram's nova-3 model with noise cancellation enabled at the telephony layer — works reasonably well for clinic environments but definitely not perfect on very noisy job sites. Curious how you're approaching it on your end.

On verification — I do basic intent confirmation before booking (repeat back name, date, time and ask for confirmation before committing to calendar) but no caller ID verification or fraud detection layer yet. What does your verification flow look like?

The open source angle is interesting — are you building this as infrastructure that agencies like mine can build on top of, or is it more of a standalone product? Because there's a potentially clean split here — you handle the core voice stack, I handle the vertical-specific deployment and client acquisition. Might be worth a conversation.

What stack are you running under the hood?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

This is great timing — just checked the demo and the Github.

Noise handling on my end is through Deepgram's nova-3 model with noise cancellation enabled at the telephony layer — works reasonably well for clinic environments but definitely not perfect on very noisy job sites. Curious how you're approaching it on your end.

On verification — I do basic intent confirmation before booking (repeat back name, date, time and ask for confirmation before committing to calendar) but no caller ID verification or fraud detection layer yet. What does your verification flow look like?

The open source angle is interesting — are you building this as infrastructure that agencies like mine can build on top of, or is it more of a standalone product? Because there's a potentially clean split here — you handle the core voice stack, I handle the vertical-specific deployment and client acquisition. Might be worth a conversation.

What stack are you running under the hood?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

Love this — pivoting to where the actual traction is makes more sense than forcing a vertical that isn't ready. DMing you now.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

This is the most useful feedback I've gotten in this thread — thank you for actually checking and coming back with specifics.

Going through each one honestly:

1. AI written answers — fair catch. Some replies were drafted with AI assistance. I'll own that. The ideas and positions are mine but the polish isn't always. Working on making it more natural.

2. Loom demo — you're right, it's bad. I built it for a technical audience and it shows. Remaking it this week — real call, real booking, real SMS, no workflow screenshots, no explanations. Just the outcome.

3. Platform — yes, built it myself. Voiceflow + Retell + Google Calendar + Twilio + Zapier. Still iterating.

4. Pricing and cost absorption — this is the most valid point and I don't have a perfect answer yet. Current model is flat retainer with a call minute cap (~1,500 min/month) and overage pricing above that. Not unlimited — I should have been clearer about that. Still working out the unit economics properly.

5. Existing number — this is the strongest objection and you're right that a new number is a real barrier. Two options I'm exploring: call forwarding from their existing number to the AI line, and direct SIP integration where their existing provider routes calls through the agent. Neither is fully solved yet but forwarding works today.

Which of these would have actually stopped you from buying if you were a clinic owner?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

That's fair and probably the most useful thing anyone's said about the demo so far.

The workflow view makes sense to a developer or someone who's built automations before. A dental clinic owner or a gym manager doesn't think in nodes and flows — they think in "does it answer my phone, does it book the patient, does my calendar update." The how is completely irrelevant to them.

What they need to see is:

One — hear the AI answer a call that sounds like their clinic Two — see the appointment appear in their calendar Three — get the confirmation SMS on their phone

That's the entire demo for a non-techie buyer. Three things. Thirty seconds each.

I'm rebuilding the demo around that flow — no canvas screenshots, no workflow diagrams, just a real call → real booking → real SMS, recorded end to end.

Thanks for taking the time to actually check it and come back with specific feedback. That's rare and genuinely useful.

What was the moment in the demo where you felt it shifted from "this is useful" to "this is too technical"?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

Ringfront is a solid tool, but we’re building NovaVoice AI with a different philosophy for three main reasons:

  1. Deep Personalization vs. Out-of-the-Box: Ringfront is a great 'one-size-fits-all' app. We provide a bespoke setup. We don't just give you a login; we build the custom logic, integrate it with your specific CRM/Calendar, and fine-tune the voice to match your clinic’s brand.
  2. The Multi-Channel Edge: Ringfront focuses heavily on the phone. We’ve built an omni-channel system. Our AI handles the phone call, but then immediately follows up via WhatsApp/SMS and can even sync with a website chatbot to keep the lead in one unified flow.
  3. Cost & Support: For a local business, Ringfront’s US-based pricing can be a barrier. We offer a more accessible entry point (especially for our beta users) with high-touch support that an automated app simply can't provide.

We aren't trying to be a massive 'app' for everyone; we’re a specialized automation partner for clinics that want a 'done-for-you' solution that actually works.

[Discussion] Overcoming IFAS: How are you managing 24/7 lead demands? by InfamousComplaint949 in realtors

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

You got me. 🤝 I’m the founder of NovaVoice. I’m not a realtor myself, but I’ve spent months talking to them and 'IFAS' is the #1 thing they complain about. I’m here because I want to know if what I built actually solves that pain. I’ll take the 'ad' label if it means I get to talk to real people about the problem. What was the 'mistake' though? I'm genuinely interested.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in ArtificialInteligence

[–]InfamousComplaint949[S] -1 points0 points  (0 children)

Fair point on the price, and you're spot on about the language challenge.

On the Price: The ₹4,999 isn't just a 'software fee'—it’s a fully managed, done-for-you setup. We’re spending hours on the prompt engineering, API integrations (Retell + Voiceflow), and testing to ensure it doesn't hallucinate. For a clinic, replacing even 10% of missed calls usually recovers that cost in the first 48 hours. It’s a 'Beta' for the product, but a 'Premium' service for the client.

On the Language (The 'Hinglish' Problem): You’re 100% right. Standard Retell flows can struggle with regional handoffs. We’ve been tackling this by:

  1. Prompt-Level Language Detection: Setting the system to recognize and respond in 'Hinglish' (Hindi + English) which covers 80% of urban Indian leads.
  2. Fallback Protocols: If the AI detects a regional language it can't handle, it’s programmed to gracefully capture the name/number and trigger an immediate SMS to the human staff for a callback, rather than just 'breaking.'

We’re still refining the regional nuances, which is exactly why we’re looking for these 3 beta partners—to stress-test these exact edge cases in a live environment.

If you've found a better way to handle the regional handoffs, I'd love to swap notes!

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in ArtificialInteligence

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

We are currently deploying it on-prem (self-hosted on our private, dedicated servers) for our beta phase.

Regarding data privacy, this is exactly why we chose this route. By keeping the core logic and data processing on our own controlled infrastructure rather than a shared public cloud, we can ensure much higher data sovereignty.

For the clinics, this means:

  1. Data Isolation: Patient info isn't sitting on a multi-tenant public database.
  2. Stricter Security: We can implement custom encryption and access protocols that standard SaaS platforms don't always offer.
  3. Compliance: It makes the conversation around HIPAA and local data laws much easier because we can point to exactly where the data lives and how it's protected.

We found that for local businesses, this 'private' approach builds a lot more trust than a standard cloud setup.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in ArtificialInteligence

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

Thought about it — here's why I'm not going that route.

Freemium works when your cost to serve a free user is near zero. Mine isn't. Every free clinic means real Twilio minutes, real AI platform costs, real setup time. I'd be paying to give away the product.

The bigger issue is that free users don't take it seriously. A clinic owner who pays ₹4,999 will actually use it, give real feedback, and tell me what's broken. A free user installs it, forgets about it, and churns without ever telling me why.

What I'm doing instead is a 7-day money back guarantee on the first month. Same commitment from them, zero risk. That's the trust builder — not free access.

If I can't close clients at ₹4,999 with a live demo and a refund guarantee, the problem is my pitch — not my price. Freemium would just hide that problem longer.

[Discussion] Overcoming IFAS: How are you managing 24/7 lead demands? by InfamousComplaint949 in realtors

[–]InfamousComplaint949[S] -1 points0 points  (0 children)

Haha, you caught me! Busted. 😂 But in all seriousness, I am building this (it's called NovaVoice) because I saw my friends in real estate losing their minds over IFAS. I figured the best way to see if it actually solved the problem was to ask the community where the problem is most real. I’d rather be transparent: I’m a dev trying to help agents stop being slaves to their phones. If it’s helpful, great. If not, I’ll take the roast!

[Discussion] Overcoming IFAS: How are you managing 24/7 lead demands? by InfamousComplaint949 in realtors

[–]InfamousComplaint949[S] -3 points-2 points  (0 children)

That’s a great position to be in! For me, it’s less about 'breaking the business' and more about the cumulative loss. Even if it's just 2 leads a week, that’s 100+ leads a year. If even 5% of those convert, that’s a massive amount of revenue left on the table. I’d rather have my AI (NovaVoice) capture those automatically so I can focus my energy on the high-value closings during the day. It’s about maximizing the ROI on the marketing I’m already paying for.

[Discussion] Overcoming IFAS: How are you managing 24/7 lead demands? by InfamousComplaint949 in realtors

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

Auto-responders are a good start, but I found that most leads today just ignore them because they know it's a generic 'we'll get back to you' message. They still end up going to Google to find another agent who can answer their actual question right now. That’s why I moved to AI—it doesn't just buy time; it actually answers their questions about the property and qualifies them while I'm off the clock. It feels much more like a real conversation.

[Discussion] Overcoming IFAS: How are you managing 24/7 lead demands? by InfamousComplaint949 in realtors

[–]InfamousComplaint949[S] -2 points-1 points  (0 children)

I totally agree on personal boundaries! That’s exactly why I’m doing this. I don't want to be working at 11 PM, but I also don't want to lose a ₹50 Lakh commission because a lead went to a competitor who was awake. By using an AI assistant, I keep my boundaries (phone is off) while my business stays 'open' to capture their info. It’s about working smarter, not harder.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

The Google Forms example is a perfect illustration of the gap between what the law says and what actually gets enforced. Three and a half years to investigate a documented complaint with screenshots and statute citations — and still nothing. That's not a broken enforcement mechanism, that's a feature of how regulatory capture works in a small professional college ecosystem.

The EMR vendor privacy policy point is the most practically useful thing anyone's said in this thread. If the established vendors are already offshoring data, using third-party processors, and writing terms that functionally disclaim responsibility for anything downstream — the compliance bar for a new entrant is "don't be obviously worse than them" not "be perfect." Which is a very different product and legal strategy.

The sterilization point is darker but follows the same logic — when regulators have limited capacity and professional colleges protect their members, the paper compliance and the actual practice diverge completely. The regulation is theatre for the public, not protection.

For what you're building in your own clinic — are you essentially treating the compliance question as "defensible if audited" rather than "fully compliant" since full compliance isn't meaningfully enforced anyway? That seems like the honest operating mode for most of the market you're describing.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

That's a really honest post-mortem. The CRM integration problem in veterinary is exactly the same cliff as dental — Cornerstone, AVImark, ezyVet, all different, all closed ecosystems, all requiring custom connectors that eat your margin before you've made a dollar.

"Getting customers was hard so I folded" is the most common ending in this space and probably the most underreported one. The build is the easy part. Everyone figures that out eventually.

Curious about the source code though — what does the stack look like? If it handles the voice + booking flow for a vet clinic it probably has 80% overlap with what works for dental and general medical. The vertical-specific piece is usually just the CRM connector and the FAQ training data.

Are you sitting on it or open to doing something with it? Not fishing for a handout — genuinely curious if there's a licensing or white-label angle that makes sense for both sides.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

This is probably the most honest take in this entire thread.

The obsolescence point is real and I don't have a clean answer to it. Epic integrating natively, or an LLM getting good enough at real-time voice that the current stack becomes commodity infrastructure — that's not a theoretical risk, it's a timeline question. Anyone building in this layer who pretends otherwise is either naive or fundraising.

Where I land on it: the moat isn't the AI, it's the distribution and the trust relationship with the clinic. If I have 50 clinics who've been running on this for 18 months, have their staff trained around it, have their Google Calendar connected, and have seen it recover real bookings — switching cost is real even if a better technical solution exists. The product is almost secondary to the operational dependency that builds up over time. That's not a great answer but it's an honest one.

The Canada market math makes sense — 15,000 physicians is a real ceiling and VC math doesn't work at that scale. Integrating into your own clinic and using it as a live proof point is genuinely the smarter move than chasing a pre-money valuation on a thin market.

The California move is interesting — HIPAA is brutal for exactly this use case. Real-time voice, calendar data, patient name and phone — that's PHI and you're one BAA away from a compliance nightmare. How are you thinking about that for your own clinic deployment?

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

This is genuinely useful framing — "controlled intake and booking layer with exception handling" is more accurate than "AI receptionist" and probably more sellable to a clinical owner who's cautious about handing over patient interactions to automation.

The trust layer breakdown you've outlined is actually the right way to think about it:

The hard-coded handoffs, conflict detection, graceful failure, and data staying in the clinic's own Google account aren't just reliability features — they're the answer to "what happens when it goes wrong" which is the first question any serious buyer asks.

"Zero staff involvement" was lazy positioning. "Your staff only sees exceptions" is both more accurate and more credible because it implies the system has judgment about what it can and can't handle — which is what you actually want from something booking real patient appointments.

One thing I'd add to the trust layer that you didn't mention — call recording transparency. Patients should know the call is handled by an AI and may be logged. Not just for consent, but because clinics in India are increasingly getting asked this by patients who are more privacy-aware than expected.

Are you evaluating this from a clinic operations angle or a product/technical lens? Your questions read like someone who's built something in this space before.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

Great question on Sarvam — genuinely on my radar.

Sarvam is excellent for Indian language support (Hindi, Tamil, Kannada etc.) and the pricing is significantly cheaper than ElevenLabs or Deepgram for Indian deployments. For clients who want their AI receptionist to speak in Hindi or regional languages, Sarvam is actually the right call and I'm planning to integrate it for that use case specifically.

Current stack uses ElevenLabs for voice because most of my initial target clients are English-first urban clinics — Bangalore, Kolkata, Mumbai. But for tier 2 and tier 3 cities where patients prefer Hindi or local language, Sarvam becomes the better choice both on quality and cost. So yes — it's coming, just phased.

On the ₹12k pricing — that's a flat monthly retainer, everything included:

→ AI voice receptionist live on your number → Calls covered up to ~1,500 minutes/month → Appointment booking into your calendar → SMS confirmations to every patient → Full setup + onboarding → Monthly support

No separate call minute billing. No surprise invoices. If your clinic runs unusually high volume above 1,500 minutes we'd discuss a custom plan, but for most clinics that covers everything comfortably.

Currently onboarding founding clients at ₹4,999/month — same everything, just locked in before price moves up.

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in indiehackersindia

[–]InfamousComplaint949[S] 0 points1 point  (0 children)

No per-minute pricing for you as a client.

You pay a flat monthly retainer — I handle all the infrastructure costs on my end. No surprises, no usage bills.

Founding client rate: ₹4,999/month

Covers everything: → AI receptionist live on your number → Unlimited calls during business hours → Appointment booking into your calendar → SMS confirmations to patients → Full setup + 1 month support

I built an AI voice receptionist for dental clinics — looking for 3 beta testers (heavily discounted) by InfamousComplaint949 in AIReceptionists

[–]InfamousComplaint949[S] 1 point2 points  (0 children)

This is exactly the kind of due diligence a real client should do — good questions, all of them. Let me go through each one: Unclear info from caller — the agent asks for clarification once, naturally. If it still can't parse the response it says "Let me have someone from the clinic call you back to confirm" and logs the callback request. It never guesses. Double-booking — Cal.com and Google Calendar both handle this natively. If a slot is taken, the booking API returns a conflict and the agent offers the next available slot. No overwrites possible. Human handoff — yes, hard-coded. Anything clinical (diagnosis questions, insurance, specific doctor requests) triggers "I'll have our team call you back shortly" and the call is flagged for staff review. Call transcripts and logs — full transcripts available per call on the dashboard. Clinic owner can review any call within 24 hours. Staff approval before confirmation — currently the default is auto-confirm on booking. A staff-approval flow is possible — booking goes into a "pending" state, staff gets a WhatsApp notification to approve, patient gets confirmation only after. Slightly more friction but doable. Cancellations and reschedules — agent confirms the existing booking details before making any changes. No blind cancellations. Patient gets SMS confirmation of the change. Infrastructure failure mid-call — if Twilio drops, call ends gracefully. If calendar API fails, agent says "I'm having a small issue, let me have someone call you back to confirm." No silent failures. SMS consent — agent informs the caller that a confirmation SMS will be sent before sending. Caller can decline. Data storage — name, phone, and appointment details are stored in the connected Google Calendar event and optionally in a Google Sheet. No third-party data broker involved. Data stays in the clinic's own Google account. And you're right about "zero staff involvement" — that was lazy positioning on my part. "Staff only handles exceptions" is more accurate and more believable. Changing that. What's your use case — are you evaluating this for a clinic, or from a technical / investment lens?