Rules first, so the answers stay consistent. AI second, for the fuzzy natural language. Every path has to be able to reach a human.
Plenty of shops run a LINE Official Account that stops at auto-reply equals keyword matched to a canned message.
One extra question from a customer and nothing comes back, so in the end a human watches all of it anyway.
This guide walks you through turning auto-reply into a system you can actually rely on:
Answers that have to be word for word go to rules.
Fuzzy natural language goes to AI.
Both sides get a safety net, and anything neither one catches goes to a human.
By the end you will have three things:
First, the skeleton of the whole message pipeline, from signature checks and deduplication to member state and sending the reply.
Second, where AI is actually worth putting, instead of letting it answer at random.
Third, the quality design that keeps the system out of trouble after launch.
Every node in the flow chart below opens up, showing what it does, how to design it, and how to test it.
The three views are: the full skeleton, where AI belongs, and how to build it well.
Click any node for the detail. The node you have selected turns gold.
Three ways to handle it
Through the gate or not
The shared data layer under the whole pipeline
Receives text, images, stickers, locations, button postbacks, friend adds and other events.
Define which events you support first. A format you do not support needs a clear message back, never a silent failure.
Prepare one test payload per event type and confirm each one is recognized and tracked correctly.
Ask yourself one thing first: does this question have a single correct answer?
How: a rule engine with a database or an API. Predictable, easy to test, cheap.
How: retrieval augmented generation (RAG) with structured output. AI is never the source of truth for data.
Six steps to a high-quality auto-reply system, done in order.
List the top 20 questions, the data each one needs, and the success and failure exits.
Put AI at the front and the usual result is a customer asking your opening hours and getting a beautiful wrong answer. Rules run first so the answers that have to be word for word stay consistent, though consistent is not the same as true, and someone still has to maintain the data behind the rules. AI runs second, to catch the phrasings the rules miss. The gate sits last, because even when both earlier layers are sure they are right, something still has to ask whether this message is really safe to send. One exception worth remembering: payments, cancellations and anything else that changes real data needs its confirmation and authorization before it runs, not a check after the fact.
Three shared foundations get overlooked. With no versioning on the knowledge base, answers stay stuck on a policy from six months ago. With no timeout on session state, a user who comes back the next day gets yesterday's follow-up question. With no logs, the only way you ever learn the system broke is a complaint.
This page covers the skeleton and the thinking behind it. To actually run the system in production, with real customers and real money, there is a reliability layer I have not opened up here:
Queue depth and retry monitoring, accuracy tracking per intent, citation checks on AI answers, conversation-level traces, reproducible model and knowledge base versions, an emergency kill switch and an event replay tool.
Do not let that list scare you at the start. Build the rule layer solidly along the skeleton above, send everything high-risk to a human, and you can start safely. Once volume grows and money is involved, come back and fill this layer in, or find someone who has done it to check your work.
I have built full LINE Official Account auto-reply for shops, from the intent list to the human handoff.
See the services