Stop Buying AI. Most Dental Groups Are Solving the Wrong Problem

[00:00:00] I want to ask the question that most of the AI adoption conversation avoids because it's a little bit uncomfortable. A really important ingredient in all of this is understanding the clinical reality that our healthcare professionals work in. We shouldn't be focusing on the tools that look cool and seem like they probably will have an impact. Talk to me about change fatigue. They're not necessarily receptive to another platform. Every DSO is different. There is no magic formula.

[00:00:26] Being able to articulate at a leadership level, what are we as an organisation trying to do? This is not really an AI conversation. What AI allows you to do is it gives you more options and it accelerates, in many cases, the route took to solving your problems. How do you build a data strategy on imperfect foundations? And is the answer to fit the foundations first or start building and accept the noise?

[00:00:52] This is the Tech Dental Podcast, the strategic intelligence hub for leaders shaping the dental industry. We break down how AI, data and operating discipline drive performance and scale. I'm Dr. Randeep. Let's dive in. Welcome back to Tech Dental. Today's conversation is about the gap between what AI can do inside a clinical organisation

[00:01:19] and what most clinical organisations are actually ready to absorb. Because here's the thing, most dental groups are approaching AI as a procurement decision. Which tools, which vendors, which price point. My guest today has spent her career on the other side of that question, building the infrastructure that makes AI actually work inside a clinical environment. And she has a framework for thinking about this that I have not heard articulated so clearly anywhere else in this industry.

[00:01:47] Dr. Sonia Shermotsky is the founder and CEO of 32Co. Before that, Oxford Medicine, BCG Strategy Consulting, BCG Digital Ventures. She has navigated every stage of this problem from inside elite strategy through the messy reality of building a clinical AI platform from scratch. Sonia, welcome to Tech Dental. Thank you for having me, Randeep. I want to start at the beginning because I think the conversation the dental industry is having about AI is focused on the wrong variable.

[00:02:16] When most practice owners and DSO operators think about AI, they start asking which platform, which vendor and which price point. What they are not asking is whether their organisation is actually capable of absorbing what AI can deliver. And that's not really a technology question. It's an organisational design one. And here's the number that puts this in context. There are approximately 1,000 specialist orthodontists in the UK serving a population of 60 million.

[00:02:42] Only one in three general dentists offers clear aligner treatment consistently. AI-enabled platforms are beginning to close it by distributing specialist level clinical intelligence across generalist networks. Sonia, you've sat on both sides of this. You were a BCG consultant advising organisations on technology strategy. Then you became a founder, building AI infrastructure inside a clinical environment.

[00:03:05] What do most dental leaders fundamentally misunderstand about what AI adoption actually requires of their organisation before they buy anything? So many questions in there, Mandeep. So I think maybe I'll start with my first job was actually an A&E doctor. A really important ingredient in all of this is understanding the clinical reality that our healthcare professionals work in.

[00:03:26] And that a tool that is a nice to have or looks cool actually isn't going to touch the sides of the complexity of the day-to-day job of being someone who is patient-facing and responsible for outcomes. So that's maybe the first thing to say. I think that we shouldn't be focusing on the tools that look cool and seem like they probably will have an impact. We need to be thinking about what the problems are first that we're trying to solve.

[00:03:51] And this is product development 101, really, is go to your users and understand what problem they're trying to solve. So you've explained a little bit about the way that we approach problem in orthodontics of a really a lack of access to specialist care. So when we started building the business, this was about how do we ensure that the patients who really like to have the top specialist quality healthcare delivered to them,

[00:04:18] how do you make sure that they can get that without having to travel to what they perceive as the Harley Street? How do you make sure that specialist expertise becomes available locally to close that gap between the demand for treatment, the demand for specialist treatment and supply of specialist treatment? For us, this was about recognising that you can't expect every single generalist in your organisation, and many listeners will be running big organisations, to suddenly become an expert in specialist care overnight.

[00:04:46] But what you can do is give them access to specialist expertise so that they can use, essentially borrow the experience and wisdom of their colleagues to deliver care as if they were in one of the top specialist centres. Now to do that, to fulfil that promise to our customers and to say that we really do think we can help you deliver the best quality care and also deliver a commercially excellent experience for the patient.

[00:05:15] You're talking about quite a lot of complex workflows and you're having to do quite a lot of the heavy lifting for your users. And when you start talking about things that are complex, where heavy lifting is required, that's where AI starts to become powerful. But what it isn't is, let's have a look at what AI can do and try and retrofit it into a scenario, because we think that everybody else is using AI and that's what we should do.

[00:05:41] AI is a different way of building and it's a different way of users experiencing tech. But the fundamentals don't change. When you're thinking about what we should, what should we be doing in the organisations? What problem are you trying to solve? Do you have an efficiency problem? Is there a specific blocker or a bottleneck in your processes that you're just frustrated by and that's preventing growth? Is it just a revenue problem? Do you just need to drive more revenue, same-store growth through your sites?

[00:06:07] If you can think of it from that lens, then you can start to be more deliberate about selecting solutions. And some of those solutions might be AI. Some of them might be processes. Some might be people problems. So being very clear about what you're trying to solve for and then only choosing AI if it's the right tool for the job. That brings me on to something that you've articulated that I want to push on directly. You draw a distinction between deterministic systems and non-deterministic AI systems.

[00:06:36] And you argue that they require entirely different governance frameworks. Can you make that concrete for someone running a multi-site group? What does that distinction actually mean on a Tuesday morning in the clinic? When I started this business, the way that you built software was very different to how it is today. So you would run around trying to find the best software developers in the world. You would pay them a lot of money and then you would viciously protect their time. Because they are your most expensive resource. By and large, they were the bottleneck to you building.

[00:07:05] That has completely changed now with AI. It's now possible for you, me, anyone to spin up an instance of Claude and build something really quickly. So the building is no longer the bottleneck. The bottleneck now comes later. The problem is later. Because what you're now having to solve for is how do you evaluate that tool on an ongoing basis? Because the fundamental difference between AI and traditional code is that it is probabilistic. It used to be a if this, then that. And it would always do the same thing.

[00:07:35] Your platform, your code would always do the same thing. When you now introduce an AI or an LLM layer in the middle, it will change its output every single time based on probability. And I think that sounds quite scary. It is the reality of how AI works. And obviously, there's a lot that you can do to build around that, to build guardrails and constraints on how it performs. But fundamentally, if you ask it to do something 10 times, you will get 10 different answers. And I'm sure that everybody here has used to use ChatGPT and has experienced that.

[00:08:03] That creates a real problem when you're building software that has to be reliable, predictable, especially in a healthcare setting. So your problem is moved to the post-build side into the evaluation side. And that's a whole new area of product development that we spend a huge amount of time on. I would argue, I would say that for any builds that we do internally or externally, between 50% and 90% of time, NFTs are focused on evaluation on the build. The build is the easy bit. Now, how do you make sure that it's performing consistently?

[00:08:33] From a DSO's perspective, you're thinking about selecting a vendor. You need to know that's also what they're thinking about and that they can evidence that. It's very easy to spin up, for example, a lovely prototype in half a day. But that isn't the same as a product you can buy that is going to be monitored and evaluated on a continuous basis by the vendor that's selling it to you, but also by your team.

[00:09:00] There's a big difference between a tool that when you turn it on, it performs and does the same basic things. And you could pretty much, if I turn it on a year later, it's going to do exactly the same things as it did a year ago. When we have models that are changing every day and people building proprietary tools, it's evolving every single day. So a really important factor that also wasn't there before is that you need to be able to continuously evaluate the performance yourself of the tool.

[00:09:28] And that sounds very fancy and technical. What I basically mean is you need to be able to look at it and need to be able to say, is this doing the same that I wanted it to do? And sometimes that's really easy to assess. And sometimes it's more, it's buried. And you've got to be cognizant when you're looking at something where you can't immediately appraise the output. So it's very easy for me, for example, to spin up a quick AI voice transcription tool, right? These exist everywhere. And when it's transcribing, I can read it and I can see whether it's done it correctly,

[00:09:58] right? It's a very transparent process. And if it's not performing and if it's making mistakes, it's very obvious to me. So that's an example of where I can continuously review its output and I can be confident. There are lots of other instances where it's doing magic or seemingly doing magic and you're being asked to trust the output. That is where I'd be a little bit more cautious is if the users can't look at it every day and go, that doesn't look right to me, then you need additional evaluation frameworks in place and your vendor really should be helping you put those in place.

[00:10:28] And if they're not, then it's probably not the safest thing for you to adopt straight away. Talk to me a little bit about change fatigue, because it's something I hear a lot when I talk to DSO operators and practice owners. Teams that have been through digital transformation, EHR rollouts, post-COVID restructuring, they're not necessarily receptive to another platform. How do you introduce genuine AI capability into a clinical team that has already been through multiple change cycles without triggering the resistance that kills adoption before it starts?

[00:10:59] Yeah. So we could do a whole podcast on change management in healthcare. The reasons why people resist change, I think, need to be understood before you try and tackle them. Very often resistance comes from not knowing the fear of the unknown. So what is this tool? What is this fancy tool that you're trying to get me to get my head around? There's a learning curve there that needs to be overcome and you need to address that and not sweep it under the carpet and say, it will work. Just trust it. Just start using it. So that's number one.

[00:11:27] The second is incentives, right? A lot of these tools are scary for people because the promise is efficiency. And when people hear the word efficiency, they hear cost cutting. So people don't necessarily know whether this is a tool that's supposed to be wiping out my job or one that is making me more efficient. And that's a really important conversation to be had at a leadership level with teams if you want them to start adopting things. But it comes down to the same point as I made earlier, which is focus on the problem, not the tool.

[00:11:56] So if you have a team or a subset of a team that has a persistent problem that they're up against, they are not able to hit whatever metrics you have set them or there's an administrative burden that is just overwhelming. Start with that and involve them in the process of articulating what the problem actually is and get them to... It's easy to say this, but get a blank piece of paper and say, what would you like to happen? How would you describe the ideal solution to this problem? Because that's what we do with our users all the time.

[00:12:26] That's how you build great tools. As you say, what would you like this thing to do? What would a magical world look like where this is all fixed for you? And then work backwards and try and find the vendor or the product or build the product that does that for you. And then what you're creating is in one fell swoop, you create incentives and you create buy-in for the solution. And I'm a huge advocate for people building their own tools internally as well.

[00:12:51] If you can add that in and if you can help the team feel like they were co-creators of the solution, in one fell swoop, you've solved the change resistance problem. I want to ask the question that most of the AI adoption conversation avoids because it's a little bit uncomfortable. What distinguishes the dental organizations that will use AI to genuinely restructure how they deliver care from the ones that will just spend the next five years automating processes that they should have really redesigned first?

[00:13:20] Every DSO that we work with is different. And so I think the most important thing is not to treat everyone the same. There is no magic formula to be applied, but I can describe some principles that I think are helpful. I think it's being able to articulate what your main priorities are. The running of a dental practice at the front line is an extremely busy, all-consuming experience for the people running it, right?

[00:13:46] Nobody in that organization feels like they have capacity to be thinking about changing things, but they all have desires and hopes and goals that they're trying to hit. So being able to articulate at a leadership level, what are we as an organization trying to do? And then here is how we're thinking about the various solutions that might allow us to achieve that goal. And not having a hundred of them, but having a few that you can really hang your hat on

[00:14:14] and then describing actually how you would do it. This is, again, this is not really an AI conversation. What AI allows you to do is it gives you more options and it accelerates in many cases that the route took to solving your problems or picking up on your opportunities. But the fundamental principles of operating a big organization is to simplify down the most important things and to bring your stakeholders along on a journey with you.

[00:14:38] And if AI or if an AI tool is part of the solution, then making sure that there's buy-in. If I describe the opposite of this scenario, it's we've just had a fantastic demo on a thing that looks really cool. Lots of other people seem to be using this cool thing. I don't really want to be left behind. I don't want to be the laggard that doesn't adopt new AI technology. This product seems as good as any other and I get the rationale. Should we just give it a go? What's the worst that could happen?

[00:15:07] That, I think, is the opposite to a successful experience. Because what you haven't done there is you haven't been able to articulate what would need to change for this to be a successful rollout. You haven't actually described that this tool will take us from A to B, X to Y. And so you can't bring people along on the journey and you can't articulate success when it happens. And you also can't articulate when things aren't going exactly to plan to try and course correct.

[00:15:33] Yes, don't necessarily get caught up in the we should do something AI because everybody else is doing it. Focus on what are you trying to do as a business and use AI as a tool. The case for AI in dental delivery is really intellectually compelling, but most of the performance data comes from platforms with a commercial interest in publishing it. Clinicians working with AI-enabled specialist support show significant improvements in confidence and revision rates. But those numbers come from the platforms themselves.

[00:15:59] How should a DSO executive evaluate AI adoption claims independently? And what is the honest baseline against which improvement should actually be measured? That is the case for any tool that you choose to use or any service that you choose to procure, whether it's a marketing agency or whether it's someone coming to fit out your practices. A company will make claims and they will say, here's the impact that we can have on your business. And here are the results of other people that we've worked with.

[00:16:27] So this comes back to, can you get verified case studies from other people that have used the tool where they are genuinely able to describe what situation they were in before and the impact that the tool had. So I don't think, again, it's a specific AI problem. I think AI is used as a mechanism to increase the speed of building and increase the, I suppose, the capacity within an organization.

[00:16:55] But it should be held to the same standards as you would any of procuring any other service or tool or device. The tension between the data that exists and the data we can independently verify is actually what makes the next question so important. Because before you can evaluate a vendor's claims, you need to understand what the data underneath AI actually looks like and who owns it. So let me just shift the conversation slightly because this is where most of the conventional analysis stops and where I think the more interesting strategic argument starts.

[00:17:25] Because AI capability in isolation is not really a competitive advantage. The advantage lies in the proprietary data layer that accumulates as AI is deployed at scale. You've got clinical decisions, treatment outcomes, revision patterns, patient engagement signals. Organizations that build this layer create a compounding asset. Those that use AI tools without capturing the underlying data remain dependent on vendors and vulnerable to commoditization.

[00:17:51] Sonia, when AI is deployed across a multi-site dental group, what data is actually being generated and who in the organization is positioned to extract strategic value from it? If you are working with an AI tool that isn't delivering value, compounding value to you as a user, then it doesn't really make sense, right? Why would you buy a tool like that? And that's the same for an analog system too.

[00:18:15] So in order for you to deliver value to a DSO or an individual dentist with technology, you need to hold and use that data. If you're a practice management system, you obviously need to have a record of every patient. I wouldn't want to imply there's any nefarious reason for that. That is actually the use of the tool. So I think we have to be a little bit careful about fear-mongering that comes with who owns the data and what's going to be done with it.

[00:18:40] For it to be useful to you, tech companies like ours actually have to be able to do stuff with your data so that it's useful to do the thing that you've bought it for. And that is no different with AI. Now, I guess that the question there are the fear of training models and what that means. For me, and certainly for us as a business, all of any kind of training that is done at a practice level or at a dentist level is to further serve that practice.

[00:19:07] Because the better that our platform gets to know you, the more it can do for you. So it's a win for the buyer of the tool if the platform gets smarter the more that it's used. And that's a really powerful part. A really big part of the AI promise is that when you start on this journey, you're going to start by putting in a bit of effort and then the effort is going to get us less, which actually is what people want.

[00:19:29] So I wouldn't be too afraid of the idea that data is being used because it should be being used in your interest. And when you're doing things that are quite personalized for an organization, which is what we do, I think that the benefit that organization gets far outweighs any fears that your data might be used for somebody else.

[00:19:50] Now, the other thing is, if you're working with credible organizations with the right backing sort of tenure, they should be behaving themselves when it comes to the use of data. And there are clear guidelines in place for how data can and should be used. So, you know, where possible, of course, patient data needs to be anonymized. And that's 101 really of building in health care is that you should be aware of that.

[00:20:14] So vendors should be comfortable that if they're working with reputable providers, that is an integral part of the way that things are built and worked, built and also monitored. You run a three-build type framework, internal read-only tools, customer-facing AI with clinical safety gates and R&D and experimental tools. The same underlying capability sits in fundamentally different governance envelopes depending on its type.

[00:20:42] Most DSOs procuring AI today have no framework at all for thinking about which of these envelopes a vendor is operating in. What's the practical starting point for a dental group who wants to build that framework from scratch? What do they do first thing on a Monday morning? As I said, I'm a big proponent of people building their own tools. What I'm not suggesting is that DSOs become tech organizations overnight. It is an incredibly complex thing to build an AI team infrastructure governance.

[00:21:10] And that is why you pay a supplier to do that hard work for you. That said, I really do believe that people within DSOs can start to turn their hand to building things for themselves that will not only increase their understanding of AI, but also will help them become themselves more efficient. The heuristics that I would use within a DSO are perhaps a bit different to what I would use for my own team.

[00:21:35] But I think when you think about whether you want to build something yourself, there's a couple of key questions to be asking yourself. And again, it is important that this happens at a leadership level. The first is when you've identified a problem. Is this a read-only problem? As in, can I read from the data? Am I writing to a database? Am I actually changing data? Read-only tools are much safer and easier to build than tools that write.

[00:22:04] The second thing is who am I actually building this for? Am I building this for an internal team member? Internal team members tend to be more forgiving of bill times, perhaps things not working immediately and revisions and redos. Dentists, a bit less forgiving. Patients, even less forgiving. So you need to think about your audience and how when you're on this journey of building something for the first time, how forgiving are they going to be of something that isn't working and reducing your risk on that side?

[00:22:34] The third is how are you actually evaluating this tool once you've built it? How do you know whether it continues to work? Like I said, you can't with AI just build it and let it sit there. There is decay that happens, which was less so the case in the olden days. And so you need to be able to monitor its performance and you need to have a team member or a team in place to do that.

[00:23:00] And my view is that it should be the stakeholder and the user that is appraising it. So if you take those three things, does it read or write? Who is it for? And can I evaluate it? My suggestion is always to DSOs that are on this journey is start with read-only internal tools. And there are lots of examples of those that you can start building tomorrow that I think can be extremely impactful in your day to day. So, for example, you can build simple KPI dashboards for yourself.

[00:23:30] If you can articulate the sort of numbers or metrics, leading indicators of success, whether it's at a practice level or at a group level, you can build yourself your own KPI dashboard. You can build your own internal Q&A bot tool. You can centralise your HR, your compliance documents in one place, and you can build a tool on top just for internal use to query that data. And that can be really useful for people welcoming. You're welcoming into the organisation for the first time as part of their onboarding. And that's something that we also do.

[00:24:00] You can start to build tools that start to look at where your leads are coming from. These are not particularly complex things to build. You can start to build it for yourself. And when you start to realise that these simple read-only internal tools are within your capability and you have some examples of people that have successfully done it, it's about championing those people and showcasing it to the rest of the organisation, saying, look, there are some things that we would like to invest in building ourselves

[00:24:27] because, A, we think it's useful and, B, we want to invest in you as our team members in upskilling you in these areas. I can speak more about actually what it takes from a training perspective. We have internally, everybody can build now and can code to some extent. And that's especially important for, that's not just the people on the product team, that's the commercial team, that's the education team, HR, finance. Everyone is able to do it because we've made a really big push for that because we think it's important.

[00:24:56] And if anyone wants to ask me about how to do that training, I'm happy to. It's probably out of scope for this conversation. But making sure that the people that are building it, this is probably my one tip. If you take one thing away from this, my one tip is do not hire an external AI team that is going to try and do AI to the DSO. That isn't going to work in my experience. The drive and the ability can and should come from within.

[00:25:23] And it won't necessarily come from the most senior person, from the most tenured person within a team or a sub team. Quite often, it's a slightly younger, very curious person who wants to give it a crack. But you should be giving the opportunity to build these things because they will be a great champion for AI within the organization. And once they've done it once, they can go around and teach everybody else.

[00:25:47] So don't hire an external organization that's going to try and outside in, apply AI and make it work. It should be a grassroots initiative. And you don't have to do anything particularly heroic or big to get things started. The argument that proprietary clinical data becomes a moat assumes that the data is clean, structured and governed consistently across sites.

[00:26:09] In most multi-site dental groups, the reality is fragmented systems, inconsistent clinical coding and data quality that undermines the AI models built on top of it. How do you build a data strategy on imperfect foundations? And is the answer to fit the foundations first or start building and accept the noise? I think you can apply a bit of an 80-20 approach to this. So if we said to everyone, don't start building anything until your data is immaculate, we would never build anything.

[00:26:37] And in reality, to build some of the things I just described, you don't need perfect data across every site. Because what you're not, what you're looking, this is not an AI exam that you're doing where you have to show it to the teacher and they're going to grade it. You can do a hell of a lot with data that is in good shape. And actually interrogating the data and trying to build on top of it is the exercise that will force you to clean it up. So I'm a big proponent, again, of not putting too many barriers in the way. Just get started. Have a look at the data that you have.

[00:27:06] Make some effort for sure to centralize it and tidy up a bit. But the only thing that's going to force you to do that is if you're trying to build something. So use it as an opportunity to say, we're going to take this small piece of the organization, look at what we've got. Here's what we're trying to achieve. And we're going to put our youngest, hungriest junior people on this and we're going to give them not very much time to do it and see what they can do. That tends to be how it works here.

[00:27:31] And how I would suggest that DSOs that have big teams use some of that resource and hopefully some of the enthusiasm that already exists around what AI can do for DSOs. So we have the readiness problem and we have the data governance problem. Now I want to get into a question that really our DSO listeners in the audience are probably thinking about most practically. When a vendor walks through the door, how do you actually evaluate them?

[00:27:56] I want to talk a little bit about vendor responsibility because there's an argument you make that I find genuinely important and I don't hear articulated enough in this industry. You said the heaviest lifting in AI adoption belongs to the vendor, not the customer. A vendor who deploys a tool and leaves the customer to figure out adoption has not really sold a solution. They've sold a problem transfer. Sonia, what does genuinely responsible vendor behavior look like in practice?

[00:28:21] And what are the red flags that tell you immediately that a vendor is maybe not set up to actually deliver? The most important thing is that it's a partnership, right? When you adopt a new tool that, as I described, has those tendencies of evolving and changing, you have to work in partnership with that vendor. So if you're hearing that as soon as the contractor is signed, the next time you're going to see him is in a year's time at renewal. That's not a good signal, right?

[00:28:49] And for us, when we work with our DSOs, we partner with them for months until we are absolutely sure and they are absolutely sure that they know how to do everything themselves. Right. So it's about a skills transfer from our team to their team and also making sure that the mechanism is not buried under the hood somewhere. For us, it's really important that we surface and allow them to tweak the back end themselves so that they feel empowered and in control of the tool.

[00:29:17] I think it's a very, again, clear signal if something's being given to you and said, don't worry too much, don't think too hard about how this thing is working. Promise you it'll be fine, just call us if there's a bug, is not a very good signal. And I think there's another piece just around trust and credibility. There are so many vendors, as I said, it's not hard to spin up a prototype and a snazzy demo.

[00:29:38] Also, I advocate that people start using these tools themselves so that if you can see what AI can do in an afternoon, you can start to compare that with what you're seeing. And you should see a significant difference with a quote unquote professionally built product versus something that you can spin up in an afternoon. And so about the credibility of the organization as well and whether there's referenceability and whether some other people have said these guys were great.

[00:30:03] That's the most important signal is people that have been using it for a while saying, no, no, these guys have actually delivered exactly what they said they would. And we are super empowered and super excited about using this. You've developed four questions you recommend every DSO ask any AI vendor before signing. I want you to walk us through them because I think these questions are the most practically useful thing we're going to say in this entire episode and something that DSO vendors can put into practice straight away. What are those questions?

[00:30:33] This is about you being a partner as a DSO rather than a recipient of magical technology and asking the questions that allow you to get one level deeper into what the product does. So I think it's back to that point about how will we check or how will you check that the AI is working? What are we going to be able to do to make sure that everything is performing as you say it will? That's the question number one.

[00:30:59] The second is back to that partnership point is that how is this tool going to be implemented? How do we make sure that the people who are going to be using it really know how to use it, how to modify it if needed? And that you are as invested in our success as we are. Who actually needs to be involved? Which members of the organization actually need to be coming into the conversation?

[00:31:22] It is more often than not more people than you think that need to be involved, especially if it's a tool like ours that impacts clinical and commercial workflows. We make a big effort to make sure dentists, hygienists, receptionists, everybody is trained and everybody is aware of the tool rather than just assuming that it's a siloed operation. Because very rarely in dental practice or in healthcare in general are things truly siloed.

[00:31:49] And then the premortem question is something that I do a lot and I ask people to do a lot, which is, okay, now let's work backwards from this being a success. What might happen that stops this from being a success? What's the premortem on this? What have you seen that makes this thing fall over, whether it's on our side, operational side, process side, or people side?

[00:32:11] And if they can't answer that question honestly, which is, look, these three things don't happen, this ain't going to work, then I think you've got to be a bit worried because it is not likely that everything is going to proceed smoothly 100% of the time. And you mentioned you work directly with DSO partners through the implementation process. You sit with them, configure the system together, show them what's under the hood and give them a dedicated person. What do you discover in that process that a remote deployment would never surface?

[00:32:41] And what's the thing that keeps coming back that nobody really talks about in the pitch decks? You're looking for signals when you're working with an organization and they could be hard metrics. For example, how many times was this thing used? And then there's the softer side, which is why is it not being used? What are people's fears? It is, I'd argue, not impossible to get those softer signals if you aren't spending time with the customer. Because what you're looking for is them to say, look, I just wasn't really sure about this. And for someone to spend the time saying, why?

[00:33:11] Which bit of it is confusing? Or could you not find this bit? Or which bit are you worried about? And more often than not, I just don't really feel like I have the time to do this. So now you have to work with their manager to try and solve the problem of how do we help them make time for this so that it can save them time later down the line. None of that is seen remotely on a hard dashboard of how many times was this thing clicked on? That's part of the story. It's certainly not the whole story. And it's very rarely. There's a very lagging indicators of success.

[00:33:39] What you're looking for is leading indicators, which is behavior change, which requires investment from the vendor in the partner. And vice versa, of course. There are organizations that are going to use this window to build durable structural advantage. And there are organizations that are going to look back in five years and realize they've optimized for the wrong variable. Let me take you to the build versus buy question, because this is the perennial decision, I think, for every DSOC suite. You argue that most dental groups could build more themselves than they currently believe.

[00:34:08] But that internal build fails more often on adoption than on capability. Sonia, what are the principles you actually use to structure the build versus buy decision? And what is the question most operators are not asking before they answer it? So I think those three questions that I mentioned at the top, understanding what you're building, what metrics you're trying to move and being really explicit about that and making sure that you start with simple, probably read only things that prove to yourself and to the organization that you can drive value.

[00:34:38] And you'd be astonished what you can build in two weeks with a dedicated person or a few people. The build versus buy problem is really a cold start problem for me. And it's giving people the confidence to take a tiny step and do something that is safe and quick and easy just to prove that they can do it and use that as a launch pad. Quite often, as I said, it's the fear of the unknown and not knowing even where to start.

[00:35:00] That's more of an issue than the fact that the tooling doesn't work or the fact that you don't have a problem to solve or the fact that you don't have enthusiastic people who would love to get more involved in this AI conversation. So, again, if I was thinking about this from a DSO's perspective, it's unlocking the cold start problem with some really simple things, which is let's identify a problem that we can solve that is safe. And if it goes wrong, nothing really matters. If you build a dashboard that is rubbish and that breaks, that's fine. You can build it and improve it and you will learn so much from it.

[00:35:29] So give people the time and the space, give them the mandate, give them something to work on and reward it when it goes well and spread it around the organization when it goes well. And don't worry if it doesn't work straight off the bat. It won't, to be honest, it won't. And that is OK. And it's part of the learning that you have to go through. Let's talk a little bit about what's happening across the pond, because it said that the U.S. dental market is two to three years ahead of the U.K. on consolidation and AI vendor density. And the lesson you're drawing from mature U.S. groups is not which tools to buy.

[00:35:57] It's that the successful groups are no longer buying more AI point solutions. They've made that mistake and now they're moving more towards end-to-end solutions that reduce governance overhead rather than increasing it. What's the specific decision that a U.K. operator should be making right now before the same mistakes arrive here? Yeah, I think it's I think from our time with our partners in the U.S., they're further along the Dunning-Kruger curve, I would say, which is that a lot of great innovation technology came out early in the AI days.

[00:36:28] And a lot of it was those point solutions that you describe. And some of them have been burnt. In fact, a lot of them have been burnt from things from projects that just haven't worked. And whenever you have a project that doesn't work and you use a lot of internal capital, social capital, money capital to get something across the line, it can be scary to start again. And so a lot of them are in that limbo, which is we made a big bet on this. It didn't really pan out. We're not really sure what the next bet should be.

[00:36:55] But certainly there is a move away from something that is just a point solution into tools that can do a lot and manage entire workflows, which is why the product that we have built is getting so much traction is because it doesn't just solve one thing. It actually takes the entire journey. And I think in the UK, if we can prevent and avoid the let's just buy this in because it looks cool because everybody else's problem, I think you'll have solved half of it.

[00:37:23] And thinking critically about what are you actually trying to do and then using that to select the right vendors based on the problem, not based on what sounds like it might be a good idea and futuristic and modern. So as with lots of things, the US is further ahead, but I think that they've had their fingers burned. If you have access as a DSO leader, which many of you will through conferences and events to people, talk to them and ask them, which of these have worked for you? What has the impact been? Have you been able to measure the impact?

[00:37:52] And some of the answers might be, look, it's too early to tell and that's OK, but you should be able to identify some leading indicators to success. And if you can't, then very quickly try and find some. For some of the DSOs who want to be the early adopters, how should they be thinking about this so they're not playing catch up in five years time? So a company like ours, we spend a lot of time co-building. And we always say that we didn't actually decide which features to build into this platform.

[00:38:17] We spend hundreds of hours with customers, patients, dentists, and they tell us what they want. And again, nothing in the platform that we've built now for the DSOs was built because we thought it was a clever idea. It was really spending time with customers and co-designing with them and saying, look, how could we make this? And pushing them and pushing them. What if we did this? Would that be? Would that help you? And putting things in front of them that they haven't thought of before. Obviously, that's part of the design process.

[00:38:43] But I think if you want to be an early adopter, work with an organisation that is willing to listen to you and say, that sounds like a good idea. Let's build it with you. Tell us what you want. Let's build it with you. We'll test it. And if you like it, then you can have it. That is how good product development should happen. And you'll quickly be able to identify with the people that you're speaking to, whether that's on the table or not. But I think if you want to increase the chance of that happening, be really explicit about what your problem is and really explicit about maybe what you've tried or what impact it would have for you to solve it,

[00:39:11] because that makes it easy for someone to come and go, OK, let's work together on this problem. I think if you have no idea where to even start, it's very hard for you to be part of the design process. You're more likely than not be a recipient of the output as opposed to a participant in the creation. So we're coming to the end of the podcast and that means the lightning round. So there's some quickfire questions. Whatever comes to mind first. First one, only one in three general dentists in the UK offers clear aligner treatment consistently.

[00:39:40] If you could change one structural thing in the UK dental system to accelerate that number, what would it be? It's a funny question because this is what we spent the last four years building. It's not one. There's not one silver bullet. I'll put it that way. If there was one silver bullet, someone would have done it by now. It is years of grind and building really deliberately, really explicitly and listening to users constantly on what they want. The four vendor questions you described earlier, which of the four do most vendors fail most consistently?

[00:40:09] And what does that tell you about the state of the market? It's the premortem question. It's being honest about what it takes to succeed. It's about working backwards from the end result as opposed to just launching into something relatively with good intentions, but relatively blindly. It's 2030. The AI infrastructure layer for UK dentistry has been built. One company owns the operating system that specialist clinical intelligence runs on. Is that a good outcome or a dangerous one?

[00:40:38] Oh, that's a good question. It depends on... Honestly, I think it depends on the culture, the incentives of the company, right? I think that your founding principles determine the direction that you'll take. And for us as an organization, the founding principle has always been delivering great care. And that's the first thing that we did. It's the first thing that we wake up every morning and think about. And if that bit isn't working, everything else stops.

[00:41:01] So as long as those principles are in place and you've built an organization that understands and reinforces those principles, I don't think we need to worry about large organizations dominating. I think it could be a force for good. But obviously competition is also healthy because it keeps everyone on their toes and makes sure everyone is constantly delivering. Obviously, I would love it. And obviously, that is our intention for it to be us, but for the right reasons.

[00:41:25] Because genuinely, I believe that building a great healthcare business for the long term, the only thing that matters is where you're delivering good outcomes. Ultimately, that's the only thing that matters to clinicians, to owners, to DSOs. It's actually extremely simple to run a business with that as your main principle. Final question. Oxford Medicine, BCG, BCG Digital Ventures and Founder. Which of those experiences shaped how you think about building the most and why? Gosh, great question.

[00:41:55] Each of those jobs was very different. And I loved every single one. I loved being a doctor. Being an A&E doctor was one of the best experiences and privileges in some ways. And the move into the corporate world was a big change. And I also loved that job. I'm a very optimistic person, I should put it that way. It was hard work. All of it was hard work. And so I think that maybe the thing that shaped most of my approach to work now is the ability to learn quickly.

[00:42:23] And moving from one job into a job that's completely different and ramping up and going from not really knowing what I was doing to becoming good at it. That experience and being unafraid to start from the bottom and be humble and learn is probably the biggest thing that shaped what we do today. Sonia, if someone listening to this wants to go deeper, engage with 32Co or connect with you directly, where should they go?

[00:42:50] Go to our website to 32co.com and you can find me on LinkedIn. Fantastic. Sonia, thank you. It's been an amazing conversation. What I want every person listening to this to take away is not just a set of tools, but a complete mental reframe of how to articulate the problem. The organizations that are going to lead in the next decade of dentistry are not the ones with the biggest budgets or the most software. They're the ones asking better questions about what they are actually building for.

[00:43:16] That's what Tech Dental is here to do, to make sure that the people in this industry are asking those questions with more rigor, more data and more clarity than they had before they listened. If this episode sharpened how you think, share it with one person in your network who needs to hear it today. Subscribe on Apple Podcasts, Spotify or YouTube. All links are in the show notes. I'm Dr. Randeep. Until next time, this is Tech Dental.