You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
En tant que prescripteur,
je veux organiser un rdv entre un usager avec qui je parle en personne et une organisation dont je ne fais pas partie
afin de rendre le service public plus accessible
Par exemple, dans le Lot et Garonne, il y a des agents des services sociaux qui redirigent les usagers vers les conseillers numériques des départements. C'est pour répondre à ce premier cas de figure qu'on prépare cette fonctionnalité.
Interface de prise de rdv
Les prescripteurs ne sont pas connectés, et commencent la réservation comme un usager normal, à partir de la recherche par adresse ou via un lien de prise de rdv.
La déviation par rapport à la prise de rdv habituelle se fait sur l'écran de connexion, où on ajoute un lien "Je suis un prescripteur qui oriente un bénéficiaire"
Page Connexion
Dans ce contexte, il semble que les prescripteurs utilisent généralement le terme de "bénéficiaire" pour parler de l'usager (c'est le cas sur Rés'in par exemple). Pour être le plus clair possible, on utilise ce terme ici aussi.
Pour notre vocabulaire interne on peut se dire qu'un "bénéficiaire" est un "usager" pour qui un "prescripteur" prend rendez-vous.
Ce lien mène vers le formulaire des informations du prescripteur :
Prescripteur
Il faudra faire attention à ce que les prescripteur mettent bien leur coordonnées et pas celle de l'usager sur cette page, et expliquer clairement pour quoi les coordonnées entrées sont utilisées.
Les labels des champs ont pour objectif éviter la confusion entre coordonnées de l'usager et du prescripteur.
On utilise Votre prénom, Votre nom, Votre email professionnel, Votre numéro de téléphone.
Texte :
Ces informations permettront à l'agent qui assure le rendez-vous de savoir qui l'a planifié, et de vous contacter s'il y a une erreur sur le type de rendez-vous.
ℹ️ On peut sortir une première version où les prescripteurs doivent remplir le formulaire à chaque fois, et ensuite faire une version améliorée où c'est pré-rempli (car stocké dans le navigateur ou la session).
Le bouton "continuer" mène à la page d'infos sur le bénéficiaire :
Bénéficiaire
On propose ici une version allégée du formulaire de nouvel usager, sur lequel on met les mêmes contraintes que pour un rdv.
Le profil d'utilisateur qu'on créé accepte par défaut les notifications par mail et téléphone, et si l'usager ne souhaite pas recevoir de notification de confirmation, il lui suffit de ne pas donner ses infos.
On indique sous les champs email et téléphone qu'ils serviront à envoyer des notifications.
On utilise le placeholder pour donner un indice sur la manière de formatter le numéro de téléphone pour ne pas avoir besoin du hint sur le formattage qu'on met ailleurs dans l'appli.
S'il n'y a pas d'email ni de numéro de téléphone portable, on affiche cet avertissement :
Le bénéficiaire ne pourra pas recevoir de confirmation ni de rappel pour son rendez-vous si vous n'indiquez pas d'adresse email ni de numéro de téléphone portable. Etes-vous sûr de vouloir continuer ?
❓ Est-ce qu'il faut qu'on ajoute des infos sur notre CGU et/ou politique de confidentialité pour gérer ce cas où un prescripteur entre les infos personnelles d'un bénéficiaire ?
ℹ️ Ici on pourrait se poser la question d'échanger les deux étapes Prescripteur et Bénéficiaire. Voici les avantages et inconvénients de l'ordre proposé ici :
Avantage : On demande les infos de prescripteur juste après l'avoir fait cliquer sur "Je suis un prescripteur", donc c'est plus cohérent
Inconvénient : Dans la liste des questions que le prescripteur pose au bénéficiaire, ça fait une interruption entre "questions sur quand le bénéficiaire est dispo", "remplissage de formulaire par le prescripteur", "questions sur les coordonnées du bénéficiaire", mais vu qu'on pourra accélérer le remplissage de formulaire par le prescripteur, c'est pas trop grave
Confirmation
Pour que le prescripteur puisse retrouver une confirmation que le rdv a été pris, il faut lui envoyer un mail de confirmation similaire à celui qu'on envoie à l'usager.
Contrairement à l'interface usager, le rdv est confirmé dès le moment où on arrive sur cette page, pour éviter que des prescripteurs quittent l'appli avant de finir la réservation.
On considère que ce n'est pas trop grave qu'il y ai une déviation entre le parcours usager et le parcours prescripteur sur le moment où intervient la confirmation, puisque ce sont deux types d'utilisateurs différents, qui ignorent donc qu'une autre convention que celle qu'ils connaissent existe.
voir aussi #2936
C'est possible qu'à cette page, le prescripteur se rende compte d'une erreur, ou que l'usager change d'avis sur le créneau qui l'arrange le plus. Dans un premier temps, vu qu'on ne permet pas l'édition de rdv par un prescripteur, on leur proposera un lien mailto pour nous envoyer un mail à l'adresse de contact. Ça permettra de savoir la quantité de cas où ça arrive, et de ne pas se lancer dans des développements prématurés.
Par ailleurs, ça peut servir à recueillir leur retours comme on l'avait fait pour le lancement de la synchro webcal.
Une première PR pour cette branche pourrait implémenter tous les écrans présentés ici, à l'exception du lien sur la page connexion. Ça permettrait de paralléliser le travail avec les issues #3034 et #3035, et de faciliter le lancement en douceur en ajoutant ce lien dans le cadre de #3037
The text was updated successfully, but these errors were encountered:
voir https://www.notion.so/rdvs/Prise-de-RDV-par-un-prescripteur-5223e6e66c5a47b6bf5d1c482c4ee82d
En tant que prescripteur,
je veux organiser un rdv entre un usager avec qui je parle en personne et une organisation dont je ne fais pas partie
afin de rendre le service public plus accessible
Par exemple, dans le Lot et Garonne, il y a des agents des services sociaux qui redirigent les usagers vers les conseillers numériques des départements. C'est pour répondre à ce premier cas de figure qu'on prépare cette fonctionnalité.
Interface de prise de rdv
Les prescripteurs ne sont pas connectés, et commencent la réservation comme un usager normal, à partir de la recherche par adresse ou via un lien de prise de rdv.
La déviation par rapport à la prise de rdv habituelle se fait sur l'écran de connexion, où on ajoute un lien "Je suis un prescripteur qui oriente un bénéficiaire"
Page Connexion
Dans ce contexte, il semble que les prescripteurs utilisent généralement le terme de "bénéficiaire" pour parler de l'usager (c'est le cas sur Rés'in par exemple). Pour être le plus clair possible, on utilise ce terme ici aussi.
Pour notre vocabulaire interne on peut se dire qu'un "bénéficiaire" est un "usager" pour qui un "prescripteur" prend rendez-vous.
Ce lien mène vers le formulaire des informations du prescripteur :
Prescripteur
Il faudra faire attention à ce que les prescripteur mettent bien leur coordonnées et pas celle de l'usager sur cette page, et expliquer clairement pour quoi les coordonnées entrées sont utilisées.
Les labels des champs ont pour objectif éviter la confusion entre coordonnées de l'usager et du prescripteur.
On utilise
Votre prénom
,Votre nom
,Votre email professionnel
,Votre numéro de téléphone
.Texte :
ℹ️ On peut sortir une première version où les prescripteurs doivent remplir le formulaire à chaque fois, et ensuite faire une version améliorée où c'est pré-rempli (car stocké dans le navigateur ou la session).
Le bouton "continuer" mène à la page d'infos sur le bénéficiaire :
Bénéficiaire
On propose ici une version allégée du formulaire de nouvel usager, sur lequel on met les mêmes contraintes que pour un rdv.
Le profil d'utilisateur qu'on créé accepte par défaut les notifications par mail et téléphone, et si l'usager ne souhaite pas recevoir de notification de confirmation, il lui suffit de ne pas donner ses infos.
On indique sous les champs email et téléphone qu'ils serviront à envoyer des notifications.
On utilise le placeholder pour donner un indice sur la manière de formatter le numéro de téléphone pour ne pas avoir besoin du hint sur le formattage qu'on met ailleurs dans l'appli.
S'il n'y a pas d'email ni de numéro de téléphone portable, on affiche cet avertissement :
❓ Est-ce qu'il faut qu'on ajoute des infos sur notre CGU et/ou politique de confidentialité pour gérer ce cas où un prescripteur entre les infos personnelles d'un bénéficiaire ?
ℹ️ Ici on pourrait se poser la question d'échanger les deux étapes Prescripteur et Bénéficiaire. Voici les avantages et inconvénients de l'ordre proposé ici :
Confirmation
Pour que le prescripteur puisse retrouver une confirmation que le rdv a été pris, il faut lui envoyer un mail de confirmation similaire à celui qu'on envoie à l'usager.
Contrairement à l'interface usager, le rdv est confirmé dès le moment où on arrive sur cette page, pour éviter que des prescripteurs quittent l'appli avant de finir la réservation.
On considère que ce n'est pas trop grave qu'il y ai une déviation entre le parcours usager et le parcours prescripteur sur le moment où intervient la confirmation, puisque ce sont deux types d'utilisateurs différents, qui ignorent donc qu'une autre convention que celle qu'ils connaissent existe.
voir aussi #2936
C'est possible qu'à cette page, le prescripteur se rende compte d'une erreur, ou que l'usager change d'avis sur le créneau qui l'arrange le plus. Dans un premier temps, vu qu'on ne permet pas l'édition de rdv par un prescripteur, on leur proposera un lien mailto pour nous envoyer un mail à l'adresse de contact. Ça permettra de savoir la quantité de cas où ça arrive, et de ne pas se lancer dans des développements prématurés.
Par ailleurs, ça peut servir à recueillir leur retours comme on l'avait fait pour le lancement de la synchro webcal.
Technique
La branche qui a servi à faire les maquettes est disponible ici : production...spike-prescripteurs
Une première PR pour cette branche pourrait implémenter tous les écrans présentés ici, à l'exception du lien sur la page connexion. Ça permettrait de paralléliser le travail avec les issues #3034 et #3035, et de faciliter le lancement en douceur en ajoutant ce lien dans le cadre de #3037
The text was updated successfully, but these errors were encountered: