McKinney, TX

AI Voice Intake Agent for McKinney TX Practices

Demonstrations of voice intake are misleading, and not because anyone is being dishonest. They are misleading because a demonstration is a cooperative caller in a quiet room asking an expected question, and almost no real call is any of those three things.

Book a Demo

A McKinney practice evaluating this should be looking at a different set of things than the ones a demonstration puts in front of it. This page is that list: what to ask, what to test, and what usually goes wrong between the demonstration and the third week.

Cleod9 provides the AI Voice Concierge as part of its cloud platform for Dallas-Fort Worth businesses. It answers, asks the questions the practice defined, books where the practice's rules allow, captures requests, and transfers to a person. It sorts and routes; the practice decides.

Question one: who writes the questions?

The most important question and the one least often asked.

If the vendor writes the intake script, the practice gets something generic that has to be corrected through somebody else. If the practice writes it, the practice gets exactly what it asked for, including its mistakes, and can fix them the same afternoon.

The second arrangement is better, and the reason is that intake scripts are always wrong in the first week. Not badly wrong, but wrong in specific small ways that only real callers reveal. A question two people misread. A branch nobody anticipated. A word the practice uses that patients do not.

So the real question is not whether the script can be changed but who can change it and how quickly. Minutes, in a browser, by practice staff is a different product from a support ticket with a turnaround, even when the underlying technology is identical.

Question two: what happens when it does not understand?

Every voice path fails to understand something. What matters is the shape of the failure.

Ask specifically: what happens on a bad audio connection, on silence, on an answer that does not match any expected option, and on the second consecutive failure of the same question. Three failed attempts at one question is the point where a caller decides the whole thing is broken, so the design should never get there.

The right answer to persistent failure is a person or a text follow-up, not another attempt. Confirm that the transfer path exists, that the practice chooses where it goes, and that a caller can force it at any moment by asking.

Then test it. Call the demonstration number and deliberately mumble, answer a different question than the one asked, and go silent for fifteen seconds. How the path handles those three is more informative than the entire scripted demonstration.

Question three: where does the data go, and for how long?

A practice evaluating voice intake is evaluating a system that will hold recordings and transcripts of conversations with people who may never become patients or clients.

Ask four things plainly. Where are recordings and transcripts stored. What is the default retention period. Can the practice set its own. Can a specific record be deleted on request.

Then ask who can listen. On the Cleod9 platform, access is governed by the access control list, which means it is a configuration decision rather than a default the practice inherits. Make that decision before go-live rather than after.

Call recording runs automatically, so none of these questions are hypothetical. A practice subject to health information rules, or a firm with confidentiality obligations, should have its own compliance advisor review the vendor's answers alongside the list of what the call may collect. This page is operational guidance and not legal or medical advice.

Question four: what does it refuse to do?

A voice intake path for a practice needs a prohibition list, and the useful question is whether the system enforces one or merely tends not to volunteer things.

For a medical practice: no assessment of symptoms, no advice about medications, no view on whether something can wait, no attempt to sort by severity. The greeting opens by telling anyone facing an emergency to hang up and dial 911, before any other question.

For a law office: no legal advice, no opinion on whether there is a case, no fee quotes beyond published consultation pricing, no predictions, nothing implying the firm has taken the matter, and no case substance collected before the conflicts inputs.

Ask to see how these are configured, then test the boundary during evaluation by asking exactly the question the path should refuse. A clinician or a partner should review the finished script line by line before it goes live regardless of what the configuration says.

Question five: what does it connect to?

Intake that ends in a summary somebody retypes has moved the work rather than removed it, and the retyping is where errors enter.

Cleod9 integrates with Salesforce, HubSpot and Zoho. If the practice runs on a vertical practice management or case management system, ask Cleod9 to confirm that integration explicitly in a live configuration rather than accepting a general statement about integrations.

Where no integration exists, that is not necessarily disqualifying. It is a cost, and it should be counted honestly: how many captured records per week, how long each takes to enter, and who does it.

x-bees is included with Cleod9, and its AI transcription and summaries work on voice calls as well as chat, which at minimum means what arrives is readable rather than a voicemail to replay with a notepad.

The two-week evaluation that actually tells you something

A demonstration answers whether the technology functions. A two-week evaluation answers whether it works for this practice, which is a different question.

  • Write the intake questions first, in the practice's own words and order, before anything is configured. This document is the design; everything else is settings.
  • Write the prohibition list alongside it, which is the half that gets skipped and the half that matters.
  • Configure one path only. After hours is the usual choice, because it competes with nothing and the value is measurable on a single number.
  • Run five deliberately awkward test calls before real callers hear it: the person who answers a different question, the one who volunteers everything at once, the one who says almost nothing, the one calling on behalf of a family member, and the one who wants a human in the first three seconds.
  • Go live and read every transcript for two weeks. Not to check the technology but to check the questions.
  • Revise the wording, then widen to a second path.

Practices that follow this sequence generally reach a stable configuration in about a month. Practices that switch on several paths at once spend the same month unable to tell which change produced which result.

What usually goes wrong, and it is rarely the technology

Three failure patterns account for most disappointing rollouts.

The first is undocumented rules. Booking rules, protected calendar time and appointment durations that live in one person's head get violated by anything that books automatically, and the practice concludes the system does not work when what happened is that the rules were never written down.

The second is an unowned queue. Captured requests land somewhere nobody clears on a schedule, and a well-captured inquiry sitting unread until Wednesday has helped no one. Name the destination, the owner by role, at least two clearing times a day, and what happens when the owner is out.

The third is a script nobody revised. The launch version goes live and stays there because reading transcripts feels optional. It is the single highest-return hour anyone spends in the first month.

What to measure during evaluation

Completion rate per question, which shows exactly where callers stall. One question is usually responsible for most of the drop.

Repeat rate per question, meaning how often the path had to ask again. That is a wording problem every time.

Transfers to a person, split between the caller asking and the script deciding.

Contacts captured outside business hours, which is usually the number that settles whether this was worth doing.

Abandoned calls by hour, meaning calls that ended before reaching anyone at all.

Common questions

Do we have to replace the front desk?

No, and most practices should not. After-hours and overflow coverage changes nothing about how the office runs during the day.

Can callers always reach a person?

Yes, by asking at any point, and the practice's own rules can transfer them without waiting to be asked.

Do we keep our existing number?

Yes. Number portability is a federal requirement, so everything attaches to the number already on the practice's cards, listings and signage.

What if the internet goes down?

The routing logic sits in the cloud rather than in the building, so calls can be sent to mobile devices instead of failing. Configure that path in advance rather than during an outage.

Question six: what does it sound like to somebody who is not you?

Practices evaluate voice intake by calling it themselves, which is the least reliable test available. They know the script, they know what the questions mean, and they are listening for whether it works rather than experiencing it as a caller.

Have three people outside the practice call the number during evaluation, each with an ordinary reason, and ask them afterward one question: how did that feel? Not whether it worked. How it felt.

The answers are consistently about tone rather than function. Too formal. Too many words before the first useful question. An apology that made the caller feel like an inconvenience. A greeting that explained the system instead of getting on with it.

Those are all writing problems and all fixable in minutes, but they are invisible from inside. A practice that skips this step ships a greeting that its own staff find perfectly clear and that strangers find off-putting, and nothing in any report will ever surface it.

Ask the testers one more thing: at what point did you know what would happen next? A caller who never gets that sense stays slightly on guard, and a caller on guard gives shorter answers, which shows up later as thin intake records that somebody has to fill in by calling back.

Question seven: what does it cost when volume changes?

Worth settling during evaluation rather than discovering in a busy quarter.

Traditional answering services generally charge per call or per minute, which means the practice's busiest months are its most expensive ones and a marketing campaign that works raises the phone bill. Platform pricing usually behaves differently, and the difference matters most for exactly the practices that are growing.

Ask three things plainly. What the cost is at current volume. What it becomes at double the volume. And what happens when the practice adds a location or a provider, since that is the change most likely to arrive without much notice.

Then ask what is included rather than accepting a headline figure. Numbers, users, recording storage, transcription, texting and integrations are all places where a low base price can turn into a different number once the practice is actually using the thing.

Finally, ask what the exit looks like. Who owns the recordings and transcripts, what format they come back in, and how the numbers port out. Number portability is a federal requirement so the numbers move, but the records are a contract question, and the time to ask is before signing rather than during a change.

Talking to Cleod9

Cleod9 is a Dallas-Fort Worth provider supporting its own customers, so a McKinney practice deals with someone in the same metro rather than a distant queue. The platform is described on the Cleod9 services page.

Bring the five questions above and the practice's own intake list. A conversation structured that way tells the practice far more than a demonstration does, and it takes about the same amount of time.

Book a Demo