In the middle of March, customer service teams at many Turkish e-commerce and financial services companies faced two simultaneous crises: inbound contact volumes climbed to three or four times their normal levels, while every agent picked up their headset and moved home. While representatives were trying to establish VPN connections from their living rooms, customer queues kept growing. In that environment, chatbot technology stopped being a convenience feature and became a structural component of operational continuity. But that shift played out smoothly in some companies and produced serious friction in others. The difference was not the technology itself — it was whether that technology had been built to handle a crisis before the crisis arrived.
The term ‘chatbot’ covers a wide spectrum, from simple rule-based decision trees to machine learning-powered conversational engines. In Turkey’s corporate customer service landscape, particularly in the SME segment, the majority of deployed systems still operate on rule-based or hybrid architectures. The bot recognises certain keywords and intents, follows predefined scenario trees, and escalates to a human agent when no match is found. This architecture has real limits: when a customer phrases a question outside the expected patterns, the bot stalls. However, the highest-volume queries during a crisis tend to be repetitive and predictable: ‘Where is my order?’, ‘How do I return this?’, ‘Why is my account locked?’ For these queries, a well-structured rule-based bot can respond faster and at a fraction of the cost of a human agent. In a crisis, that predictability is not a weakness — it is precisely the strength that makes the system useful.
During the pandemic period, e-commerce volumes in Turkey rose sharply, and with them came a surge in shipment tracking queries, delivery delay complaints, and return requests that flooded customer service channels. Several large e-commerce operators in Istanbul and Ankara were forced to rapidly reconfigure their bots: new query types were added, existing scenarios were updated, and automated tracking responses connected to carrier APIs were activated. Companies that had maintained a flexible bot infrastructure completed these updates within days. Those that had not found their bots continuing to run on outdated scenarios, giving customers incorrect or stale information. This distinction is important: a chatbot is not a system you deploy once and leave running. It is a knowledge layer that requires continuous content maintenance. Whether that layer is current at the moment of crisis directly determines the quality of the customer experience.
The dispersal of operations to home offices created a second dimension of chatbot dependency that received less attention: internal support. A significant number of mid-sized Turkish companies saw a sharp increase in IT helpdesk requests as employees transitioned to remote work. VPN setup problems, access authorisation issues, and software licence questions surged simultaneously. Some companies adapted their existing customer-facing chatbot infrastructure to serve as an internal support channel as well. At smaller scale, this adaptation can be completed quickly — but only if the underlying technical architecture of the existing bot supports it. The realistic expectation here is modest: the bot does not resolve the employee’s technical problem; it routes the employee to the correct resource or the correct person. Even that routing function, during a high-volume period, can meaningfully reduce the burden on an IT team that is itself working remotely and stretched thin.
The crisis period also made the limits of chatbot technology visible in ways that comfortable normal operations tend to obscure. Consider the situation of a Turkish cargo company during peak delivery disruptions: customers contacting support do not only want information — they want to feel heard. A response of ‘your shipment is in transit’ is not sufficient for a customer who has been waiting for hours and is genuinely frustrated. A bot cannot establish empathy, cannot interpret an exceptional situation in its full context, and cannot generate a personalised resolution. This is not a failure of the bot; it is a design reality that must be explicitly accounted for. The handoff point — where the bot ends and the human agent begins — needs to be as carefully designed as the opening interaction. In systems where this transition is poorly engineered, customers end up repeating the same information to both the bot and the agent. That friction erases much of the speed advantage the bot was supposed to deliver. The handoff scenario, in other words, is not an afterthought; it is a core design element.
For a manager currently considering a chatbot investment or trying to rapidly improve an existing system, there are several concrete decision points worth examining before committing resources. First, which query types actually dominate by volume needs to be verified with data, not assumption. Call centre logs or CRM records make this analysis possible and should be the starting point. Second, the speed at which the bot can be updated is a critical selection criterion: does adding new content or changing a scenario require IT involvement, or can the business unit manage updates independently? In a crisis, that difference is measured in days versus hours. Third, success metrics must be defined before deployment, not after: resolution rate, escalation rate, customer satisfaction scores, and average response time form the baseline of any meaningful evaluation. Without these measurements, the question of whether the bot is working remains a matter of intuition rather than evidence. Chatbots do not make customer service fully autonomous during a crisis. But when properly configured, they serve as a buffer that prevents operations from collapsing at precisely the moments when human capacity is most constrained. Whether that buffer is ready before the next disruption arrives is the decision that will matter most.
This article was originally written in Turkish by Gökhan MERCANOĞLU on January 20, 2020 and has been automatically translated into English and other languages using machine translation.