As a tour operator for active travel (cycling and hiking tours), we need and manage countless data and information about the individual cycling and hiking stages. Some of this is already stored in our booking system, which we want to keep. However, a large part is currently stored in Libre documents and then combined with the data from the software. Since we create travel documents that are as personalized as possible for our guests, we need identical data in many different formats, which is why we sometimes record information twice or even three times in documents. For example, we list restaurants and bike repair shops along the route for each cycling stage, as well as important information about the route. On a cycle path, for example, guests can book the tour in the direction of the nearby river or against the direction of the river, and in German or English, which means that the same information is recorded at least four times. Creating the travel documents requires extensive training and a great deal of know-how on the part of our employees.
What specific information is required?
General (regardless of customer and route)
Route-specific
In addition, there is customer- and supplier-related data that we can already record in our booking system (e.g., directions, hotel restaurant closing days, parking options, etc.).
What is the goal?
We want to manage all this data centrally in stages and then display it in the appropriate places (e.g., in the itinerary or, in the future, on the website for customers to download or in a tour app) in the appropriate language (German or English). We need to be able to maintain and update the data easily without a software company having to install or reprogram anything. Furthermore, it should be possible to feed rules into the system so that automatic processes can be created. Example: A guest books a bike tour along the Elbe Cycle Route from Prague to Dresden. Based on the language specified by the customer, the hotel locations, and other travel-specific information entered by the employee during the booking process, the system should automatically recognize which information needs to be compiled for the travel documents.
In the future, we also want to check whether we can import or retrieve certain data from other sources. We currently update all this information manually every winter, checking, for example, whether bike repair shops still exist and whether their address and phone numbers are still up to date. But this is data that already exists somewhere on the internet. Exactly what data this will be, where it can be found, and, above all, how it can be made usable for us is still open. But the system should be designed to offer import options or interfaces. Of course, it must also be able to be connected to our current booking system, as travel itineraries for guests are always a mixture of customer-specific and route-specific information.
Ideally, the new system would also allow us to capture geodata, i.e., map the individual stages or tours on maps and display POIs located along the route. However, this may not be essential, as there are other options on the market for this. It is important that the system can communicate with others (export/import/API/etc.).
Ultimately, the aim is to be able to record different data, define dependencies and rules, and then output this data via various channels.
Twenty to thirty software workstations are required.
| Quantity | |
|---|---|
| Researched solutions | 38 |
| Selected potentially relevant solutions (of which published) | 20 (8) |
| Sent e-mails (questions, queries) and telephone calls | 87 |
| E-mails received from vendors | 28 |
| Direct responses to the IT project | 2 |
| Responses classified as relevant | 8 |
The IT project has already been closed.
We are happy to answer questions about IT projects by phone +49 5363 / 8094-0 or e-mail info@softguide.de