CRM pour agences d'éducation : un seul pipeline de la demande à l'inscription

Un étudiant se renseigne sur un cours via votre site web. Un conseiller répond par e-mail. Un autre bureau reçoit un message du même étudiant. Quand la candidature arrive chez un établissement partenaire, plus personne ne sait quel dossier est à jour.

Un CRM pour agences d'éducation doit donner à ce parcours un dossier partagé, une personne responsable et une prochaine action visible. Commencez par définir ces règles avant de choisir des écrans ou des automatisations. Le même exercice vaut pour un groupe d'écoles de langues qui traite des demandes directes, ou pour une équipe edtech qui développe des outils de recrutement pour les agences.

Définir ce qui circule dans le pipeline

Gardez distincts la personne, le parcours de recrutement et chaque candidature. Un étudiant peut se renseigner deux fois, envisager plusieurs programmes et déposer des candidatures auprès d'établissements différents. Ces événements ne doivent pas créer des dossiers étudiants sans lien entre eux.

Utilisez un seul dossier étudiant pour les coordonnées et les préférences de communication. Rattachez-le à une demande ou à un parcours de recrutement pour la rentrée visée. Associez une candidature distincte à chaque établissement et à chaque programme. Conservez les documents auprès de l'étudiant ou de la candidature concernés, selon leur finalité.

Imaginons par exemple une école de trois centres partageant une équipe d'admission. Un étudiant se renseigne sur deux centres, puis modifie les dates de cours. Il s'agit d'un workflow hypothétique : l'équipe doit mettre à jour le parcours existant et conserver son historique, plutôt que de compter chaque conversation comme un nouveau prospect.

Décidez ce qui se passe lorsque cet étudiant revient pour une autre rentrée. Réutilisez son identité, mais ouvrez un nouveau parcours afin que les résultats précédents restent lisibles.

Donner à chaque étape une règle d'entrée et une règle de sortie

Convenez d'un petit nombre d'étapes communes à tous les bureaux. Des libellés comme « en cours » laissent trop de place à l'interprétation. Chaque étape exige une preuve, un responsable et une prochaine action.

Appliquez les étapes de candidature à chaque candidature. Donnez au parcours global son propre résultat de synthèse. Une candidature refusée ne doit pas en clore une autre encore active.

Gardez le paiement, la vérification des documents et tout suivi lié au visa dans des champs ou des checklists distincts. Ils peuvent avancer indépendamment. Une seule étape « en attente de visa » peut sinon masquer un solde impayé ou une condition d'offre non résolue.

Ajoutez les issues reporté, retiré et clos, chacune avec un motif. Décidez comment un parcours reporté se rouvre sans perdre l'historique de sa rentrée d'origine.

Rendre le pipeline des conseillers exploitable

Un pipeline de conseillers doit répondre à trois questions : ce qui demande de l'attention, qui en est responsable et quand c'est dû.

Pour chaque parcours actif, exigez :

• Un conseiller nommé et un bureau responsable.

• Une prochaine action précise, par exemple « confirmer les nouvelles dates de cours ».

• Une date d'échéance dans le fuseau horaire de travail concerné.

• Le dernier contact significatif et son résultat.

• Un motif lorsque la progression est bloquée.

Choisissez une règle d'attribution que vos équipes peuvent expliquer. La rotation est simple, mais elle demande des exceptions pour la langue, la connaissance des programmes, la charge de travail et les absences. Donnez aux demandes non attribuées une file visible et un responsable chargé de la vider.

Un accusé de réception ne doit pas compter comme une réponse de conseil. Indiquez si une personne a examiné la demande et y a répondu sur le fond.

Lorsqu'un conseiller est absent, désignez un remplaçant temporaire. Évitez de laisser la responsabilité à quelqu'un qui ne peut pas agir. Demandez lors d'une démonstration : un responsable peut-il retrouver chaque action en retard sans ouvrir chaque dossier étudiant ?

Concevoir les transferts pour les agences multi-sites

Les agences multi-sites ont besoin de définitions partagées et de règles de transfert explicites. Une base de données commune ne suffit pas à établir la responsabilité.

Convenez du moment où un bureau destinataire accepte un transfert et de qui est responsable du dossier d'ici là. Incluez dans la passation les choix actuels de l'étudiant, les candidatures ouvertes, les conditions en suspens et le prochain contact promis.

Testez ce scénario : un étudiant contacte un deuxième bureau pendant que son conseiller initial prépare une candidature. Les équipes reconnaissent-elles le dossier existant ? Peuvent-elles ajouter la conversation sans s'approprier le dossier ? Qui approuve un transfert définitif ?

Conservez la source d'origine de la demande en plus du responsable actuel. L'attribution marketing et la responsabilité du suivi du jour répondent à des questions différentes.

Définissez les accès par rôle et par bureau. Décidez qui peut consulter les coordonnées, télécharger des documents, changer le responsable et exporter des enregistrements. Testez les comptes du personnel ordinaire comme ceux des responsables.

Servez-vous de ces questions en lisant la présentation pour agences d'éducation et en rédigeant votre propre brief de workflow.

Séparer la collecte des documents de leur vérification

« Téléversé » et « accepté » doivent être des statuts différents. Une checklist doit montrer ce qui a été demandé, quelle version est arrivée, qui l'a examinée et ce qui reste en suspens.

Demandez aux relecteurs d'indiquer clairement pourquoi un dossier est renvoyé. « Veuillez téléverser à nouveau » guide moins bien un étudiant que « la dernière page est manquante ». Conservez les versions précédentes pour que les équipes comprennent ce qui a changé.

Appliquez la même rigueur aux offres. Enregistrez les conditions, les échéances et la réponse de l'étudiant sur la bonne candidature. Ne copiez pas une condition d'offre dans une note générale qu'un autre conseiller risque de manquer.

Si vous mettez en place un portail pour les étudiants ou les parents, décidez quelles informations chaque personne peut voir. Définissez explicitement l'accès des parents plutôt que de supposer que chaque adulte rattaché doit recevoir chaque mise à jour.

Séparez les notes internes des messages destinés aux étudiants. Choisissez qui valide les mises à jour sensibles et comment les corrections parviennent à tous ceux qui ont reçu le message initial.

Connecter les systèmes avec une responsabilité claire

Avant de connecter des formulaires, la messagerie, les paiements ou les systèmes partenaires, notez quel système contrôle chaque champ. Par exemple, la finance peut confirmer un paiement tandis que le CRM affiche cette confirmation aux conseillers.

Définissez l'événement qui déclenche une mise à jour. Un formulaire soumis, un paiement confirmé et une offre acceptée sont des événements différents. Précisez comment la connexion traite un événement répété sans créer un autre enregistrement ni envoyer un autre rappel.

Posez ces questions avant de convenir d'une intégration :

• Comment les étudiants existants sont-ils rapprochés, et qui examine les correspondances incertaines ?

• Que se passe-t-il lorsqu'une mise à jour échoue ou arrive en retard ?

• Où les équipes peuvent-elles voir les échecs et demander une nouvelle tentative ?

• Quel système l'emporte lorsque deux personnes modifient le même champ ?

• Que se passe-t-il lorsqu'un message ne peut pas être remis ?

Commencez par une connexion qui répond à un problème de transfert connu. Ajouter toutes les intégrations disponibles d'un coup rend les données contradictoires plus difficiles à retracer.

Rendre compte des inscriptions selon des définitions convenues

Décidez ce que signifie « inscrit » pour votre activité. Une offre acceptée, un acompte et la confirmation d'un établissement peuvent représenter des jalons différents. Choisissez la preuve dont votre reporting a besoin et enregistrez sa date.

Comptez les parcours étudiants uniques séparément des candidatures. Sinon, un étudiant qui postule auprès de plusieurs établissements peut fausser la taille apparente du pipeline.

Pour un premier rapport opérationnel, envisagez les demandes non attribuées, les prochaines actions en retard, le temps passé à chaque étape, les conditions en suspens et les inscriptions confirmées par rentrée. Comparez des groupes de rentrée équivalents et tenez compte des parcours encore ouverts avant d'interpréter les taux de conversion.

Séparez le statut de la commission de l'inscription. Rattachez une commission attendue à la candidature concernée et aux conditions convenues avec le partenaire. Suivez indépendamment la facturation, les échéances, les litiges et les encaissements. Une inscription ne signifie pas que sa commission a été payée.

Configurer, connecter ou développer ?

Testez votre CRM actuel de recrutement d'étudiants sur ces workflows avant de le remplacer. Une configuration peut suffire s'il sait représenter des candidatures distinctes, appliquer des règles de responsabilité et faire apparaître clairement les exceptions.

Envisagez une intégration lorsque le processus sous-jacent fonctionne mais que les équipes ressaisissent sans cesse des informations d'un système à l'autre. Envisagez un module sur mesure lorsqu'une vérification ou un transfert précis ne peut pas être géré dans la configuration actuelle.

Un remplacement exige un dossier plus solide. Intégrez à la décision la migration, la formation des équipes, les contrôles d'accès, la maintenance, les abonnements et la responsabilité des évolutions futures. Demandez qui administrera le système après le lancement.

Utilisez le même scénario pour évaluer chaque option. Demandez une démonstration d'une demande en double, d'un transfert de bureau et d'une candidature reportée. En consultant des études de cas, demandez quelles décisions concernent votre workflow et quelles preuves étayent un résultat annoncé.

Par où commencer

Choisissez une rentrée et un transfert qui pose problème. Réunissez un conseiller, un responsable des opérations et la personne qui reçoit ensuite le travail.

Passez en revue un petit nombre de parcours anonymisés, dont un avec exception. Cartographiez les étapes actuelles, convenez des définitions d'étapes et rédigez des critères d'acceptation. Par exemple : après un transfert de bureau, le conseiller qui reprend voit les conditions en suspens et le prochain contact promis sans solliciter le responsable initial.

Testez le changement avec une équipe restreinte. Vérifiez les responsables manquants, les doublons et les actions en retard avant de l'étendre. Convenez de qui corrige les données importées et de la façon dont les équipes signalent les problèmes.

Softvery développe des logiciels sur mesure et des fonctionnalités d'IA pour les entreprises de l'éducation internationale. Son sprint de discovery payant, court, couvre un scénario, les écrans clés, les hypothèses et un plan pour la suite. La discovery n'inclut ni application fonctionnelle, ni code de production, ni intégrations en production, ni migration de données.

Pour plus de contexte, lisez l'article sur les sprints de discovery ainsi que la présentation des logiciels pour agences d'éducation.

Si vous souhaitez discuter d'un transfert dans votre pipeline : Réserver un appel de 30 min.