Cookies & privacy
We use essential cookies to run the site and, with your consent, analytics cookies to understand how it's used. You can change your choice anytime.
"Service-as-a-software" is the model where the provider doesn't sell you a tool to operate yourself, but operates it for you, and you only see the result. The difference from regular software can be counted in minutes: if your team spends even 15 minutes a day configuring reminders, checking why a template didn't send, or learning a new feature, that's 15 × 5 days × 4 weeks = 300 minutes a month, 5 hours operating a tool before it helps a single patient. In the service-as-a-software model, those 5 hours don't exist. The provider absorbs them.
The term comes from enterprise software, but the idea is simple. For years, and still in 2026 for most providers, buying technology for your clinic meant one thing: you were sold a license, you (or your team) learned to use it, and the outcome depended on how much time and discipline you put in. That's "software as a service", the SaaS everyone knows: you pay a subscription, but the operating still falls on you.
Service-as-a-software flips that logic. The provider doesn't sell access to a tool. It sells an outcome, and to deliver it, the provider operates the technology itself, with its own team or its own AI, inside your clinic. You don't configure anything, you don't log into a dashboard to check automations, you don't train anyone on new software. You see the result: patients contacted, appointments confirmed, reminders sent. How it got done is the provider's responsibility, not yours.
Put in dental clinic terms: it's not "here's a program to manage your patient recall, training is Thursday". It's "your patient recall is handled, and you won't need to touch it".
It's worth separating three models that get confused because they all "use technology":
The middle category (the classic managed service) solves the "I don't have time to operate this myself" problem, but it does so by adding human hours, which is exactly what doesn't scale. Service-as-a-software solves the same problem without that ceiling: the provider operates a system, not a shift of work. We covered this first split (software vs. managed service) in another article; here we go one step further and define the third category that makes that choice unnecessary.
This isn't a knock on traditional software. A clinic with a team that enjoys configuring tools and has spare hours to do it can get a lot out of a good management platform. The point isn't that one model is bad, but that they solve different problems: one hands you a tool, the other hands you an outcome and keeps the operating part for itself.
In a dental clinic, the non-clinical side of the work (reminders, reactivating inactive patients, appointment booking, review follow-up, reporting) is exactly the kind of work that fits this model: repetitive, measurable, and it doesn't require clinical judgment.
With regular software, each of those tasks needs someone on your team to log in, review, adjust, and sometimes fix. With an autonomous system (the way we talk about this with dentists, rather than the technical term "service-as-a-software", the same idea we cover in how to apply artificial intelligence at your dental clinic), those tasks happen on their own: the platform decides which inactive patient to message today, sends the reminder, handles the WhatsApp conversation, and only escalates to a person when human judgment is genuinely needed.
The line we hear most often in early conversations with clinics (a composite of several real conversations, not a single verbatim quote) sums up the problem well: "We bought recall software two years ago. We used it for the first three weeks. Then a busy stretch hit and nobody touched it again." That isn't a failure on the clinic's part or the software's, but what happens when a model depends on someone finding time, on top of their day job, to operate one more tool.
The most honest way to see it is to count the hours your team would spend operating a tool, not treating patients:
Added up, it's common for a clinic to spend 3-5 hours a month just keeping a communication tool running, before counting the time spent writing or reviewing the messages themselves. In the service-as-a-software model, those hours disappear because there's no dashboard to operate. The provider takes that part on as part of the service.
What this doesn't mean is that the system makes clinical decisions or speaks on the dentist's behalf without oversight. Everything that gets automated is administrative work (scheduling, reminders, follow-up), not diagnosis or treatment, and conversations that need human judgment get escalated to the clinic's team.
Any product can call itself "autonomous" or "managed" in its marketing. These five questions separate the real category from the label:
None of these questions has one universal "correct" answer. Software operated well by a team with the time and interest to learn it can work very well. What these questions do is tell you clearly which category you're buying into, so the decision is a conscious one instead of a surprise three months in.
Keishal is an autonomous system that operates the non-clinical side of a dental clinic: reminders, reactivating inactive patients, 24/7 appointment booking, reviews, and the reports that summarize all of it. It integrates with the practice management software (PMS) the clinic already uses, without replacing it (see how we fit alongside each PMS in our dental software comparison in Spain), and without the team having to learn a new dashboard.
This doesn't mean Keishal is the only possible example of the category, or that the category only exists because we use it. It means the opposite: the category exists independently, describes a real model with its own advantages and limits, and Keishal is one concrete way of applying it to the day-to-day of a dental clinic.
If you want to see what this looks like running on your own clinic's numbers, you can book a demo and we'll show you with your real database, not a generic case.
Next month's revenue forecast is a calculation from three numbers you already have: confirmed agenda times average ticket, adjusted for your drop-off rate, plus what your reactivation and recall will still generate. Example: 340 confirmed appointments, a 12% historical drop-off rate, and an 8% reactivation conversion on 220 contacts add up to a forecast of about €30,115. It's not a promise: it's arithmetic with your own numbers, and you can recalculate it every month.
There's no single right recall system. There are three paths (manual, software, and an autonomous system) and which one fits depends on how many patients you have due for recall each month and how many real hours your team has to spend on it. Count your patients due this month and multiply by 5 minutes of handling each: that number, not any vendor's pitch, is your real starting point.
