Asked before every contract.

Every engagement is one fixed build fee. What it comes to depends on how many locations you run, which channels get connected, what has to be integrated, and your call volume. We map that on the first call and come back with the quote in writing before anything starts. After handover the system runs on your infrastructure and there is nothing further owed to us. No hourly billing, no open-ended retainer.

Because you are not buying seats in someone else's product. You are giving a supplier access to your phone line, your calendar, your client records and your booking rules, and that build is different in every business. A published tier would either overcharge a single practice or badly undercharge a group, so scope and price are agreed for your case instead.

It gets quoted as its own stage before anyone writes code for it. The original quote stands for the original scope. If we find something during the build that changes the answer, you hear it the week we find it, not in the invoice.

No. The system is built into what you already run. It reads live availability out of your scheduling software and writes confirmations back into it, so your front desk keeps working the way it works today.

Then we say so during scoping rather than after the invoice. With an open booking interface the system reads availability and writes the appointment back directly. With a partial one it does everything permitted and hands the last step to a named person with the whole conversation captured. With a closed one it answers, qualifies and prepares the record, and the booking stays manual. Which case you are in is established by looking at the live system, not by asking the vendor.

A first production workflow usually launches in two to six weeks. Bigger rollouts go out in scoped stages, and each stage is quoted on its own. The variable is almost never the conversation. It is what the scheduling system permits and how fast the escalation rules can be agreed and written down.

Access to the scheduling system, your service list with durations and prices, the rules your front desk already follows, and one person who can decide. That last one matters more than the rest. Projects stall on nobody being able to approve a wording change, not on engineering.

That is your decision and it is written into the configuration before launch, not left to the model. In several markets disclosure is a legal requirement rather than a courtesy, and the rules differ by jurisdiction and by sector. We build to the rule that applies to you.

It escalates, and how it escalates is the part that matters. A transfer that drops someone into a queue with no context is worse than voicemail. The system hands over who is calling, why, what has been established and what is still open, so the person picking up starts informed.

It replies in the language the client wrote or called in. Coverage is confirmed during scoping against your actual client base rather than promised as a list.

It listens for two weeks before it answers anything, which gives you a real baseline instead of a story. Where traffic allows, we hold back a slice the system never touches, so seasonal movement does not get mistaken for impact. Results come back in your own numbers: show rate, rebook rate, recovered contacts, utilization by hour.

On your infrastructure, in the region you specify. You pick where recordings and transcripts sit. Processing records and data minimization are in place from day one, and data processing terms are issued at contract. After handover we are not a subprocessor, because nothing routes through us.

No. getmai.ai is an AI engineering company that builds custom intake, retention, conversation analysis and planning systems for appointment-based businesses, founded by Ekaterina Shalel. It is not affiliated with getmyai.ai, getimg.ai, getmee.ai, get-mai.com, Microsoft MAI, or mai.co.