Tecof • September 15, 2026
AI Chatbot vs. Live Support: The Hybrid Setup for E-commerce
In Brief
An AI chatbot is software that reads a customer's question and answers it from your store's own data; live support is a person doing the same job. In e-commerce the two are not rivals but two layers of one queue: repeating questions that data can answer close in the automated layer, questions that need judgement and authority get handed to the human layer. As of 2026 the question is no longer “bot or human” but “which question sits in which layer, and at what threshold does it hand over”.
Tuesday evening, 21.40. There are 148 open messages in the store's support inbox and 96 of them are variations on a single sentence: “Where is my parcel?” When the team starts at 09.00 the next morning, the first two hours go to answering those 96 one by one. Underneath them sit the 11 messages that are actually costing sales: a sizing question, a stock question, three carts stuck at payment.
The team is not slow. The problem is that a question answerable in a second from a tracking number landed in the human queue and buried the questions that genuinely need a human. The whole point of a hybrid setup is to fix that ordering, not to cut headcount.
What the Two Layers Actually Do
The debate usually starts in the wrong place: “Can the chatbot understand the customer?” The right question is this: does the answer already exist as a record in your system, or is it the outcome of a decision?
What a chatbot closes
The chatbot's clear territory is questions whose answer is already sitting in a system. Order status, tracking number, return process, payment options, size charts, stock levels, campaign terms. What these share is that the correct answer lives in the order itself, the product record or the policy text. The model is not being creative here; it is finding the right record and writing it readably.
Its second territory is repetition. The same question asked 90 times a day is exhausting for a person and neutral for software. The third is time: a large share of orders are placed between 20.00 and midnight, and the human queue is closed at those hours.
What live support closes
The human layer exists for questions whose answer lies in a decision rather than in data. What to do about a damaged item, whether to offer a gesture on an order shipped wrong twice, how to price and schedule a business buyer's request for 40 units. None of these can be read off a record; someone with authority has to decide.
The second territory is emotion. An angry, disappointed or second-time writer is looking for a counterpart, not for correct information. Keeping that customer in the automated layer damages the relationship even when the problem gets solved.
The terms
- Deflection rate: the share of conversations that close without ever reaching a person.
- Handover: passing a conversation, with its context, from the automated layer to the human one.
- First-contact resolution: the issue closing without the customer having to write again.
- Context window: what the model can see while answering — order record, product data, policy text and conversation history.
- Escape threshold: the confidence level at which the model must say it does not know; without it, the model invents.
Cost and Coverage: The Comparison in Numbers
The case for a hybrid setup is usually made on cost, and the cost maths is usually done wrong. The right calculation measures total cost per issue resolved, not cost per message.
Split the volume into three layers
Open a month of support records and drop every issue into one of three boxes: answerable from data, answerable from policy, requires a decision. In a mid-sized Turkish store the split usually lands around 55-25-20 percent. The first two boxes are candidates for the automated layer; the third belongs to people and never reaches zero.
Automation rate: which number is real?
The “80 percent automation” figure in vendor decks is usually calculated per message rather than per conversation. If the bot writes three messages and hands over on the fourth, 75 percent of messages were automated and the issue still reached a person. The number you need is conversation-based.
The saving that gets miscounted
The gain from the automated layer is not the number of messages removed from the human queue; it is how much faster the rest of that queue becomes. When 96 shipping questions leave, the real win is that sizing and stock questions get answered in six minutes instead of two hours. That lands directly on conversion rate.
| Question type | Example | Right layer | Target response | Risk |
|---|---|---|---|---|
| Order status | Where is my parcel? | Automated | 10 seconds | Reading the wrong order |
| Product detail | Does this run small? | Automated + rules | 30 seconds | Inventing what data lacks |
| Returns | How do I return this? | Automated | 20 seconds | Promising outside policy |
| Complaint / damage | It arrived broken | Human | 15 minutes | Coldness of an auto reply |
| Bulk / B2B request | Price for 40 units | Human | 2 hours | Quoting without authority |
Designing the Hybrid: Where Does Handover Happen?
The quality of a hybrid setup is measured not by how well the bot talks but by when it stops. A chatbot built without handover rules traps the customer in a loop and manufactures complaints.
Handover triggers
Four triggers cover most of what goes wrong in practice. First, a confidence threshold: if the model is unsure, it does not write, it hands over. Second, repetition: if the customer has asked the same thing twice, the bot does not try a third time. Third, an intent list: complaints, damage, legal demands and payment failures go to a person untried. Fourth, an explicit request: the moment the customer asks for a person, handover happens regardless of any other condition.
Carrying context across the handover
Handovers break most often when the human restarts the conversation. Writing “Hello, how can I help you?” to someone who just wrote three messages reads as an insult. What must travel across: a summary of the conversation, the order number, anything the bot promised, and the customer's emotional state. The same model writes that summary; this is where it is genuinely useful.
Out of hours and queue management
If there is no one at 23.00, saying so beats a fake “connecting you shortly”. The correct design: the bot solves what it can, and where it cannot, it makes a precise promise (“Someone will reply here between 09.00 and 10.00 tomorrow”) and opens that promise as a task. Miss the promised hour and every point of trust the automated layer earned evaporates in one message.
| Trigger | When it fires | Bot's last job | What passes to the human |
|---|---|---|---|
| Low confidence | Model is unsure of the answer | Write the summary | Question + sources tried |
| Repeated question | Same intent a second time | Apologise, announce handover | Text of both attempts |
| Sensitive intent | Complaint, damage, legal | Does not attempt | Raw message + order |
| Explicit request | “Get me a person” | Immediate handover | Conversation history |
| Out of hours | Human queue closed | Promise a time | Task record + hour |
The Channel Reality in Turkey
Building one chatbot and wiring it to every channel looks elegant on paper and does not hold up in practice, because customer expectations differ by channel and the channels have different technical limits.
Expectations per channel
In an on-site chat window the customer is mid-decision; speed matters less than accuracy, and wrong information converts straight into a return. On WhatsApp nobody expects an instant reply but everybody expects a personal tone. Instagram messages are short and mostly about price and stock. Marketplace inboxes impose their own rules: response time feeds your score and steering customers off-platform is restricted.
Shipping questions and integration
The single highest-return job for the automated layer is shipping status, and it cannot be done without integration. If movement records from Yurtiçi, Aras or MNG never reach the store side, the bot can only say “here is your tracking number”; it cannot produce the sentence that actually helps — “it reached the transfer hub last night, estimated delivery tomorrow”. Carrier and ERP integrations are therefore a precondition of a chatbot project, not an add-on.
Marketplace inboxes are a different world
In Trendyol and Hepsiburada messages the customer's counterpart is the platform, not you, and return terms follow the platform's rules. Automated replies there must reflect the platform's policy rather than your own; otherwise the bot makes a promise that binds you and that you cannot honour.
| Channel | Dominant question | Expected speed | Automation share |
|---|---|---|---|
| On-site chat | Size, stock, shipping fee | Seconds | High |
| Order status, returns | Minutes | High | |
| Instagram DM | Price, stock, links | Hours | Medium |
| Marketplace inbox | Returns, invoices, defects | Platform rule | Low-medium |
| B2B requests, disputes | Hours | Low |
Measurement: Which Metrics Do Not Lie?
Most chatbot projects look successful while losing customers, because the measurement was set up wrong. A correct metric set has no more than four numbers in it.
The deflection trap
Deflection rate on its own is dangerous, because it also rises when a customer gives up and closes the window. Always read it alongside a second number: the share of customers who open a new conversation within 24 hours. If deflection and repeat contact rise together, the bot is not resolving anything, it is deferring.
CSAT and first-contact resolution
Run a one-question satisfaction check at the end of a conversation and read the result in two groups: conversations closed by the bot alone, and conversations that were handed over. The handed-over group's score is a direct mirror of handover quality. When the gap between the two groups closes, the design has settled.
The effect on sales
Measure the support layer purely as a cost centre and you will make bad decisions. Compare the conversion rate and average order value of customers whose question was answered at the cart stage against customers who asked nothing. That gap is the real justification for the investment.
| Metric | How to measure | Healthy range | Misreading |
|---|---|---|---|
| Deflection | Conversations closed without a person / total | 40-65% | Counting abandonment as success |
| 24-hour repeat contact | New conversation from same customer | Below 10% | Never looking at it |
| Post-handover CSAT | One-question survey | Above 4.2 / 5 | Reading one blended average |
| Handover latency | Trigger to human pickup | Under 60 seconds | Only checking working hours |
KVKK, Consent and the Limits of Liability
The automated layer speaks on your behalf in legal terms. A promise the bot makes binds you; “the software got it wrong” is not a defence that travels well in a field interpreted in the consumer's favour.
Promises the bot must not make
Anything that creates cost — approving a return, granting a discount, waiving shipping, committing to a delivery date — belongs in system permissions, not in prompt text. A prompt can be talked round; a permission matrix cannot. We set out that distinction in the guide to prompts and constraints. On Tecof, order, return and customer tools are exposed to agents with defined permission boundaries, so the bot can only perform what has been opened to it.
Log retention and data minimisation
Conversation records are personal data. Add to your privacy notice that automated systems are used, how long records are kept, and that the model provider acts as a data processor. Putting the customer's name and phone number in the prompt is usually unnecessary; the order number and the topic are enough.
The right to reach a human, and marketing messages
A customer must be able to reach a person whenever they ask; that is a trust condition, not a feature. Announcing a campaign inside a conversation, on the other hand, is a commercial message and is subject to consent. That check belongs in the system rather than in the bot's text; the rules on permission-based marketing apply here too.
A Thirty-Day Hybrid Rollout
Chatbot projects usually begin with a tool selection and stall there. The timeline below begins with data instead.
Days 1-7: count the queue
Export every support message from the last 30 days and tag it by topic. The output is one table: topic, volume, average response time, the data needed to resolve it. Nothing gets built this week. If the five most repeated topics do not add up to more than half the total, automation's return will be low, and it is good to know that before you start.
Days 8-14: automate the top three topics
Take only the first three, not all of them. For each, write down which data the answer comes from, and if that data is not accessible, fix the access first. In the same week write the handover rules: four triggers, one page.
Days 15-21: run it in shadow mode
Without exposing the bot to customers, have it draft replies to incoming messages. The team reviews and sends. This week teaches you, at no risk, where the bot gets things wrong. Do not go live until the share of drafts sent unedited passes 85 percent.
Days 22-30: go live and narrow the scope
Open it on one channel, for one group of topics. Read the metrics daily in the first week. If deflection climbs while 24-hour repeat contact climbs with it, narrow the scope rather than widening it. The right week to widen is the one where both metrics improve together.
Here is the job for tomorrow morning: open the last seven days of support messages, count the five most repeated questions, and mark whether each one's answer exists as a record in your systems. The ones that do are the first scope of your automated layer; the ones that do not are not a chatbot problem but a platform and data problem, and that gets solved first.
Frequently Asked Questions
Can I shrink the support team once a chatbot is live?
Usually not, at least not in the first year. The automated layer does not reduce the team's workload so much as change its mix: repeating questions fall away and decision-heavy, emotionally loaded conversations rise as a share. That means a more demanding queue per person. The gain shows up as speed and coverage, not headcount.
Should I tell customers they are talking to a bot?
Yes. There is nothing to gain from hiding it and a lot to lose: the moment a customer works it out, trust drops in both the conversation and the brand. A clear “I answer automatically and can connect you to a person whenever you want” does not lower satisfaction; it sets the handover expectation correctly.
Do I need a model trained on my own data?
For most stores, no. What you need is not retraining but access to the right sources: the product catalog, order records, carrier movements and policy texts. The jump in answer quality almost always comes from access, not training.
Who is liable if the bot gives wrong information?
You are. You are the seller in the customer's eyes, and an automated system's mistake is your mistake. That is why cost-creating promises are taken out of the bot's authority and conversation logs are retained. When something goes wrong, fast remedy is cheaper than a legal argument.
How many languages should I support?
If you do not sell abroad, one is enough. If you do, running the automated layer multilingually is far cheaper than the human layer; but the design is incomplete if nobody can answer in that language after a handover. Decide the language question by the capacity of the human layer.
Is automated replying on WhatsApp allowed?
Replying inside a conversation the customer started is fine. Messages you initiate that carry a campaign are commercial messages and require consent. The platform also has its own template and time-window rules; encode those in the sending system rather than in the bot's text.
Should bot conversations sit in the same queue as human ones?
Yes. A team working across two separate screens cannot see the history of a handed-over conversation and ends up asking the customer the same question again. One queue, one history — that matters more in tool selection than most feature lists.
Does this make sense for a small store?
Below roughly 300 conversations a month, setup and maintenance cost more than the automation saves. At that scale the right move is canned replies and a good order-status page. The chatbot decision starts to make sense once repeating questions consume more than five hours a week.
What about voice support?
It is two steps behind text. Voice systems have a lower tolerance for error, and interruptions and misunderstandings cost more. For most stores the right sequence is to settle a hybrid design in text first and then carry it to voice, not the other way round.