DBJOY does not set out to replace the accounting package you have used for years, or the CRM your sales team has built its habits around. It does two things: it puts families, accompanying teachers and schools in a position to follow the student’s enrolment themselves, and it opens booking file data up to the systems you already run.
A large share of office time is spent neither selling nor operating. It is spent moving information around: answering a family who wants the programme, reminding somebody whose instalment is due, rekeying an invoice into the accounts, asking for the third time for a consent form that has not arrived.
The family rings for a document that already exists. The teacher leading a group writes to ask how many of their students have signed up. Every answer given by voice is time that does not come back, and one more chance of the wrong version circulating.
The instalment falling due, the missing parental consent, the partner school allocation running out. As long as the reminder depends on somebody remembering it, sooner or later one gets missed.
The family exists in the operating system and in the CRM. The invoice exists on the booking file and in the accounts. If there is no connection, there is a person acting as the connection, doing it by hand.
The family signs in, completes the student’s details, uploads the consent forms and the minor’s documents and sees where the instalments stand. The teacher leading a school group sees the state of that group: who has signed up, which documents are missing, which deadlines are coming. The agent who sells your product consults the enrolments they brought you.
These are not three different products: it is the same booking file seen through different permissions. Whoever signs in sees what concerns them and nothing else, and what they see is current because it is the file itself, not a copy exported last week.
Automatic messages are not a campaign. They are messages produced by something that happened on a booking file. The enrolment confirmation goes out when a sign-up is recorded. The reminder goes out when a family instalment approaches its due date. The request for missing paperwork goes out when the file still shows a document as missing, and pre-departure information goes out as the course start date approaches.
Internal alerts follow the same logic and face inwards: places on option about to expire, partner school release dates approaching, instalments outstanding, groups still below the minimum. Every send is recorded, so you always know who was written to, when, and with what content.
The questionnaire sent to the student and the family after the return does not end up in a separate tool. The answers stay linked to the booking file, and therefore to the destination, the partner school and the session that produced them. That is the difference between knowing your families are happy and knowing which school is pulling the average down.
Feedback collected this way becomes product data, useful when you renegotiate a partner school contract or decide whether to repeat that session next season.
Below are the categories of system DBJOY is designed to exchange data with. Whether a connection with one specific product is possible depends on what that product makes available: it is something we check together before we start, not a promise made on a web page.
Passing sales, purchase and receipt data to the software you keep your accounts in, so your finance team and your accountant stop rekeying documents that have already been issued.
Keeping client records and sales status aligned with the CRM or email marketing tool your sales team already lives in, instead of maintaining two contact lists.
Connecting with systems that distribute availability and rates, so places sold elsewhere do not stay outside the count of your remaining allocation per session.
Application interfaces that let an external system read and write booking file data, for the cases where the connection you need does not fall into a standard category.
Delivery of the transactional email tied to a booking file: enrolment confirmations, instalment reminders, requests for missing paperwork and pre-departure information to families, schools and travel agents.
Extracting student and family records, enrolments, transactions and reports in open formats, to feed external analysis or to take your history with you if you ever change system.
Which tools are staying, which data has to travel and in which direction. A good number of requested integrations turn out to be data DBJOY already produces and that simply needs exporting.
A connection exists only if the system on the other side offers a way to read or write its data. We check that on the real product, in the version you have installed.
Which data passes, how often, and what happens when something does not pass. If a connection is not sustainable we say so up front, and we pick the workable alternative.
You will not find a list of the third-party products DBJOY connects to. That is not evasiveness. A list of brand names ages badly, changes with every release of the other software, and ends up promising connections that are not reproducible in your particular configuration.
We would rather state the categories and check your specific case during the free trial, when your systems are on the table instead of in a brochure.
What typically crosses from DBJOY to accounting is sales documents, supplier costs attributed to booking files, and the elements needed for the margin calculation under art. 74-ter of Presidential Decree 633/1972. The exact scope and the frequency are agreed with the tour operator’s administration and accountant, together with the decision on which system is the archive of record for tax data.
A tour operator’s website and its back office answer different questions: the website presents and captures, DBJOY produces and administers. A connection normally means enquiries and registrations arriving as records rather than as emails somebody retypes. What is technically available for a specific website is checked case by case, on the systems actually in use.
Before any integration, a tour operator decides which system is the source of truth for each entity: customers, suppliers, sales documents, supplier costs. One system owns the data and the other receives it. Skipping that decision is what produces two versions of the same customer and a monthly reconciliation nobody wants to do.
Access to a DBJOY interface is granted per connected system and per permission scope, not as a general opening of the database. A reporting tool can be allowed to read without being able to write, and an accounting connection can be limited to the documents it needs. Which interfaces exist for a specific requirement is confirmed case by case during set-up.
Didn't find your question? Go to the full FAQ hub
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.
No credit card. No automatic renewal. Your data stays yours and stays exportable.