EXPO 2027 in Belgrade is a practical point by which businesses in Serbia should review the whole customer journey: from the first call or message to booking, the visit, feedback and a repeat enquiry. If requests sit in separate inboxes, employees transfer data manually and changes are confirmed late, increased workload will make these breaks more apparent.
Preparation is not limited to large hotels. It concerns apartments, restaurants, event venues, tourism and transport companies, beauty salons, wellness centres, service businesses and B2B suppliers. The exhibition itself does not guarantee increased demand or revenue for every business. Decisions should reflect location, audience, sales channels, seasonality and the team’s actual capacity to serve additional volume.
What is known about the scale of EXPO 2027
The specialised EXPO 2027 Belgrade is due to take place from 15 May to 15 August 2027. The programme is planned for 93 days and its theme is “Play for Humanity: Sport and Music for All”. The organiser expects more than four million visits across the full period. This distinction matters: it is an expected number of visits, not four million unique international guests, buyers, bookings or hotel nights.
For businesses, the event’s duration and the possibility of uneven demand matter. The volume of enquiries may depend on programme dates, the area of the city, transport access, the company’s profile and the composition of its audience. It is therefore better to assess future volume using a business’s own data and several scenarios, rather than one overall figure.
Expansion of hotel supply and related infrastructure is being discussed in connection with the exhibition. Yet business automation for EXPO 2027 should not be a short-term measure for three months. A well-selected process can remain useful after the event, during tourist seasons, conferences, business travel and work with returning customers.
Why preparation does not end at the hotel desk
The guest journey consists of connected services. A person chooses accommodation, checks arrival rules, looks for a restaurant, transport, an event or an everyday service. An organiser needs participant registration, a venue, contractors and timely communication. A supplier of equipment or catering needs agreed volumes, documents, deadlines and responsible employees. A failure in one link creates extra calls and manual work in the others.
The starting point should not be the question of where to add artificial intelligence, but a map of current operations. Where does an enquiry arrive? Who receives it? Where is availability checked? Which system holds the confirmed booking? What happens after rescheduling, cancellation, lateness or a dispute? Who can see unanswered enquiries? If these rules are not defined, a new interface only moves confusion between employees faster.
Fragmentation is especially risky for small and medium-sized businesses: a website form sends an email, a message remains on an administrator’s phone, a call is not recorded, and a booking is added manually to a spreadsheet. Management then sees only disconnected parts of the picture. Business process automation by VMTech can connect enquiry channels, CRM, tasks, reminders and analytics while retaining human control over exceptions.
The guest journey: from the first question to a repeat enquiry
A working scenario can be viewed as a sequence of states. A guest contacts the business in one of the languages selected and tested in advance. The system or an employee clarifies the service, date, number of people and special conditions. Availability is then checked, an enquiry or booking is created, confirmation is sent and, where the rules require it, a reminder is issued before the visit. After the service is provided, the outcome is recorded and feedback is handled.
Every enquiry should have one current record. Changing a date updates the existing booking rather than creating an unnoticed duplicate. A cancellation releases the resource and triggers the required action. A request for early check-in, special meals or accessibility should not remain solely in a long message thread. The responsible employee needs context, current status and an understandable next step.
This logic applies to hotels, restaurants, events and salons, but the rules differ. A room is booked for several nights; a table for a specific time and number of guests; a treatment according to its duration and the specialist’s qualifications. Event participation may depend on registration category and capacity. There is no universal model without configuration: automation must cover the specific scenario and its constraints.
Hotels and apartments: where voice automation is useful
When employees are busy with guests on site or the working day has ended, an incoming call should not disappear without being recorded. A voice agent can receive routine enquiries around the clock: answer pre-verified questions, collect request parameters, communicate approved property rules and pass a task to the responsible person. If a connection to a current availability source has been technically confirmed, the scenario can check data and act only within authorised limits.
Multilingual automation is useful when an international guest finds it difficult to explain a request quickly in Serbian or English. For each selected language, terminology, service names, pronunciation, date confirmation and recognition quality need separate testing in real call conditions. A voice agent should not be assumed to understand every language, accent, ambiguous context or non-standard request.
Handover to a person is a required element of such a solution. A complaint, payment dispute, medical situation, disagreement about accommodation rules, complex group booking or a request with unclear conditions requires a responsible decision. The scenario should stop, retain the collected context and transfer the enquiry rather than invent an answer. The published AI Call Center 24/7 project shows VMTech’s practical work with voice automation, but the parameters of every new implementation are assessed separately.
Events, restaurants, salons and wellness
For an event, an automated chain can include registration, checking available places, confirmation, changing the time, reminders and assignment of a task to an employee. Special participant requirements are sent to the responsible person. Instead of manually compiling reports from several spreadsheets and inboxes, the organiser receives an overall view of capacity, confirmed registrations, cancellations and unresolved questions.
For a restaurant, important details include the number of guests, visit time, duration of table use, possible prepayment and lateness rules. For a salon or wellness centre, they include the selected service, specialist, treatment duration, preparation and rescheduling. Automatic confirmations and reminders remove repetitive actions and help prevent enquiries from being lost, but they do not guarantee that guests will not fail to attend. If rules exist only in an administrator’s memory, they must first be agreed and documented.
A complete multichannel system is not necessary for everyone. With low volume and a high share of individual requests, it can be excessive. Sometimes it is enough to organise the enquiry form, shared calendar, statuses and notifications. The scale of the solution is determined by how often operations repeat, the cost of an error, the number of channels and management’s need for consolidated analytics.
CRM as the process’s working memory
CRM is useful when it reflects the real state of an enquiry. A customer profile should provide contact history, request source, agreed parameters, status, the responsible employee and the next task. This reduces dependence on an administrator’s personal memory and saves a guest from having to explain the situation again to every person.
CRM does not need to retain every piece of information without distinction. Before implementation, the business should determine which data are truly needed, who can access them, where they are transferred and when they are deleted. Call recordings, documents, payment information and sensitive requests require a separate security assessment and consideration of applicable data-processing rules. Automation does not remove this responsibility.
Website, telephone, messages, booking and operational tools can be connected using available APIs, webhooks, file exchange or a controlled database connection. Compatibility must not be inferred from a system’s name. Documentation, access rights, supplier limitations, reference-data quality and behaviour on error must be checked first. The principles of such a connection are examined in more detail in the article on CRM and ERP integration without manual data transfer.
What should happen when a failure occurs
Integration reliability is not determined only by successful data transfer. The team must understand what happens if one system becomes unavailable. It needs an operations log, duplicate protection, safe retries, notification to the responsible person and a manual way to restore the chain. A confirmation may have been sent by the system, but that alone does not prove that the booking was created correctly in the primary system.
Three realistic implementation levels
1. A pilot for one scenario
Start with one repeatable, measurable flow: a missed call, an availability enquiry, a service appointment or a visit reminder. Record the initial state, permitted actions, exceptions and the verification criterion. Such a pilot makes it possible to assess the data and the team’s work before connecting all channels.
2. A connected operational workflow
The next level brings together the enquiry, customer profile, booking, task, confirmation and exception control. Employee roles, common statuses and error monitoring are important here. The process needs an owner accountable for the rules and outcome, not only a specialist maintaining the technical tool.
3. A multichannel architecture
A broader option connects calls, forms, email, messages, CRM or ERP, booking, payment and analytics. It is justified where channels genuinely form one customer journey and their separation creates operational problems. Cost and timing depend on the number of systems, interface availability, data quality, security requirements and the number of exceptions. They cannot be determined before an engineering assessment.
Before, during and after EXPO: three operating modes
Before EXPO, document the rules, clean reference data, appoint responsible people and test the pilot under normal load. Test not only a successful booking, but also cancellation, rescheduling, duplication, an incorrect contact, an unsupported language and an unavailable connected system. Launching the entire architecture immediately before a peak period increases risk to current operations.
During EXPO, focus on monitoring new and unprocessed enquiries, the exception queue, employee workload, integration errors and current availability. The team needs a clear manual mode for a failure. Changes to critical scenarios should be made in a controlled way, with the ability to return to the working version.
After EXPO, temporary rules can be removed while retaining useful elements: a unified customer profile, correct statuses, enquiry history, reminders, analytics and a tested handover to a person. Collected contacts should not automatically become an open-ended marketing database. The possibility of further communication must be checked against the purpose for which data were collected and applicable restrictions.
What should not be automated blindly
An autonomous scenario should not be given decisions with a high cost of error: disputed refunds and compensation, serious complaints, medical questions, conflicts, suspected fraud, non-standard contractual terms and actions involving sensitive data. The system can collect facts, classify a request and create a task, but an authorised employee should make the final decision.
Automating unstable rules is also risky. If employees define availability, a discount or cancellation terms differently, technology will not remove the contradiction. The business must first agree the rule and appoint the responsible person, then transfer it into the scenario. The practical criterion is simple: a routine enquiry proceeds predictably, an exception is not lost, and the employee receives sufficient context to decide.
Owner’s checklist before technical assessment
To make an implementation discussion specific, prepare a factual picture of current operations:
- the channels through which calls, messages, enquiries and bookings arrive;
- normal and expected peak load for each channel;
- the languages to support and enquiries that are immediately transferred to a person;
- where current availability of rooms, tables, places or specialists is held;
- the CRM, ERP, telephone, payment and operational systems in use;
- whether they have documented interfaces and the required access rights;
- the rules for confirmation, rescheduling, cancellation, lateness and refunds;
- what data are needed, where they are stored and who can see them;
- who handles exceptions and what the team does in a technical failure;
- the measurable criterion for continuing, changing or stopping the pilot.
VMTech can review enquiry channels, CRM, bookings, tasks, notifications and analytics as a connected working workflow. An engineering assessment begins by checking specific systems, data and constraints. It does not assume compatibility, a fixed price or a universal timeline in advance.
The main preparation principle
Business automation for EXPO 2027 makes sense when it removes repetitive manual data transfer, helps prevent routine enquiries from being lost and leaves employees in control of non-standard situations. A sensible starting point is one process that can be tested before workload grows. Channels and systems are then connected where the connection genuinely improves the work.
Preparation thus becomes more than a one-off campaign around the exhibition. The company retains a clear customer journey, usable CRM history, controlled integrations and data for later decisions. Long-term value is determined not by the number of tools connected, but by how predictably the business receives a request, performs the promised action and handles exceptions.
