Customer enquiries via messenger: what can be automated – and what can’t
I wanted to find out how far customer enquiries via chat can sensibly be automated, and built the process as a prototype using a car repair shop as the example. Three scenarios, one clear limit.
This is what a morning in a car repair shop can look like: the phone rings while someone is lying under a car. Messages keep coming in on the side. Whether there is still an appointment free next week. Whether a courtesy car is available. And one time: that the brakes have been making a strange noise since this morning.
Most of these messages are answered quickly. But someone has to read them, sort them and reply, often in between two other jobs. And one of them is not routine.
Customer enquiries via messenger can be sensibly automated where standard cases are clearly described, the necessary company knowledge is available and it is defined when a person takes over. Handing over to an employee is not a flaw in the system, but part of a good process.
The question
Not “chatbot, yes or no”, but: which message needs a person?
Some customers prefer to write rather than call, for example via WhatsApp. For a business, that is another channel that has to be read and answered.
What interested me was not whether a chat can be automated, but which enquiries can be reliably handled without an employee, and how a system recognises that it had better stop. To answer this not just in theory, I built the process as a prototype using a car repair shop as the example. The chat is only the surface. What matters is the process behind it.
In brief
- What
- A prototype that answers customer enquiries in a chat, reserves an appointment or hands over to a person.
- Example
- A car repair shop.
- Built
- Three scenarios: workshop knowledge, appointment request, safety-critical case.
- Person
- Takes over as soon as an enquiry is safety-relevant.
- Status
- Demonstrator. Not in use with any client, no measured results.
Built
Three scenarios
The prototype covers three situations. The chats below are re-enacted: the texts are fictitious, but the process in each scenario matches the prototype. Each chat comes with the process, showing who is acting at any moment: the customer, the system or a person from the workshop.
01 · A question with a fixed answer
Many questions have an answer that rarely changes: is there a courtesy car? How can I pay? The prototype answers organisational questions like these directly from the existing workshop knowledge.
- Customer asks an organisational question
- Matching information in the workshop knowledge
- Direct answer
Can I get a courtesy car while my car is in for its service?
- Workshop knowledge: courtesy car
Yes, there is a courtesy car for services, as long as one is available. It’s best to let us know when you book the appointment.
And can I pay by card on site?
- Workshop knowledge: payment
Yes, by debit or credit card.
02 · An appointment request
An appointment request needs more than an answer. The prototype recognises the request, asks for a missing detail, checks available slots, offers them and reserves the one chosen. Where the available slots would come from in a real business depends on how it plans its appointments.
- Customer wants an appointment
- Request recognised, missing detail asked for
- Available slots checked
- Customer chooses
- Appointment reserved and confirmed
Hello, I need an appointment for a tyre change. Is next week possible?
Of course. Which vehicle is it for?
A Golf, 2019 model.
- Available slots checked
These slots are free next week:
Wednesday at 14:30 works.
- Appointment reserved · Wed, 14:30
That’s booked in. See you on Wednesday at 14:30.
03 · A question that is not routine
The third message looks like the others: short, with a question at the end. But only someone who looks at the car can give a reliable answer. The prototype recognises that the enquiry is safety-relevant, gives no assessment of its own and hands over to a person.
- Customer describes a possible safety problem
- Recognised as safety-relevant
- No assessment of its own
- Handover to a person
Since this morning the brakes squeal when I brake and the pedal feels soft. Is it still safe to drive?
- Recognised as safety-relevant
Someone from the workshop should look at this in person. I’m passing your message straight on to our team.
- Handed over to the workshop teamFrom here on, a person replies.
The limit
The most important case is the one where the system stops
A system that generates text would find an answer to the question about the brakes, too. That is exactly what should not happen here. Wrong information about opening hours is annoying. Wrong information about roadworthiness is something else.
Good automation recognises when it should not carry on.
That is why the limit belongs to the solution and not to its margins. The prototype is meant to handle standard cases and to recognise when an enquiry belongs in the hands of a person. For me, that is not a restriction but the most important part of the process.
Research on human–machine interaction describes this as a question of how tasks are divided: Parasuraman, Sheridan and Wickens (2000) distinguish between acquiring and analysing information, deciding and acting. Each of these functions can be automated to a different degree. In the prototype, the system recognises the request and prepares it; in sensitive cases, the decision stays with a person.
The principle
What can be transferred
Take the workshop out of the picture and you are left with a pattern that occurs in many businesses:
A message arrives and is automatically recognised and classified. In the standard case, the system answers it using existing knowledge. If the enquiry is sensitive, an employee takes over and replies personally.
Standard case
- Enquiry (system)
- Recognise (automated)
- Classify: standard question (automated)
- Use knowledge, take action if needed (automated)
- Reply (system)
Exception
- Enquiry (system)
- Recognise (automated)
- Classify: belongs with a person (automated)
- Employee takes over (human)
- Reply (system)
Whether the pattern works in a given business depends on three conditions:
- The standard cases are clear. Which questions and requests keep coming up, and what is the right answer or action in each case?
- The knowledge is available and kept up to date. Opening hours, services, procedures: an answer is only as good as the information it is based on.
- The limit is defined. Which topics always go to a person, and how does the employee find out?
Whether the effort pays off for a business is a separate calculation. How to set it up is described in the article When is process automation worth it?
Conceivable
Where the principle could fit outside the workshop
The following examples are not completed projects, but possible transfers of the pattern. Whether they make sense in an individual case depends on the process and the existing systems.
- Trade business: It would be conceivable to pre-qualify requests for maintenance or inspection appointments before someone calls back.
- Service provider: The same principle could answer recurring questions about the procedure or the documents required.
- Business with fixed appointments: Depending on how appointments are planned, bookings could be prepared via the chat.
- Specialist retailer: Conceivable would be answers on opening hours and collection, or pointing out who the right contact is for a question.
Possible further developments
The prototype could also be extended in the workshop. None of this has been implemented:
- Collect details before an appointment so the workshop is prepared.
- Reschedule appointments without anyone having to call back.
- Answer questions about the status of an ongoing job, provided the workshop software makes this information available.
- Pass enquiries that are not handled automatically straight to the person responsible.
- Send service reminders or status updates. Messages that a business sends on its own initiative, however, raise questions of their own, for example about customer consent and the rules of the respective channel, and would need to be examined separately.
Which of these are worth it only becomes clear from the specific process. Not everything that is possible also makes sense.
Status
What the prototype is, and what it isn’t
The prototype is a demonstrator. It is not in use with any client, and there are no measured results.
For a real business, several questions would first have to be answered: which channel customers write through, where available slots come from, who maintains the knowledge that answers are based on, and how customers’ data is handled. These decisions depend on the systems and processes of the business in question. A prototype doesn’t answer them.
If a business uses an AI system for answers like these, there is an additional legal question: under Article 50 of the EU AI Act, systems that communicate directly with people must, since 2 August 2026, be designed so that the people concerned learn that they are talking to an AI, unless this is obvious. What that means in an individual case would have to be clarified for a real deployment.
A prototype shows that a process can work. Whether it holds up in everyday use is only shown by putting it into use.
Takeaways
What I take away from it
- The interesting question is not whether a chat can answer enquiries, but which ones. The answer lies in the business, not in the technology.
- The limit has to be defined before you build. Which questions are passed on is a decision for the business.
- An answer is only as good as the knowledge behind it. Which information a business releases and keeps up to date matters more than the tool.
If you are considering whether a process like this would be the right place to start in your own company, you will find criteria in the article Which process should you automate first?
Sources
Model according to which automation can take over individual functions to different degrees – here: recognising and preparing automatically, deciding with a person.
Since 2 August 2026, AI systems that interact directly with people must be designed so that the people concerned are informed of this, unless it is obvious.