An AI enquiry workflow should take an incoming request, organise the relevant facts and prepare the next useful action for a named owner. Start with draft replies and reviewed follow-ups. Add automatic sending only after the business has defined the authority, stopping rules and recovery process for that specific action.
The workflow ends with a verified outcome: a qualified conversation, an agreed appointment, a clear decline or a human handoff. It does not end when AI generates a friendly message. This guide uses an illustrative service-business enquiry so the same structure can be adapted without assuming a particular inbox or CRM.
Define the enquiry record before the automation
Create one record for each enquiry. It should contain the contact reference, request, source, current stage, owner, last interaction and next action. Store only information needed for the job. Keep the original message available to the people authorised to review it.
Agree what counts as a qualified enquiry. For a service business, that might mean the requested service, location, timing and enough context to judge fit. A person can be interested without meeting those conditions. Do not label every submitted form as qualified.
Give AI current business facts and a narrow task
Supply the approved services, service area, hours, qualification questions and escalation rules. Date those facts and assign someone responsibility for keeping them current. AI should mark a missing answer rather than silently filling it from a plausible guess.
A useful instruction is: extract the request, list missing facts, draft one reply and identify the next owner action. Keep customer text separate from the business instructions. OpenAI’s safety guidance recommends treating untrusted text carefully and keeping approval controls around tool actions.
Separate the states people need to act on
Suggested states are New, Needs details, Ready for review, Awaiting customer, Qualified next step, Closed and Exception. These are operating suggestions, not built-in capabilities promised for a particular product. Choose names your team will use consistently.
Every change needs evidence. A request becomes Ready for review when required details are present. A booking is confirmed only when the booking system shows the agreed reservation. A sent email is not evidence that the customer accepted anything. Keep both the event and its meaning visible.
Make the approval boundary explicit
During the first pilot, have the owner approve every external reply. They check the recipient, facts, tone and proposed commitment. Missing information, a complaint, a price exception or a request outside the approved scope should produce a clear human handoff.
If you later automate a routine response, define the exact conditions it must satisfy. Limit the systems it can change and keep an activity record. The option to send a message does not imply authority to offer discounts, accept a contract or change a reservation.
Follow up from the current record
A follow-up task should recheck the enquiry immediately before sending. Has the customer replied? Has someone already contacted them? Has the enquiry closed? Has the person asked to stop? If any of those conditions changes the next step, the old message must not go out.
Agree a restrained follow-up policy suited to the conversation and applicable contact permissions. This is an operational design choice, not permission to market to every address you hold. Useful follow-up adds the agreed information or asks a relevant question; it does not manufacture urgency.
Handle duplicate events and failed actions
An integration may receive the same event again. Give each incoming event an identity and prevent it from creating duplicate records, messages or tasks. After an uncertain send result, check the provider status before retrying. A timeout does not prove that nothing happened.
When a connection fails, preserve the enquiry and surface the issue to its owner. Show what is known, what failed and what needs doing manually. A visible exception is safer for the customer journey than a successful-looking status with no supporting record.
Walk through one illustrative enquiry
Imagine a customer asks a studio for a website by the end of the month. The message gives no scope, existing website or launch requirement. AI records the request and drafts questions about those missing details. The owner checks the draft and sends it.
When the customer replies, the enquiry moves to review. The owner decides whether it fits an approved offer or needs custom discovery. The workflow records the chosen next step and closes the earlier reminder. It does not invent a price or promise the requested date.
If the customer goes quiet, the owner follows the agreed policy. If they decline, the record closes and scheduled chasing stops. The useful result is a clear status that another team member can understand, with the customer’s actual response preserved.
Measure the full handover
Track time to the first useful response, the proportion of enquiries with an owner, missing-detail resolution, qualified next steps and corrections. Review replies that were fast but wrong. Keep completed bookings, accepted proposals and received payments as separate downstream outcomes.
OpenAI’s evaluation documentation describes traces and repeatable evaluations for examining agent behaviour. The practical lesson for this pilot is to inspect the whole run, including handoffs and failures, rather than judging one generated answer in isolation.
Start with the free AI Workflow Starter Kit. It includes a prompt and tracker for a supervised pilot. If your enquiry path still depends on one person’s memory, use a diagnosis to decide which handover needs fixing first.
Sources & further reading
AI-assisted Klarnow editorial analysis. Sources checked on 31 October 2026. Workflows, sample sizes and financial examples are illustrative recommendations, not client results or guaranteed outcomes.