How to Build Communication with Parents and Teachers in EdTech

Date: 2026-06-26 | Time of reading: 8 minutes (1596 words)

In this article, we’ll explain how an EdTech project can build communication not only with the student, but also with the people around them — parents and teachers. We’ll break down a practical scenario based on Altcraft and show how to turn a student’s actions into a full-scale multi-party CJM.

Why Communication with a Student’s Support Network Matters in EdTech

In education, it is important to consider that a student’s success depends not only on their personal motivation, but also on how involved the adults around them are in the process. Parents can support regular attendance and track progress, teachers can adapt their approach and give timely feedback, and tutors or coordinators can handle organizational issues. When communication is organized properly, it becomes possible to respond to gaps in performance in time, encourage active participation, and reduce the risk of missed classes or churn.

That is why EdTech needs more than just campaigns sent to a database. It needs connected communication logic, where an action by one profile can launch scenarios for other participants.

The student hasn’t been active for a while — the parent gets a reminder

This is where the role of a CDP becomes clear. One system can store data about the student, their progress, statuses, actions, and related profiles — for example, a parent or teacher. The campaign is triggered by the student’s actions, while the communication scenario can include messages for other participants in the educational process in advance.

For example: the student completes a lesson — the parent receives a progress message. The student has not studied for a long time — a reminder is sent to the parents so they can monitor the situation. The student reaches an important milestone — a separate support chain for the family is launched. Marketing automation becomes part of the educational process.

Where Standard Logic Usually Breaks

In EdTech, marketing management should not follow the “one action — one profile” model. A student completes a lesson, and the scenario continues working with that same student. They do not finish their homework — again, the scenario stays with them. They open an email, click a link, perform an action on the website — the platform remains within the same profile card. This logic works well when communication is truly built around a specific user. But if there are other participants around the student, it is no longer enough.

What is needed here is a mechanism that connects participants to each other and passes an event from one profile to another, so that a new personalized scenario can then be launched.

How to Link Student, Parent, and Teacher Profiles

To do this, additional fields are created in Altcraft profile databases, such as parent and teacher, and the identifier of the related profile is recorded in them: the profile_id of the parent or teacher.

Additional fields are added for the entire database at once — either when the database is created or when it is edited after creation. These fields also exist in teacher and parent profiles, but they are not filled in.

These fields are then used in scenarios as a transition point from one participant in the educational process to another: the student performs the action, while communication is launched for the related adult profile.

Process logic (one possible option; you can implement the process differently):

A database is created for the educational product or course. Additional profile fields are specified: parent and teacher.
Three separate profiles are added to this database: student, parent, and teacher.

Additional fields are filled in the student’s profile — in our example, the parent and teacher fields.
Communication scenarios are configured to connect all participants in the process.

Inside the CDP, you collect not just data about the student, but a relationship model around them: who influences progress, who makes the decision to continue learning, and who is responsible for support. As a result, the CJM stops being linear. The same learning step can be broken down into several different paths, with exactly the role that the event actually concerns included in the communication.

How a Scenario Is Launched for a Parent or Teacher

A student completes a lesson, performs a target action, does not log in to their account for a long time, or fails to complete an assignment. This event becomes the entry point into the scenario. First, the scenario is triggered on the student’s own profile, because the action happened to that profile. But the student’s card already contains additional fields, parent and teacher, where the profile_id values of the linked profiles are stored.

Therefore, the scenario takes the required identifier from the student’s card and passes it further. For this, an API node is used inside the scenario. It calls the internal Altcraft endpoint “Send to Scenario” — or launches a trigger campaign — and passes data about which profile needs to be found and launched into a separate chain.

The image shows an example of a simple scenario implementation

Example of how it will look in the request:

{
  "matching": "profile_id",
  "profile_id": "{lead.parent}"
}

Here, matching = profile_id means that Altcraft should search for the profile specifically by profile_id, not by email, phone number, or another field. The profile_id value is taken from the student’s additional field.

After this request is sent, Altcraft finds the parent’s profile by the passed profile_id and launches a separate scenario or separate communication for them. At the same time, the parent receives not a message addressed to the student, but their own personalized chain: with the right text, channel, conditions, and logic.

The same approach can be used with the teacher. If you need to launch a scenario for the teacher, the value from the teacher field is inserted into the request:

{
  "matching": "profile_id",
  "profile_id": "{lead.teacher}"
}

What This Gives the Business and How to Implement It

For an EdTech business, this setup changes communication around learning. The company starts working not only with the student who logs in to the platform and completes assignments, but also with those who influence the student’s results: parents, teachers, and tutors. If a child completes a lesson, the parent can receive a progress message. If the child does not finish an assignment, the teacher sees a signal and understands where attention may be needed. If the student has not logged in for a long time, you can launch not one general reminder, but several different scenarios: a push notification for the student, an explanation of the situation for the parent, and a contact task for the tutor.

With this logic, communication becomes closer to the real educational process. Learning does not happen in a vacuum: it includes schedules, motivation, supervision, feedback, payment, renewal, parents’ expectations, and teachers’ work. The marketing campaign does not exist separately from the product. It reacts to what is happening with the student right now and connects the right participant at the right moment.

The manual workload on the team is also reduced. There is no need to export parent data from the database every time, create separate lists for teachers, check spreadsheets, or manually launch a campaign after each student action. The connection already exists in the child’s profile card: it stores which parent and which teacher are linked to the student.

In this setup, the CDP works not as a regular contact database, but as the center of all communication around the student. Profiles, links between them, action history, and conditions for launching scenarios are stored in one place. The student can have their own CJM, the parent can have their own, and the teacher can have their own, but all of them are connected by one learning event.

How to Implement It

During implementation, it is important to organize the links between profiles from the start. The student’s profile card must contain the parent and teacher fields filled with the profile_id of the parent or teacher. If the field is empty or filled in incorrectly, the scenario simply will not find the linked profile and will not launch the communication.

It is better to use profile_id specifically: email addresses and phone numbers can change, repeat, or belong to different roles, while profile_id points to a specific profile.

It is also worth choosing events that actually require communication. Not every student action needs to become a message. Good triggers include completing a lesson, an unfinished assignment, a long break in activity, risk of falling behind, a high score, completion of a module, or an upcoming renewal.

Conclusion

In this setup, everything is tied to the student’s action. The student completes a lesson, skips an assignment, or reaches an important milestone — and this triggers not one campaign, but several connected communications for the relevant participants.

The student receives their own message, the parent receives theirs, and the teacher receives theirs. Each participant sees only what they need to know at that moment.

Altcraft works here as a unified marketing system for roles, data, and scenarios. This makes CJM management easier and reduces manual work.