Automate customer enquiries without letting software make promises

Picture a parent messaging a tuition centre at 10.40pm. Is there space in the Saturday Primary 5 maths class, what does it cost, and can her son try a lesson first? The centre opens at two the next afternoon. By then she may have asked two other centres the same thing.

The owner knows a faster reply would help. What stops her automating it is usually not the quality of the drafts. It is that a message sent under the business's name cannot be taken back. A wrong fee becomes a fee she is asked to honour; "yes, there's space" becomes a seat she has promised. A playbook on automating enquiries with human approval puts the fear the same way, and its answer is a design rather than reassurance: let the software do the reading and preparing freely, and put a person at the point where something leaves the building.

Reading the question, checking the timetable and writing a draft are internal. They can run at any hour. Sending, booking and anything touching money are actions. The method below decides which of those actions need a person, and how that changes over time.

Sort enquiries by what a wrong reply would cost

Not every reply carries the same risk. Before switching anything on, sort a month or two of past enquiries into three classes by the damage a wrong answer would do.

• Fixed facts: the address, which levels and subjects run, what to bring to a trial lesson, how to reach the centre. A wrong answer is awkward but easy to correct.
• Live facts: whether a class has space, whether a make-up slot exists this week. The answer depends on a timetable that changes, so it must be read fresh and phrased with care.
• Commitments: fees for a particular arrangement, discounts, refunds, holding a seat and anything about results. These create obligations or expectations.

Then write a short never-say list: statements the software may not produce, whoever is approving. For a tuition centre it might include any promise about grades or exam outcomes, any fee not on the current fee sheet, any discount, and any sentence saying a seat is held.

Worked example: a tuition centre's first eight weeks

Consider a fictional tuition centre in Bishan with four part-time tutors and one administrator, Mei Ling. Enquiries arrive through WhatsApp and a web form, roughly 60 a week in term time. All figures here are invented.

Weeks 1 and 2: watch. The tool reads incoming enquiries and produces a daily summary: what was asked, what went unanswered, which questions repeat. It drafts nothing and sends nothing. Mei Ling learns that almost half the messages are about class availability and trial lessons.

Weeks 3 to 5: draft everything. Every enquiry gets a draft built from the fee sheet, the timetable and a one-page trial-lesson policy. Mei Ling approves, edits or rejects each one. When a draft is wrong, she fixes the document it relied on rather than the draft. The trial policy never said trials were for new students only, so drafts kept offering them to existing ones; one added sentence fixed every later draft.

Weeks 6 to 8: fixed facts go automatically. Replies in that class send without review, from approved wording, and are logged. Availability replies still wait for a quick approval. Commitments are always drafted for a person, and anything that touches the never-say list is flagged instead of drafted.

The owner decides in advance what earns a class of reply its promotion: for instance, 30 consecutive drafts approved without edits and no change to the source documents in the past fortnight. The numbers are hers to choose. What matters is choosing them before looking at the results, and being willing to move a class back down if errors return.

What can go automatically, and what always waits

A reasonable default for a small service business:

• Automatic, once proven: fixed facts from approved text, and acknowledgements that say only that a message has arrived. An acknowledgement that promises a reply time is a commitment, so keep it out of this list until you can keep that promise.
• Approval each time: availability answers, trial bookings and any reply that names a price.
• A person only: refunds, discounts, complaints, anything about a child's progress or results, and any reply to someone who is upset.

Money stays gated whatever else happens. Promoting availability answers does not loosen the rule for refunds; each kind of action keeps its own gate. That separation is what makes it safe to give routine replies more room.

Make approval quick, or it will not happen. Requests should reach the approver somewhere they already look during the day, such as the team's messaging app, so approving is a short reply rather than a visit to another screen. Name a back-up approver for days off, and decide what happens to queued drafts if nobody approves them by the end of the day.

When a parent goes quiet after a trial lesson, the next message is a sales follow-up, not an enquiry reply. It should answer whatever was left open; our guide to a follow-up that helps covers that.

Keep a record you will actually use

An audit trail is only worth keeping if it answers questions you will ask. For each enquiry, record:

• the customer's message and when it arrived;
• which sources the draft used, such as the fee sheet version or the timetable date;
• the draft, any edits, and who approved or rejected it;
• what was sent, when, and on which channel;
• whether it went automatically or with approval.

The record pays for itself in three situations the enquiry playbook also describes. When a customer disputes what they were told, you look it up instead of relying on memory. When drafts keep failing the same way, the pattern points to a missing or out-of-date document. And when you consider promoting a class of reply, you decide from reviewed history rather than a feeling.

The record contains customers' messages and contact details, so treat it like any other customer data: keep what the job needs, and limit access to the people who handle enquiries.

Common questions