Automated AI Receptionist
An automated AI receptionist that qualifies website enquiries for an events hire company, so the team only picks up conversations that are ready for a price.
The client hires out stretch tents for weddings, festivals and events. Enquiries came in through the website contact form and through live chat, and almost none of them arrived with enough detail to price.
Date. Location. Guest numbers. Duration. Every one of those had to be chased by a person before a quote could be written, which meant the first real conversation with a customer was a list of questions rather than an answer.
What they asked for was an automated AI receptionist: something that captures those enquiries and qualifies them, so that by the time anything reaches the team it is ready for quoting.
What I deliberately left out
Two things were out of scope from the start: inbound phone calls, and direct emails sent outside the website forms. Both can be covered by the same approach, and both were left out on purpose rather than discovered as gaps halfway through.
Agreeing that up front is the difference between a build that finishes and one that keeps growing. It also meant the client knew exactly what they were getting before anything was built, which is how I run every project.
Intake first, cleverness second
The first step is the boring half, and it runs natively in the CRM. A form submission creates the contact, attaches the submission as a note, opens or updates an opportunity, and alerts the team.
Nothing intelligent happens at this stage, and that is the point. The record exists before any AI touches it, so nothing is lost if a later step has to be rerun.
An AI brain, not a flowchart
This is where most automations fall over. A linear workflow has to guess every path in advance, and an enquiry inbox does not behave that way. One message is a new booking request. The next is an existing customer chasing a date they already hold.
So I did not build a flowchart. I built a decision layer that holds a set of tools and works out which one a message actually needs. Each tool triggers a real workflow underneath. The branching lives in the model’s judgement rather than in a hundred hard-coded conditions, which is what stops the whole thing collapsing the first time a customer writes something nobody anticipated.
Two very different messages, the same brain:
A new enquiry that is missing detail. It runs the enquiry workflow, then checks whether there is enough to price. If something is missing it writes back and asks for it, and keeps the thread open until the answer arrives. If the enquiry already has everything, it does not invent a reason to email: it acknowledges and hands over to a person.
An existing customer chasing a booking. Same inbox, completely different job. It looks the contact up, finds the booking they are asking about, pulls any other bookings held against them, summarises the lot and answers the actual question. The customer gets a straight answer instead of a holding message.
Live chat, and then making it readable
Chat needed the same outcome by a simpler route, so that one runs natively in the CRM. The conversation is tagged by what the visitor actually wanted, summarised into notes and written onto the right opportunity, creating one if none exists.
I flagged that this opens an opportunity for chat visitors who were never going to book. The client wanted it that way, so that is how it was built.
That left two channels writing notes against the same contacts. Accurate, and unreadable. Nobody wants to reconstruct a booking from a stack of timestamped notes, so I added a clean-up pass that fires whenever a record changes: it finds the open enquiry, formats what has been captured into the opportunity’s own fields, and clears tags that no longer apply. The team reads a structured record rather than a transcript.
Nothing goes quiet
Qualified enquiries still go cold if nobody picks them up. The last piece watches the pipelines for opportunities that have sat untouched past a set number of days, alerts the team, and raises a task against the record so the chase is assigned to someone rather than hoped for.
The outcome
The back and forth that used to eat a morning now happens on its own, at whatever hour the enquiry lands. What reaches the team is a structured opportunity with the answers already in the fields.
25 hours a week came back across the team, and response times dropped 99.9%. An enquiry that used to sit until somebody started their morning is now answered as it lands.
The people who used to chase details now write quotes. That is the whole trade: not a tool the team has to operate, but work that is already done when they arrive.
Building agents that hold judgement rather than a fixed script is the core of AI Agent Development, and most enquiry handling is the same shape underneath. If yours looks like this, the audit is where I would start.