AI Intake for a DFW Professional Office: Chatbot vs Intake Form

A dentist, a small law office, and a two-provider clinic walk into the same sales call. Each one gets shown a chat bubble in the corner of a website. Each one is told it will capture leads around the clock. Two of the three did not have a question-answering problem. They had a follow-up problem, and the chat bubble does not fix that.

This is worth separating carefully, because the two products get marketed with the same words and cost very different amounts of money to get wrong.

What is actually broken in most small offices

Before the solution, the specifics. In a small professional office, new business usually arrives through four doors: the phone, a contact form, a referral email, and whoever walks in. Those four doors almost never lead to the same place.

The phone goes to a person who writes on a sticky note. The contact form goes to an inbox that one staff member checks and nobody else can see. The referral email goes to whoever the referrer happened to know. The walk-in gets a clipboard, and that clipboard gets typed into the practice management system later that afternoon, or the next morning, or Monday.

So the same information gets captured four different ways at four different levels of completeness, and then somebody retypes all of it. The cost shows up in three places: information that arrives incomplete and has to be chased, inquiries that sit for a day or two before anyone responds, and staff hours spent transcribing things that were already typed once by the client.

Notice that none of those three problems is “visitors have unanswered questions.” That matters, because the unanswered questions problem is the one a chatbot solves.

What a chatbot actually does

A chatbot sits on your website and answers questions using whatever you have fed it: your service pages, your hours, your policies, your FAQ. Modern ones are genuinely good at this. Ask it whether you take a particular insurance and, if that fact exists in what it was given, it will find it and answer in plain language.

What it is doing is deflection. It reduces the number of times a human has to answer the same twelve questions. That is real value when the volume is real. If your front desk fields sixty calls a day and forty of them are hours, location, insurance, and parking, a chatbot buys back meaningful staff time.

If your front desk fields eight calls a day, it does not. You have bought an expensive way to answer two questions, and the two people who wanted to become clients this week still fell through the same crack they fell through last week.

What an intake system actually does

An intake system is unglamorous by comparison. It is a structured form, sometimes conversational and sometimes not, that collects the specific fields your staff need in order to act. It validates those fields as they are entered so the phone number is a phone number and the date of birth is a date. Then it puts the result where your team already works and tells a specific person that it is there.

That last clause is the whole product. Not “captures leads.” Puts the structured result into the system your staff already open every morning, and notifies a named human who owns the response.

The AI part, where it helps, is narrow and specific: reading a messy free-text description and sorting it into the right category, pulling structured fields out of an uploaded document so nobody retypes an insurance card or a filed petition, flagging the submissions that look urgent, and drafting the first response for a human to approve. That is document intelligence pointed at intake. It is not a personality in a chat bubble.

The comparison, plainly

These are not mutually exclusive. A larger practice may want both, and the chatbot gets considerably more useful once the intake system exists underneath it, because then the conversation has somewhere to hand off to. The order matters though. Build the capture and routing first. The conversation layer on top of nothing just produces friendlier dead ends.

How to tell which one you are being sold

Four questions, and you can ask them on the first call.

1. Where does the submission end up? If the answer is “our dashboard,” you are buying a second place to check. The right answer names a system you already use.
2. Who gets notified, by name and role? If the vendor has not asked you this, they are not building intake. They are installing a widget.
3. What happens when it does not know something? A good answer describes a handoff. A bad answer describes confidence.
4. What do I own at the end? Ask whether you keep the workflow and the data if you stop paying. The answer tells you whether this is a build or a rental, and both can be fine as long as you know which one you agreed to.

What it costs

Published numbers, because comparing them should not require a discovery call.

• One well-defined intake workflow: $3,000 to $5,000 to build. You own it.
• Two or three connected workflows: $7,500 to $15,000.
• Ongoing management, optional: $1,500 to $3,000 per month.
• Hourly: $100 per hour development, $150 per hour consulting.

Set that against what the problem currently costs you. If a staff member spends forty-five minutes a day retyping intake, that is roughly a full working week every quarter. The math is usually not close. The reason it still does not get fixed is that retyping never shows up as a line item anywhere, so it never competes for budget against things that do.

What breaks

Two failure modes, and both are about people rather than technology.

Nobody owns the inbox. The build works, submissions arrive correctly, and then someone leaves and the notification keeps routing to their address for five months. This is the most common way a working system quietly stops working. The fix is boring: notifications go to a role, not a person, and somebody checks quarterly that the role still maps to a human who is employed.

Validation is too loose and trust erodes. Junk submissions accumulate, staff learn that the queue is mostly noise, and within two months everyone is back on the phone while you keep paying for the thing they stopped opening. Tighter validation up front feels unfriendly and is worth it.

If your data touches protected health information, where it is stored stops being a technical detail and becomes the constraint that decides the whole architecture. That question gets settled before anything is built, not after. Self-hosting the components that touch the data is one way to keep the answer simple, which is part of why I run my own infrastructure.

Where to start

Not with a vendor. Spend one week counting. How many new inquiries arrived, through which of the four doors, how long until someone responded, and how many had to be chased for missing information. A tally sheet at the front desk is sufficient.

If most inquiries arrive complete and get answered same day, you do not have an intake problem and nobody should sell you one. If the count says otherwise, you now have the specific numbers that tell you which of the two products you are actually shopping for, and you will not be talked into the other one.