Features

The traveller is a student, usually a minor

The fifth and sixth modules of DBJOY govern the student and the travel documents: student and paying family records, medical data and parental consents, host family matching and rooming lists, registration fees and instalment plans, the guaranteed departure threshold, accompanying teachers and the tutor on site.

Module 5 — Students

A hundred student records, not a “number of passengers” field

On a language holiday each student has a name, a travel document, a family that pays, a place in a host family or a residence, and often an allergy or a course of medication. Software that treats the group as a single booking pushes all of that into a parallel spreadsheet.

An enrolment list that stays current

Enrolments, withdrawals and replacements are recorded on the booking file. Students and accompanying teachers are counted separately, with the free places the contract allows and the student-to-leader ratio always in view.

Host family matching and rooming list

Host family matching or residence allocation, requests to stay together, rooms for accompanying teachers, allergies, diets and accessibility needs. These are fields on the student, not notes in a margin.

Minors: data and consents

Travel documents, parental consents and release forms, medical data, allergies and medication, emergency contacts. Processing follows the GDPR, and the data stays in the booking file rather than in the inbox of whoever received it.

Schematic illustration of the interface.
Enrolments and payments

Every family has its own payment schedule

Registration fee, instalments and balance per family

On a language holiday the money does not arrive from one customer. It arrives from dozens of families, at different moments, in different amounts. DBJOY holds the registration fee and the instalment plan for each student, with due dates and the status of every instalment.

The booking file shows how much has come in, how much is outstanding and who is behind. The school contact receives a current picture instead of rebuilding it by ringing round the families. Instalments received flow into the same payment schedule as the rest of the operation.

  • Different instalment plans within the same session, where the terms allow it.
  • A status per student: enrolled, paid to date, late, withdrawn.
  • A summary for the school or the group leader, without exposing other families’ data.
  • registration fee
  • deposit
  • instalments
  • balance
  • reminders

The guaranteed departure threshold decides the trip

A session departs if it reaches a minimum number of students, and the price per student often depends on the band reached. DBJOY holds the guaranteed departure threshold on the booking file and sets it against the real enrolments, so you know at any moment whether the departure stands up.

Below the threshold there are two decisions: push the enrolments, or tell the families in time. Both need today’s picture, not one from a month before departure. This is also a legal matter, not only a commercial one: the Package Travel Directive (EU) 2015/2302, transposed into the Italian Tourism Code (Legislative Decree 79/2011), requires the minimum number of participants and the deadline for notifying cancellation on that ground to be stated to the traveller before the contract is concluded. Those information duties are part of the document flow of the booking file.

  • guaranteed departure
  • minimum number
  • price bands
  • break-even
Enrolment portal

Schools and families enter their data once

Collecting the data is the most expensive part of a language holiday: names, documents, allergies and diets, parental consents, and every change that arrives by email. The enrolment portal moves that collection to where the data is born.

Who fills it in

The school contact opens the session and follows the enrolments. Families enter the details of their own student and upload the travel document, consents and release forms. Each person sees only the part that concerns them.

Where the data lands

Straight into the booking file: student list, host family matching and rooming list, instalment due dates, welcome pack and travel documents. Operations copy nothing across, and last-minute corrections arrive where they are needed.

Module 6 — Travel documents

Documents are produced from the booking file

Vouchers, info sheets, rooming lists, student lists, tickets and insurance certificates are not written: they are generated. The document reads the booking file, so it carries the host family matched yesterday and the student who joined this morning.

Towards the supplier

Vouchers for the partner school, the accommodation, transfers and excursions, rooming lists for the residence or the host families, student lists for the airline or the coach operator.

Towards the family and the school

A welcome pack with the programme, timings, the tutor on site and useful contacts, the placement test result and the certificate of attendance, confirmation and deadline messages.

Cover and obligations

Tickets and student insurance certificates stay attached to the booking file together with the pre-contractual information required by package travel rules.

Schematic illustration of the interface.
The rest of the cycle

Where work on the group continues

A session touches every module. It starts as a quote with a price band by number of students, it commits places in host families and seats on the partner school’s course, it produces payments split across many families, and it closes with a margin that has to be measured on the session rather than on the season.

Back to the map of the nine modules

Frequently asked questions

How are student enrolments for a group departure collected in DBJOY?

For a group departure DBJOY holds each student as a record inside the booking file, with personal details, travel document, host family preference and the family’s payment position. Enrolments can arrive through a school contact or family by family. The advantage for a study travel operator is that the group total and the individual positions are the same data, so no list ever has to be reconciled against a spreadsheet.

Study travel and school groups in practice

How is the rooming list produced in DBJOY?

The rooming list in DBJOY is generated from the student records and their host family or residence allocations, not maintained as a separate file. When an allocation changes, the list changes with it, so the version sent to the partner school is the current one. Special requirements, such as one student per host family, two students who must stay together, or an allergy, stay attached to the student record.

How does DBJOY follow instalments paid by individual families?

Each paying family in a DBJOY group has a payment position: registration fee, instalments with their due dates, payments recorded and the balance still outstanding. A study travel operator sees who is up to date and who is late without adding up bank transfers by hand, and a reminder starts from a figure held in the system rather than from a manual check of the bank statement.

How study travel organisers track family payments

How does DBJOY help with a guaranteed departure threshold?

A guaranteed departure depends on reaching a minimum number of confirmed students by a given date. DBJOY holds confirmed enrolments against the session, so a study travel operator watches one figure instead of counting enrolments across emails. The decision to confirm, postpone or cancel stays commercial, but it is taken on a current number rather than on an impression.

Reading a departure before you commit to it

Didn't find your question? Go to the full FAQ hub

Run DBJOY on your real enrolments for three months

We set the system up together on your own rates, partner schools and destinations. At the end of the three months the decision is yours, with no strings attached.

Start your free 3-month trial

No credit card. No automatic renewal. Your data stays yours and stays exportable.