Concern from a long-time individual Heidi subscriber — pattern of degradation + how feedback is being handled
A
Andrew Jun
Posting in case other individual clinicians are seeing the same pattern. Sharing both the substance of feedback I recently submitted to Heidi and how it was handled by support — because the handling itself is part of the story.
Context
Canadian GP Derm in Calgary, four clinics, multiple EMRs. Early Heidi adopter — back when the Canadian landscape was still wide open and most colleagues were trialing different vendors. For 1.5+ years I've actively recommended Heidi across the clinical roles I hold and to colleagues at every clinic I work in.
The last two months have been a real disappointment, and the price increase has sharpened it.
What I wrote to Heidi
Strategic feedback, not a bug report. Substance:
Heidi has been expanding rapidly over the past year — Comms, Evidence, Remote, the AutoMedica acquisition, Athena and Epic integrations. The strategic direction toward enterprise health systems is clear. They're building a platform.
The problem is what's happened to the core scribe experience for individuals during this expansion:
– Reliability has noticeably degraded over the past 1–2 months. Glitches, stalls, and restarts are daily.
– The tasks sidebar has become unreliable enough that I've stopped relying on it.
– Default template resets between clinics are delayed by hours, requiring manual selection on every encounter regardless of restarts.
– Schedule upload is now a regular error source. Appointment times routinely get misinterpreted — a 2pm slot parsed as 2am — with no apparent PM default and no batch-correction option. The only fix is opening every session individually, which defeats the feature.
– Note generation lag has shifted from background to active friction point.
– New bug categories surface week over week.
Cumulative cost: 30–45 minutes of dead time and active friction per day.
Meanwhile, the Clinician plan went from $90 to $150/month. That price was reasonable when the product was snappy. It is not reasonable for the current experience.
The strategic point: individual clinicians aren't just a smaller customer segment — we're the recommendation pipeline into the organizations Heidi's enterprise strategy depends on. When solo clinicians stop recommending Heidi, warn colleagues, and migrate to alternatives, that has a downstream effect that won't show in dashboards for several quarters.
Two asks: public acknowledgment with a credible timeline, and reconsideration of the $150 individual tier until value is restored.
How support responded
– Conditional apology ("sorry
if
you experienced some issues")– Request that I now collect screen recordings, session IDs, and consultant-level technical documentation for engineering
– Pricing routed to "feedback we'll make sure the team hears"
– Generic closing reassurance
Nothing engaged with the substance.
Why this matters
I'm a practicing physician. My time bills at physician rates. Between dead time over two months plus the unpaid work of providing strategic feedback to help Heidi improve, I've absorbed thousands of dollars in lost productivity at typical Canadian dermatology billing rates — while paying $150/month for the subscription.
The support response asked me to spend additional unpaid hours collecting documentation that should be reproducible from Heidi's own systems given the multiple help tickets I've already filed. Session metadata, device logs, ticket history — it's there. If that's not enough for engineering to identify the issues, the gap is on Heidi's end. It is not a documentation task to delegate to a paying physician customer who has already absorbed real economic cost from the product's failures.
The original feedback wasn't a bug report. It was strategic feedback. It was handled like a low-priority bug report.
The handling itself confirms the thesis: individual clinicians have become a deprioritized segment. The same dynamic eroding solo clinician
experience
is now eroding solo clinician support
experience. Raising this as data, not complaint.Open question for other users
– Reliability degradation over the last 1–2 months — widespread, or am I in a worse-luck cohort?
– The schedule-import time misinterpretation bug — anyone else?
– Support handling — is anyone getting strategic feedback escalated to product, or is everyone getting the "send screen recordings" routing?
If I'm an outlier, I'd like to know. If I'm not, worth surfacing collectively.
— Andrew Jun, MD
Calgary, AB
A
Andrew Jun
Appreciate the more substantive response — it's a meaningful step up from the support-ticket handling.
That said, I'm not going to engage with the questions, and I want to be clear why.
The original post already contained reproducible substance:
–
Schedule import:
defaults to AM when it should default to PM (2pm parses as 2am). Reproducible from any user uploading a PM-heavy schedule. Doesn't require my screenshot to identify.–
Template reset delay:
persists for hours across clinic-context switching regardless of restarts or settings resets. Help tickets filed; moved to manual workarounds.–
Stalls/restarts:
present enough that I've moved most work from mobile to web with a wired mic and local wifi. The workaround itself is information.The request for browser specifics, network correlations, time-of-day patterns, and screenshots — even framed gently — is still asking me to assemble triage documentation that engineering should be able to reproduce from session logs and the help tickets already filed. The shape of the ask hasn't changed; only the wrapping has.
This is the same dynamic the original post was about: individual clinicians being treated as the data-collection layer for a paid product. I've absorbed thousands of dollars in lost productivity to the underlying issues. More unpaid documentation work, in exchange for an unspecified "we'll route this," isn't a trade I'm making.
So: no further documentation, screenshots, or input from me. The substance is in the original post. If the routing results in actual product changes, that will be visible in the product. If not, that will also be visible.
A genuine question for other forum users:
when you've raised reliability or workflow issues here, how has "we'll share this with product and support leads" actually resolved? Does it translate into visible product changes, or die in queue? Other clinicians' experience would be useful data for the broader question my original post was really asking — whether individual-clinician feedback at Heidi gets traction.— Andrew
Heidi Team
Andrew Jun Thanks for taking the time to write this up — it’s thoughtful, specific, and really important context (especially the point about individual clinicians being the recommendation pipeline).
You’ve raised two things here: (1) a clear pattern of reliability/workflow degradation (stalls/restarts, tasks sidebar, template resets, schedule import time parsing, note lag), and (2) how your strategic feedback was handled. We’re going to share both with the product + support leads so it’s not treated as “just another ticket.”
To help us route this to the right owners with the clearest signal, could you share a bit more detail on 2–3 items?
1) For the schedule upload time issue (2pm → 2am): what format/source is the schedule (CSV upload, calendar sync, EMR export), and does it happen across all four clinics/EMRs or only specific ones?
2) For the template reset delays: are templates tied to clinic/workspace, browser profile, or login? And roughly how often do you switch clinics in a day?
3) On reliability (stalls/restarts): is it happening in a specific browser (Chrome/Safari/Edge) and does it correlate with longer sessions, specific clinic networks, or certain times of day?
If you’re willing, a single screenshot of the schedule import showing the misread times (with any patient identifiers removed) would be hugely helpful — but totally hear you on not wanting to do “consultant-level” logging.
Appreciate you raising this as data, not just a complaint. We’ll make sure it’s seen by the right people.
A
Andrew Jun
Heidi Team Appreciate the more substantive response — it's a meaningful step up from the support-ticket handling.
That said, I'm not going to engage with the questions, and I want to be clear why.
The original post already contained reproducible substance:
–
Schedule import:
defaults to AM when it should default to PM (2pm parses as 2am). Reproducible from any user uploading a PM-heavy schedule. Doesn't require my screenshot to identify.–
Template reset delay:
persists for hours across clinic-context switching regardless of restarts or settings resets. Help tickets filed; moved to manual workarounds.–
Stalls/restarts:
present enough that I've moved most work from mobile to web with a wired mic and local wifi. The workaround itself is information.The request for browser specifics, network correlations, time-of-day patterns, and screenshots — even framed gently — is still asking me to assemble triage documentation that engineering should be able to reproduce from session logs and the help tickets already filed. The shape of the ask hasn't changed; only the wrapping has.
This is the same dynamic the original post was about: individual clinicians being treated as the data-collection layer for a paid product. I've absorbed thousands of dollars in lost productivity to the underlying issues. More unpaid documentation work, in exchange for an unspecified "we'll route this," isn't a trade I'm making.
So: no further documentation, screenshots, or input from me. The substance is in the original post. If the routing results in actual product changes, that will be visible in the product. If not, that will also be visible.
A genuine question for other forum users:
when you've raised reliability or workflow issues here, how has "we'll share this with product and support leads" actually resolved? Does it translate into visible product changes, or die in queue? Other clinicians' experience would be useful data for the broader question my original post was really asking — whether individual-clinician feedback at Heidi gets traction.— Andrew
Mounir from Heidi
Andrew Jun: Andrew, I am Mounir, the Product Manager of our Models Team.
I have spent time reading your strategic feedback and every single interaction that led up to the dissatisfaction voiced in the above thread.
I will preface by saying this: at Heidi we do not discount the value of our individual clinicians. The success of our product has been fundamentally driven by critical feedback, engagement and feature requests like yours, which allowed us to build a product that is effective and interactive. A development towards enterprise-scale should and will not come at the cost of the individual user that got us to the stage we are at. This is not a conditional apology, but an absolute one for the previous subpar interactions.
I have reviewed all your lodged concerns and agree that they include necessary information to reproduce and triage through. Your concerns have attached bug discoveries in our systems and I will personally see to it that they get prioritised and actioned appropriately this week, including the schedule import issues, template reset delays and particularly the note generation lag, with my team and myself.
We appreciate your feedback with regards to tasks. My team and I are currently working on improving tasks by evaluating appropriate prompting, model choices and feature improvements to ensure that tasks are usable, appropriate for the specialty context and concise.
We have collected a vast amount of feedback points on the current delivery of tasks, yours included, and are currently working on immediately making tasks useful/appropriate in the short-term and personalised/tailored in the medium to long-term.
I understand that you have had issues with tasks not appearing at all in the past, which I will personally investigate this week in the realm of improving tasks as a feature.
I want to conclude by passing an important and critical message into this public forum: the thesis that individual clinicians have become a deprioritised segment at Heidi is not true.
We at Heidi sincerely apologise if previous support interactions, lacking escalation lines to product and feeling like the burden is on the paying user to triage through our bug investigations, has caused friction in using our product. If any of the readers of the above thread resonate for reasons not stated in this thread, feel free to reach out to me directly and I will personally reconcile the situation.
Best,
Mounir