A man arrives with a laptop. He sets up a server, creates “users,” configures something called master data, and leaves before lunch. Three weeks later your receptionist is still clicking through a settings menu looking for the thing that lets a patient book an appointment. This is what passes for dental clinic software for small clinics in most demos: a hospital system with a few menus deleted and the word “lite” added to the name.
You can tell where it came from. There is a field for ward number. There is a module for the pharmacy counter you do not have. There is a billing department tab sitting next to a tab for bed allocation, in a clinic with two chairs and a doctor who also answers the phone.
Why hospital software feels wrong in a two-chair clinic
Hospital software was built for a building with an admissions desk, a pharmacy, a billing office, and an IT department on the second floor keeping the servers alive. Every one of those departments gets a screen. Every screen assumes somebody is sitting there, full time, whose job is that screen.
Your clinic has you, your receptionist, and a tablet. There is no admissions desk. There is no pharmacy counter inside the software’s job. There is no IT department, there is a nephew who is good with phones and comes by on Sundays.
So when a receptionist opens hospital-grade software to book a patient, she is clicking past a ward field, a bed field, an inventory tab, three settings she will never touch, to reach the one thing she actually needed: who’s coming today, who is this person, what did we do last time. The product was not built small. It was built big and then had bits switched off, and you can always tell, because the bones of the big thing are still there, waiting to confuse someone.
What a clinic actually needs, and nothing more
Here is the question worth asking before buying anything: does this software assume your clinic has departments it does not have?
Start from the chair, not from the hospital. A patient books, so there needs to be a form. A receptionist runs the day, so there needs to be a dashboard: who’s coming, in what order, what’s their status right now. A doctor needs to remember the patient, so there needs to be a record: what we did last time, what’s pending.
That is the whole list. Nothing about wards. Nothing about a billing department. Nothing that assumes a person two floors away is managing “master data” so that your receptionist can type a name into a box.
Software should be sized to the clinic it runs in, not shrunk down from one that was never built for it.
Does a dental clinic need a hundred screens, or three?
Count them. The booking form a patient fills in: a three-field form with name, phone, date, nothing to log into. The dashboard the receptionist lives in all day, with status counters she updates per booking. The patient record she taps into from that same dashboard.
Three screens. Now compare that to the demo with settings, roles, inventory, reports, a wizard to configure the wizard, forty-something screens deep, where the salesman knows the path because navigating it is his full-time job and your receptionist’s isn’t.
Three screens means a new hire learns the whole product on her first morning, no manual, no training video. Three screens means a doctor can glance at a phone between patients without hunting for the right tab. Three screens means that when something looks wrong, it is in one of three places, not somewhere inside a nested settings menu nobody has opened since installation day.
Every screen that was never built is a screen nobody in your clinic has to find, learn, or explain to the locum covering next week.
Where does the IT department fit, if there isn’t one?
It doesn’t, by design. Big clinic software assumes someone technical is on staff, or on call, to configure it and fix it when it breaks. That is a reasonable assumption for a hospital. It is the wrong assumption for a clinic with two chairs and a tablet, where the only person “good with computers” is the owner’s nephew, and he visits on Sundays.
Dentao assumes the nephew, not the IT department. There is nothing to install, so there is no server for anyone to configure. There is a link, a login, a browser. The patient types his own details into the booking form; you type your own notes into the record. There is no master data to set up before day one, no separate roles to administer because the clinic shares one login between doctor and receptionist. If something looks off, support is a message to a real person, not a ticket that gets a reply in two working days while your patients wait outside.
Software sized for a clinic has exactly as many screens as the clinic has jobs, and not one more.
Where Dentao fits
Dentao runs in a browser, on whatever is already in the room, laptop, tablet, or the receptionist’s own phone. There is nothing to install, no server, no IT visit on day one. The whole product is three screens: the patient-facing booking form, the dashboard with its five status counters, and the patient record opened from a row on that dashboard. One login per clinic, no roles to configure, no modules to turn on or off. Support, for now, is messaging the team directly; that will change shape as Dentao grows, but today it is a person, not a ticket number. It does not do billing, inventory, or a tooth chart; it was built to do the three screens well, not forty screens badly.
A clinic built like a clinic does not need a department it never had.
Try Dentao on your clinic at dentao.in.
Dentao is a booking link and a patient record for one- and two-chair clinics. Three fields for the patient, one dashboard for the desk, one file per phone number. Try Dentao on your clinic →