AI Ambient Scribe ($120M Raised)

It's actually not as slow as I feared. In our category, ambient AI, we've seen incredibly fast adoption — from zero to 50% of physicians in the US using it in about two years. So adoption can be very, very fast. But it's not the norm.

Some people who've been in the industry much longer than me — like 30 years — say they've never seen such fast adoption of any technology in healthcare. I can't judge that, because I wasn't there. But the dynamic with ambient AI is different. Usually clinicians resist new technology, and I think they're right to — they're so tired, so overwhelmed, they don't have time to test things, to play with tools that aren't perfect. We've already pushed so much onto them, like EHRs, that they tend to resist whenever the IT department or the chief medical officer tells them to use something.

but ambient AI is different, because it addresses a key pain point: documentation.

You're a physician, you know what I'm talking about. So the exception with ambient AI is that it was pushed by clinicians themselves. And they have a lot of influence inside their organizations over which tools get deployed. That's why this category was the exception.

A very, very large provider — I won't say who, but a very large health system in the US — we had an inbound from them saying, "Hey, we'd like to pilot Nabla."

At this point, we had no sales team, no customer success team, no one.

And we hadn't even thought about enterprise yet. But they had more and more clinicians using the product, so it was like a miracle inbound. They said, "We'd like to start a pilot on August 14th." This was two years ago. At that point, no health system in the US was using ambient scribing — Microsoft had been trying a few pilots with DAX, but it was still half human-in-the-loop. It was very early. Nobody was doing it. And we said, of course, let's do a pilot.

They sent an email to contact@nabla.com — the kind of address we don't even really read, there's a lot of spam.

And we were lucky.

They were saying, "Hey, we'd like to talk, we have providers using this." And we were lucky, because many people at Nabla had worked in the US, so they knew the name of this organization. Someone could easily have just skipped that email — it really was a miracle inbound. And the market is very different today, to be clear — fast forward two years, everybody's educated, it's a completely different market. But when your timing is perfect and you're first, you get these kinds of dream situations.

We said, of course, let's do a pilot. So I went there with two others — one of our co-founders and one engineer. We each rented a car, spent the first day in a medical center in central California, and the second day moved to another medical center.

And we started this pilot like that.

We were sitting in on consultations. We asked every patient, "Are you okay if someone attends the consultation?" I'd sit in the back and observe how the product worked in that setting. It was incredible to see how, after four or five encounters, physicians loved the product so much — they'd say, "We didn't know this was possible."

And even patients felt the difference: the physician is looking at them, not taking notes during the encounter, so they feel better attention from their physician. They were also very proud that their physician was using new AI — they think, "Okay, we're getting better care." Whereas before that, I'd assumed patients would be afraid of being recorded. The impact on patients was completely different from what I expected. I learned more in a week than I had in the two years before.

And on their side — we were a 15-person company at that point, with no references, and I commend them for being able to play along. But the CEO was there every day with us, taking feedback directly.

Next day, it's solved.

If they don't have that, there's no way they take a risk working with such a small, unproven company. For all these reasons, I think being on the field yourself as an entrepreneur is just necessary.

During this two-week pilot — it was in California, but the engineering team is in Paris — during the day the physicians would say, "It would be good if we could generate a summary for patients, a visit summary on top of the medical note, something we can send the patient that sums up what we discussed." I'd say okay, good, and send a message to the team in Paris. Because of the time difference, we'd come in the next morning and the feature would be in the product.

So for two weeks we had this very, very quick learning and product evolution cycle.

And actually, before the end of the two weeks, the physicians said, "We don't want to lose access to this product, we cannot work without it anymore." So they pressured the health system to sign a contract, and we signed an enterprise-wide, one-year contract within one month — something that usually takes one to two years — because the physicians said they'd leave if they couldn't keep the product. That's how we got started in the market, and how we saw the connection between bottom-up go-to-market and the enterprise contracts it can trigger.

The surprise we got turned into the biggest disappointment in the company's history. A lot of drama. But in short, we were so happy with our bottom-up go-to-market that we forgot there are also enterprise, top-down forces to manage. We were a little bit naive.

This health system had a VC investment arm that, at the same time we were doing this pilot, decided to invest in one of our competitors. We weren't aware — I think they weren't aware of the pilot either; it's such a big company. And it triggered a huge political fight inside the organization, because the venture arm, very close to the national IT team, had just invested in this other company.

on the other hand, we had this contract and 10,000 physicians using us — I was very happy. They even published a study in the New England Journal of Medicine on the results. It was a proven success after just one month's deployment — 4,000 active users in the first month. So it became a problem for them to have two vendors. We had completely overlooked the political side of things and the top-down dynamics. We should have looked for political support at the top, and we didn't. So our supporters inside the organization lost this political battle.

And so eventually, the system went with the solution they'd invested in, even though it wasn't deployed, wasn't tested — I can't say everything, but we felt it was the biggest injustice of our lives, given the success we'd had with clinicians and their product. To this day I still get emails from clinicians saying, "Hey, it's too bad, we prefer your product, we're not happy" — but there's nothing we can do anymore.

We learned a lot. It was a true disappointment, feeling we were unfairly pushed out despite the product's success. But by then we already had dozens of health systems as customers, very happy, a lot of revenue, tens of thousands of happy clinicians using us. We were launched already. It was an interesting up-and-down story.

That's probably where it was. And who knows — even if we'd done that, these things are quite difficult, it might not have worked out anyway.

Our customers, clinicians, want three things, I think. First, they want something perfectly integrated with their EHR — it has to work hand-in-hand with it, pull context from the EHR about the patient you're seeing, and then fill everything in. You can't do that as a standalone product. Second, they want very deep workflow integration — they want to build hundreds of workflows on top of documentation with their ambient AI. Sending referral letters, revenue cycle management, coding, claims, CDI — they want their assistant to do that for them.

They want to get rid of it, basically. Even upstream — preparing for encounters with summarization, helping you pre-chart before you see the patient, which is very important in hospital settings. So they expect very quick horizontal product expansion, far beyond documentation — which was the wedge, only the wedge, the starting point. And third, they want a lot of customization. We've talked about this already.

The one-size-fits-all approach was fine three years ago. It was very new then. Now every specialty, every health organization, every clinician has different ways of doing things. They expect their AI to learn from them, to be deeply customizable — and that's hard to do at scale. So we plan to win by being the best at these three things: EHR integration, workflows on top of documentation, and the ability to customize and personalize.

Now, if you look at what's happening in the market, yes, you'll have more free offers like Doximity or OpenEvidence. These are very simple, non-integrated scribes — a free, small feature to attract customers to their paid products. It'll work for a few physicians, maybe, but 90% of the market expects very deep EHR and workflow integration, and you don't get that from a consumer product like that. Epic announced — it's not a rumor anymore — last week at UGM that they'll partner with Microsoft DAX to have scribing inside Epic. In six months, in January, they'll release something close to what we had three years ago: scribing, one-size-fits-all, no other workflows.

but of course, if we stopped working at Nabla — us and our friends across the industry, the other AI-native startups — if we stopped working for one or two years, we'd be dead. So now we're expanding super quickly into these workflows, upstream and downstream, and offering a lot of customization.

If we don't do that well enough or fast enough, eventually distribution will matter most, and Epic will win this. So it's a question of how fast we can keep the three-year lead we have. I think this dynamic — incumbents slowly adding AI to their products, and AI-native startups improving their AI fast enough to stay ahead — you see it in every industry.

The first thing we added is related to coding and CDI — Clinical Documentation Integrity.

We did that.

One reason is there's a very hard, core ROI attached to these workflows.

CFOs are very happy, because they're leaving a lot of money on the table with claims denied for no good reason. By working at the source, during the encounter, we can make sure the documentation is accurate and will support the coding well. So it has a direct, measurable financial impact.

But it's also a pain point removed for clinicians, because they get a lot of queries from the coding team — typically three weeks after an encounter, a claim has been denied and the coding team reaches out asking, "We have an issue with this encounter." It's a nightmare for clinicians: they see it in their email, have to reopen the chart to see what happened, and they've forgotten all the context. We can remove that for them too.

We're not optimizing for cost yet. Costs are going down for many reasons, so the natural evolution takes care of that for us. We're keeping accuracy first, but optimizing more and more for latency.

For instance, when we started doing ICD-10 coding, we initially used GPT-4, and it took ten seconds to generate the code. Then we built an internal, custom-made model that initially matched that accuracy but ran in half a second, at much lower cost. Usually cost and latency are correlated — the more time it takes, the more GPU you burn — so it was an obvious decision to switch to our own model. And since then, because we can do reinforcement learning and other techniques, our model is now much better than GPT-4's accuracy.

That's typically how we think about a new feature: first use a very large, horizontal model like GPT-4 to get a baseline, then try to beat that baseline in both accuracy and speed with different models. It's a good feature development process.

First, on the EHRs — Epic's market share in the US is 45%, so 55% is non-Epic. We actually work with a long tail of at least 12 or more EHRs, and that's a differentiation we have versus some competitors who are Epic-only shops. We even partner with more and more of these EHRs, who are actively reselling Nabla.

Yeah, you're absolutely right. We've been partnering with many EHRs since the beginning. Epic is definitely the winner — it's almost monopolistic among the biggest health systems in the US — but there's a very long tail of other EHRs and providers, and we address them very well today.

On geographies — we made the decision three years ago to go full US, because we felt the market was ready, was right, very big. The hard thing with startups is you have to say no to many things every day — if you're not saying no at least once a day, something is wrong. So three years ago we said no to Europe, no to Asia, and decided to focus on the US. I think it was the right decision. Now things are different — we're starting to build up our go-to-market teams in Europe and even in Asia.

Because three years later, markets outside the US have become more mature. And these markets almost always lag a little behind the US — they're watching what happens there. Maybe the best marketing for France, for instance, is to deploy in the US: a French hospital sees, "Hey, the Americans are using it," and they want to buy the product. Even though I'm French, and it's my home market, I think it was a good decision to start with the US. But it's clearly changing this year — this is the year we build out sales in other markets.

as for self-service, it's interesting — we've always invested a lot in self-service use of Nabla, because it helps our enterprise sales. As I said, having champions inside an organization before it becomes a customer is very powerful. It also helped us create a community of very loyal, active, engaged users who discovered us through the self-service release and help us every day with feedback and data.

This is how we build the product with them. And it's the only way to cover dozens of medical specialties and different settings — the only way to do that well is to have this community. It was a byproduct of our self-service go-to-market; we never prioritized self-service revenue. We saw self-service as an accelerant, not a revenue source.

I still think the biggest problem with self-service is you don't get good EHR integration, or integration with other tools like RCM. Moving forward, that will be a bigger problem. It was fine, a year ago, to have a standalone scribe generating something you copy-paste — but that's not the future. The future is a perfectly integrated AI working alongside you, and you can't do that without integrating with your tools. That's why I'm personally not a big believer in the long-term viability of self-service for what we do.

Not really — I'm still learning.

What I try to do now, when I'm about to make a decision on product or go-to-market or positioning, is confront that decision with customers or thought leaders in the industry very early on, because there are so many ways to be wrong in healthcare, to make mistakes. Even our own team — we all believe the same things, we think the same way, so it's dangerous to only ask my team. Of course I ask their advice and opinion, but they're too close to us. Same for our investors — I convinced them to invest, so now they're believers. How can they be really, honestly critical about important decisions we're making?

So it means going outside my comfort zone — sometimes I'll ask someone, a leader on LinkedIn, and they'll think it's garbage. But it's very important, because one decision can cost us a year of development. You want to act fast, but also carefully, and getting that external, unbiased opinion is so important.

Exactly. For instance, we released dictation — Dragon-style dictation — a few months ago. It was a huge engineering investment, so many engineer-years to build what Nuance had been working on for 20 years: the accuracy, the latency, the operating-system integration, being able to type into anything, everywhere. Deciding to add that to our product set — if I'd been wrong, that's 50 engineer-years lost. It's a good example of how a decision that looks easy to take can have big consequences, so you don't want to take that kind of decision too fast.

Yeah, it's very stressful. As soon as you have large customers, it's stressful, because many things can go wrong — they can be unhappy for a bad reason. And every time you raise, the more money you take on, the more pressure you have to deliver and not fail. So there's a growing — even with key employees: we have incredible engineers that OpenAI is trying to poach every week, and sometimes my nightmare is, "This guy will leave, we'll lose him tomorrow." The surface area of potential stress keeps expanding, and there's no solution for that.

So first you have to understand, okay, it's normal, and you'll always have a reason to stress. Whether you're a one-person company or the head of a million-employee public company, there are reasons to stress every day, and you can't suppress the source — you can only cope better with the impact it has on you.

I think it comes down to learning to disconnect, and to think, "Okay, actually it's a game" — it's a big game, maybe even life is a big game, but we're playing it seriously, we're focused, we do what we can. This is one aspect of my life, not the most important thing — even the outcome of Nabla isn't important compared to many things happening in the world today.

And second, being very honest with investors, with the team, even with customers, helps a lot — because typically you get stressed when you've made a promise, or lied about something, and can't hide it anymore. The more transparent you are with everyone around you, the more it helps, tremendously, because you have nothing to hide. That's usually the core reason for stress. And you can talk freely with others — sharing the burden is very, very impactful.

So, let's say you lose a very large customer because you're betrayed. If you think of it as a game, you think, "Wow, my opponent made a good move, and I lost this move — let's think about the next move." It's normal to have setbacks in a game; this was a move today, there'll be a move tomorrow, and another the day after.

whereas if you're too close to it and feel it's your whole life, you'll exaggerate any disappointment or betrayal and take it personally, which is worse — thinking, "They did that because they want me to feel bad." Actually, nobody wants you to feel bad — they're choosing what they think is the best product, or leaving your company for a better salary. Taking things personally is very easy when you're an entrepreneur, because you're so involved in what you do. Treating it as a game helps you not take things personally, and understand that everything happening today, even if it looks very big, will seem very small a week from now, a year from now. It's just one step in a long sequence of steps, and it's okay to sometimes be disappointed or lose something.

I've always loved building things, since childhood — and then watching people use the things I build, and building a better version based on that. I don't know why, but I like building, and building for someone. I could probably do that in many different contexts. And once you start being an entrepreneur, I can't see myself doing anything else.

And so after two companies, I chose healthcare, because it's more difficult but has a bigger impact. It's like level two of the game, or level three, or more, I don't know. But I thought, wow, this is exciting — I wouldn't have started another CRM company, for instance, or a customer support company. I felt like, okay, I've done that, we've been through that cycle, we need a bigger challenge. So this is how I'm happy every day, doing this.