The moment that forces this decision is usually a resignation letter or a renewal invoice. A front-desk coordinator gives notice, or an answering-service contract comes up for renewal, and someone in the business has to decide within about two weeks whether to repost the job, re-sign the contract, or configure an AI receptionist and see if it holds.
Here is how we help clients weigh it. Reposting the job costs you three to four weeks of CVs and trial shifts before anyone is useful on the phone, and the phone is unanswered the whole time. Re-signing an answering service costs you another year of message-taking, which is not booking. Configuring an AI receptionist costs you one working afternoon plus a few days of supervised testing, and if it fails you have lost a week and can still repost the job. That asymmetry is why most operators try the configuration first. It is the cheapest experiment on the table.
So this piece is the configuration itself, in the order we actually run it when we set up MindyOne for a clinic, salon, or property agency. Not the philosophy of AI reception. The screens, the fields, the toggles, and the decisions that sit behind each one.
One honest note on timing before we start. Published industry guidance for AI receptionist deployments generally puts basic configuration at 15 to 30 minutes and a build with real integrations at up to three hours, with a further 15 minutes of active testing across the first day. Those are general benchmarks for the category, not MindyOne's own published figures, and our lived experience is that the software time is never the bottleneck. The thinking time is. Budget an afternoon for the whole thing and you will be comfortable.
Gathering your inputs before you open the dashboard
Every configuration screen you are about to fill in wants information that lives in someone's head. Collect it first and the build runs in one sitting. Skip this and you will half-configure eleven screens and finish none.
What you need in front of you, in a document or on paper:
- Your full service list, and just as importantly the services you do not offer but get asked about weekly.
- Prices or price ranges you are willing to state on the phone, and the point at which the answer becomes "that needs a consultation".
- Opening hours per branch, including Friday variations and Ramadan hours.
- Staff or practitioner names, specialities, and working days.
- Your booking policies: cancellation window, deposit rules, late arrival, no-show consequence.
- The phone numbers that will receive transfers, and who is on call on which nights.
- Login access to your calendar and CRM, because you will be asked to authorise connections mid-build.
That last one derails more sessions than anything else. The person configuring the assistant is rarely the person who owns the calendar admin account, and everything stops while someone hunts for a password.
Sorting your call types once, quickly
You need a short list of call types before you can build routing rules, because routing rules are just call types with a destination attached. Pull a week of call history and group it. In a clinic you will land on something like: new booking, reschedule, cancellation, insurance question, price question, results follow-up, supplier call, emergency. In a salon: booking, reschedule, price, walk-in availability. In a property agency: viewing request, availability, price. Then mark each one as resolved by the assistant, captured and handed off, or transferred immediately. The third category deserves proper thought rather than a guess, and we have written the failsafe logic out in detail in our piece on emergency handoff scenarios. Read that, decide your list, come back. Fifteen minutes.
Creating the assistant and setting its voice and identity
The first screen in MindyOne asks for the assistant's identity: business name, assistant name, industry, and primary language. These feed the default prompt scaffolding, so answer them properly rather than accepting placeholders you will forget to change.
Voice selection sits on the same screen. Play each option out loud on a phone speaker rather than laptop speakers, because a phone line compresses audio and a voice that sounds warm through headphones can sound thin through a handset. Pick for clarity over character. Callers forgive a plain voice; they do not forgive one they have to strain to parse.
Latency settings and why you should not push them
There are audio and response settings here that let you trade quality for speed. Leave them at the high-quality defaults unless testing shows you a problem. Response delays past 300 milliseconds start to feel unnatural to callers, which is the number that matters, and the defaults are tuned to sit under it. What actually creates perceived lag in real deployments is a knowledge base so large the assistant hunts through it, or an integration call to a slow calendar API. Fix those rather than fiddling with audio settings.
Running English and Arabic together
Most of our UAE clients need both. Set the primary language to whichever your callers open in most often, and enable the second as a supported language rather than building a separate assistant. Callers here switch mid-sentence and a single bilingual assistant handles that far better than two monolingual ones behind a language menu. The configuration trap: enabling a second language does not translate your knowledge base. You have to enter the Arabic answers yourself. Have a bilingual staff member read them aloud before go-live, because formal written Arabic often lands stiffly when spoken and the whole point is that the caller relaxes.
Loading the knowledge base so the assistant stops guessing
The knowledge base is the section where you will spend most of your build time, and it is where the difference between a useful assistant and a polite one is decided. An AI receptionist without a properly loaded knowledge base is a well-mannered new hire who has never worked at your business. Fluent and wrong.
MindyOne accepts documents, pasted text, and a website crawl. Use the crawl last, if at all. Website copy is written to persuade, and an assistant working from marketing language will answer an insurance question with a sentence about award-winning care. Paste in your own answers instead, written the way you would say them out loud to someone standing at the counter.
Structuring entries so retrieval works
Keep entries short and single-topic. One entry per service, one per policy, one per branch. A single wall of text containing everything about the business retrieves badly, because the assistant pulls the whole block and answers around the edges of the actual question.
The entries we insist on in every build:
- An explicit not-offered list. The single highest-value entry in the whole knowledge base. Wrong bookings come from services you do not do, and a caller who is told plainly that you do not do implants will accept a referral gracefully. A caller who discovers it in the chair will not.
- Price entries with a stated boundary. Give the range and the escalation trigger in the same entry, so the assistant knows both the answer and its limit.
- Per-branch hours and directions. Which entrance, which floor, where to park. These are the questions that eat front-desk time and nobody ever writes them down.
- Policies in plain sentences. Cancellation window, deposit, late arrival, missed appointment.
Think of it the way a hotel trains a night porter. You do not hand them the brochure. You hand them the sheet that says the pool closes at ten, the shuttle leaves on the hour, and if a guest asks for late checkout you say you will check rather than saying yes. Bounded authority, written down. That is a knowledge base.
The confidence setting nobody adjusts
There is a behaviour control governing what the assistant does when it cannot find an answer. The default in most systems is to attempt a helpful reply from general knowledge. For a service business, set it to decline and hand off. An assistant that says it will have someone confirm and takes a number is doing its job. An assistant that invents a price is creating a refund conversation for you in three weeks.
Writing the greeting and the intent scripts
The greeting editor is a single text field and you will rewrite it more than anything else in the build. Ours land in the same shape almost every time: business name, one warm line, one question that moves the call forward. Nothing else. No menu of five options, no mission statement.
The reason is that callers start talking the moment they think it is their turn. A greeting that runs fifteen seconds before asking anything gets talked over, which garbles the first turn and sets a poor tone for everything after it.
Configuring what each intent collects
Under conversation settings, each intent gets a list of fields the assistant must capture before it can complete. Booking needs four: name, service, preferred day or time window, contact number. We regularly inherit setups asking for eight, including date of birth and how the caller heard about you, and you can watch the abandonment happen in the transcripts.
The exact wording of those questions decides whether a call ends in a booking or a callback request, and we have covered that in depth rather than repeating it here: start from the seven questions that separate revenue from runaround, and check your phrasing against the script most businesses get wrong. Paste the wording straight into the intent fields.
Two settings we enable on every build. Confirmation read-back before any booking is written, so the service, time, and practitioner are repeated once. And a hard instruction against quoting anything not present in the knowledge base.
Building routing rules and after-hours behaviour
The routing rule builder is where your call-type list becomes configuration. Each rule is a condition and a destination. MindyOne can route on department, individual, location, keyword, or detected caller intent, which is the standard lever set for serious systems and the reason call routing setup is consistently the more involved part of any deployment. Multi-branch businesses feel it most.
Build them in this order, because rules evaluate top down: emergency keywords first, then location, then intent, then a catch-all. Get that order wrong and a caller saying they are in severe pain about the Jumeirah branch gets routed on location instead of urgency.
Assigning destinations that actually ring
Set an on-call number per rule, not one number for the whole business. In a two-branch salon, a caller asking about Jumeirah should not be reaching the Al Barsha manager at nine at night. Configure notification preferences per team member in the same panel, and verify that every destination is a phone somebody answers. A handoff into an unanswered line is worse than no handoff at all, because the caller has been told help is coming.
After-hours mode is a booking mode, not a message mode
This is the toggle that pays for the system. Set your business hours in the schedule panel, then configure the after-hours profile to do three things: state that you are closed, book into tomorrow's calendar anyway, and escalate emergency keywords to the on-call number as a live transfer rather than a notification.
Every call that used to reach voicemail at 8pm on a Thursday was a booking somebody else took on Friday morning. Voicemail, keypad menus, and hold queues cannot compete with an assistant that answers, because none of them can take a booking. If you configure nothing else well, configure this.
Connecting the calendar, the CRM, and the reminder sequence
Everything up to here produces an assistant that talks well. The integrations panel is what makes it useful. Three connections matter, in this order.
Calendar. Authorise the connection, then select which calendars are bookable and which are read-only. This is where most misconfiguration happens. If you leave a staff member's personal calendar in the bookable set, the assistant will offer their lunch break. Set buffer time and minimum notice here too: a fifteen-minute buffer and a two-hour minimum notice stops the assistant from booking someone into a slot that starts before they can drive there.
CRM. Map the fields explicitly rather than accepting the default mapping. Name, phone, service interest, and source at minimum. The value is that a returning caller is recognised, so the assistant can reference the existing appointment instead of asking a patient to explain who they are.
WhatsApp. Connect the number the assistant will send confirmations and reminders from. This is the connection with the fastest payback in the whole build.
The reminder sequence, and why it is the first thing to wire
If you only configure one integration properly, make it this. Reducing no-shows is the fastest return available in appointment-based automation and it is not a close race. An empty chair at 3pm is revenue that never comes back, and a reminder message costs almost nothing to send.
Set three sends: confirmation at the moment of booking, a reminder the day before, a reminder the morning of. Each carries a one-tap reschedule link. That link is the point. Without it, a customer who cannot make it simply does not show. With it, they move the appointment and you refill the original slot.
Where you deliberately leave the human in
Automate the repetitive, personalise the meaningful. Reminders, confirmations, availability, hours: automatic, always. But after a first consultation, after a complaint, after any treatment that mattered to the person, a staff member sends the follow-up personally. Clients who automate that last touch get the worst of both worlds: callers who feel processed and staff with nothing distinctive left to do.
The same reschedule, before and after
To make the configuration concrete, here is one workflow traced twice. Take a patient with a Wednesday afternoon crown fitting who calls just after closing on Tuesday evening to move it. This is illustrative, drawn from the pattern we see repeatedly rather than a single client's record.
On the manual front desk
The call rings out to voicemail. Most callers under forty leave nothing. The coordinator arrives Wednesday morning, works the voicemail box between walk-ins, calls back, gets no answer, leaves a message. They connect somewhere in the afternoon, by which point the appointment is too close to refill and they agree on next week instead. The chair sits empty because nobody knew it was free until the afternoon. Several call attempts, a good chunk of coordinator time, no revenue produced.
With the configuration above in place
After-hours mode answers on the second ring. The CRM connection recognises the number and the assistant references the existing appointment rather than asking who is calling. The patient asks to move it; the calendar integration reads back two genuine openings; the patient picks one; the booking is rewritten before the call ends. The original slot is released that same evening, so the waiting-list message goes out overnight and the slot refills before the clinic opens. The patient gets a WhatsApp confirmation immediately and a reminder on the morning of the new appointment. The coordinator arrives to a dashboard note explaining what happened.
Same call, same patient. The delta comes from three specific settings: after-hours profile set to book rather than message, calendar connection with write access, and CRM lookup on inbound number. Nothing clever happened. The call was simply answered when it was made.
Verifying it works before you trust it with the main line
Do not port your primary number on day one. Run the assistant on a secondary number, forward a portion of calls to it, and read every transcript. Gradual rollout is not timidity. It is how you discover the three phrasings your callers actually use that you never thought to configure.
The test pass itself is short and specific. Call during business hours and check the greeting sounds like your business rather than a template. Call after hours and confirm the after-hours profile engages and still completes a booking. Speak one of your emergency keywords and confirm the transfer fires to a phone that physically rings. Then add your team to the dashboard, assign their on-call numbers, and set notification preferences. Published guidance puts that verification pass at roughly 15 minutes of active time, and it is the least expensive quarter hour in the whole project.
Reading transcripts in week one
Daily for the first week, then weekly. Four things to look for, each mapping to one specific fix:
- Calls where the assistant said it did not know. That answer goes into the knowledge base.
- Calls where the caller repeated themselves. Rewrite that question in the intent script.
- Calls ending with neither a booking nor a handoff. An intent is missing entirely.
- Handoffs nobody answered. The routing rule points at the wrong phone.
Do that for two weeks and the assistant stops being a configuration and starts being the front desk. Then, and only then, port the main line.
As for the fork we opened with: the answer for most operators is not fewer people at the front desk. It is people who spend their mornings with whoever is standing in front of them rather than working a voicemail box.
If you are weighing a front-desk hire against automating the phone line, we will go through your call log with you and say plainly which calls a MindyOne AI receptionist should take and which should always reach a person.
