Picture a front-desk manager at a mid-sized resort on Turkey’s Aegean coast: the phone rings, two WhatsApp messages arrive, and a guest walks up to the reception counter — all at the same moment. Each contact carries equal urgency; each comes through a different channel. Whoever the team answers first determines who gets ignored. Every ignored message is either a misread complaint or a future cancellation. This scenario plays out daily in the majority of Turkish coastal and city hotels. The real question is not ‘should we get a chatbot?’ The real question is: ‘what communication model are we building, and who owns it?’ Buying a chatbot before answering that question does not solve the problem — it adds a new layer of noise on top of the existing one.During fieldwork at a 312-room five-star resort on the southern coast, I counted three separate WhatsApp numbers in active use. Reception handled one, the tour desk another, management a third. Guests were sharing these numbers among themselves; messages arrived at all three, and none had centralised tracking. A dinner reservation request sent to the tour desk number sat unanswered for hours — because that number was intended for excursion bookings. The problem was not a lack of technology. It was a complete absence of channel design. The principle is simple and non-negotiable: you design the channel architecture first, then select the tool. Not the other way around.The true role of a hotel chatbot differs substantially from how most vendors frame it. A bot is not built to handle every guest need; it is built to eliminate a defined category of workload. Pool hours, spa appointment availability, check-in time, restaurant menus, parking capacity — these are recurring, standard, documented pieces of information. In a mid-sized Turkish resort property, this category of question is asked somewhere between 35 and 60 times a day across all channels. If a bot handles these queries reliably around the clock, the front-desk team recovers real capacity to deal with noise complaints, room-change requests, and medical situations. That is the legitimate use case. The limit is equally clear: a bot cannot carry emotional weight or navigate ambiguous intent. Hotels that push bots beyond this boundary do not just deliver poor answers — they actively frustrate guests who already feel unheard. Recognising that boundary before deployment is what separates a useful tool from an expensive reputation risk.The acceleration of WhatsApp adoption in Turkish hospitality during 2018 and 2019 is explained by two specific pressures rather than a general trend. First, a large share of international guests — particularly those arriving from Germany, Russia, and the United Kingdom — prefer messaging before arrival rather than placing an international call. Writing a WhatsApp message has a lower behavioural threshold than dialling a foreign number. Second, Booking.com and TripAdvisor review analysis increasingly shows explicit references to communication quality; the phrase ‘I could never get through to anyone’ now consistently costs rating points. These two pressures together pushed management teams to open WhatsApp channels quickly — but rarely with the operational infrastructure those channels require. Opening a WhatsApp Business number is not the same as running a communication operation. Behind every open channel there must be a routing protocol, a shift-handover process, and a logging system that shows who received which message, when, and what happened next. Without those, messages disappear into individual staff phones and the first guest complaint arrives from exactly that gap.Framing the choice as ‘chatbot versus live agent’ is the wrong question. A well-designed model includes both, with explicit rules governing the handover between them. In practice the architecture works like this: a guest writes via WhatsApp or web chat; the bot first attempts to classify the intent — is this an information request, an operational task, or a complaint? Information requests the bot handles and closes. Operational requests — room service, towel replacement, airport transfer — the bot logs, routes to the relevant department, and confirms to the guest with a realistic response window. Complaints and ambiguous messages go immediately to a live agent; the bot steps back entirely. This escalation path is the structural heart of the system. A chatbot without a defined escalation path leaves the guest in a void. I observed a 445-room city hotel on the Aegean coast where this architecture was never built. The deployed bot sent the message ‘I did not understand, could you rephrase?’ for three consecutive months. The property closed that period with a 24-point drop in review scores. The management team recognised the pattern only when the number arrived on a report — not before.Central visibility is the most consistently overlooked requirement. Hotels open messaging channels but rarely configure a shared dashboard, a message log, or a structured shift-handover note. Each shift manages its own messages from its own device; a late-night request never reaches the morning team; the guest explains the same issue twice. This is not only a service quality failure — it is a data loss problem. Which request arrived at what time, when was it answered, how many guests asked the same question this week — these are operational inputs that should be informing management decisions. As of 2019, systems capable of centralising this data and integrating with WhatsApp Business API exist in the market: Freshdesk, Zendesk, and several PMS-linked hospitality platforms address this gap. The pattern I see repeatedly in Turkey is that properties purchase the tool before fixing the internal process. Technology layered on top of an unresolved workflow does not resolve the workflow; it digitises the chaos.For a hotel general manager ready to move, the starting point on any Monday morning comes down to three sequential steps. The first is drawing a channel map: how many distinct phone numbers, email addresses, and social media accounts are currently receiving guest messages, who sits behind each one, and what type of request do they handle? No technology decision should precede this map. The second step is building a standard-request catalogue: which questions are asked most frequently each week, are the answers documented consistently, or does each staff member say something different? This catalogue is the foundation of both bot content and live-agent protocol. The third step is defining the escalation ruleset: which message categories go immediately to a human, what is the maximum response window for that transfer, and where is the record of the escalated conversation stored? Starting chatbot procurement before these three steps are complete is structurally equivalent to laying walls before the foundation is set. In Turkish hospitality, technology budgets are typically finalised between October and November. Completing this design work before the new season begins will consistently outperform any system assembled mid-season under operational pressure.
This article was originally published in Turkish by Gökhan MERCANOĞLU on January 10, 2019. The English edition has been reviewed and edited by the author.