Connecting an AI receptionist to your bookings

Talking is easy, booking is the hard part

Hosted AI receptionists are a product you can sign up for. They answer calls and take messages. What they can do with your bookings depends on whether they are connected to the system your office uses, and on what that connection allows.

Without a connection, the receptionist takes a message and a person re-keys it later. With one, it can look the caller up, see their existing bookings and record the outcome where your staff will see it. The connection is an API: a controlled door into your system that another program can knock on, with rules about what it may read and what it may change.

Two ways we have built it

Both of these are running for a real business today.

Local AI. An SMS assistant that runs on SecureSpace's own servers in Perth, using Ollama. It texts customers back, books their service into the office system, moves or cancels a booking when asked, answers questions from the business's own website content, alerts staff when a person is needed, and stops when a customer opts out. No customer data goes to an outside AI service.

Hosted AI. Sophiie AI (also written Sofy AI) is a hosted receptionist for trades and service businesses. We built the API that lets it look up a customer in PayTrack by phone number, see their bookings, make a booking, and write the outcome of the call back. Every call to that API is keyed and logged, and the hosted AI sees only what the API lets it read. AutoCall, which provides voice AI agents and call routing, is connected the same way today.

PayTrack is our own product: bookings, customer records, invoicing and card payments, each business getting its own version built around how it works. Because we wrote it, we decide what its API shows and what it accepts.

What the connection has to get right

Whichever receptionist you use, the connection to your bookings decides whether it helps or causes a mess. These are the parts worth insisting on, whoever builds it.

• Identify the caller by phone number, so the receptionist works from a record, not a guess.
• Read only what is needed: the caller's own record and bookings, not the whole customer list.
• Write the outcome back where your staff already work, not into a separate inbox.
• Key and log every request, so you can see what was asked and what was done.
• Hand over to a person when the AI is out of its depth, and tell staff it has done so.
• Stop when a customer says stop.

A receptionist needs a way to hand over, and a customer who has opted out must not hear from the system again.

Questions to ask before you connect one

Ask these of anyone offering to connect one, us included.

• Where does the AI run, and does any customer data go to a third party's AI service?
• Exactly which fields can it read, and which can it change?
• Can it move or cancel an existing booking, and do I want it to?
• What does my office see after a call: a note, a booking, a flag that a person is needed?
• Is every request between the AI and my system logged, and can I read the log?
• What happens when the AI is unsure, and what does the caller hear?
• How does a customer opt out, and what stops the system afterwards?

Where you do not know the answer, the connection is not ready. That is not a reason to drop the idea; it is the list of things to design before any code is written.

How a build like this goes

We start by talking, and by drawing the system with you: who calls, what they want, what your office needs to see. Then a written plan, before any code. Then the build, in rounds you can click through on a private development site. Then we host it, back it up, and keep changing it as the business changes. One team does all of that, so when something needs to change you talk to the people who built it.