Portfolio

EasyVoyage

EasyVoyage was an intelligent travel chatbot for Skype, Viber, Telegram, Facebook Messenger and web chat, helping users discover tours through natural conversation.

Client
EasyVoyage
Industry
Travel / tour aggregation
Project type
AI / multi-messenger travel chatbot
Period
Historical (~2017–2019)
EasyVoyage project visual

Overview

EasyVoyage was an intelligent travel chatbot created for Skype, Viber, Telegram, Facebook Messenger and web chat. Instead of asking users to navigate complex tour catalogues, it turned travel discovery into a guided conversation inside channels they already used every day.

The chatbot was the product’s primary interface. Behind it, a substantial aggregation platform collected and organized offers from tour operators so that the conversation could lead to real, relevant travel options rather than generic scripted answers.

The product, website and chatbots are no longer active. This case documents the historical platform and does not provide obsolete download or service links.

Travel discovery as a conversation

Searching for a holiday usually begins with an idea rather than a complete set of filters. A traveler may know the approximate dates, budget or preferred climate without knowing a specific resort, hotel or operator.

EasyVoyage was designed to work with that natural starting point. The chatbot asked focused follow-up questions and gradually translated the user’s intent into structured search criteria.

Instead of confronting travelers with a large form, the dialogue could move progressively through factors such as:

  • destination or preferred type of holiday;
  • departure city and travel dates;
  • number and composition of travelers;
  • approximate budget;
  • accommodation and meal preferences;
  • other details needed to narrow the available offers.

This conversational model made a complicated search process feel closer to speaking with a travel consultant.

One chatbot across major messaging platforms

Historical project materials record EasyVoyage across Skype, Viber, Telegram, Facebook Messenger and web chat. Supporting this range allowed customers to begin a travel enquiry without installing a dedicated application or learning a new interface.

Each messenger had different interaction components and technical constraints, but the travel logic needed to remain consistent. DigitalTouch created a shared conversational experience while adapting buttons, messages and transitions to the capabilities of each channel.

The web chat extended the same concept to visitors who arrived through a browser. Together, these interfaces made the chatbot available both inside existing conversations and on the public web.

Beyond a scripted FAQ bot

EasyVoyage was not designed only to answer a fixed list of questions. Natural-language recognition helped the system interpret travel requests and extract useful intent from ordinary messages.

Guided scenarios provided structure when a request needed clarification, while free-form input made the interaction feel less like completing a rigid questionnaire. The chatbot combined both approaches: understand what it could, ask for missing details and use the resulting criteria to search the travel data behind it.

The quality of the bot depended on maintaining context across the conversation. Dates, budget, travelers and preferences had to work together rather than being treated as unrelated messages.

An aggregation engine behind the chatbot

The travel market contains large amounts of rapidly changing information. Destinations, departure cities, dates, accommodation, room categories, board types, availability and prices may all be represented differently by each operator.

EasyVoyage addressed this fragmentation by creating an aggregation layer between operator data and the traveler. Its job was not merely to copy offers into one page, but to make information from different sources usable within a shared product model.

The platform needed to support a continuous cycle:

  1. Collect current information from tour-operator sources.
  2. Interpret and normalize different data structures.
  3. Store offers in a common system.
  4. Make the resulting catalogue searchable and understandable.
  5. Expose relevant information through web and messenger interfaces.
  6. Refresh or retire offers as source information changed.

This data layer gave the chatbot substance. It was the engine behind the experience, while conversation remained the primary way users interacted with the product.

Normalizing a fragmented travel vocabulary

Aggregation becomes useful only when offers can be compared. Different operators may describe equivalent destinations, hotels, room types or meal plans using different naming conventions and identifiers.

The platform therefore needed a consistent internal representation of travel information. Normalization helped prevent the catalogue from becoming a list of duplicate or incompatible records and allowed filters and conversational questions to operate across multiple sources.

The exact ingestion mechanism for each operator is not preserved in the public project record. Sources may have differed, so the case does not claim that every integration used a formal API, data feed or automated parser. What is confirmed is the broader aggregation responsibility: collecting tour-operator information and presenting it through one system.

Turning dialogue into relevant tour options

Travel discovery is naturally multi-criteria. A useful result depends on the combination of destination, dates, departure point, party composition, budget and accommodation preferences.

EasyVoyage transformed details collected during the conversation into a manageable set of relevant offers. The bot helped users refine their requirements without exposing the complexity of every underlying operator source.

This was as much a UX problem as a data problem. Too many questions at once create friction, while too few produce irrelevant results. The product needed a progressive path from broad travel intent toward a practical shortlist.

One backend behind multiple interfaces

The web experience and messenger bots depended on the same aggregated information. A shared backend prevented each channel from becoming an isolated product with different offers or business logic.

PHP and MySQL formed the recorded application and data foundation, with Apache and Nginx supporting the web infrastructure. This layer coordinated travel data, user requests and the channel-specific interfaces.

WordPress supported the public content presence, while HTML, CSS, JavaScript, Bootstrap and jQuery formed part of the web presentation stack. The architecture separated informational website content from the more dynamic responsibilities of the travel aggregator.

Designing for constantly changing data

A travel offer can become outdated quickly. Price, availability or departure details may change between discovery and booking, so the product had to treat aggregated information as time-sensitive rather than permanent catalogue content.

This changes the design of the experience. Users need enough detail to evaluate an option, but the interface must also support confirmation and continued communication before presenting an offer as final.

The platform’s value came from reducing the initial search space and connecting users with relevant travel possibilities, not from pretending that volatile operator data would never change.

Reducing search effort through self-service

Without aggregation, the same request may need to be repeated across numerous operator systems. EasyVoyage moved that repetitive discovery work into a centralized product.

For travelers, this meant a simpler starting point. For customer-service or travel professionals, a unified information layer could make conversations more efficient because relevant operator offers were available through one workflow.

The multi-channel model allowed a conversation to begin where the user was most comfortable rather than forcing every enquiry into a phone call or desktop-only website. The chatbot could handle initial discovery at any time and preserve human attention for requests that required personal assistance.

DigitalTouch’s role

DigitalTouch delivered EasyVoyage as a chatbot-led travel technology engagement covering:

  • conversational UX and dialogue architecture;
  • natural-language request recognition;
  • Skype chatbot integration;
  • Viber chatbot integration;
  • Telegram chatbot integration;
  • Facebook Messenger integration;
  • web chat and conversational interaction;
  • shared cross-channel backend logic;
  • tour-operator data aggregation and normalization;
  • public web delivery.

The project demonstrates the difference between a simple scripted bot and a chatbot that functions as a real product interface. EasyVoyage combined conversation design, natural-language input, multi-channel delivery and a substantial aggregation system capable of supplying relevant travel information.

Historical status

EasyVoyage is no longer operating, and its web and messenger experiences are unavailable. The portfolio case is retained because it represents an ambitious early multi-messenger chatbot supported by real travel data and a complete backend platform.

No active website, store or bot links are shown, and no present-day availability is implied.

The challenge

Travelers had to search multiple tour operators and navigate complex filters to find a suitable trip. EasyVoyage needed to turn that fragmented process into a simple conversation while still working with large volumes of changing offers from different sources.

What DigitalTouch built

DigitalTouch created a multi-messenger travel chatbot with natural-language recognition and guided dialogue across Skype, Viber, Telegram, Facebook Messenger and web chat. Behind the conversation, an aggregation platform collected and normalized offers from tour operators so the bot could return relevant travel options.

Technical approach

The recorded platform used PHP and MySQL with Apache and Nginx infrastructure. WordPress and an HTML/CSS/JavaScript front end supported public web content, while Bootstrap and jQuery formed part of the interface stack. Messenger integrations exposed aggregated travel information through conversational flows. The surviving materials do not establish whether every operator source used an API, feed or parser, so individual ingestion methods are not claimed.

DigitalTouch’s role

Multi-messenger travel chatbot, conversational UX, aggregation backend and web delivery

Technologies

  • PHP
  • MySQL
  • WordPress
  • Apache
  • Nginx
  • HTML
  • CSS
  • JavaScript
  • Bootstrap
  • jQuery
  • Skype Bot
  • Viber Bot
  • Telegram Bot
  • Facebook Messenger

Outcome

EasyVoyage demonstrated how a chatbot could become a complete travel-discovery interface rather than a scripted FAQ. It reduced the need to search operator websites individually and made a large travel catalogue accessible inside familiar messengers. The product has since been discontinued.