Page types built for your facts
Office, provider and service page types shaped by how your group actually works rather than by a purchased layout.
Service file
Custom here means the page types, the data model and the integrations are built for how your group actually works. A theme decides in advance that you have one location, one booking button and one team page, and every difference from that becomes a workaround. We start from your offices, your providers, the services each office offers and the systems each front desk already runs, then build the page types those facts require. Nothing is bent to fit a layout somebody else designed for a different business.
What it costs
It pays in the awkward cases every real group has. A provider who works Tuesdays at one office and Thursdays at another. A service offered at three of your seven locations. An office with a separate surgical suite that takes its own referrals. A location whose Saturday hours change seasonally. On a theme, each of these is a manual note somebody has to remember to update in four places. Built properly, each is a relationship in the data, so the provider page lists both offices, the service page lists the three that offer it, and the finder never sends a patient somewhere the service is not available.

Group front desks rarely all run the same software, and pretending otherwise is how requests end up in a shared inbox. We connect each office to the destination it actually uses, by API where one exists and through Zapier or Make where it does not, and every request carries the office, the provider and the service as structured fields rather than free text in a message body. If one office migrates to a different practice management system next year, only that office's routing changes and the rest of the group carries on untouched.
The reason groups end up on themes is the fear that custom work becomes unmaintainable and needs replacing. That happens when custom means a pile of one-off pages. Ours means a small set of page types generated from your records, so growth is data entry rather than development: an eleventh office, a new specialty, a provider who joins. All of it is a revision, included in the monthly fee. There is no rebuild bill in year three, because there is nothing about the site that decays. The design can be refreshed without touching the structure underneath it.
Custom work invites feature requests, and some of them make a website worse. We will argue against a patient login you do not need, an online payment flow that belongs in your practice management system, a symptom checker of any kind, and any feature that stores clinical detail on a marketing site. We do not build tools that give dental or medical advice, and we will not put outcome claims or success rates on a page. Saying no to those is part of the work, and it keeps the site fast, simple and defensible.
Who it is for
Groups whose offices, systems or services do not fit a standard template: different practice systems per office, referral routes, specialty mixes.
Symptoms
How the work is done
The same four steps for every service. The only thing paid before launch is the first month.
Pick a plan and pay the first month. That is the whole commitment; the $797 build fee waits until your site is live.
Thirty minutes with your operations lead: offices, providers, services, brand, where each office's requests should go, and hub or one site per location.
We design the site, write the pages, configure the finder for each office and connect each front desk. You review, we revise.
Your site goes live in 7, 10 or 15 days depending on the plan. Only then is the $797 build fee invoiced. Weekly updates start the same week.
Timeline
Counted from the onboarding call, not from purchase. Revisions after launch are completed within 2 to 5 working days.
Cost
Custom integrations per office are inside the plan. Usage-based costs such as AI minutes on the AI Engine are billed at cost; nothing else is metered.
What's in each plan
What each feature does, the everyday problem it removes, what you have to do (usually nothing), and which plan carries it.
Out of scope
So nobody is surprised after ordering. Each of these is a deliberate line, not an upsell waiting to happen.
We do not write treatment recommendations, success rates, outcome claims or before-and-after captions. Your clinicians own every statement about care.
Request forms ask for a name, contact details, the office, the service and a preferred time. Medical history, insurance IDs and consent forms stay in your own intake system, never on the website.
We build pages that are fast and relevant enough to be good landing pages for your ads. Running and bidding on the campaigns themselves stays with you or your ads partner.
We route requests into the system or CRM each office already uses, by API, Zapier or Make. We do not sell, host or administer the practice software itself.
We use the office and team photos you own and have consent to publish, sized for their slots. Where you have none yet we use neutral, non-clinical images until yours arrive.
There are none. One fee covers every office in the group; extra revisions beyond 5 a month are a flat $20 each.
Reviews
We expected a prettier website; what we actually use every day is the new form. It collects preferred office, visit reason and callback number up front, so the back-and-forth we used to do by reply has largely gone. Most mornings I can prepare for the callback from the first message alone.
Got Inquiry form and response workflow for dental office selection
The idea that visitors could sort themselves before writing seemed obvious only in hindsight. The sender picks the route, which means the best-informed person does the sorting. The morning triage is minutes rather than an hour.
Got Inquiry categories and guided navigation for dental office selection
We approved the new dental office selection form only after trying hard to break it. Labels stay put, errors explain themselves, and valid answers survive a failed attempt. It behaves the way we assumed forms behaved, until we tested the old one.
Got Form usability and error handling for dental office selection
Built in, not bolted on
A dental website carries obligations a brochure site does not. These ship with every plan, written for your practice and reviewed by you before launch.
These pages and practices help you meet common US requirements for a dental practice website. They are not legal advice, and we recommend your own counsel reviews the policies before launch. We are not a dental practice, dental group, dentist or healthcare provider, and we are not a law firm.
A privacy policy and site terms written around what your site actually collects, drafted for your review and your counsel's sign-off. Built with state privacy laws such as the CCPA in California in mind.
Analytics and marketing tags load only after a visitor agrees, and the cookie policy lists what the consent banner controls.
Real contrast ratios, visible focus states, keyboard navigation and alt text, built with the Americans with Disabilities Act (ADA) and WCAG 2.2 AA in mind, plus a statement telling patients how to report a problem.
Request forms are designed not to collect health information. That keeps the website out of your HIPAA scope as far as a website can be, while your intake system handles records.
Where a form or the AI Engine sends texts, consent wording sits next to the phone field, and we file the A2P 10DLC carrier registration for you on plans with the AI Engine.
Service pages and articles say they are general information, not a diagnosis or treatment plan, and send patients to your providers for anything about their own care.
Risk reversal
Each promise is written with its condition in plain sight, so nothing is discovered after the invoice.
The $797 one-time build fee is invoiced after launch, once you have seen the site live and are happy with it.
Condition The first monthly fee is paid up front to start the plan.
Every page we build scores at or above the target on mobile and desktop at launch.
Condition If a page drops below it because of our work, we fix it at no charge and it does not use a revision.
The site starts ranking for local searches in your area within the window.
Condition If it has not, we keep working on it at no charge. We never promise a specific position.
Deliverables
Office, provider and service page types shaped by how your group actually works rather than by a purchased layout.
Providers to offices, services to offices, so the finder and every page stay consistent without anyone maintaining them.
API, Zapier or Make into each office's system, with the office, provider and service sent as structured fields.
Referral intake, insurance panels, seasonal hours or a surgical suite page, built when your group actually needs one.
Growth is a revision. New offices, new providers and new services are data, not a development project.
We will tell you which requested features would slow the site, duplicate your clinical software, or amount to advice.
Thirty minutes
We open a site built for a group like yours, walk the pages a patient would, and tell you which plan fits. Plans from $137 a month; the $797 build fee is invoiced after launch.
Case studies
No. 01Oral surgery
For dental office selection, whoever opened the inbox first had to chase the missing details before the message could be passed on. On a busy day, that follow-up alone could push an answer into the next morning.
10 working days
No. 10Multi-location groups
With dental office selection, subjects gave nothing away. The morning sort consumed the hour that answering should have had.
15 working days
No. 14Cosmetic dentistry
With dental office selection, visitors re-entered correct information because the form would not say what was wrong. The less patient simply left.
15 working days
It is the same build. Every ChairsideWeb site is custom-coded around the group it is for; there is no template tier and no premium tier for custom work. The plans differ by what runs alongside the site, which is the AI Engine and the Content Engine.
In most cases yes, by API where the system exposes one and through Zapier or Make where it does not. Tell us the systems in use per office on the onboarding call and we will confirm the route for each before the build starts.
That is the normal case and it is handled per office. Each front desk keeps its own destination, and a migration at one office changes only that office's routing.
No. Those belong in your practice management software, which is built to hold clinical and financial records. The website hands requests to those systems and does not store clinical detail.
Live in 7 days on Chairside, 10 on Operatory Suite and 15 on Group, measured from the onboarding call rather than from purchase. The one-time build fee is invoiced only after launch.
Yes, on Operatory Suite and Group. The AI Engine is configured per office, with each office's own greeting, providers and booking destination.
No. Forms are designed not to collect health information, and requests are passed through to your own systems rather than stored on the site.
Yes. If one office moves to a new system, only that office's routing changes, as a revision.
A live walk-through of the site you would get, in about 30 minutes. Plans from $137 a month, the $797 build fee invoiced only after launch, domain and hosting included.
Book a demoOr email and a person replies within one working day.
ChairsideWeb uses the cookies below. Necessary cookies keep the site working and cannot be turned off.
Saved on this device only. Press Esc to close.