The app for booking transfers and flights.

What we already have

The website and its API already run the business. The app will sit on that system. People keep one account. A booking made on the phone is the same booking as on the web.

The site is available in English, German, French, Dutch, Hungarian, and Polish. Profile data already covers name, group, company, address, phone, email, and travel document.

What this offer adds

• An iOS app and an Android app for customers: transfers, flights, tickets, profile, and a login that stays signed in.
• An agency check-in area in the same app. Staff sign in once, choose the trip, then scan. Customers cannot open it.
• Push notifications for the same events that already send email. The emails stay.
• Telegram groups for a route, started by the agency, with a join notification to the people on that transfer.

What the app is for

People should finish the usual jobs faster than on the website, on a phone that already knows who they are.

• Sign in once. After that the phone stays signed in. Opening the app does not ask for the password again.
• Search and book a transfer, or request a time, with the same rules as today.
• Open EasyFlight and book with the same rules as today.
• Show a ticket and a QR code at boarding, from the phone, after the ticket has been saved on the device. This works without a connection.
• Let agency staff open their trip list, pick the bus, scan the code, and finish check-in without the website.
• Keep the customer’s own profile on the phone, saved straight into the existing system.

iOS is built and shared for review first. Android follows once that version is accepted. Both are included. Account deletion is not included. The agency back office, events, routes, users, and statistics stay on the website.

Screen preview

The screen preview is clickable. Open it and move through the MVP screens, for a customer and for agency check-in, and see what the app will contain. It is not the finished design.

The real app will look more finished and more detailed. Wording, layout, and details stay open and can change to match what you want. The preview is enough to see the shape of it.

Open the screen preview

Customer side

A customer sees only their own trips. The booking steps match the website, including confirmation of the booking conditions.

Screens

Agency side

Agency staff use the same app and the same accounts. Check-in appears only for agency and administrator roles. A customer never sees these screens. Sign-in is the first time only. The phone stays signed in after that, the same way it does for a customer.

Push notifications

When the system already sends an email, the app also sends a push. Emails continue as they are. Typical messages:

• Request received, transfer ready to book, booking confirmed, booking reminder, ticket.
• A change in transfer time, and the overbooked case.
• Flight request, flight confirmation, a change in flight time, missing passenger data, and the existing Telegram reminder.
• The new invitation to join a Telegram group for that route.

Telegram

One group per transfer gives staff a single place to post a time change, a gate change, or a delay. Customers on that ride see the same update instead of a chain of separate messages.

Telegram does not let a normal bot create a group and drop every customer into it. Adding someone also fails when that person has no Telegram on the phone number we have, or when their privacy settings refuse group invites. Because of that, the reliable flow is the one below. The exact details stay open until we align them.

• Agency staff create the group for a transfer from the web platform. Creating it from the app is possible too, if we want that in the same place as check-in.
• The system sends a push, and can send the existing style of email, to everyone on that route: join this Telegram group for news about the ride.
• Messages for the group are sent from one SEE Travel identity, so the thread stays in one voice.
• People who never join still have email and push. The group is the fast channel, not the only channel.

Price and warranty

Included after delivery

For one month after handover we fix defects in the delivered app and in the Telegram functionality. A defect is something that does not work as described in this offer. A new screen or a new rule is quoted on its own.

Timing

The first full version for testing will be ready at the beginning of December 2026. December is for testing, and for changes where something needs to be adjusted. From the start of the new year, or earlier if we decide, the app goes to the stores and to production.

Later, if you want it

None of this is inside the €6,000. It is the short list of upgrades that came out of the conversation, once the app itself is in use.

An assistant for customers

A chat on the website, in the app, or in both. It answers from the offers and trips that already exist: which transfer fits, what a status means, how booking works, what to do at check-in, and what to expect on the day of the trip. You choose which of those it is allowed to talk about. A customer gets the answer in the moment, instead of hunting through the site or writing to the office.

The panel is the chat already open, with example lines. This is not the final wording. A lot of detail still gets added, and you decide which topics it may answer.

A clearer website

The pages already do the work. Booking, the transfer list, customer requests, and users can be much easier to read without changing the fields or the actions. The direction is the same white, gray, and SEE Travel red, with the content pulled into a calm layout instead of stretched across the window.

Today is on the left. A proposal for the same screen is on the right. This is not the final look. A lot of detail still gets added, and wording stays open to whatever you want adjusted. The pictures are here so you can see that these pages can feel a little more modern.

Book a transfer

Users

Customer requests

Transfer overview

A faster website

Agency screens sit on a large background photo, and the long lists arrive as one table. The customer form runs the full width of the window. A lighter working screen, and lists that load in pages, make the same tasks quicker to open and quicker to scan.

Logging, errors, and usage

The app and the mobile endpoints can report failures and basic usage. When something breaks, you get the error, the screen, and the device, without waiting for a customer to describe it. The same setup shows which steps people finish and which they abandon.

Clearer application logs would sit with this, so a booking or a check-in can be traced on the server when a phone report is not enough. Connecting Sentry and PostHog is the work. A paid plan, if you take one, is paid by SEE Travel directly to those services.

Reports and activity

A reports view for the office: the progress and the activity of each booking and each transfer, in one place, with the numbers behind them.

• One booking, from the request to check-in. Who opened it, what changed, and when.
• One transfer: seats, requests, confirmations, and the messages that went out.
• A dashboard for the period: bookings, transfers, events, airports, and where people stop along the booking.

You choose which reports matter. The detail is lined up when you want this built.

Transfers from requests

You asked about using AI to build transfers out of requests. The website already has transfer suggestions, and the agency algorithm that groups requests. This would extend that step: a suggestion, or a draft transfer, built from the requests that are waiting. How far it goes stays open until you want it built.