Sales follow-up with AI employees

Suppose twenty catering enquiries arrive through a website form. Each needs an answer, but the next step will depend on what the customer has already supplied. One may have enough detail for a quote. Another may still need to confirm the event date or number of guests.

Two AI employee roles give a sales team a practical place to start: one builds the sales pipeline, and the other follows up on the leads inside it. Give one employee responsibility for the working app and another responsibility for the enquiries. People can inspect both the pipeline and the messages before anything reaches a customer.

The guide below develops that setup. The suggested records, sample message and operating rules are examples to adapt, not a report of customer results or a claim that a ready-made catering CRM ships with the product.

Give the builder and the sales employee separate jobs

The builder needs to understand how the team works. Which details arrive on the form? What makes an enquiry ready for a quote? Who can confirm availability or agree a discount?

Its assignment is to build a shared place to answer those questions for each lead. Start with a pipeline view, a lead detail page and a queue of messages waiting for review. Reuse the team's existing CRM if it already holds the authoritative record; avoid making staff reconcile two competing pipelines.

The sales employee works against those records. It reads the enquiry, identifies what is missing and prepares the next response. It should leave a named owner and next action even when it cannot finish the enquiry itself.

For a small pilot, the responsibilities might look like this:

Keep enough context on every lead

A name and an email address are not enough to write a useful catering follow-up. Keep the original enquiry available alongside the event details and conversation history.

A starting lead record could contain:

• The source enquiry ID, received time and original message.
• Contact details and the permitted channel for a response.
• Event date, location, guest count and stated requirements, with missing values left blank.
• Pipeline stage, responsible owner and the next action with its due date.
• Last customer reply, last outbound message and any request to stop contact.
• The current draft, its version and the review decision that covers it.

Link separate message and delivery records where the workflow needs them. A reviewer should be able to see which enquiry a draft answers and whether someone has already replied.

If the website form is connected automatically, the intake service should recognise repeated submissions by their source IDs. A repeated event must not create a second lead and a second welcome message. Agree which customer information may be stored or sent to the model provider before importing real enquiries.

Make the first reply useful

Give the sales employee approved information about the service, including where to find current pricing and who can confirm capacity. Its first job is to distinguish supplied facts from unanswered questions.

A starter assignment could read:

Read this enquiry and its conversation history. Draft a reply using the approved catering information. Ask only for details still needed for the next step. Save the draft and any unresolved questions on the lead. Do not send, promise availability, invent a price or change agreed terms.

For an illustrative enquiry that already gives a date and a guest count but omits the venue, the draft might say:

Thanks for your catering enquiry. Could you share the event venue and whether you would like delivery only or service on site? That will help us prepare the quote. We will confirm availability separately.

The message asks for information that affects the next step. It does not ask the customer to repeat everything on the form or imply that the booking is confirmed.

Keep unsupported details out of the draft. If the customer asks whether a menu meets a particular allergy requirement and the approved information does not answer it, route that question to the responsible person.

Review messages where the work is visible

Put the enquiry, proposed reply and unresolved questions together in the app. The reviewer should be able to approve the exact message or request a specific correction without searching through another conversation.

Build a correction path into the process from the start. For example, a reviewer might ask the sales employee to remove an unconfirmed delivery promise and ask for the venue instead.

Keep the previous draft and the correction attached to the lead. A changed message needs a new review decision; approval of an earlier version should not carry over silently.

During the pilot, let people send approved replies through the team's existing email system. Automated sending requires a separately authorised delivery route. Enforce recipient, version and permission checks there, rather than relying only on an editable approved field in the app.

Record a provider's acceptance separately from confirmed delivery. If a send request times out, check its result before retrying so the customer does not receive the same message twice.

Decide what happens when a lead goes quiet

Write a follow-up policy before scheduling that work. Define how long to wait, how many attempts are permitted and when to stop. An inbound enquiry should not become permission for an unrelated marketing sequence.

Before preparing another message, check whether the customer has replied, another employee has contacted them or the event date has passed. Stop on an opt-out or closed enquiry. If there is no clear next step, give the sales lead the record and the question to resolve.

Start with a person opening the due-follow-up queue. If you later want that check to happen on a schedule, configure and test a routine; an app sitting open is not a background worker. Keep scheduled work visible, including failures and the owner responsible for them.

Start with one batch of enquiries

Test the workflow on a small batch before enabling automatic delivery. Include incomplete forms, duplicate submissions and a customer who replies while a follow-up is waiting for review.

Check whether drafts use the supplied facts, ask relevant questions and avoid promises the business has not authorised. Measure time to a reviewed first response, corrections per draft and leads left without a next action. Track bookings separately: a drafted or sent email is not evidence of a sale.

KyoubeAI is an AI operating system for organisations where people and AI employees share tasks, company data and apps. Start with one enquiry source, a shared pipeline and draft-only follow-up. The implementation guide covers the wider rollout, while the app-task guide explains how a person can assign work to an AI employee from an app.