Booking enquiries need an assistant, not a free rein

What shipped

TechCrunch reported on a powerful personal AI assistant that can connect to email, messages, calendars and other apps, then act on a user's behalf. The article focused on privacy and security concerns, including broad data access, unclear retention and the risk of an assistant making commitments for the user.

For an Irish SME, the useful lesson is not that every business should copy a consumer assistant. It is the opposite. If you want AI to help with bookings, you do not need an all-access agent that can roam across inboxes, screens and private data. You need a narrow workflow that answers common booking questions, checks the right availability source, asks sensible qualification questions and hands over anything uncertain to staff.

That is a good fit for workflow design. The practical version is an appointment and booking enquiry assistant for chat, email or WhatsApp. It reads an incoming enquiry, identifies the service requested, checks a calendar or booking sheet against agreed rules, drafts a reply with suitable slots or next steps, and creates a structured hand-off for the team.

The human review step should be named and designed, not left vague. In this case I would call it Human Booking Review. The assistant provides decision support. A staff member reviews, tests and approves bookings, cancellations or changes before confirmation is sent where required.

Who should care

This is relevant if your team spends too much time on the same scheduling messages. Typical examples include clinics, training providers, professional services firms, trades with call-out windows, salons, repair businesses, tourism operators, private tutors and any service business where customers ask roughly the same questions before booking.

The pain is familiar. A customer asks if there is a slot next Thursday. Staff reply with two options. The customer answers the next day, by which time one option is gone. Someone asks whether the service is suitable for their case, whether a deposit is needed, whether parking is available, or whether they can reschedule. None of these questions is difficult, but they interrupt the day and stretch a simple booking across several messages.

The gain is not replacing customer service. It is reducing the avoidable back and forth. Common enquiries can be answered in minutes rather than hours. Staff still handle exceptions, awkward cases and commercial judgement.

This also matters because booking touches personal data. Names, phone numbers, appointment reasons and availability can be sensitive, especially in health, financial, legal or family contexts. The answer is not to give a general assistant unrestricted access to every mailbox. The answer is to design the workflow around the minimum data needed, clear approval rules and a record of what was proposed.

If you are reviewing this for your own business, start with workflow design support from Artellis, not with a software shopping list. The main decision is what the assistant is allowed to see, suggest and send.

A worked example

Take a 35-person training company in Galway that sells first aid, manual handling and safety courses to SMEs. Enquiries arrive through the website chat, email and WhatsApp. Some people want to book a public course. Others want an in-company session. Many ask the same questions: dates, group size, certificate validity, location, price and whether the trainer can come onsite.

The current process sits between a shared inbox, a spreadsheet and a calendar. Two administrators answer messages when they can. If a trainer needs to be checked, the enquiry is forwarded. If a customer is not sure which course they need, there may be three or four messages before a useful proposal is made.

A booking enquiry assistant could be designed like this.

First, every incoming enquiry is classified. Is it a public course booking, an in-company request, a reschedule, a cancellation, a price query or something outside scope? The assistant extracts the requested course, preferred date, location, number of learners, urgency and contact details.

Second, it checks a controlled availability source. That might be a test calendar, a booking table or a simple list of upcoming course dates. It does not need access to every staff member's email. It only needs the availability data relevant to the booking journey.

Third, it asks missing qualification questions. For a public course, that might be the number of places and preferred date. For an in-company course, it might be site location, learner count, course type and whether the customer needs weekdays only. The assistant can draft a short reply rather than sending a long list of questions.

Fourth, it applies approval rules. Low-risk replies, such as providing course dates or asking for a missing learner count, may be sent after a quick staff check during the pilot. A booking that takes the last available place, changes an existing booking, applies a discount, confirms an onsite trainer or deals with a complaint goes to Human Booking Review.

Fifth, the hand-off is structured. Instead of asking an administrator to read a long thread, the assistant presents: customer name, request type, proposed slot, missing information, policy checks, confidence level and draft response. The staff member can approve, edit or reject.

This is also where privacy concerns are handled in the process, not as an afterthought. The assistant should not retain more message content than needed. It should not train a model on customer messages unless that has been deliberately agreed and documented. It should have limited access, tested prompts, a clear escalation path and a log of suggested actions.

A useful pilot would run internally first. Staff paste or forward real examples into a test environment. The assistant drafts responses and booking proposals, but nothing goes to customers until reviewed. After two weeks, you can measure response time, correction rate, common failure points and whether staff trust the hand-off. For more on keeping AI practical rather than theoretical, see the Artellis AI insights library.

Where I'd start

Pick one booking journey. Do not start with every service, every channel and every exception. Choose something frequent and bounded, such as new customer appointments, public course bookings, discovery calls or service call-outs.

Write the rules before connecting tools. What counts as a qualified enquiry? Which slots can be offered? How much notice is required? When is a deposit needed? Who can approve a cancellation? What words should never be used in a confirmation? Which cases must always be escalated?

Then connect a test calendar or booking table. Keep it separate from live operations at first. Feed in past enquiries and check whether the assistant extracts the right details, asks the right questions and avoids making promises it should not make.

Name the review step: Human Booking Review. Make it visible in the workflow. The assistant can propose, summarise and draft, but a person reviews and approves before operational use, especially for bookings, changes and cancellations.

Finally, run a small pilot with staff before exposing it to customers. Measure minutes saved, faster replies, fewer back-and-forth messages and the number of cases that need escalation. If the pilot works, expand one channel at a time.