Business logic
How a store's support assistant grew out of a website chat: drafts for staff, answers opened in measured waves, questions to drivers, order changes.
TL;DR
Support Line AI Assistant is a bot that answers the customers of an online store with courier delivery, on WhatsApp and in the chat on the store's website. It sees the customer's orders in the store's platform, answers with facts taken from it, passes questions to the driver or the dispatchers, and since 30 September 2026 it changes an order itself once the customer says "yes". I started the project on 29 January 2026 with the website chat. From 31 July the bot wrote drafts for the people on the line, and on 21 September its first answer went to a customer with no person involved. Between 5 and 19 October the bot answered first in 77% of conversations, with a median wait of 29 seconds. 3% of conversations went unanswered, against 16–18% in the summer, when only people answered.
How it started
The store takes customer questions in two places: an ordinary WhatsApp number that the team answers from, and the chat on its website. The questions are nearly always the same: where is my order, when will it arrive, how do I pay, is this in stock. They come at any hour, and the people on the line answer from a phone between other jobs. In the summer of 2026 the median first reply from a person took between 2.7 and 4.4 minutes, and 16–18% of conversations got no reply at all.
The website chat came first. I made the first commit on 29 January 2026, and the first customer message arrived in the chat on 1 February. The chat answered with a model, using the store's list of questions and answers, and called an operator in Telegram when it could not cope. In its first three days the model changed twice: xAI Grok, then GPT-4o, then GPT-5.2, which the project still runs on. From March to June the same backend also ran a sales bot on WhatsApp, on separate numbers. On 4 June I turned it off with a switch, and it has stayed off.
The support line: drafts only at first
The store's main channel is its WhatsApp line. On 31 July the bot was connected to it through the messenger gateway. From that day the bot wrote a draft reply to every customer message in the operators' feed in Telegram, and only a person could send it, with one button. The bot itself sent customers nothing: the first version of the interface with the gateway had no "send" outcome at all.
Before connecting it I built a knowledge base from about 2,200 questions the line had answered before, and calibrated its thresholds on a held-out sample. The target was no harmful answers and no more than 5% wrong ones. On 61 questions the result was 0 harmful and 3 wrong (4.9%). Since 4 August the bot has seen the customer's orders in the store's platform, which has a case study of its own: Last-mile Delivery Platform.
The owner and a dispatcher check the rules
On 12 August a script turned the model's instructions into a document of how the bot answers in each situation: 85 items, each explained in plain words. The store owner and a dispatcher read it on dedicated pages and gave every item a verdict, and I read some items too. That came to 180 verdicts: 165 "right", 8 "not sure", 4 "needs a fix", 3 "must not be done". I fixed the five real errors in the bot. The review pages were switched off on 14 August and kept as an archive. The document itself lives on: it now holds 134 cards, and a test stops anyone changing a rule in the instructions without its card.
How I work
I am the only developer on the project. The code is written by Claude Code: changes, tests, and a review of every shift on the line from the log. Plans for larger changes, such as customer memory, were read by a separate Claude session before any code existed, and it found defects in them. I decide which class of answers to open, read the review of each shift, write to the bot from a test number, and approve every deploy. The rule of asking before a deploy dates from 21 September, after the agent pushed a utility script to the main branch on its own and production restarted.
In the 263 days since the first commit there have been 426 commits, with work happening on 86 of those days. More than half of them, 220 of 426, came in September and October, when the bot started answering on its own.
Who decides what the bot tells a customer?
I do. The agent proposes a change and checks it with tests and with runs against the live model, but opening a new class of answers, changing a rule or deploying anything takes my word. Every rule in the instructions has a card that the store's people can read. I read the review of each shift myself and only then decide what to fix.
The line month by month
The figures were taken on 19 October 2026 from the messenger gateway's database and the bot's log. A conversation is the messages of one chat with gaps shorter than 45 minutes, the same boundary the bot uses for customer memory. My test chat and probe messages are excluded throughout.
| 2026 | Conversations | Customer messages | Bot only | Bot and a person | Person only | No reply | First reply by a person, median |
|---|---|---|---|---|---|---|---|
| February¹ | 37 | 252 | 0 | 0 | 26 | 11 | 1.7 min |
| March | 270 | 1,515 | 0 | 0 | 230 | 40 | 1.8 min |
| April | 243 | 1,648 | 0 | 0 | 214 | 29 | 1.8 min |
| May | 128 | 641 | 0 | 0 | 116 | 12 | 2.8 min |
| June | 985 | 5,100 | 0 | 0 | 829 | 156 | 2.7 min |
| July | 1,173 | 5,641 | 0 | 0 | 960 | 213 | 3.5 min |
| August | 1,143 | 4,667 | 0 | 0 | 932 | 211 | 4.4 min |
| September | 1,048 | 4,301 | 19 | 78 | 707 | 244 | 4.6 min |
| October 1–19² | 307 | 1,788 | 117 | 122 | 55 | 13 | 0.5 min |
¹ The gateway has recorded the line since 23 February. ² A partial month.
A reply by the bot here includes a driver's or dispatcher's reply that the bot carried back to the customer. A draft sent by a person with the button counts as a reply by a person.
When the bot answers first, the median wait is 28–29 seconds, and nine conversations out of ten wait no more than 46 seconds. Twenty of those seconds are the gateway waiting to see whether the customer adds anything; the rest is the model and the checks. In September the bot sent customers 153 answers on its own, and 672 in the first 19 days of October.
Since late September the line has had fewer conversations: about 80 distinct chats a week, against 120–180 in the summer. In the same weeks the platform began putting a link to the order page, with a chat to the driver, into every order notification, and the bot began passing questions to drivers. From my own data I cannot tell how much each of these changes contributed.
How the bot answers today
Step 1. A message reaches the line
The messenger gateway receives the message and waits 20 seconds in case the customer writes more, but no longer than a minute from their first line. Then it sends the batch to the bot as a signed request, along with the last ten lines of the chat. A voice message is transcribed first; a photo is passed on as it is.
Step 2. The bot recognises the customer
The bot asks the platform who owns this phone number and what orders they have. If the platform does not know the number, the bot asks for the order number and works from that.
Step 3. Is a person already there?
If someone from the team wrote in this chat in the last 15 minutes, the bot does not answer: a person is handling the conversation. If they wrote between 15 and 60 minutes ago, the bot answers only in narrow classes: order status, payment, store rules, an order change the customer has already confirmed. An answer held back because of a person waits 15 more minutes for them and is then sent once.
Step 4. Pre-screening
Short "ok"s and "thanks", reactions and repeats are filtered out before the model. A clear thank-you gets one fixed line, everything else gets silence. A complaint, a legal question, a business proposal and a couple of other classes go straight to people. Since 6 October a request for a person gets a fixed reply: what the bot can do right here, and the office phone number for anyone who would still rather call.
Step 5. Topic and live data
A classifier compares the message with the knowledge base (3,006 sample questions across 25 topics), and the model names a topic of its own. Then the bot gathers live data: the order status, the arrival time, the link to the order page, whether the store is open, whether it delivers to the address, what is on the shelf. It takes these values from the platform exactly as they are and calculates nothing on top.
Step 6. Customer memory
If the customer has written before, the bot adds their card: a short summary, up to 12 facts about how best to talk to them and how they like to receive an order, and summaries of their last three conversations.
Step 7. The model writes an answer
The model gets the line's rules, the live data, the card and the chat history, and answers in a strict schema: the reply, the topic, whether a person is needed, whether a clarifying question is needed, and how sure it is. Where it fits, it can also propose passing the question to the driver or changing the order.
Step 8. The guard
Every answer from the model goes through a guard that checks for 22 kinds of error. Among them: a promised time that is not in the order data, a link from outside, an invented phone number, a promise to call back, "I'm a real person", and an offer to cancel an order the customer never asked to cancel. When it finds one, the model rewrites the answer once, told exactly what was wrong. If that fails too, a fixed line goes out that cannot turn out to be untrue, or the conversation goes to a person.
Step 9. The outcome
What the customer sees depends on the outcome.
| Outcome | What the customer sees | Share of the bot's decisions, 5–19 October |
|---|---|---|
| Answer | a reply on WhatsApp from the line's number, including a clarifying question or a request for the order number | 55% |
| Stay silent | nothing: an "ok", an emoji, a repeat, or a question a person has already answered | 26% |
| Draft for people | nothing from the bot; the answer waits in the operators' feed | 11% |
| Hand to a person | a line saying the question has gone to the driver or the dispatchers, or nothing if it waits for someone from the team | 9% |
Passing a question to the driver or the dispatchers is logged as "hand to a person": the person here is the driver or a dispatcher. The customer gets a line saying the question has been passed on, and later the driver's reply in the same chat.
Step 10. One last check before sending
Before the answer goes out, the gateway checks once more whether a person wrote in the chat while the bot was working. If one did, the bot's answer is not sent.
People come before the bot
The staff answer customers from the line's phone, and the bot sees their messages: they land in the same log as its own. The bot treats any message from our side that is missing from its own send log as a person's. The 15- and 60-minute windows of step 3 run on exactly that.
The bot receives every reply from a person as feedback. From those replies I collected examples of how the line answered typical questions: 42 lines across 10 topics. They do not go into the instructions yet. I had expected the examples to make the model more confident and open more answers without a person. A measurement on 28 September showed otherwise: the block would have touched 180 answers over two weeks, and every one of them had already been given with high confidence. The block would only have changed the manner of about 13 answers a day, and I left it off.
If 25 or more messages reach the line within five minutes, or 8 or more different people write, the bot sends nothing on its own. That is what a batch of old messages arriving all at once looks like, with yesterday's questions inside it, and a person should deal with it.
What the bot does with an order
Since 4 August the bot has seen the customer's orders: status, arrival time, items, the link to the order page. It takes the link only from the order data and never builds one itself.
A question for the driver or the dispatchers
Before 28 September a customer who needed the driver wrote to the line, while the driver works in the platform's app. A separate measurement by the platform on 14 August showed the gap: 81% of 324 messages from drivers to customers were never opened, and customers wrote to the driver themselves in 6.6% of orders. Since 28 September the bot passes the customer's question into the driver's chat if the order is already with a driver, or to the store's dispatchers otherwise. The bot brings the driver's reply back to the customer on WhatsApp.
Between 28 September and 19 October the bot passed on 82 questions from customers; another 30 were my test questions. 35 times it held a question back because a person was in the chat. The bottleneck turned out to be people's replies. According to the platform, 62% of drivers answered in writing within a day (median 5.5 minutes) and 42% of dispatchers (median 2.4 minutes); my test questions are included in those shares. On the dispatchers' side the "question waiting" badge went out as soon as anyone opened the conversation, and nothing reminded anyone again. On 19 October the platform changed that: a question now stays open until someone answers it or marks it handled. The "after" measurement is due in November.
Order changes after a "yes"
Since 30 September the bot can add an item, remove one or cancel an order, and since 1 October it can also move the delivery time and change the address. It first asks the customer what exactly it is changing and makes the change only after a "yes", and that "yes" has to answer the bot's latest question. For a cancellation, a "yes" next to a "no" or next to the customer's own words does not count, and the bot asks again. The change reaches the platform the same way as a dispatcher's buttons.
Between 30 September and 19 October there were 7 changes: 3 cancellations, 3 rescheduled deliveries and 1 added item. Four of them were my tests and three came from real customers. The platform refused none. It is still a small sample, and I read it as one.
The website chat
The chat has been running since February: 58–92 conversations a month, with a median answer time of about 3 seconds. If the customer is signed in, the chat and the WhatsApp line share one memory card for them. Anonymous visitors are not remembered.
Until 15 October the chat lived apart from the line: some of its answers came from a question list matched on shared words. Before the switch an AI agent graded the chat's 210 answers over 30 days: 118 right, 65 weak, 25 wrong, 2 ungraded. Word matching did worst: 10 of its 37 answers were wrong. On 15 October the chat moved onto the line's knowledge. It now answers with the model and the same live store data, reads the customer's orders if they are signed in, and goes through the same guard. For a person it sends visitors to WhatsApp and does not promise that anyone will join. There is no "after" measurement yet, only a live check of 8 questions asked twice each.
The line's voice
On 3 October the line got a tone standard: warm and professional, with no long dashes and no slang. Before that I had taught the model to write the way a dispatcher writes, and a measurement showed the cost: 58% of the model's answers had a style defect, 46% had long dashes and 33% had slang. The standard aims for under 5%. An instrument measures the standard on the log of answers, and the same check function runs in the test suite.
What went wrong and what I took from it
Drafts that nobody sent
For seven weeks the bot only wrote drafts, and people were supposed to send them. In August 1,264 drafts went into the operators' feed and 28 were sent with the button. In September it was 1,228 and 58. In September I found out why: people answer from the line's phone, and hardly anyone looks at the operators' feed. To a customer, a draft that nobody sees is the same as silence. On 3 October I changed the rule: the bot holds an answer back only when a person really is in the chat, and everything else it can answer goes to the customer. Since 5 October 3% of conversations go unanswered.
The lesson: before building a process around people, look at where they actually work.
"I'm a real person"
On 18 October a customer asked whether they were talking to a bot and was told they were talking to a real person. The rule "never say you are an AI" had been in the instructions since 29 July, when every answer was a draft and a person sent it. Back then the rule was true. Once the bot started answering on its own it became a lie, and a test kept guarding it. On 19 October I replaced it: the bot says it is the line's automated assistant and does not offer a person for that reason. The guard now catches "I'm a real person" in any answer. Against the live model, 40 runs passed without a single claim to be human.
The lesson: a rule written for one way of working has to be reread when that way of working changes, even when a green test guards it.
The wave switched off after 14 minutes
On 24 September a wave opened that answered "thanks". I switched it off 14 minutes later: two "you're welcome" replies had gone out in the middle of a live conversation about a purchase. The wave relied on a check that answered "can the bot stay quiet here?", but it was being used for a different question: "is 'you're welcome' appropriate?". I recounted the closing messages: of 85, 38 held a clear thank-you, 8 were emoji only, and the other 39 carried the conversation on. The wave was narrowed to clear thanks.
The lesson: every class of answers needs its own switch that works from the very next message. Here it did, and the damage stopped at two messages.
Before and after
| June–August: people answered | 5–19 October: the bot and people | |
|---|---|---|
| Conversations with no reply | 16–18% | 3% |
| Who answers first | a person | the bot, in 77% of conversations |
| Median first reply | 2.7–4.4 minutes | 29 seconds |
| Conversations without a person | 0 | 41% |
| A question for the driver | the customer writes to the driver | the bot passes it on and brings the reply back |
Questions people ask most
Does the bot answer when a person is already in the chat?
No. If someone from the team wrote in the chat in the last 15 minutes, the bot stays quiet. Between 15 and 60 minutes it answers only in narrow classes: order status, payment, rules, a confirmed order change. Before sending, the gateway checks once more whether a person wrote while the bot was working, and if so the bot's answer is dropped.
Can the bot invent an order status or a delivery time?
The guard catches a promised time that is not in the order data, outside links and invented phone numbers. The bot takes the status and the arrival time from the platform exactly as they are. If an answer still fails after the rewrite, the customer gets a fixed line that cannot be untrue, or the question goes to a person.
How long does a customer wait?
When the bot answers first, the median is 29 seconds, and nine conversations out of ten wait 46 seconds or less. Twenty of those seconds are deliberate, in case the customer adds something. In the summer, when only people answered, the median first reply took between 2.7 and 4.4 minutes.
What does the bot remember about a customer?
A short summary, up to 12 facts about how to talk to them and how to hand over their order, and summaries of their recent conversations. A filter strips payment details, phone numbers and addresses before anything is stored. Closed conversations are kept for a year, cards for unknown numbers for 90 days. Memory has been on since 27 September.
What the bot does not do
- It never writes to a customer first. Every message is a reply to a customer's message; the latest went 52 minutes after one, and it was a driver's reply being carried back.
- It does not promise to call back or return later: the guard catches such answers.
- It does not pretend to be a person.
- It does not answer in groups, and does not read videos, documents or stickers.
- It does not learn from people's replies automatically: the examples are collected but switched off.
- The store has no dashboard or settings: I change the rules and switches.
- There is no single command to delete everything about a customer: data goes when its retention period ends.